Redirect Chains: How They Happen, What They Cost, How to Flatten Them

A redirect chain is the rare technical defect that hides behind a green light. Type the URL, get the page, status 200 — every ordinary test passes, because every ordinary HTTP client follows the whole chain silently and reports only where it landed. The hops in between exist, they are billed on every fetch, and nothing in a browser tells you how many there were.

A useful redirect finding shows the entry URL, intermediate destinations and final page. That record lets the responsible team decide which rule should send the original request directly to the intended destination. The observation is also easy to verify after a repair: inspect the sequence again and compare it with the saved path.

A 4-hop chain assembles from 4 separate correct decisions

Chains accrete one layer at a time, and each layer earns its place when it lands:

1. TLS lands. Someone adds an edge rule sending http:// to https://. The intended destination now uses HTTPS.
2. A canonical host is chosen. The team standardizes on www, so the apex redirects to it. The sibling hostname should lead to the same intended destination.
3. Trailing slashes get normalized. A framework or CDN default adds a rule appending or stripping the final slash. Published links and sitemap entries should use the intended style consistently.
4. Internationalization ships. Root paths start routing to a locale prefix, /blog/ to /en/blog/. Localized pages need distinct stable URLs, although a redirect from the root is a site-design choice.

That is 4 correct rules, and now http://example.com/blog reaches its destination through 4 redirects. A CMS migration that rewrites /blog/* to /articles/* adds a 5th without touching any of the first 4, because it is implemented in the application while the others live in the edge, the web server, and the router. The rules fire in the order the request traverses the stack, not in the order that would resolve the URL fastest. Nobody owns the composition.

This is also why the http-to-https result in our own data has to be read carefully. Between May 23 and August 31, 2026, HTTP-to-HTTPS normalization was flagged on 44% of 171 evaluations but only 8% of 48 distinct sites. The site-level 8% is the prevalence figure; the evaluation figure describes our observations, not the web. A check is evaluated every time an audit runs, so a handful of sites audited repeatedly while the defect persisted contribute many failing evaluations each, and they pull the evaluation rate far above the share of sites affected. Quoting the 44% as "44% of sites" would overstate prevalence by more than a factor of 5.

Google follows up to 10 hops and advises you stay under 5

The hop budget is documented, not folklore. Google's crawling documentation states that by default its crawlers follow up to 10 redirect hops, and notes that individual products differ — Google's own Inspection Tools do not follow redirects at all. The site-migration guidance is more pointed: Googlebot can follow up to 10 hops, but "we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5." The crawl-budget documentation reduces it to one line: avoid long redirect chains, which have a negative effect on crawling.

The cost divides into 3 parts, and they carry unequal weight:

Crawl efficiency. Each hop is a request Google's crawler spends without receiving content — the documentation is explicit that content returned by a redirecting URL is ignored and only the final target's content is processed. On a site of a few hundred URLs this is noise. On a site where the chain sits in the URL pattern every internal link uses, it multiplies across the whole crawl and competes with the crawl capacity limit the same host is already subject to.

Latency, on every uncached fetch. A hop is a full round trip: DNS may already be warm, but connection reuse ends the moment a hop changes host, which the example.com to www.example.com step does by definition. Users feel this once and then stop feeling it, because browsers cache permanent redirects. Machines fetching cold, without a warm cache, feel it every time.

Signal consolidation, which is where the folklore lives. The old claim is that each hop bleeds a percentage of link equity. Google contradicted it publicly in July 2016, when Gary Illyes stated flatly that 30x redirects do not lose PageRank, clarifying what John Mueller had already said about http-to-https moves earlier that year. The durable version of the concern is narrower and still real: a 301 is the strongest available canonicalization signal, and the value of a redirect is that it names one destination unambiguously. A chain still names one destination, so the equity argument is the weakest of the 3 reasons to flatten. Crawl efficiency and latency carry the case.

AI fetchers and agents handle chains less forgivingly than browsers

Browsers are the most permissive redirect clients a site will ever be tested with. They follow long chains without comment, cache permanent redirects aggressively, and present the destination as though it were the URL requested. Programmatic clients — the layer that AI assistants, retrieval pipelines, and agents actually fetch through — vary in ways a browser test cannot reveal.

curl follows nothing at all without -L; a chain returns a bare 301 and an empty body. Library HTTP clients each pick their own hop ceiling and their own default for whether to follow at all, and those defaults are set by whoever wrote the fetching code, not by the site. Spec-compliant clients drop credentials when a redirect crosses origins, which is precisely what an apex-to-www hop does. Method semantics shift too: 301 and 302 have a long history of rewriting a POST into a GET, while 307 and 308 preserve the original method — a distinction that matters the moment an agent is submitting rather than reading.

Add the budget constraint. A summarizer or agent working a page under a time limit spends part of it on hops that return no content, and a fetch that exceeds an internal hop cap looks identical to a site that is down. The chain does not report itself as a chain; it reports as an empty result. That is the same failure shape as the directive conflicts in our indexability data — the site works for people and quietly declines to work for machines.

Flatten in 4 steps: inventory, collapse, relink, keep the map

1. Inventory the real hop counts. Measure, do not reason about the config. For a single URL:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

The first line gives the count, the second the path. Run it against http:// and https:// forms, apex and www, with and without a trailing slash, and against a representative URL from each template — the chain usually lives in a pattern, not a page. An audit does the same walk on the homepage, the canonical target, and the alternate host in one pass, and reports the traced path as evidence.

2. Collapse each chain to a single 301. Take the entry URL and the final destination from the inventory and write one rule that maps the first directly to the last, at the outermost layer that can see both — usually the edge or CDN. Then retire the intermediate rules the chain was composed from, rather than leaving them in place behind the new one. Use 301 for a permanent move, and 308 when the method must survive. The target must be a 200 that declares itself canonical; a redirect landing on a page whose canonical points elsewhere restarts the ambiguity in a different vocabulary, which is the interaction our canonical tags guide works through.

3. Point internal links at final URLs. A flattened rule still costs a hop on every internal link that names the old URL. Sitemaps, navigation, hreflang annotations, canonical tags, and in-body links should all reference the destination directly, so the redirect exists only for external inbound links and old bookmarks. This step is what converts a config fix into a crawl-efficiency gain.

4. Keep the chain map. Record every retired rule, its entry URL, and its final destination in one file that lives with the infrastructure config. Chains re-form because the next person to add a locale prefix or migrate a path scheme has no way to see the 4 rules already in the request path. The map is what makes the composition visible to whoever ships layer 5, and it is the input to the next inventory. The full check-by-check treatment lives in our redirects and URL normalization guide.

A flattened redirect layer is one of the few technical improvements with no content dependency, no ranking lag, and a verification step that takes a single command. It stays broken on so many sites because no test anyone runs by hand reports the hops. Once a trace is part of the audit, the seam between 4 teams' correct decisions becomes a finding with a path, a status per hop, and one rule to write.