Every redirect hop costs you speed, PageRank, and crawl...

A redirect chain is what happens when URL A redirects to URL B, which redirects to URL C, which finally lands on URL D. Each hop adds a full HTTP round trip. On a fast server, that's 50-100ms per hop. On a typical shared hosting setup, it's 150-300ms. A 4-hop chain adds half a second to a second of pure waiting time before the browser even starts loading the destination page.

But the performance cost isn't the worst part. Each hop in a redirect chain dilutes the PageRank flowing through it. Google has confirmed that 301 redirects pass PageRank, but in practice, multi-hop chains pass less equity than a direct link. And every hop consumes crawl budget. Googlebot has a finite number of URLs it will crawl per visit, and spending three of those on redirect hops instead of real content means three fewer pages discovered per crawl session.

How chains accumulate

Redirect chains almost never get created intentionally. They accumulate over time through a sequence of individually reasonable decisions.

Year one: you move a page from /services to /our-services. You create a 301 redirect. Year two: you rebrand and move /our-services to /solutions. You create another 301 redirect from /our-services to /solutions, not realizing that /services still redirects to /our-services. Now /services is a 2-hop chain. Year three: you add HTTPS and your server redirects http:// to https://. Now the original HTTP link to /services is a 3-hop chain: HTTP to HTTPS, /services to /our-services, /our-services to /solutions.

Domain changes compound this further. If you also changed from www to non-www (or vice versa) at some point, that's another hop. A link from 2019 pointing to http://www.yoursite.com/services might now traverse four redirects before landing on https://yoursite.com/solutions.

CMS migrations are particularly bad. WordPress to Shopify, Squarespace to custom, Wix to anything. Each platform has its own URL structure, and the migration typically creates redirects from old URLs to new ones. If you've migrated twice, old links from your first platform pass through two sets of migration redirects.

What Google says about chains

Google's official guidance is to minimize redirect chains and ideally point every redirect directly to the final destination. John Mueller has said that Googlebot will follow redirect chains up to about 5 hops but "it's not great" and that having direct redirects is better for crawl efficiency.

In practice, very long chains (5+ hops) may be abandoned entirely by crawlers. The inbound link equity from that old backlink pointing to your original URL? It evaporates at hop 5 instead of reaching your current page. Meanwhile, you can't see this happening because the redirect still works fine in a browser. Chrome will follow 20 redirects before giving up. The problem is invisible to humans and only affects crawlers and link equity.

Mixed redirect types within a chain create additional problems. A chain that goes 302 (temporary) then 301 (permanent) sends conflicting signals about whether the move is final. Googlebot may choose not to pass PageRank through a 302, breaking the equity flow even if the chain length is short.

The meta refresh problem

HTTP redirects aren't the only kind. Some pages use <meta http-equiv="refresh" content="0;url=/new-page"> in the HTML head. These are slower than server-side redirects (the browser has to download the HTML before it sees the redirect instruction) and search engines treat them differently. A meta refresh with a delay of 0 is treated roughly like a 301 by Google, but with a delay of 5 seconds or more, it's treated as a soft redirect that doesn't pass PageRank.

Old CMS platforms and manual HTML edits sometimes leave meta refreshes behind. They're particularly hard to spot because they don't show up in server logs as redirects. The server returns a 200 OK with the meta refresh in the body.

What the audit checks

The Redirect Chain Audit takes a bulk list of URLs and follows the full hop chain for each one. It reports every hop, the status code (301, 302, 307, meta refresh), the final destination URL, and flags chains longer than 2 hops that are likely leaking PageRank.

It also catches mixed HTTP/HTTPS hops, canonical URL mismatches (where the final destination's canonical tag points somewhere else, creating a loop), and meta refresh chains that are invisible to standard redirect checkers.

Use this alongside the Broken Link Decay Scanner to find links that end in errors after traversing redirect chains, and the Canonical Cluster Conflict tool to check whether your redirects and canonicals agree on the final destination.

In The $97 Launch, I talk about the hidden friction that accumulates in a site over time. Redirect chains are exactly that kind of friction: invisible, gradual, and compounding. Every old link to your site that passes through a 4-hop chain is working at a fraction of its potential.

Fact-check notes and sources

Google follows up to 5 redirect hops but recommends minimizing chains. Source: John Mueller, Google Search Central Hangout, 2019.
301 redirects pass PageRank. Source: Google's Gary Illyes confirmed on Twitter/X in 2016 that 30x redirects no longer cause PageRank loss (for a single hop). Multi-hop dilution is observed empirically but not confirmed numerically by Google.
Chrome follows up to 20 redirects before failing. Source: Chromium source code, net::URLRequest::kMaxRedirects = 20.
Meta refresh with 0 delay treated as a permanent redirect by Google; delays of 5+ seconds treated as soft redirects. Source: Google Search Central documentation.

Every redirect hop costs you speed, PageRank, and crawl budget