Redirect Chains and Loops: How to Find and Flatten Them
Redirects accumulate as sites are migrated, renamed and reorganized. A link that once pointed at a live page may now pass through three or four hops before reaching content. Each hop adds latency for visitors and another request for crawlers, and a single misconfigured rule can create a loop that never resolves.
Why chains and loops cost more than they appear
Every redirect is a full round trip. On mobile networks, a chain of three redirects can add noticeable delay before the first byte of real content arrives. Crawlers follow a limited number of hops; Googlebot documents following up to ten, and stops treating the destination as reachable after that.
Loops are worse: the URL never produces content, so it is reported as an error and any links pointing to it are wasted. Loops often appear when two rules disagree, such as one forcing a trailing slash and another removing it.
Finding them
Crawl the site with a tool that records every hop, then group results by the number of redirects before a 200 response. Also check the redirect targets of old URLs taken from previous sitemaps, analytics landing pages and server logs, because internal links rarely reveal historical URLs.
A short script can confirm a single URL quickly by printing each status and location in order.
curl -sIL -o /dev/null -w '%{num_redirects} %{url_effective}\n' https://example.com/old-pageFlattening them safely
Point every old URL directly at the final destination with a single permanent redirect, and update internal links, canonicals and sitemaps to the final URL so the redirect is rarely needed at all. Keep the redirect map in version control so later migrations can extend it rather than stacking new hops on top.
After deployment, re-run the crawl and confirm the count of multi-hop chains has dropped to zero.