What is a redirect chain?
A redirect chain exists when one URL redirects to another URL that redirects again. A visitor starting at A may travel through B and C before finally reaching D. The page can still appear to work, which is why chains survive unnoticed.
Every hop is another HTTP exchange: resolve or reuse a connection, send a request, wait for the response, read the next location, and repeat. The exact cost varies with the network and connection reuse, but the direction is always the same — more hops mean more work.
Why redirect chains form
Most chains are a history of reasonable decisions. A page moves during one redesign, its section is renamed a year later, and the domain changes after that. If each project adds a redirect without revisiting old rules, the route records the entire history.
Chains also appear when several layers each normalize one part of a URL. The CDN adds HTTPS, the web server adds www, the application removes a trailing slash, and the CMS changes the slug. Each layer sees its own rule as small, while the visitor sees four requests.
Internal links are another source. A template may still link to an old URL even though a redirect makes it look fine in the browser. The site then sends every visitor and crawler through an avoidable hop.
How chains affect performance and SEO
They add latency before useful content
The browser cannot request the final page until it learns each next address. On a fast desktop connection the delay may be modest. On a mobile network, across regions, or when a new TLS connection is required, it becomes more noticeable.
They create more points of failure
Any hostname, certificate, rule, or service in the middle can fail. An old domain that expires can break every chain that still depends on it even if the final site is healthy.
They spend crawl effort on routing
Crawlers can follow redirects, but repeated hops consume requests that could be spent on current pages. A direct information architecture also gives search systems a clearer, more consistent set of canonical URLs.
They make signals harder to keep aligned
Sitemaps, canonical tags, hreflang references, navigation, and backlinks may point at different stages of a chain. That inconsistency makes migrations harder to audit and maintain.
How to find redirect chains
- Start with URLs from old sitemaps, migration maps, analytics landing pages, backlink reports, campaign archives, and server logs.
- Check each important URL with the Redirect Where route inspector.
- Flag any route with more than one redirect. Also flag a final 4xx or 5xx response, even if the chain itself is short.
- Compare the final destination with the intended canonical URL. A short route to the wrong page still needs repair.
- Crawl your current site for internal links that return 3xx responses. Those links can usually be updated directly.
Prioritize by exposure. Navigation and template links affect many pages. High-traffic landing pages and strong backlinks deserve attention before obscure historical URLs.
How to replace a chain with a direct route
Build a map with two columns: every known retired URL and its one current destination. Then change the earliest rule so it skips intermediate addresses. Keep rules for B and C if those URLs are independently used, but point each of them directly to D as well.
| Before | After |
|---|---|
| A → B → C → D | A → D |
| B → C → D | B → D |
| C → D | C → D |
Coordinate URL normalization in one place when possible. If the edge or CDN can handle HTTPS, hostname, and slash normalization in a single response, avoid repeating those concerns in the application.
After changing rules, clear relevant caches and test every entry point again. Pay particular attention to relative paths, query strings, locale prefixes, and URL-encoded characters. Do not delete a historical redirect merely because it is old; remove the intermediate hop while preserving useful inbound paths.
Redirect checklist for a site migration
- Export the old site’s indexable URLs before the move.
- Map each valuable old URL to the closest new equivalent.
- Return 301 or 308 for permanent moves and avoid blanket homepage redirects.
- Point rules directly to final HTTPS canonical URLs.
- Update internal links, canonical tags, hreflang, and sitemaps.
- Keep the old hostname and its valid certificate operating while redirects are needed.
- Monitor 404s and unexpected redirect paths after launch.
- Recheck a representative sample after CDN, CMS, or server configuration changes.
The best redirect map is boring: one old address, one relevant current address, one permanent hop. That simplicity is exactly what makes it resilient.