Redirect Chain (Multiple Hops)

What’s actually happening

The page does eventually load, so it's easy to miss — but it takes three or four hops to get there. curl -IL prints a stack of 301s before the final 200. Each hop is a round trip, so mobile users on slow connections feel the lag, and crawlers spend extra budget walking the chain instead of indexing real pages. Link equity also leaks a little with every hop. Unlike a loop, a chain terminates; it's just inefficient.

Common causes

• Redirects stacked over time — http://a to https://a to https://b to https://b/ — each migration adding a hop instead of updating the original.
• A site migration that redirected old to interim to new without collapsing the steps.
• www to non-www and http to https handled as separate sequential rules rather than one combined redirect.
• An old 301 pointing at a URL that has since been redirected again, extending the chain.
• Trailing-slash normalization firing as its own extra hop after a protocol or host redirect.

How to fix it

1. Map the full chaincurl -IL https://example.com/url shows every hop and the final destination. Note the start URL and the final 200 URL — everything in between is removable.
2. Point each source straight at the final URLRewrite the first redirect so the original URL 301s directly to the final destination in one hop. Update the rule at the source, don't add another redirect on top.
3. Combine host and protocol rulesHandle http to https and www to non-www in a single redirect to the canonical host+protocol, so you don't pay two hops for what should be one.
4. Update internal links to the destinationChange internal hrefs and sitemap entries to point at the final URL, so your own pages never trigger the redirect at all. Reserve redirects for inbound external links you don't control.
5. Recrawl to verify single hopsAfter collapsing, recrawl and confirm every redirect resolves in one hop with no chain — and that you didn't accidentally create a loop.