Guides · 4 min read · Updated 2026-09-08

Redirect chains and loops: how they happen, what they cost, and how to fix them

Every redirect hop costs time, crawl budget and a slice of link equity. How chains and loops form on real sites, how to find every one with its sources, and the three-step fix.

A redirect chain is a URL that redirects to a URL that redirects again. A loop is a chain that comes back to where it started. Both are almost never designed; they accumulate. A site moves to HTTPS (one redirect), adds www (another), enforces trailing slashes (a third), migrates platforms (a fourth), and five years later the old blog links that still get traffic pass through four hops before a page appears. Each hop is a round trip for the user, a fetch for the crawler, and a small loss of the signal the link carried.

What a chain costs

Time. Each hop is a full request: DNS, connection, TLS, response. On mobile networks that’s 200–500 ms per hop. A three-hop chain can add over a second before the page even starts loading, and it shows up in Core Web Vitals as slow Time to First Byte.

Crawl budget. Googlebot follows up to ten hops, then gives up. Every hop is a fetch counted against your budget; sites with widespread chains get their new content discovered later.

Link equity. Google has said 301s pass full PageRank, but chains still lose signal in practice: each hop is a chance for the crawler to stop, and old URLs deep in a chain are re-evaluated less often. The safe assumption is that a direct link is worth more than a link through three hops.

Fragility. Every hop is a rule in a config file somebody can delete. Chains break in migrations; loops appear when two rules contradict.

How chains form

Stacked migrations. http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/. Four URLs, three hops, all from separate rules that each do one thing.
Content moves. A post is renamed twice. The first redirect points at the second URL, which redirects to the third.
Platform rules plus application rules. The CDN enforces HTTPS, the web server enforces www, the application enforces the slash. Each layer redirects once.
Case and encoding. /Shoes → /shoes → /shoes/.
Language and geo redirects on top of everything else: / → /en/ → /en-gb/.

Loops come from contradiction: a rule that adds a slash and a rule that removes it; a redirect to a URL that a later rule sends back; an HTTPS enforcement on a server that’s behind a proxy terminating TLS, so the app thinks every request is HTTP and redirects forever.

The other redirect problems worth catching

Temporary redirects used permanently. A 302 or 307 says “this is temporary, keep the old URL indexed”. Migrations done with 302s keep the old URLs in the index for months. Use 301 or 308 for permanent moves.

Meta refresh and JavaScript redirects. <meta http-equiv="refresh"> and window.location are slower, weaker signals and are often invisible to link checkers. Truelint reports meta refreshes as redirects and, with rendering on, catches JavaScript-only redirects by comparing the requested URL with the one the browser ended on.

Redirects to errors. A chain that ends in a 404 is a broken link that looks like a redirect.

Redirects on internal links. The redirect works; the link that goes through it shouldn’t exist. Every internal link should point at the final URL.

Finding every chain with its sources

A crawl follows every redirect to its end, records each hop with its status, and, critically, records which pages link to the redirecting URL. That last part is what makes the fix possible: you need to change the link, not just the redirect.

In Truelint, the Response Codes tab has filters for redirect chains, loops, temporary redirects and meta refreshes. Each URL’s detail pane shows the full chain hop by hop, and its inlinks tab shows which pages link to it. The “Redirect chains” report exports every chain with its source count.

The fix, in three steps

1. Collapse the chain. Every redirect should point directly at the final destination. Regenerate the redirect map so A → D, not A → B → C → D. Keep the intermediate rules (B → D, C → D) because external links point at them too.

2. Repoint the internal links. Search the templates and content for links to A, B and C and change them to D. With the crawl’s inlinks list this is a targeted job, not a site-wide search.

3. Use the right status code. 301 (or 308 when the method must be preserved) for permanent moves. Reserve 302/307 for genuinely temporary situations like A/B tests and maintenance pages.

Then re-crawl and compare: the chain count should drop to zero for internal links, and the remaining redirects should all be single-hop.

Preventing them

One layer owns redirects. Decide whether the CDN, the web server or the application does redirects, and put every rule there, in the canonical form (HTTPS, www, slash) applied in one step.
Redirect to final form. The rule that enforces HTTPS should also enforce the hostname and slash, so one hop lands on the final URL.
Test with a crawl before every migration goes live, on staging, with the redirect map applied. It takes minutes and it’s the only way to see chains before users do.