A redirect loop is one of the more disorienting server problems to diagnose: the symptom is immediate and obvious — the browser refuses to load — but the cause is invisible unless you can see every hop in the chain. You can't spot a loop by looking at a single redirect rule. The conflict is between two rules that each appear correct in isolation but cancel each other out when combined.
This is why redirect loops often survive for hours after a deployment: the developer checks their HTTPS redirect rule, sees it looks fine, and moves on — without realising there's a second rule somewhere else pointing in the opposite direction.
Key Takeaways
- A redirect loop causes "ERR_TOO_MANY_REDIRECTS" in browsers and prevents Googlebot from crawling any URL in the chain
- The most common cause is an HTTP→HTTPS redirect conflicting with a HTTPS→HTTP setting elsewhere (e.g. server config vs. CMS plugin)
- www vs. non-www redirect rules can create loops if both directions are set simultaneously
- Redirect loops are invisible in standard site crawls — you need to trace the specific URL chain to see where the loop forms
- Once found, loops are usually fixed by removing one conflicting redirect rule — not by adding more redirects
What Causes Redirect Loops
Redirect loops always come from conflicting rules — two separate configurations that each redirect away from the other's destination. Here are the most common patterns.
HTTP / HTTPS Conflict
A server redirect forces HTTP → HTTPS, but another rule — in .htaccess, a plugin, or the CMS settings — forces HTTPS → HTTP. The two rules create a loop. This is the most common cause on WordPress sites with SSL plugins. The server (or CDN) handles HTTPS enforcement correctly, but then a plugin like "Really Simple SSL" or a CMS setting also tries to force the scheme — in the wrong direction, or redundantly triggering a round-trip.
www / non-www Conflict
A rule forces www. → non-www, and a second rule forces non-www → www.. Setting both simultaneously — even if they're in different config files or layers — creates an infinite loop. The correct approach is to pick one canonical form and redirect the other to it in exactly one place.
Canonical Redirect Conflicts
A page at URL A has a canonical tag pointing to URL B, but URL B has a server-level redirect back to URL A. The redirect and the canonical create conflicting signals. While this doesn't always produce a hard browser loop, Googlebot can't resolve the chain and may report both URLs as having errors in Google Search Console.
CDN / Proxy Layer Conflict
A CDN rule (Cloudflare page rule, AWS CloudFront behaviour, Vercel edge config) redirects one way, and the origin server redirects the opposite way. This is particularly common when migrating between infrastructure providers — old origin rules linger while new CDN rules are added on top.
CMS Plugin Conflicts
Two active redirect plugins both managing the same URL with conflicting rules. WordPress is the most common environment for this: a site may have Yoast, Rank Math, Redirection, and Really Simple SSL all active and all trying to enforce redirect policies on the same URLs.
How Googlebot Handles Loops
Googlebot follows a redirect chain up to approximately 5 hops. A loop is detected when a URL appears twice in the chain. When this happens, Googlebot reports the URL as having a "Redirect error" in Google Search Console's Coverage report and cannot index any page in the loop.
Unlike browsers — which detect the loop immediately and show ERR_TOO_MANY_REDIRECTS after about 20 hops — Googlebot stops earlier but may not detect the loop until after several hops. A loop that forms at hop 4 still causes Googlebot to crawl the first 3 URLs before failing. This means multiple pages can end up in an error state in GSC, even though only one redirect rule is at fault.
The practical consequence: if you see a cluster of "Redirect error" URLs in GSC Coverage, and they all share a common base path or domain pattern, a loop is the likely cause — not individual broken links.
Tracing the Loop
You can't fix a loop you can't see. The challenge is that browser developer tools show you only the final error state, not the full chain of hops that produced it. To diagnose a redirect loop, you need to follow each hop individually.
Use the ByteWaveNetwork Redirect Tracer:
- Enter the looping URL into the Redirect Tracer
- The tracer follows each redirect hop in sequence, recording the full URL, status code, and Location header at each step
- When a URL appears twice in the chain, the loop point is identified — you can see exactly which hop circles back to a URL already in the chain
Without a tracer, you'd need to manually follow each curl -I request in sequence, or step through browser developer tools hop by hop with cache disabled. The tracer does this in one pass and shows the full chain in a single table.
The output tells you not just that a loop exists, but which specific URLs are involved — which points directly to which redirect rule is conflicting with which other rule.
Fixing Common Loop Types
HTTP ↔ HTTPS Loop
Check two places:
- Your server config (Apache
.htaccessor Nginx config) — look for aRewriteRuleorreturn 301that handles HTTP→HTTPS - Your CMS settings or plugins — look for any "Force HTTPS" or "Force HTTP" setting
If both layers have a force rule, remove one. The correct configuration is to enforce HTTPS at the server level only; no CMS-level force rule is needed if the server already handles it.
Correct Apache .htaccess configuration:
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]With this in place, disable any "Force HTTPS" setting in your CMS or SSL plugin. The server redirect fires before the CMS ever runs, so the CMS rule can't execute — but if the plugin also sets an HTTP response header or cookie that triggers a redirect, a conflict can still occur. Remove the plugin rule entirely rather than relying on execution order.
www ↔ non-www Loop
Pick one canonical domain (www or non-www) and redirect the other to it. The redirect should exist in exactly one place — either in your server config, or your CDN rules, but not both. Remove any conflicting rule from the other layer.
If you've set a www → non-www redirect in Nginx and a non-www → www redirect in a Cloudflare page rule, both rules are active simultaneously for requests that hit the CDN. One of them must be removed.
CDN + Origin Loop
Identify which layer owns the redirect by temporarily bypassing one. If your CDN supports an "origin pull" mode or a bypass header, use it to send a request directly to the origin and trace the chain there. If the loop disappears, the CDN rule is conflicting with an origin rule.
Common scenario: an origin server has a redirect from HTTP → HTTPS, and a CDN terminates TLS and forwards requests to the origin over HTTP. The origin sees an HTTP request, fires its HTTPS redirect, which the CDN sends back — but the CDN itself already redirected the user to HTTPS, so the origin redirect is redundant and potentially conflicting. Fix: disable the origin HTTPS redirect and let the CDN handle it, or configure the origin to trust the X-Forwarded-Proto header and skip the redirect when the request arrived as HTTPS at the edge.
Plugin Conflict
Deactivate redirect plugins one at a time and re-test with the Redirect Tracer after each deactivation. When the loop resolves, the last deactivated plugin was the conflict source. Re-activate the others; leave the conflicting plugin deactivated and configure the redirect it was enforcing at the server level instead.
On WordPress, the safest redirect architecture is: all HTTP→HTTPS and www canonicalisation handled at the server or CDN level, no plugin touching those rules. Plugin-level redirects should only be used for content URL changes (old-slug → new-slug), not protocol or domain enforcement.
Preventing Loops
Redirect loops are almost always a documentation and process failure, not a technical complexity problem. The fix is straightforward once you can see the chain; the damage comes from how long the loop goes undetected.
- Document every redirect rule and which layer it lives in: server config, CDN, CMS, plugin. Keep this in a single place — a comment block in your
.htaccess, a README in your Nginx config directory, a note in your infrastructure runbook. - Test redirect rules with the Redirect Tracer immediately after implementation, before the deployment is considered complete
- Never set redirects in both directions for the same URL pair — pick a canonical direction and enforce it in one place
- After any CMS plugin update, server config change, or CDN rule modification, re-test key URLs through the tracer. Plugin updates can silently re-enable redirect rules that were previously disabled.
- Add redirect loop checking to your post-deployment checklist alongside HTTP status checks and SSL verification
Trace Redirect Chains Instantly
Free, no signup. The Redirect Tracer follows every hop in a redirect chain — URLs, status codes, timing — and flags loops, chains over 3 hops, and final destinations. Diagnose any redirect issue in seconds.
Try the Redirect Tracer Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.