Too Many Redirects: What Causes It and How to Fix It
The “too many redirects” error means a URL is caught in a redirect loop that never resolves. Instead of arriving at a real page, the browser is bounced from one address to another and then back again, over and over, until it gives up. Chrome shows it as ERR_TOO_MANY_REDIRECTS, Firefox says “The page isn’t redirecting properly,” and Safari reports “too many redirects occurred.” They are all describing the same thing: a loop with no exit. This guide explains exactly what triggers the loop, how to find it, and how to fix each cause so the page loads and Google can crawl it again.
What “Too Many Redirects” Actually Means
When you request a URL, the server can respond with a 3xx redirect (most often a 301 permanent or 302 temporary) that tells the browser to go somewhere else. The browser follows it and requests the new address. Normally that second request returns a real page with a 200 status and you are done. A loop happens when the destination redirects back to a URL that has already been visited in the chain — so A points to B, and B points back to A, and neither ever serves content.
Browsers do not follow redirects forever. After roughly 20 hops without reaching a final 200 response, the browser stops and shows the error rather than hanging indefinitely. Googlebot behaves the same way: it follows a redirect chain up to its own limit and then abandons the URL. That is the critical difference between this error and a normal redirect. A single clean redirect is healthy and expected — see our page with redirect guide for why those entries are usually fine. A loop, by contrast, means the page is completely unreachable.
Common Causes of the Error
Almost every “too many redirects” case traces back to two redirect rules that contradict each other, or a single rule that accidentally points back to itself. These are the patterns we see most often:
Conflicting HTTP-to-HTTPS rules
Your application forces https://, but a proxy or load balancer in front of it terminates SSL and forwards the request as plain HTTP. The app sees HTTP, redirects to HTTPS, the proxy strips it back to HTTP, and the loop is born. This is the single most common cause. The fix is to make sure only one layer handles the HTTP-to-HTTPS upgrade, and that the app trusts the X-Forwarded-Proto header from the proxy instead of redirecting again. Our HTTPS SEO guide covers a clean redirect setup.
Cloudflare “Flexible” SSL mode
This is the most famous version of the loop. In Cloudflare, “Flexible” SSL means Cloudflare talks to your origin server over plain HTTP even though visitors connect over HTTPS. If your origin also redirects HTTP to HTTPS, it redirects the request Cloudflare just sent over HTTP — forever. Switch the Cloudflare SSL/TLS setting from Flexible to Full (or Full (strict) if you have a valid origin certificate). This resolves the loop in the vast majority of Cloudflare cases.
www and non-www conflicts
One rule sends www.example.com to example.com, while another sends example.com back to www.example.com. Each redirect is individually reasonable, but together they form a perfect loop. Pick a single canonical host and make every rule point one direction only. Our www vs non-www redirect guide walks through doing this cleanly so the two rules can never fight.
Duplicate or stale redirect rules
A redirect plugin, a .htaccess entry, and a server config block can each add their own rule for the same path. When two of them disagree about the destination, requests bounce between the targets. WordPress sites are especially prone to this when more than one SEO or redirect plugin is active. Audit every layer — CMS plugin, .htaccess, Nginx/Apache config, and CDN page rules — and make sure only one owns each path.
Misconfigured trailing-slash or case rules
A rule that adds a trailing slash to /page while another removes it from /page/ creates a slash loop. The same happens with rules that lowercase URLs while a different rule uppercases part of the path. Normalize in one direction only — decide whether you want trailing slashes or not, and whether URLs are lowercase, then enforce that with a single rule.
Login, cookie, or session loops
Some loops are dynamic rather than configured. An auth check redirects logged-out users to a login page, but a broken session or a missing cookie means the user is treated as logged out again on the next request, so the redirect fires repeatedly. A corrupt cookie stored in one browser can also trigger the error on an otherwise healthy site. This is why the page sometimes loops in one browser but works in another.
How to Diagnose the Loop
Before changing anything, find exactly where the loop starts. Guessing at redirect rules without tracing the chain usually creates a second problem on top of the first.
1. Trace the redirect chain with curl. Run curl -sIL https://example.com/page. The -L flag follows redirects and the -I flag prints each response header, so you will see every hop and its status code. When the same two URLs alternate in the output, you have found the loop and the exact pair of URLs fighting each other.
2. Test in incognito. Open the URL in a private window. If it loads there but loops in your normal window, the cause is a stale cookie or cached redirect in your browser — clear the site’s cookies and cached files rather than editing any server config.
3. Check your CDN or proxy first. If you use Cloudflare or another proxy, check the SSL mode before touching application code. Flexible SSL is the cause far more often than anything in your codebase, and switching it is a one-click fix.
4. Confirm in Search Console. Run the URL through the URL Inspection tool. If Google reports a redirect error, the loop is hurting crawling, not just one browser. This tells you whether it is a sitewide SEO emergency or a local browser quirk.
How to Fix “Too Many Redirects”
Once you know which rules form the loop, the fixes are direct:
1. Set Cloudflare SSL to Full. If you are behind Cloudflare, change SSL/TLS from Flexible to Full or Full (strict). This alone resolves most loops involving HTTPS.
2. Remove the contradicting rule. When two rules point at each other (www vs non-www, slash vs no-slash, HTTP vs HTTPS), delete or rewrite one so every request resolves in a single direction. Keep one canonical version and redirect everything else to it once.
3. Trust the forwarded protocol. If a proxy terminates SSL, configure your app to read X-Forwarded-Proto and stop redirecting requests that are already HTTPS from the visitor’s side. In many frameworks this is a single “trust proxy” setting.
4. Deduplicate redirect layers. Disable redundant plugins and consolidate rules so only one layer — CMS, .htaccess, server config, or CDN — handles each path. On WordPress, run with a single redirect plugin.
5. Clear cookies and cache. After fixing the server side, clear the affected browser’s cookies and cached files for the domain. Browsers cache 301s aggressively, so the loop can appear to persist locally even after the real fix is live.
Why This Matters for SEO and Your Sitemap
A redirect loop is not just a user-facing annoyance — it removes the page from Google entirely. Googlebot follows a chain up to a limit and then drops the URL, so a looping page is never crawled, never indexed, and cannot rank. If the loop lands on a template, a category, or your homepage, it can quietly deindex a large section of your site.
The related, less dramatic problem is the redirect chain: A redirects to B redirects to C. A chain eventually resolves, so the page still loads, but every extra hop wastes crawl budget, leaks a little link equity, and slows the page down — which feeds into Core Web Vitals. The cleanest setup is one hop maximum: every old URL should redirect straight to its final destination, and a loop should never exist at all.
Your XML sitemap should list only final, 200-status URLs — never a redirecting URL, and certainly never one that loops. A redirecting or looping URL in your sitemap tells Google “please index this” while your server says “you can never reach it,” which is a direct contradiction. You can scan for redirecting URLs, chains, and loops sitting in your sitemap automatically with the SitemapFixer tool rather than tracing every URL by hand.
301 vs 302 in a Loop
The status code does not cause the loop — the contradicting destinations do — but it changes how stubborn the loop is to clear. A 301 is permanent, so browsers and Google cache it aggressively; a looping 301 can keep firing from cache even after you fix the server, which is why clearing the cache matters so much. A 302 is temporary and cached less, so those loops tend to clear faster once the rule is corrected. For a full comparison of when to use each, see our 301 vs 302 redirects guide. The rule of thumb: use a 301 for permanent moves, a 302 only when the original URL will genuinely return, and make sure neither ever points back into the chain.
How to Validate the Fix
After deploying the fix, confirm the loop is genuinely gone before moving on:
Re-run curl. curl -sIL https://example.com/page should now end in a single HTTP/2 200 after at most one redirect, with no alternating URLs. That is the definitive proof the loop is broken at the server.
Inspect in Search Console. Use URL Inspection on the affected page, then click “Test Live URL.” A “URL is available to Google” result means Googlebot now reaches a real page. Click Request Indexing to speed up recovery for pages that were dropped.
Test across browsers. Load the page in a fresh incognito window in two different browsers. If it loads everywhere without looping, the fix is complete. If it still loops in one browser only, clear that browser’s cookies and cache for the domain.
Frequently Asked Questions
What does “too many redirects” mean?
It means a URL is caught in a redirect loop. The server keeps sending the browser from one address to another and back again, so the loop never resolves. After about 20 hops the browser gives up and shows ERR_TOO_MANY_REDIRECTS. The page never loads because there is no final destination.
How do I fix the “too many redirects” error?
Find where the loop starts with a redirect tracer or curl -sIL, then fix the rule that points back on itself. The most common fixes are correcting a conflicting HTTP-to-HTTPS or www rule, setting Cloudflare SSL to Full instead of Flexible, or removing a duplicate redirect in your CMS or .htaccess. Clear cookies and cache after fixing.
Is “too many redirects” bad for SEO?
Yes. Googlebot follows redirects up to a limit and then stops, exactly like a browser. A looping URL is never crawled or indexed, so the page cannot rank. If the loop affects a template or your homepage, it can deindex large parts of your site until you fix it.
Why does it loop in one browser but work in another?
Redirect loops are often triggered by a stale cookie or a cached 301 stored in that specific browser. Try the URL in an incognito window or a different browser. If it works there, clear the cookies and cached files for the site in the original browser to resolve it.