Redirect Chains and Loops: How to Find and Fix Them

A redirect chain is any sequence where one URL redirects to a second URL that redirects to a third, instead of going straight to the destination. A redirect loop is a chain that never ends, because a URL somewhere in the sequence points back to one that came before it. Chains are a performance and ranking problem: every hop is a full round trip before the visitor sees anything, and Googlebot follows only about 10 hops before it gives up. Loops are an outage: nothing renders at all, and the browser stops with an ERR_TOO_MANY_REDIRECTS error.

What is a redirect chain?

When a server returns a 3xx status code, it is telling the client to go and ask a different URL instead. One redirect is normal and often necessary. A chain is what you get when the URL it sends you to also returns a 3xx, and so does the next one.

The reason chains are hard to notice is that browsers hide them. Type an old address, and the browser silently walks the whole sequence and paints the final page. The address bar shows the destination. Nothing in the interface suggests you just made four requests instead of one. The only way to see the chain is with a tool that stops at each hop and reports it, which is what the HTTP status code checker on this site does: it refuses to follow redirects automatically and instead prints every hop, its status code and how long it took.

A typical accumulated chain looks like this:

Nobody designed that. Four different people solved four different problems correctly, at four different times, and the chain is what their rules produce when stacked.

What is the difference between a redirect chain and a redirect loop?

A chain ends. A loop does not. In a loop, a URL that already appeared in the sequence appears again, so the client would keep requesting forever if it did not stop itself. Browsers cap the attempts and show ERR_TOO_MANY_REDIRECTS in Chrome or "The page isn't redirecting properly" in Firefox. The page never loads for anyone.

The practical difference for your work: loops announce themselves, chains do not. A loop generates support tickets within the hour. A chain can sit in place for two years, costing a fraction of a second and a fraction of a ranking signal on every single request, and nothing will ever tell you it is there.

Why are redirect chains bad for SEO?

Three separate costs, and they compound.

Crawl efficiency. Every hop is a request Googlebot has to make and wait for. Crawl budget is finite, and a site where a meaningful share of URLs resolve through three hops is spending that budget on redirects instead of on pages. On a small site this is irrelevant. On a large catalog it is the difference between new pages being discovered in a day and in a fortnight.

Signal transfer. Google treats a 301 or 308 as a strong signal that the redirect target should become canonical, and a 302, 303 or 307 as only a weak one. When a chain mixes types, the weakest link in the sequence governs what actually gets passed. A chain that starts with a 301 and picks up a 302 halfway through is not a permanent move as far as the indexing pipeline is concerned. Whatever authority the original URL earned from the work that built it, the chain is the least reliable way to deliver it to the page that should inherit it.

Speed. This is the one that shows up in real numbers. Each hop is a DNS lookup that may be cached, a TCP connection, a TLS handshake if the scheme changes, and a full request and response, before a single byte of the actual page is sent. Three hops on a mobile connection can add most of a second to the point where anything appears. That is time charged to your Core Web Vitals and to the patience of the person waiting.

How many redirects will Google follow?

Googlebot follows up to 10 redirect hops by default, according to Google Search Central. Past that, the fetch is treated as a failure and the URL is not indexed. Almost no real site reaches that ceiling, which is precisely why chains are a quiet problem rather than a loud one. They stay well under the limit and simply make everything slightly worse.

Treat 10 as the point of total failure, not as a budget to spend. The target for any URL that matters is one hop, or zero.

How to find redirect chains

Four approaches, in rough order of how much of your site they cover.

For a single URL on the command line, this prints one line per hop and no response bodies:

curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

Start with the URLs that carry external links, since those are the ones where the wasted signal actually costs you something. Your sitemap, your top landing pages in Search Console, and anything that appeared in a migration mapping file are the right first list.

How to fix "Redirect Chain Contains HTTP"

If you have been through a vendor security review, you may have met this finding on a SecurityScorecard report rather than in an SEO audit. It fires when at least one URL between the initial address and the final one uses plain HTTP, even when both ends are HTTPS.

The reasoning is sound. An unencrypted hop in the middle of a chain is still an unencrypted request, carrying the full URL and any cookies scoped to it across the network in clear text, and it is a place where an attacker on the path can intercept and rewrite the response. The fact that the journey ends on HTTPS does not undo the exposure that happened at hop two.

