What Is Redirect Loop?

How a Redirect Loop Works

A redirect loop is a redirect chain that never ends. In a normal chain, each hop moves a request closer to a real page and the sequence eventually terminates at a 200 OK response. In a loop, one of the redirects points back to a URL that is already earlier in the sequence, so the request is sent in a circle: URL A redirects to B, and B redirects back to A, which redirects to B again. No hop ever returns actual content, so the cycle would run forever if nothing stopped it.

Clients do stop it. Browsers keep a running count of redirects for a request and, once the count grows unreasonable, abort with an error rather than loop indefinitely — Chrome shows ERR_TOO_MANY_REDIRECTS, and other browsers display equivalent “redirected you too many times” messages. The practical result is the same everywhere: the visitor sees an error page, not your content. Because a search crawler behaves the same way, a looping URL is completely unreachable. It cannot be crawled, so it cannot be indexed, so it cannot rank. This is an availability failure, not a ranking penalty — the page is simply gone as far as the web is concerned.

Google names the condition explicitly. In the Search Console Page indexing report, “Redirect error” is triggered by one of four problems, and a redirect loop is one of them. The other three — a redirect chain that was too long, a redirect URL that eventually exceeded the maximum URL length, and a bad or empty URL in the redirect chain — sit in the same bucket, all describing redirects that fail to deliver real content.

What Causes a Loop, and How to Break It

Loops are almost always born from redirect rules that each look correct alone but contradict each other when combined. The usual suspects:

• HTTP vs HTTPS conflict — one rule forces every request to HTTPS while another, elsewhere in the stack, forces HTTP. The two bounce a request back and forth.
• www vs non-www conflict — a CDN or edge rule forces the www host while the origin server forces the bare domain, or vice versa.
• CMS canonical vs server rewrite — a CMS emits its own canonical redirect that disagrees with a hand-written server rewrite rule.
• Trailing-slash disagreement — one layer appends a trailing slash and another strips it, ping-ponging the URL.

The reason these slip through is that each rule is individually reasonable and often lives in a different config layer — server, CDN, and application — so the collision only appears in production where all three run together. The fix is diagnostic, not clever: request the URL with a tool that prints each hop’s status code and Location header, watch where the sequence turns back on itself, and remove or reorder the rule causing the reversal. After correcting the rules, clear any caches, since cached redirect responses can keep serving the loop even after the underlying configuration is fixed.

Example of a Redirect Loop

A textbook loop comes from two well-meaning canonicalization rules that disagree. Suppose the origin server is configured to force the bare domain, so it redirects any www request back to the apex:

1. https://www.example.com/page — 301 to https://example.com/page

Meanwhile, a CDN sitting in front of the site is configured to force www, so it does the reverse:

2. https://example.com/page — 301 back to https://www.example.com/page

Now trace a single request. It arrives at the www URL, the origin sends it to the apex, the CDN sends it back to www, the origin sends it to the apex again, and the cycle repeats. The browser counts the redirects, gives up, and prints ERR_TOO_MANY_REDIRECTS. Googlebot hits the same wall, and Search Console files the URL under “Redirect error” as a redirect loop, excluding it from indexing. Neither rule is wrong by itself — the site simply cannot enforce www and non-www at the same time. Pick one canonical host, make every layer agree on it, and the loop resolves into a clean single hop.

Frequently Asked Questions

The Bottom Line

A redirect loop is a redirect that eats its own tail — the URLs point back at one another so a request circles forever and no page is ever delivered. Browsers cut it off with a “too many redirects” error and Google reports it as a redirect error, dropping the page from its index. There is no partial version of this failure: fix the conflicting rules that feed the loop, or the page stays invisible to users and search alike.