How to Fix a Redirect Loop (ERR_TOO_MANY_REDIRECTS)

A redirect loop happens when a URL redirects back to itself, directly or through a cycle of other URLs, so the browser never reaches an actual page. The visitor sees ERR_TOO_MANY_REDIRECTS (Chrome) or "the page isn't redirecting properly" (Firefox), a full page failure, not a slow one. That makes it a different problem from our 301 vs 302 redirects guide's "redirect chain" issue: a chain is multiple hops that eventually reach a working page, just with wasted signal and latency along the way. A loop never reaches one at all.

The Four Usual Causes

• HTTP-to-HTTPS conflicts between your server and CDN. Your CDN forces HTTPS and redirects http:// to https://; your origin server is separately configured to redirect https:// back to http://. Each one is individually correct, together they loop forever. This is the single most common cause on sites behind Cloudflare or a similar CDN.
• WWW canonicalization fighting itself. One layer redirects www to non-www, another redirects the same domain the opposite way. Usually introduced when a CMS-level setting and a server or CDN-level rule are both trying to enforce canonicalization independently.
• A CMS plugin or app-level redirect rule conflicting with a server-level one. Common on WordPress specifically: an SEO plugin's redirect settings and an .htaccess rule both try to handle the same URL pattern.
• Cookie or session-based redirect logic with a bug. A login wall or geo-redirect that's supposed to check a cookie before redirecting, but the cookie never gets set correctly, so every request re-triggers the same redirect.

How to Find Which One You've Got

1. Check the affected URL's protocol and host carefully first. Is the loop between http and https? Between www and non-www? The exact pattern usually points straight at the cause.
2. Look at each layer independently: CDN/proxy rules, server config (.htaccess, nginx config), CMS or plugin-level redirect settings, and application code, in that order from outermost to innermost. The loop is almost always two of these layers disagreeing, not one layer being wrong on its own.
3. Clear cookies and try again in a private/incognito window before assuming it's a config issue - a stale cookie from a previous, already-fixed redirect rule can cause a loop that a fresh session won't reproduce.
4. Fix the conflict at one layer, not both. Once you've found the two rules fighting, pick the layer that should own the decision (usually the CDN, since it runs first) and remove or disable the equivalent rule everywhere else.

Why This Is Worse Than a Slow Chain

A redirect chain dilutes ranking signal and adds latency, a real but gradual problem. A loop is binary: the page returns nothing to visitors or to Google's crawler at all. If a URL that used to rank suddenly vanishes from search results entirely rather than slipping down the rankings, a redirect loop introduced by a recent CDN, hosting, or plugin change is worth checking before anything else - see our guide to why your website isn't showing up on Google for the fuller diagnostic list this fits into.

Common Questions

Why does this only affect some pages, not the whole site? Redirect rules are often scoped by path or protocol, so a loop introduced by one rule (say, an HTTPS enforcement change) can affect only URLs matching that specific pattern rather than every page.

Can I fix this without server access? Not fully. Diagnosing which layer is responsible doesn't need server access, but fixing it does, since the conflicting rule lives in server config, CDN settings, or a plugin's admin panel, not anywhere a browser-side check can reach.

Will this hurt my rankings even after I fix it? Once the loop is fixed and the URL resolves normally again, Google typically recrawls and re-indexes it on its usual schedule; there's no separate penalty to recover from beyond the temporary loss of that page from search results while it was broken.

The Fast Way to Check Yours

Following every redirect on a site by hand to confirm none of them loop is impractical past a handful of URLs. AuditCrow's free scan follows each page's redirect chain as part of its crawlability review and flags a URL that fails to reach a working destination, so a loop introduced by a recent CDN or plugin change surfaces automatically rather than waiting for a visitor to report a broken page.