top of page

Redirect chains build up quietly over every site rebuild

  • Aug 29
  • 3 min read

Updated: 2 days ago

Introduction


A page moved during a rebuild in 2019. It moved again when the services were reorganised, and once more when the site changed platform. Each time, a redirect was added from the old address to the new one.

The link on somebody else's site still points at the 2019 address. Following it now means three separate hops before anything appears. It works, slowly, until one of those middle redirects is removed during the next tidy-up and the whole path collapses into an error.


1. Redirect chains are what happens when nobody cleans up


Understand how they form.

Each individual change is correct in isolation, and the person making it points the old address at the current one without checking what already pointed at the old address. Chains are a consequence of correct decisions made without a full picture.


2. Know why they matter beyond tidiness


Three real costs.

Each hop adds delay before anything renders, each hop is a chance for something to break, and long chains may not be followed to the end. The first cost is felt by every visitor who arrives via an old link.


3. Find them with a crawler


Detection is mechanical.

A crawl of your own site reports internal links that pass through a redirect and how many hops each takes. Adding your list of known old addresses to the crawl surfaces the external paths as well.


4. Fix the source link, not just the chain


The step that actually resolves it.

If your own pages link to an address that redirects, update the link to point directly at the final destination. Shortening the chain helps external visitors; fixing your own links removes the problem entirely for internal traffic.


5. Collapse each chain to a single hop


The standard remedy for the rest.

Point every old address directly at the current final destination, rather than at the next address in the sequence. This keeps all the old links working while reducing every path to one redirect.


6. Keep the old redirects rather than deleting them


A common and damaging mistake.

Removing the 2019 address because nothing on your site uses it breaks every external link and bookmark still pointing there. The rule is to repoint old addresses, not to retire them.


7. Use permanent redirects unless the move is temporary


The type carries meaning.

A permanent redirect tells search engines the move is settled and consolidates the page's history onto the new address. Temporary redirects left in place for years keep signals split between two addresses indefinitely.


8. Watch for loops


The failure mode that takes a page down completely.

Two redirects pointing at each other produce a page that never loads at all. These usually appear after a bulk edit, and a crawl reports them immediately, which is one reason to run the crawl after every change rather than before.


9. Audit after every migration


The moment chains are created in bulk.

A platform change or restructure generates dozens of redirects at once, frequently on top of the previous set. A crawl in the week after the migration catches them while the context is still fresh in somebody's memory.

Keep a single record of every redirect in one place, with the date and reason. Sites accumulate these in server configuration, platform settings and plugins simultaneously, and the conflicts between them are far harder to diagnose than the chains themselves.


Conclusion


Recognise that chains form from individually correct decisions made without seeing what already pointed at the old address.

Fix them because of the delay, the fragility and the risk that long paths are not followed, detect them with a crawl that includes your known old addresses, update your own links to the final destination rather than merely shortening the chain, repoint every old address directly at the current page, never delete old redirects because external links still use them, use permanent redirects for settled moves, watch for loops that take pages down entirely, audit after every migration, and keep one central record of what redirects where and why.


Related reading


 
 
 

Comments


bottom of page