SecurityScorecard's own guidance lists four fixes: make sure every URL in the chain uses HTTPS, review and update outdated redirects that still specify http, use relative paths in redirects so the protocol is inherited rather than restated, and implement HSTS on the target domain, which they will accept as a compensating control.

In practice the third one is where the bug usually lives. A redirect rule written years ago with a hardcoded http:// target keeps working perfectly, because something further along upgrades it, so nobody ever notices the downgrade in the middle. The status checker flags exactly this pattern, and so does any crawl that records the scheme of every hop rather than just the final one.

How to fix a redirect chain

The fix is almost always simpler than people expect, and it is not to delete the rules.

Point the first URL directly at the last one. Keep every existing rule in place, because each of them is still doing a legitimate job for other requests. Add or amend the specific redirect so that the entry point of the chain goes straight to the final destination in a single 301 or 308.

Some specifics worth getting right:

• Use 301 or 308, not 302. Most frameworks and load balancers default to 302, so a permanent move ships as temporary unless somebody changes it deliberately. Use 308 when the request method and body must survive the redirect, and 301 otherwise.
• Redirect to the canonical form in one step. If your canonical URLs are HTTPS, with www, and with a trailing slash, then the redirect target should have all three properties already. Sending traffic to a URL that will immediately be rewritten again is how a two hop chain becomes a three hop chain.
• Fix the order of your rules, not just the targets. Doing the HTTPS upgrade first and the host canonicalization second costs two hops. A single rule that normalizes scheme and host together costs one.
• Update internal links to the final URL. A redirect is a safety net for external links and old bookmarks. Your own navigation, sitemap and content should link to the destination directly, so most requests never touch a redirect at all.
• Re-check after deploying. Redirect rules interact, and the fix for one chain occasionally creates another. Run the same URLs through a checker afterwards and confirm the hop count actually dropped.

How to stop chains coming back

Chains are not a one time cleanup, because the conditions that create them never go away. Every migration, rebrand, CMS change and campaign URL adds new rules to a stack that already has rules in it.

Two habits keep it under control. First, whenever you add a redirect, check whether its target is itself redirected, and point at the end of that sequence instead. This takes ten seconds at the time and saves an audit later. Second, keep the redirect map in one place. Chains flourish when rules are spread across a load balancer, a CDN, an nginx config and application middleware, because nobody can see all four at once.

The wider point is that a redirect chain is one of a family of problems where the URL works, so nothing alerts, and the cost is paid quietly on every request. A page returning 200 with the wrong content type behaves the same way. So does a 302 that should have been a 301, and a certificate that is fine today and expired in six weeks. None of it breaks loudly enough to notice, which is why the value of an ongoing programme of technical fixes and content work that compounds is so easily undone by infrastructure nobody is watching.

That is the case for checking status codes continuously rather than occasionally. A one off audit tells you the truth about the day you ran it. Monitoring that requests your URLs on a fixed interval tells you the moment a 200 becomes a 302, a 404 or a 500, which is usually the moment a deploy went out and nobody noticed what it changed.

Common questions

Is a redirect chain always bad? A two hop chain on a page nobody links to is not worth an engineering ticket. A two hop chain on your highest traffic landing page, or on a URL with external links pointing at it, is worth fixing today. Prioritize by traffic and by inbound links rather than by hop count alone.

How many redirects is too many? One is fine. Two is worth fixing when you are next in that config. Three or more should be treated as a defect, because at that point you are reliably adding hundreds of milliseconds and passing signals through a sequence where any weak link governs the result.

Do redirect chains affect Core Web Vitals? Yes, indirectly but measurably. Every hop delays the first byte of the real response, which pushes out Largest Contentful Paint. The effect is largest on mobile connections, where each additional connection and handshake costs the most.

What causes ERR_TOO_MANY_REDIRECTS? A loop. The usual culprits are two rules disagreeing, such as a CDN forcing www while the application forces non-www, a plugin or middleware redirecting to HTTPS while the origin already receives HTTPS traffic and thinks it is HTTP, or a mismatch between the site URL in a CMS and the actual hostname being served.