Audit redirects: find every chain and loop, then flatten it

The problem

Redirects rarely stay simple for long. A page moves during a migration and gets a redirect; two years later a redesign moves it again, and the new redirect gets pointed at whatever URL was already there — not the original one, because nobody went looking for what was already redirecting to it. Repeat that a few times over a site's life and you get chains: A → B → C → D, where a visitor or crawler has to hop through three intermediate URLs before reaching real content. Occasionally two independently-added redirects cancel each other out into a loop — A → B → A — which never resolves at all.

Both accumulate silently, and both are hard to catch with a typical crawl report: most tools record only the first redirect a URL returns, not what's downstream of it. A URL that shows as "redirects to B" might actually take four more hops after that before landing anywhere real — and there's no way to tell from a single-hop report. That's the gap this guide closes. For the underlying concepts — what a 301 vs. a 302 means, when to use each — see the redirects glossary entry first if you need it; this guide assumes that part and focuses on the practical audit.

Do it in RacingRoach

Start a crawl as usual. When RacingRoach hits a redirect, it doesn't stop at the first hop — it keeps following the chain, hop by hop, until it reaches either real content or a dead end, and records the entire path against the original URL. On the Issues screen, a chained URL shows the full route from start to finish in one place: how many hops, every intermediate URL in order, and what the chain actually terminates at. You're not left inferring chain length from a stack of single-hop redirect records — you see the whole thing resolved in one view.

Loops get flagged as their own distinct case rather than folded in with chains. That distinction matters: a chain is inefficient but eventually gets somewhere, while a loop is a hard failure — the URL never resolves, for a crawler or a real visitor — so RacingRoach surfaces it separately instead of letting it read like just a long chain that happens not to finish.

Interpret the results

Once you can see full chain length, prioritizing is straightforward: the longer the chain, the more latency and diluted ranking signal it's costing you, and the more places it can break. We cover the "why does this actually cost me anything" mechanics — per-hop latency, signal dilution, and chain fragility — in full in redirect chains are quietly costing you rankings; the short version is that every hop is a full request-response cycle and search engines treat each additional hop as a little more ranking signal lost, not a clean pass-through.

Fix it

The fix for a chain is always the same move: repoint the original URL directly at the final live destination, then remove the now-unnecessary intermediate redirects. That collapses the whole chain — however many hops it had — down to a single direct redirect. Don't "fix" a chain by adding another redirect at the end to shorten it by one hop; that just makes it a slightly shorter chain instead of a direct one, and it'll grow again at the next migration.

Loops need a different move, because there's no "final destination" to point at yet — that's exactly what's broken. One of the redirects in the loop has to be corrected so it actually terminates at real content instead of looping back to where it started. Usually that means figuring out which of the two conflicting rules is stale (an old migration redirect, a leftover www/trailing-slash rule) and updating it to point at wherever the content genuinely lives now, not at the other half of the loop.

Once a chain is flattened or a loop is broken, check the internal link graph for pages still linking to the old, intermediate URLs — updating those links to point straight at the final destination removes the redirect tax from every future crawl and visit, not just the one you just fixed.