Guides · July 23, 2026 · 6 min read

Too Many Redirects: What Causes It and How to Fix It

too many redirects

A too many redirects error means your browser followed a chain of redirects, noticed it was going in circles, and gave up. Chrome shows it as “This page isn’t working — example.com redirected you too many times” with the code ERR_TOO_MANY_REDIRECTS. Firefox says the page “isn’t redirecting properly.” Safari calls it a redirect loop. Same problem, different wording.

The page is not down. Your server is answering every request — it is just answering with an instruction to go somewhere else, and that somewhere eventually points back. Browsers cut this off after about twenty hops. So does Googlebot, which is why an uncaught loop takes pages out of the index rather than merely annoying visitors.

Is it your site or your browser?

Settle this first, because the fix is completely different. Open the URL in a private window, and on a different device or network. If it loads fine there, the problem is local to your browser session. If it fails everywhere, it is server-side.

For the local case — the too many redirects chrome version of the problem — the culprit is almost always a stale cookie. Many redirect loops are driven by cookie state: a login check redirects to a sign-in page, the sign-in page sees a partial cookie and redirects back. Clear cookies for that specific domain rather than wiping everything: in Chrome, click the icon left of the address bar, choose Cookies and site data, then delete the entries for that site. Reload. That resolves the majority of user-side reports.

A second local cause worth ruling out: browser extensions that rewrite URLs, particularly privacy tools that strip tracking parameters or force HTTPS. Disable them and retry before you go digging through server configs. And remember that browsers cache 301 responses aggressively — if you have already fixed a bad permanent redirect, your own browser may keep replaying the old one long after the server stopped sending it.

If clearing cookies fixes it for you but users keep hitting it, the underlying bug is still on the server. A cookie clear is a workaround, not a repair.

Six causes of a server-side redirect loop

When the loop is real, it is nearly always one of these:

  • Conflicting HTTPS and www rules. One rule forces HTTPS, another forces www, and they are ordered so each undoes the other. This is the single most common cause.
  • CDN SSL mode mismatch. Cloudflare set to “Flexible” SSL requests your origin over HTTP; your origin redirects all HTTP to HTTPS; Cloudflare requests over HTTP again. Infinite loop. Set SSL to Full or Full (Strict).
  • Wrong site URL in the CMS. A WordPress install with siteurl set to http:// while the server forces https:// will bounce forever.
  • Two redirect systems fighting. A plugin rule and an .htaccess rule that each own the same path.
  • Trailing slash disagreement. One rule adds a slash, another strips it.
  • A self-referencing redirect — a rule whose destination matches its own pattern, so it fires against its own output.

Diagnosing it in under a minute

Skip the browser. Ask the server directly and read the hops:

curl -sIL --max-redirs 10 https://example.com/ | grep -E "HTTP/|location"

The output shows every status code and every Location header in sequence. A loop is obvious immediately: you will see the same two URLs alternating, or a URL appearing twice. That pairing tells you exactly which two rules are arguing.

Chrome DevTools gives you the same picture visually. Open the Network tab, check “Preserve log,” load the URL, and read the chain of 301s and 302s down the request list. Either way, the goal is the same — identify the two addresses bouncing off each other, then find the rules that produce them.

Two details make the diagnosis faster. Test with and without a trailing slash, and with and without the www prefix — the loop often only fires on one variant, and that alone identifies which rule is at fault. Also test with cookies suppressed, which curl does by default; if the loop disappears without cookies, you are looking at application logic rather than a rewrite rule, and the fix belongs in the authentication or localization code rather than the server config.

Fixing it on the server

Once you know the pair, the repair is usually small. Three principles cover most cases.

First, redirect in one hop. Combine protocol and hostname into a single rule so a visitor on http://example.com lands on https://www.example.com without an intermediate stop:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Second, make every rule exclude its own destination. A rule that rewrites to a pattern it also matches will fire against its own output forever. The RewriteCond lines above do exactly that job — the rule only fires when the request is not already correct.

Third, keep all redirects in one layer. Pick the server config, the CMS plugin, or the CDN — not two of them. Most loops I have untangled were caused by a rule someone added at the edge years earlier that nobody remembered.

For WordPress specifically, check Settings → General and confirm both the WordPress Address and Site Address use the exact same protocol and hostname your server enforces. A mismatch there produces a loop no .htaccess edit will fix. If you are locked out of admin, set them directly in wp-config.php with WP_HOME and WP_SITEURL.

How to fix too many redirects: a working checklist

  1. Reproduce in a private window on another network to confirm it is server-side.
  2. Run the curl command and write down the looping pair of URLs.
  3. Check your CDN’s SSL mode — set it to Full (Strict) if the origin has a valid certificate.
  4. Check the CMS site URL settings match what the server enforces.
  5. Disable redirect plugins one at a time and retest.
  6. Review .htaccess or the nginx server block for two rules touching the same path.
  7. Consolidate to one rule, one hop, with a condition that excludes the destination.
  8. Clear the CDN cache, then retest with curl before trusting a browser.

Catching loops before your users do

Redirect loops rarely appear on the homepage, where you would notice immediately. They appear on one product category, one language subfolder, or one legacy URL pattern — quietly, for weeks. Search Console will eventually report them under “Redirect error” in the Pages report, but by then the affected URLs have already been dropping out of the index.

The reliable prevention is a periodic full-site crawl that follows every hop and flags any URL that fails to resolve. SEO Rocket’s technical audit does this across entire sites — verified past 900 pages — and returns evidence per issue rather than a total: the exact URLs, their redirect targets, and the titles and tags found at each end, so you can trace a loop back to the rule that caused it. It also reports PageSpeed and Core Web Vitals with real-user field data alongside lab metrics, which is where the latency cost of long redirect chains actually shows up. It will not edit your .htaccess or change your CDN settings — that part stays with you.

Run the crawl after every migration, plugin change, or CDN configuration edit. Those three events cause almost every loop that ever reaches production, and a five-minute check afterwards is cheaper than finding out from a customer.

Keep reading