One 301 redirect from an old URL to its replacement is completely normal and effectively free — every site accumulates them from URL restructuring, and Google has been clear there's no penalty for a well-formed permanent redirect. The problem isn't the redirect; it's what happens after a site has been through two or three migrations without anyone cleaning up the trail, and /old-page now redirects to /older-replacement, which redirects to /newer-replacement, which redirects to the current URL. Each individual hop still "works" in a browser, which is exactly why chains like this survive undetected for years.
What a Redirect Chain Actually Costs
Crawl efficiency
Every hop in a chain is a separate HTTP request a crawler has to make before reaching the final content. On a small site this is negligible. On a large site with thousands of chained URLs — common after repeated CMS migrations or a series of URL-structure changes — the cumulative crawl overhead competes with crawl budget that could otherwise go toward discovering and refreshing real content. This is a resource allocation problem more than a per-URL penalty.
Signal dilution and eventual drop
Google's own guidance describes following redirects to reach the target URL, but a long or malformed chain increases the chance a hop fails to resolve cleanly or that the system deprioritizes following it to completion. In practice, the real risk isn't a mathematically decaying "link juice" per hop — it's that longer chains are more likely to contain a broken link, a loop, or a hop that times out, at which point the entire chain fails and the destination page gets none of the consolidated signal, not just less of it.
User-facing latency
Each redirect hop is a round trip before the page starts rendering. On fast connections this is barely perceptible for two hops; on a chain of four or five, especially compounded with slow server response times on any single hop, it becomes a measurable part of page load — and unlike most performance issues, it's invisible in front-end profiling tools that start measuring from the final URL rather than the entry point.
Where Chains Actually Come From
Understanding the cause matters because the fix differs:
- Sequential migrations without cleanup. Migration A redirects old→interim. Migration B, done later by someone unaware of migration A's redirects, redirects interim→new. Nobody goes back to point old→new directly.
- CMS plugins that redirect automatically on slug change, stacking a new redirect rule on top of existing ones instead of checking whether the source URL is already a redirect target itself.
- HTTP-to-HTTPS or www/non-www redirects layered on top of content redirects, so a single user request hits a protocol-normalization redirect, then a domain-normalization redirect, then the actual content redirect — three hops for what should conceptually be one.
- Trailing slash or case-normalization rules combined with content redirects, particularly on servers where these are handled by separate, unaware-of-each-other configuration blocks.
The last two categories are the ones people most often miss during an audit, because each individual redirect rule looks intentional and correct in isolation — the chain only becomes visible when you trace an actual request through all of them in sequence.
Auditing for Chains
Trace redirects with a tool that follows and logs every hop rather than just confirming the final destination — curl -IL shows the full chain from the command line:
curl -IL https://example.com/old-page
HTTP/1.1 301 Moved Permanently
Location: https://example.com/interim-page
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
HTTP/1.1 200 OK
For a site-wide audit, cross-reference your list of all known historical URLs (from old sitemaps, CMS export, or server logs) against your current redirect rules, and flag any source URL whose target is itself found on the left side of another redirect rule — that's a chain link by definition, independent of hop count.
# Flag redirect rule targets that are themselves redirect sources
awk -F',' 'NR==FNR{src[$1]=1; next} $2 in src {print $1" -> "$2" -> chain"}' redirects.csv redirects.csv
Use the Regex Tester to validate the URL-matching patterns in server-level redirect rules (.htaccess, nginx rewrite, or platform-specific redirect config) before deploying a fix — a pattern that's slightly too broad or too narrow when consolidating multiple rules into one is how new chains or unintended redirect loops get introduced during the very cleanup meant to remove them.
The Fix: Flatten, Don't Add
The correct fix for a chain is always to point every source URL directly at the final destination — never to insert a new intermediate hop, even a well-intentioned one. If /old-page → /interim-page → /new-page, the fix is /old-page → /new-page and /interim-page → /new-page, both as direct single-hop redirects. Resist the temptation to redirect /old-page → /interim-page and let the existing /interim-page → /new-page rule handle the rest; that's how chains get re-created immediately after being "fixed."
Decision Point: When to Actually Prioritize This
Not every chain is worth immediate cleanup effort. Prioritize fixing:
- Chains on URLs that still receive meaningful organic traffic, external backlinks, or crawl activity per server logs — these are actively losing value right now.
- Chains longer than two hops anywhere in the site, since the marginal risk of a broken link or timeout compounds with each additional hop.
- Chains created by recent or upcoming migrations, since fixing them before they age into the crawl index is cheaper than fixing them after months of accumulated crawl history built on the chained path.
Deprioritize chains on genuinely dead pages with no remaining traffic, backlinks, or crawl interest — a two-hop chain to a page nobody visits and nothing links to isn't costing anything meaningful, and cleanup effort is better spent where traffic or link equity is actually at stake.
After flattening a batch of redirects, regenerate and resubmit the sitemap with the Sitemap Generator so it reflects only final destination URLs — a sitemap that still lists intermediate chain URLs sends a mixed signal about which URL is actually canonical, undermining the cleanup you just did.