Redirect Chains and SEO: What Actually Breaks, and When

Redirect chains get treated as an emergency in most audit reports, usually with a line about lost link equity. The evidence for that panic is weaker than the reports suggest, and the actual damage sits somewhere else entirely.

Google's own documentation states that Googlebot follows up to 10 redirect hops in a single crawl attempt before giving up and treating the URL as an error. A chain of two or three hops resolves without drama. The costs that matter are latency for the human waiting on the page, crawl budget spent re-resolving destinations you already know, and the loop that forms when a third migration stacks rules on top of two earlier ones.

Below: what a chain actually costs, when it crosses into real damage, and how to remove one so it stays removed.

What a Redirect Chain Costs, Measured Honestly

A chain is any sequence where URL A redirects to B, which redirects to C. The browser follows each hop in turn, and so does a crawler.

Google's redirect guidance for Search states that Googlebot follows up to 10 hops in one crawl attempt. Beyond that it reports an error and the destination goes uncrawled. That ceiling matters for a specific reason: it means the common two-to-four hop chain is not a ranking emergency, and treating it as one wastes an audit's credibility on a finding the client can verify is overstated.

Googlebot follows up to 10 redirect hops in a single crawl attempt. Past that limit it reports a redirect error and the destination is not crawled on that attempt.

— Google Search Central, redirects and Google Search documentation

What the chain does cost is concrete:

Cost	Who absorbs it	Scale of impact
Latency per hop	The visitor	Each hop is a full DNS + TCP + TLS round trip; on mobile networks this compounds fast
Crawl budget	Large sites	Every hop is a request; on a 50,000-URL site with widespread chains this is meaningful
Debugging time	Your team	Chains obscure which rule is actually firing, so the next migration is harder
Signal consolidation	Rarely anyone	Google has stated PageRank is not lost through 30x redirects

That last row is where most audit reports overreach. Google has repeatedly stated that no PageRank is lost through 301 or 302 redirects. Writing "your chains are leaking link equity" into a client report puts a claim in writing that the client's developer can disprove in one search, and the rest of the report inherits that doubt.

When Chains Turn Into Real Damage

Three situations move a chain from housekeeping to urgent.

The chain closes into a loop. A redirects to B, B redirects back to A. Now nothing resolves — not for crawlers, not for users. Loops are almost never authored deliberately; they emerge when a new rule is added without auditing the existing set. A site that has been through three platform migrations typically carries rules from all three, and the fourth migration is where they collide.

The chain crosses a protocol or host boundary more than once. The classic pattern is http://example.com → https://example.com → https://www.example.com → https://www.example.com/. Four hops to load a homepage, each one a full round trip. This is the single most common chain on the web and the easiest to collapse: one rule that jumps straight from the first URL to the last. Getting HTTPS canonicalization right at the same time is covered in the HTTPS migration guide.

The chain ends somewhere unintended. Chains hide their destination. A rule written years ago sends a retired category to a page that has itself since been retired, and the visitor lands on a 404 after three hops — or worse, on an unrelated page that happens to still resolve. Nobody notices, because the intermediate hops all return a healthy 301.

A fourth pattern deserves its own mention because it hides from most crawlers: the chain that only appears for some visitors. Geographic routing, language detection, and mobile-specific rules can each add a hop that a desktop crawl from one country never sees. If a site serves multiple regions, request a sample of URLs with different Accept-Language headers and from different locations before concluding the redirect map is clean.

Collapsing a Chain So It Stays Collapsed

The repair itself is trivial. Making it survive the next deploy is the part that takes discipline.

1. Map the full chain before touching anything. Request the source URL with redirects disabled and record each hop and its status code. curl -sIL https://example.com/old-page prints the whole sequence. Do this for a representative sample rather than the whole site — chains cluster by rule, so twenty URLs usually reveal every distinct pattern you have.

2. Rewrite the source to point at the final destination. Not the next hop — the last one. A chain of four collapses to a single 301 from the original URL to the live page. Leave the intermediate rules in place if other URLs still depend on them; removing a rule that something else feeds is how you turn a chain into a 404.

3. Order the rules so the general case cannot swallow the specific one. Most regenerated chains come from rule ordering. A broad pattern placed above a specific rewrite fires first, sends the request somewhere generic, and the specific rule catches it on the second pass — producing exactly the hop you just removed. Specific rules go above general ones.

4. Re-crawl and confirm. This step gets skipped, which is why chains reappear. After deploying, re-request the same sample and verify each returns a single hop to a 200. Fixing a chain and never re-checking it means finding it again in the next audit and telling the client it came back, which is a worse conversation than the first one. Findings that carry their own verification state make this loop cheaper to run — the canonical versus 301 comparison covers which tool belongs on each URL before you start rewriting rules.

The illustrative MendMySEO demo shows evidence-backed findings and comparable re-scan states; it is not a promise that every redirect chain is production-covered. Review the current release status — commercial access remains evidence-gated.

Frequently Asked Questions

How many redirects in a row is too many?

Googlebot follows up to 10 hops per crawl attempt, so that is the hard ceiling. The practical target is one. Two is acceptable during a migration window. Three or more on a permanent basis means a rule set nobody has audited recently, and the risk is less about the current chain than about what the next rule added to that set will do.

Do redirect chains lose link equity?

Google has stated that PageRank is not lost through 30x redirects. The costs are latency, crawl budget, and maintainability rather than signal leakage. Audit reports that claim equity loss are repeating an older belief, and a technically literate client will notice.

Is a redirect chain worse than a redirect loop?

A loop is categorically worse. A chain still resolves — visitors and crawlers reach the destination, just slowly. A loop never resolves, so the page is unreachable for everyone and effectively removed from the index. Any loop is a same-day fix; a three-hop chain can wait for the next sprint.

Should I fix redirect chains before or after a site migration?

Before, without exception. Migrations layer new rules on top of whatever exists, so an unaudited chain becomes a longer chain or a loop the moment the new rules land. Cleaning the existing set first also gives you a much shorter list to verify afterwards.

How do I find redirect chains across a whole site?

Any crawler that records the hop sequence rather than just the final status will surface them. What matters more than the tool is that the output shows each intermediate URL — a report saying "312 URLs have chains" is not actionable, while one showing the four-hop sequence tells you which rule to rewrite.