A redirect chain happens when one URL redirects to another, which redirects to a third, which redirects to a fourth, before finally reaching a 200 response. Every hop in the chain is a separate request that costs crawl budget and adds latency for the user. The signal does not leak away hop by hop, but a chain long enough that Googlebot stops following it before the destination will keep that destination out of the index entirely.
Redirect chains accumulate over years, not in a single mistake. A site migrates URLs in 2018; the old URLs redirect to the new ones. It migrates again in 2021; the 2018 URLs now redirect to intermediate URLs that redirect again to the 2021 versions. The structure changes once more in 2024, and the 2018, 2021, and 2024 variants all point forward through each other rather than straight to the current URL. By the time anyone audits it, some legacy URLs pass through four or five hops before reaching content, and nobody remembers building the chain because each individual migration looked complete on its own.
This guide covers what chains actually cost, how to detect them at scale, and the cleanup patterns that reliably collapse them back to a single hop.
What a chain costs, and what it does not #
A 301 redirect tells search engines a URL has moved permanently. Google follows it, treats the destination as the indexable URL, and consolidates the ranking signals onto that destination. In a clean single-hop redirect this works exactly as designed:
/old-url -> 301 -> /new-url (200)In a chain, the same resolution happens at every hop:
/old-url -> 301 -> /intermediate -> 301 -> /another -> 301 -> /current (200)Here is where a common piece of advice needs correcting. You will still read that “each hop loses roughly 15 percent of link juice,” or that authority bleeds away a little at every step. That is a myth, and it has been for years. Gary Illyes stated in 2016 that 301, 302, and 30x redirects all pass PageRank with no dilution, and John Mueller has repeated since that “301s don’t lose value.” Google forwards the signal by using the redirect to pick a canonical and concentrating the signals of every URL in the chain onto that canonical. There is no per-hop percentage tax.
So chains are not a signal-loss problem. They are a crawl-efficiency, latency, and reliability problem, which is a different and more concrete set of costs:
| Consequence | Effect |
|---|---|
| Crawl budget consumption | Each hop is a separate request. A four-hop chain costs four requests where one would do, spent on redirect resolution instead of on real pages. |
| Slower user experience | Each hop adds latency before the browser lands on content, typically tens to a few hundred milliseconds per hop depending on where the redirect fires (edge or CDN redirects on the low end, application-layer or plugin redirects on the high end). |
| Crawl-limit risk | Googlebot follows up to about 10 redirects in a chain, then stops. A chain longer than that leaves the destination undiscovered and unindexed. |
| Mixed redirect types | Chains often mix 301 and 302. A 302 is treated as temporary, so the source URL may keep some of its own indexing weight instead of fully consolidating onto the destination. |
On a site with thousands of chains, the crawl waste and the user-facing latency add up. The ranking damage, when it appears, comes almost entirely from that last row: a chain so long the destination never gets crawled, not from a slow drip of lost authority.
Where chains come from #
Three patterns account for most of them.
Layered URL migrations are the leading cause. A site changes its URLs without updating the older redirects, so the 2018 rules still point at URLs that were themselves retired in 2021, which redirect again to 2024 URLs. Each migration adds a hop without removing the earlier ones.
CMS or platform changes produce the same effect through different plumbing. Moving from one platform to another routes the old URLs through the new platform’s redirect rules, and that logic often layers in its own hops for canonicalization, www handling, or trailing-slash normalization on top of the content-URL change.
Protocol and hostname inconsistency is the third source. A site with separate 301 rules for HTTP to HTTPS and for non-www to www can turn a single request into three hops: http://example.com/old-page redirects to the HTTPS version, then to the www version, then to the new content URL. Three hops to handle protocol, hostname, and content in sequence.
The patterns combine. A site that has been migrated a few times and also normalizes protocol and hostname can routinely produce five- to seven-hop chains that nobody noticed during any single migration.
Detecting chains at scale #
For a site under a few thousand URLs, manual spot-checking can work. Past that, you need tooling, and four sources cover the problem from complementary angles.
Screaming Frog SEO Spider is the workhorse. Its Redirect Chains report, under the Reports menu, lists every chain found during a crawl and shows each hop in sequence. It flags chains of two or more hops and lets you sort the longest to the top for triage.
Log file analysis shows what crawlers actually hit rather than what the crawl theoretically found. Looking at Googlebot’s real requests tells you which chains Google is genuinely resolving and how often, which is what you want to know before spending cleanup time.
Internal link audits catch where new chains get introduced from inside the site. An internal link pointing at a URL that redirects creates a hop for every user and crawler that follows it. The audit lists internal links with their HTTP statuses so links to redirecting URLs can be flagged and pointed at the destination directly.
Search Console’s Pages report gives the aggregate view. The Redirect category lists the URLs Google has classified as redirects, and the trend over time tells you whether the redirect count is stable, growing, or shrinking after cleanup.
No single tool is complete. Screaming Frog maps the structure but is bounded by crawl size; logs show real Googlebot behavior but need log access; internal link audits catch the source of new chains; Search Console shows the aggregate effect over time. A thorough cleanup draws on all four.
Cleaning up in priority order #
Not every chain deserves the same urgency. Work from most to least consequential.
- Chains near or over the follow limit. Anything approaching 10 hops risks Google stopping before the destination, which makes the URL effectively unreachable. Mueller has advised keeping frequently crawled URLs under about five hops as a practical safety margin, well short of the hard limit. These come first.
- Chains on high-traffic URLs. A chain on a page nobody visits is a small loss; a chain on a page that gets real clicks multiplies the latency cost across every visit. Search Console’s Performance report shows which URLs earn clicks.
- Chains on frequently crawled URLs. Log analysis shows which URLs Googlebot requests most. Chains on those burn crawl budget at a higher rate than chains on rarely touched URLs.
- Chains that internal links point through. Fixing the internal links and collapsing the chains in the same pass compounds the benefit, since users and crawlers both stop taking the detour.
- Everything remaining. Once the high-impact chains are collapsed, the rest can be cleared in bulk as maintenance.
The cleanup process #
The mechanical steps are straightforward. For a chain that runs A to B to C to D to E, where E returns 200, the goal is to make A redirect straight to E and drop B, C, and D as intermediate hops.
Start by identifying the true start and end of the chain. Then update the redirect rule for A so that it sends A directly to E instead of to B. The intermediate hops may still need to exist if other URLs redirect into them, but A no longer travels through them.
Verify the result: A should now be a single 301 to E, and E should return 200. Then check for siblings. If A was in a chain because of a 2021 migration, other URLs from that same migration are almost certainly in matching chains, so bulk-updating them together prevents the problem from reappearing next quarter. Finally, update any internal links that pointed at A so they point at E, since internal links should target the canonical URL regardless of whether a redirect would eventually get there.
Implementation details that decide whether it holds #
A few technical points determine whether cleaned redirects stay clean.
Redirect type consistency. A 301 is the standard for a permanently moved URL. Mixing 301 and 302 in a chain leaves 302 hops that Google treats as temporary, so after cleanup every hop should be a 301 unless there is a specific reason to signal a temporary move.
Rule order. In Apache, Nginx, and similar servers, redirect rules evaluate in order, and a poorly ordered rule set can manufacture chains because a single request matches several rules in sequence. Auditing rule order after any change catches this.
Status-code accuracy. URLs that moved should redirect; URLs that are genuinely gone should return 410 rather than redirect to something loosely related; URLs that moved temporarily should return 302. Using the wrong code muddies what Google records about the URL.
Redirect loops. A rule that points a URL back to itself, or an A-to-B-B-to-A pair, is broken. The browser eventually gives up with a “too many redirects” error, and Google stops and drops the URL. Loops are almost always misconfigurations introduced during a migration, which is exactly when to test for them.
Edge-case URLs. Trailing slashes, query parameters, fragments, and letter case all need consistent treatment. /Page and /page, or /page and /page/, should resolve to one canonical rather than redirect to each other in ways that can loop or lengthen chains.
Redirects and robots.txt during migrations #
Robots.txt and redirects interact in a way that trips up many migrations. The instinct during a move is to block the old paths:
# Wrong: blocking the source URLs of redirects
User-agent: *
Disallow: /old-category/
Disallow: /legacy/Those blocked URLs are exactly the ones Googlebot needs to crawl in order to see the redirects and consolidate the old signals onto the new URLs. Disallowing them stops Google from following the redirects at all, so the new URLs never inherit what the old ones earned. Leave the redirect sources crawlable and let Google process them:
# Right: leave redirect sources crawlable
User-agent: *
Allow: /old-category/
Allow: /legacy/Once Google has consolidated the old URLs into the new ones over the following months and the old URLs stop appearing as crawled in Search Console, disallow rules can be added if desired. The sequence is redirect, allow the crawl, wait for consolidation, then restrict.
For URLs that should disappear permanently rather than redirect anywhere, return 410 Gone instead of using robots.txt Disallow. Google reads 410 as a definite removal and drops the URL from the index faster than it drops a disallowed URL, which it can keep indexed on the strength of external links. The difference between 404 and 410 is small, but 410 is the cleaner signal when you are certain the page is gone for good.
Keeping chains from coming back #
Chains are technical debt that compounds: each migration adds a layer, and each year without cleanup makes the next cleanup harder. The discipline that prevents accumulation has a few parts.
Treat every migration as two phases, not one. The first phase sets up the new redirects; the second consolidates the older redirects so they point straight at the current URL. The second phase gets skipped because the site “works” without it, and that skip is where chain debt is born. Run a redirect audit on a schedule, a Screaming Frog crawl once a quarter, so new chains get collapsed before they become structural. Where a deployment pipeline exists, a simple test can assert that no sitemap URL returns a redirect and that no chain exceeds two hops, catching regressions before they ship. And keep the redirect rules documented so the team knows what each rule is for and which ones can be retired as content evolves.
A clean redirect is invisible. What draws attention is the chain that slows a page, the loop that stops a crawler, or the missing rule that lands a user on a 404. Redirect work has succeeded when nobody notices it, and for a site carrying years of accumulated hops, a focused rationalization pass can recover that quiet in weeks rather than leaving the debt to compound for another migration cycle.
FAQ #
Do redirect chains cause you to lose link authority?
Not in the way the old advice claims. Google passes PageRank through 301, 302, and 30x redirects without a per-hop percentage loss, so a chain does not slowly bleed away authority. The real costs are wasted crawl budget, added latency for users, and the risk that a chain long enough for Googlebot to stop following it leaves the destination unindexed.
How many redirects will Googlebot follow before it gives up?
Googlebot follows up to roughly 10 hops in a chain and then stops. That is a ceiling, not a target. Google’s own guidance is to keep chains short, and Mueller has suggested staying under about five hops for frequently crawled URLs to leave a safety margin.
What is the difference between a redirect chain and a redirect loop?
A chain moves forward through several URLs before reaching a final 200 response. A loop never reaches one, because a URL points back to an earlier URL in the sequence, so the browser eventually errors out and Google stops and de-indexes. Loops are configuration mistakes, most often introduced during a migration.
Should I block old, redirecting URLs in robots.txt during a migration?
No, not while the redirects still need to consolidate. Blocking the source URLs stops Google from crawling them, which means it never sees the redirects and the new URLs never inherit the old signals. Leave the sources crawlable until consolidation finishes, then restrict them if you want. For URLs that should simply be gone, use a 410 instead of a block.
If you only do one thing after reading this, run a redirect-chain report and look at the longest chains and the highest-traffic ones first. That single pass tells you whether your redirects are quietly costing crawl budget and speed, and it is the point where cleanup stops being theoretical and starts paying back.