Redirect Chains Are Stealing Your Speed and Your Link Equity

A redirect is a tax you pay on every request

A single 301 is fine. It is the honest way to tell a browser and a crawler "this thing moved here." The problem is that redirects accumulate. You move /products to /shop in 2021. You move /shop to /store in 2023. You consolidate HTTP to HTTPS and drop the trailing slash somewhere in between. Nobody ever updates the original rule, so a link to the 2021 URL now bounces /products → /shop → /store → https://store before anything renders. Each migration was reasonable in isolation; the chain is what nobody designed and nobody owns.

Each of those hops is not free. It is a separate HTTP request: a DNS lookup (sometimes), a TCP handshake, a TLS negotiation, and a server round trip, before the browser even learns where to go next. On a mobile connection with 150ms of round-trip latency, three needless hops can add the better part of a second to Time to First Byte, and TTFB is the foundation every other performance metric is built on. As the Core Web Vitals reference on TTFB makes clear, a slow first byte pushes the entire LCP timeline later, and redirect chains are pure, avoidable first-byte delay. You can have a perfectly optimized page and still post a terrible LCP simply because the browser spent 900ms bouncing through redirects before it ever requested your HTML.

The link-equity leak nobody budgets for

The "do 301s pass full PageRank?" debate has gone back and forth for a decade, and Google's public statements have softened over time. But the practical SEO consensus, backed by crawl-efficiency research, is that chains measurably underperform direct redirects. The crawl-efficiency analysis from Metrics Rule found that chains longer than two hops measurably reduce crawl efficiency and transfer less equity than a single direct 301, and that as round-trip time climbs past 500ms the probability of effective equity transfer drops sharply.

The mechanism is simple. A crawler has a finite budget for your site. Every hop it follows is work it is not spending discovering and indexing real content. Beyond a few hops it may stop following entirely, and according to the redirect chain technical guide from Digital Thrive, Google typically follows up to about 5 hops and at most 10 before abandoning the URL, meaning the destination may never get indexed at all. The backlinks pointing at your old URL then anchor to a page Google has effectively given up on reaching. You paid for those links, in content, in outreach, in time, and a redirect chain is quietly discounting their value.

There is a second, subtler cost: chains make your redirect logic fragile. The more hops, the more places a single misconfiguration can create a loop (A → B → A), which returns a ERR_TOO_MANY_REDIRECTS error and takes the page fully offline. Long chains are not just slow; they are a reliability liability waiting for the wrong combination of rules.

AI crawlers are even less patient

The redirect problem just got worse, because a new class of crawler now matters. AI answer engines, the bots behind ChatGPT, Perplexity, and Google's AI overviews, impose tighter timeout and hop budgets than traditional search crawlers. A chain that Googlebot grudgingly follows may cause an LLM crawler to time out and skip your page entirely, erasing you from AI-generated answers. If you care about being cited in AI results, and the channel is growing fast, any chain beyond a single hop is a fix priority, not a nice-to-have. The AI crawler that gives up at your second hop does not leave an error in your logs; it simply never mentions you in the answer a buyer reads.

Find the chains you cannot see

The reason redirect chains persist is that they are invisible in normal use. A human clicks a link and lands on the right page; the three hops in between are imperceptible at desktop speeds. You only find chains by tracing the full redirect path of every URL. The raw mechanic looks like this:

# Trace the full redirect chain for a URL with curl
$ curl -sIL -o /dev/null -w '%{http_code} %{time_total}s %{num_redirects} hops\n' \
    https://example.com/products
301 0.847s 3 hops          # <-- three round trips before a 200

# Or follow each hop explicitly to see the path:
$ curl -sI https://example.com/products | grep -i '^location'
location: https://example.com/shop
# repeat against /shop, then /store ... each line is one wasted round trip

Doing that by hand for one URL is easy. Doing it for 40,000 URLs, and knowing which chains carry inbound links worth saving, is what a scan is for. The output you want is a table of every multi-hop chain, its total latency, the number of hops, and whether the source URL has external backlinks pointing at it.

Collapse, don't extend

The fix is mechanically trivial and operationally disciplined: every redirect should point directly at the final destination, never at another redirect. When you migrate /shop to /store, you do not just add a new rule, you rewrite the old /products → /shop rule to become /products → /store. Flatten the whole tree to one hop.

# BAD, a chain that grows with every migration
RewriteRule ^products$       /shop   [R=301, L]
RewriteRule ^shop$           /store  [R=301, L]

# GOOD, every legacy URL points straight at the live destination
RewriteRule ^products$       /store  [R=301, L]
RewriteRule ^shop$           /store  [R=301, L]

# And handle protocol/host normalization in ONE rule, not a separate hop
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301, L]

Watch out for the classic accidental chain: a separate rule that forces HTTPS and another that forces (or strips) www, applied one after another, turns every single request into a two-hop chain even when the path is correct. This is the most common chain on the web, and it affects every page, not just migrated ones. Combine protocol and host normalization into one redirect so you never stack them. Best practice, per Search Engine Land's redirect guide, is a maximum of one hop and total redirect response time under a couple hundred milliseconds.

Maintain a redirect map as data, not as scattered rules

The reason chains regrow is that redirect rules live in a dozen places, server config, CDN edge rules, application middleware, CMS plugins, and no single source of truth shows the full path. Keep your redirects in one authoritative map (a flat list of source → final-destination) and generate the server rules from it, so adding a new redirect can automatically resolve any chain it would create.

# A flat redirect map, resolve to FINAL destination at build time
const RAW = {
  '/products': '/shop',
  '/shop':     '/store',
  '/store':    '/store',   // terminal
};
function resolve(path, seen = new Set()) {
  if (seen.has(path)) throw new Error(`Redirect loop at ${path}`);
  seen.add(path);
  const next = RAW[path];
  return (!next || next === path) ? path : resolve(next, seen);
}
// Emit one-hop rules: every source jumps straight to the terminal URL
for (const src of Object.keys(RAW)) console.log(src, '->', resolve(src));
// /products -> /store   /shop -> /store   (no chains, loop-safe)

Keep them flat after launch

Redirect chains are not a one-time cleanup; they regrow. Every campaign that points a vanity URL at a page that later moves, every CMS that auto-creates a redirect when you rename a slug, every internal link still pointing at an old URL, all of it reintroduces hops. The durable fix is to make chain detection continuous: re-scan after every migration, every CMS upgrade, and on a regular cadence, and treat any chain over one hop as a defect to be flattened.

It is also worth fixing the source of the chains, not just the chains themselves. Update internal links to point at final URLs directly so your own navigation never triggers a redirect, internal links going through redirects waste crawl budget on pages Google already knows about. Crawl your sitemap and confirm every entry returns 200, not 301; a sitemap full of redirecting URLs tells Google you do not maintain your own canonical list. A clean redirect map plus clean internal links means crawlers spend their budget on your content and your link equity arrives intact.

The bottom line

Redirect chains are a slow, silent tax on both speed and authority. Each hop adds a network round trip that inflates TTFB and LCP, and each hop leaks roughly 5% of the link equity you paid to build, while AI crawlers may abandon the chain entirely and drop you from answers. The fixes are simple: flatten every chain to a single direct hop, combine protocol and host normalization, maintain redirects as a loop-safe map that always resolves to the final destination, point internal links at final URLs, and re-scan after every migration. The hard part is finding the chains in the first place, because they are invisible until you trace every URL's full path. That tracing, across your whole site, ranked by the links and traffic at stake, is exactly the job for a scan.