Redirect chains don't happen on purpose. Nobody sits down and designs A→B→C→D. They accumulate: a page moves in one migration, gets a redirect; the same content moves again two years later during a redesign, gets another redirect — pointed at the old URL, not the original one, because whoever set it up didn't go looking for what was already redirecting there. Repeat that across a few years of a site's life and you end up with URLs that hop three or four times before landing anywhere real. Each individual redirect was a reasonable decision in isolation. The chain is the accident.
We've already covered the conceptual basics — what a 301 vs. a 302 means, when to use each — over in the redirects glossary entry, along with the related HTTP status codes that a crawler acts on. This post is the "why does this actually cost me anything" companion: three concrete failure modes, and what to do about them.
Every hop is a full round trip
A redirect isn't free. Each hop in a chain is a complete request-response cycle — DNS lookup (if it's a different host), TCP handshake, TLS negotiation, then the server's own response time before the 3xx even comes back. None of that is skipped just because the destination happens to be another redirect. We covered the underlying mechanic in why response time is a crawl-budget problem: a search engine spends a roughly fixed amount of time crawling your site per day, not a fixed number of pages. A four-hop chain doesn't cost one page's worth of that budget — it costs four requests' worth, for a single URL that could have been one hop.
That latency compounds in a specific, easy-to-miss way: internal links. Every other page on your site that links to the original URL A is forcing whatever crawls it — search engine or human — through the same B and C hops, every single time, for as long as those internal links go unfixed. A chain isn't a one-time tax on the one URL that got redirected. It's a recurring tax on every page that still links to it.
Signal gets diluted at every step
A 301 is supposed to consolidate ranking signal onto the destination — that's the whole point of using it over a 302. But that consolidation happens hop by hop, and search engines have been fairly consistent about treating each additional hop as a little more signal lost along the way, not a clean pass-through. Two hops leaks a little. Four hops leaks more. The exact amount isn't something you can compute precisely, and it's not the headline reason to fix a chain — but it means a page's authority arriving at its final destination through four redirects is not the same as the authority that page would have if the first URL pointed straight at it.
The fix is almost never "add a redirect to shorten the chain." It's repointing the original URL directly at the final destination — one hop, full signal, and it holds even if a future migration reshuffles everything downstream again, because there's nothing left in between to break.
Loops are the failure that actually breaks something
A chain degrades quietly. A redirect loop — A → B → A, with no real content ever reached — fails outright. Browsers detect the cycle and show an error page ("too many redirects"). Crawlers detect it too, abandon the URL, and mark it as unreachable. There's no partial credit for a loop: the page is functionally gone, for every visitor and every crawl, until someone breaks the cycle.
Loops usually aren't intentional either. The common cause is two redirects added independently, months apart, by two different people (or two different plugins) who each had a plausible reason for their half of the loop and no visibility into the other half. A migration redirect and an old "www vs. non-www" or trailing-slash rule can quietly cancel each other out this way, and the result — a URL that never resolves — can sit undetected for a long time if nothing is actively walking the whole redirect graph.
Chains are fragile in a way a single redirect isn't
The failure mode that does the most quiet damage isn't the latency or the diluted signal — it's that a chain has more links that can break than a direct redirect does. A single A→D redirect has exactly one thing that can go wrong: the destination goes away. A four-hop chain has four. If the server hosting hop B gets decommissioned, or someone deletes the page at C during an unrelated cleanup, the entire chain from A onward breaks — not just the segment that changed. A crawler hits a 404 or a 5xx partway through and reports the whole URL as broken, even though A, C, and D might all still be perfectly fine on their own.
That's the genuinely dangerous part: nobody notices right away. The URL isn't in anyone's daily workflow — it's an old redirect nobody thinks about, until it breaks, and then it can stay broken for months, because the only way to catch it is to actually walk the chain, not just check that the original URL "still redirects somewhere."
Finding and fixing chains at scale
The reason chains survive for years is that they're invisible from any single migration's checklist. Each migration only ever looks at "does my new redirect work" — nobody goes back and re-derives the full history of every URL that's been moved multiple times. Catching them requires something that walks the entire redirect graph across a full crawl and resolves every hop, not just the first one.
That's what RacingRoach's broken-link and redirect detection does: it resolves redirect chains and loops hop by hop across the whole crawl, so a URL that's quietly hopping through three intermediate redirects shows up as exactly that — the full chain, not just "this URL redirects" with no visibility into what's downstream. Once a chain is visible end to end, fixing it is straightforward: repoint the original URL directly at the final destination, and remove the now-unnecessary intermediate hops. The same view surfaces loops as their own case, since a loop and a chain that happens to be very long look identical from the outside until something actually resolves every step.
The internal link graph is the other half of the fix: once you know which URL is the true final destination, that view shows every page still linking to the old, chained URL — the ones adding the redirect tax to every visit and every crawl until they're updated to link straight to D instead of A.
None of this is exotic to find once you're looking at the whole graph in one pass. It's invisible precisely because most workflows never look at more than one hop at a time. Walk the whole chain, and the fix — repoint the start at the end, cut what's in between — is usually a five-minute change per URL, not a mystery.