Redirect Chain Audits: Finding the Loops, Hops, and Lost Equity

Redirects are easy to create and hard to see. A CMS slug change adds a hop, a domain migration adds another, and eighteen months later a URL passes through four redirects before reaching a 404. Each hop costs latency and crawl budget, and Google's handling of long chains is less forgiving than the documentation implies. An audit makes the chain visible and gives you a prioritized fix list.

Crawl for redirect behaviour, not just status codes

A standard crawl reports a URL's final status. You need the full chain: each hop's status code, Location header, and whether it is permanent or temporary.

Use a crawler that logs redirect hops, or script it with a HEAD request that follows redirects manually:

curl -sI -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/old-page

Repeat until the Location header is absent. Record every hop. A chain of one permanent redirect is fine; a chain of three is a finding.

Classify the findings, and measure the cost

Chains — two or more hops. Collapse to a single 301 pointing at the final destination.

Loops — A redirects to B and B redirects back to A. Browsers abort with ERR_TOO_MANY_REDIRECTS, and crawlers give up. These usually come from conflicting CMS rules.

Soft 404s behind redirects — a 301 that lands on a page returning 200 with "not found" copy. The redirect looks healthy to a status-only audit and is a dead end for users.

302s used permanently — temporary redirects that have persisted for months. They pass signals less reliably and confuse canonicalization.

Redirects to irrelevant pages — a retired product redirecting to the homepage. This is the most common migration shortcut and the one that wastes the most equity.

Count the URLs in the crawl that require more than one hop, and sum the added latency: roughly 100–200 ms per hop on a typical server. Multiply by crawl frequency for high-value URLs. A site with 10,000 affected URLs and one extra hop each is spending real time on every crawl.

Also check whether the redirect target is canonicalized elsewhere. A chain that ends on a URL with a canonical pointing to a third URL is three signals disagreeing; search engines pick one and ignore the rest.

Fix in the right order

Collapse chains first: for each chain, update the source rule to point directly at the final 200 URL. This is a server configuration change, not a content change, and it clears most of the crawl waste.

Then resolve loops, which are usually a rule-ordering bug. Test after every change; a single wildcard rule can create a new loop across thousands of URLs.

Then replace homepage redirects with the closest equivalent page. If no equivalent exists, return a 410 rather than redirecting to an unrelated page.

Prevent the next generation

Add three checks to the deploy pipeline: a redirect test for every changed slug, a rule that a redirect can point to at most one hop, and a monthly crawl diff that flags new chains. Most chains are introduced by well-meaning slug cleanups, so catching them in the pull request is cheaper than a quarterly cleanup.

Keep a migration map for domain moves: old URL, new URL, date, and status. When the next migration happens, the map prevents the double-hop that comes from pointing old URLs at URLs that themselves moved.

Harvesting redirect data at scale, and permanent versus temporary intent

A crawler configured to follow redirects loses the chain. Run two passes: one that follows normally to find final status, and one that disables automatic redirects and records each hop. The second pass needs a concurrency limit and a timeout per hop; a misconfigured redirect can loop indefinitely.

Deduplicate by the chain signature rather than by source URL. Ten thousand URLs with the same two-hop pattern are one configuration bug, and fixing it once clears all of them.

A 302 that has been live for six months is effectively permanent, but it still signals temporariness to crawlers. Audit the age of each 302 by comparing first-seen dates in the crawl history. Convert long-lived temporary redirects to 301 if the move is permanent, or remove them if the old URL should return 404.

Redirects used for A/B tests or geolocation should stay 302 and should not be in the sitemap.

Chains through external services, and CDN caching

Links shortened by a URL shortener, affiliate links, and CDN vanity domains add hops you may not control. Check the first hop from your own server; if the chain leaves your domain, document it rather than trying to collapse it.

Internal links should never point at a shortener. Replace with the destination URL where the link is editorial.

A 301 cached at the CDN edge will survive a server configuration change until the cache expires. When fixing a chain, purge the affected paths explicitly. Otherwise the fix looks ineffective for hours and the team re-fixes a problem that is already solved.

Set a short cache TTL on redirects during a migration, then lengthen it once the map is stable.

The migration map, and a one-line regression test

Maintain a table of old URL, new URL, date, status, and owner. When the next migration happens, map old URLs to the current canonical targets, not to the previous migration's targets. The double-hop problem is almost always caused by chaining migrations without reading the previous map.

For every slug change in a pull request, require a test that requests the old URL and asserts a single 301 to the new one. That test costs a few lines and prevents the most common source of chains.

Auditing outbound links, and chains that hide a loop

The same check works on the links you publish. Internal links that pass through two redirects waste crawl budget and lose referrer context.

Rewrite them to the final destination and add the audit to the pre-publish checklist. A quarterly pass catches the drift introduced by CMS migrations.

A chain of five hops usually contains a loop somewhere upstream. Follow until the URL repeats, and report the cycle rather than the length.

Fix the last hop first. Redirects are followed from the start, so repairing the final target resolves every chain that ends there.