A redirect chain is a URL that redirects to another URL that redirects again before reaching a final destination. Each hop works, so nothing appears broken, which is why chains persist for years and grow quietly with every site change.
Why they matter
- Each hop is a request. Two or three add measurable latency, particularly on mobile.
- Crawl capacity is consumed resolving hops rather than fetching pages.
- Long chains may not be followed all the way, at which point the destination is never reached.
- Diagnosis becomes harder, because the reported redirect target is not the final page.
- They compound. Every subsequent URL change adds another hop to existing chains rather than replacing them.
That last point is the real cost. A chain is not a fixed problem; it is a growing one.
How they form
Successive migrations
The commonest cause. Site A to site B, then B to C, with the original A redirects left pointing at B. Three migrations produce three-hop chains for the oldest URLs, which are frequently the ones with the most external links.
Protocol and www redirects stacked
http://example.com to https://example.com to https://www.example.com. Two hops where server configuration could resolve to the canonical form in one.
Trailing slash handling
A URL redirecting to add or remove a slash, then redirecting again for another reason. Common and easily missed.
Plugin and server rules both active
A redirect plugin and server-level rules each handling the same path. Each is correct alone and together they chain.
Bulk imports
Redirect maps imported without checking whether destinations are themselves redirected. This is how a migration creates chains on day one.
Finding and fixing them
- Crawl the site with redirect following enabled and report hop counts.
- Test old URLs specifically, particularly ones with external links, since those carry the most value.
- Point every redirect at its final destination rather than at the next hop.
- Resolve protocol and www in a single server-level rule.
- Consolidate to one redirect mechanism rather than running plugin and server rules together.
- Update internal links to point at final URLs, so internal paths do not traverse redirects at all.
Flattening is straightforward once identified. The work is in finding them, since nothing reports a chain as an error.
Frequently asked questions
How many hops is acceptable?
One. Two works and is worth flattening. Beyond three you risk the destination not being reached, and you are certainly wasting crawl capacity.
Do chains lose link equity?
Modern handling passes signals through hops, so the loss is smaller than once believed. The practical costs are latency, crawl waste and the risk of the chain growing.
Can I just remove the old redirects?
No. Removing them turns the URLs into 404s, which is worse than a chain. Repoint them at the final destination instead.
Do internal links matter here?
Considerably. Internal links pointing at redirected URLs make every internal path traverse a redirect. Update them to final destinations. See internal links and indexing.
Consulting CTA
If your site has migrated more than once, book an SEO consultation for a redirect audit. Chains accumulate silently across migrations.