Redirect Chain

A redirect chain is a URL that reaches its destination through multiple redirect hops instead of one — A 301s to B, B 301s to C, C finally serves the page. Every extra hop adds a full network round trip for users, burns crawl requests for bots, and past ten hops Googlebot simply gives up and reports a redirect error, meaning the destination never gets crawled through that path at all.

Watch a chain happen, hop by hop

curl -IL shows you exactly what a browser and a bot experience. Here's a genuinely common four-hop chain — the kind that accretes when a site adds HTTPS, then www, then a trailing-slash rule, each in a different config file over several years:

$ curl -sIL http://example.com/old-page

HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page        <- hop 1: protocol

HTTP/2 301
location: https://www.example.com/old-page    <- hop 2: hostname

HTTP/2 301
location: https://www.example.com/old-page/   <- hop 3: trailing slash

HTTP/2 301
location: https://www.example.com/new-page/   <- hop 4: the actual move

HTTP/2 200

Four round trips to serve one page. Each rule is individually reasonable; the chain exists because nobody ever tested the combination. The fix is one rule for the canonical form (protocol + host + slash in a single redirect) plus updating the old-page mapping to point directly at the final URL — collapsing four hops to one. The deeper why-and-how, including chains created by stacked site migrations, is covered in this site's main article on redirect chains and loops.

Hop count: impact and fix priority

Not every chain deserves a ticket. Prioritize by hop count and traffic:

One nuance worth stating plainly: a 301 passes its signals fine, and a two-hop chain isn't an emergency. Chains matter in aggregate (crawl waste across thousands of URLs) and at the extremes (latency on traffic pages, the ten-hop cliff), not as a per-URL panic.

How to check it on your own site

1. Crawl with Screaming Frog → Reports → Redirects → Redirect chains. You get source, every hop, final status, and hop count in one export. Sitebulb and Semrush Site Audit produce equivalents.
2. Spot-check the patterns that generate 90% of chains: run curl -sIL against your four base variants — http://site.com, http://www.site.com, https://site.com, https://www.site.com — each of the four should reach the canonical one in a single hop.
3. Test your internal links, not just your redirects. Filter the crawl for internal links whose target returns 301. Every one of those is a chain you're creating on purpose; update the href to the final URL. (Chains also hide in JavaScript redirects, which crawlers only see with rendering enabled.)
4. Check your redirect map after every migration: old URLs must point at the current final URL, not at the intermediate URL from the previous migration. This is where multi-migration sites accumulate their worst chains.
5. Re-test in PageSpeed Insights for landing pages — chained redirects show up directly in the avoid multiple page redirects check, with the latency cost quantified.

Common audit mistakes

• Reporting every 2-hop chain as critical. It buries the ten URLs that matter under four thousand that don't. Weight by hops × traffic × backlinks.
• Flattening chains by deleting the old redirects. Those middle URLs may still have backlinks and bookmarks. Repoint every hop directly at the final destination; delete nothing until logs show zero traffic.
• Fixing the redirects but not the internal links. If your nav still links to the pre-migration URL, you've kept a permanent one-hop tax on every page view and left the chain ready to regrow.
• Ignoring mixed-status chains. A 302 in the middle of a 301 chain, or a chain ending in a 404, changes the story entirely — the status codes along the path matter as much as the count. Reference: HTTP status codes for SEO.
• Auditing only the HTML. Chains on images, CSS, and JS waste crawl and slow rendering too, and image chains have caused real indexing failures.

FAQ

Do redirect chains lose PageRank at each hop?

Google has said for years that 301s pass full signal and chains of a few hops consolidate fine. The measurable costs are latency, crawl waste, slower consolidation, and the hard stop near ten hops — reason enough to flatten without inventing a decay percentage.

How many hops will Googlebot follow?

Up to ten within a crawl session (documented in Search Central's redirect guidelines); beyond that, Search Console shows "Redirect error" and the final URL isn't reached through that path.

What's the difference between a redirect chain and a redirect loop?

A chain resolves — inefficiently, but you land on a page. A redirect loop circles back on itself and never resolves, which turns an efficiency problem into an availability outage.

Should I fix chains on URLs that get no traffic?

Batch-fix them when you're already editing the redirect config, since the marginal cost is near zero — but they never outrank a chained URL that has backlinks or ad spend pointed at it.

Can a CDN or plugin create chains I didn't write?

Constantly. Cloudflare rules, WordPress redirect plugins, .htaccess, and app-level logic each add hops independently, and none of them knows the others exist. That's why testing with curl -IL against production beats reading any single config file.