How to Fix ERR_TOO_MANY_REDIRECTS in WordPress

ERR_TOO_MANY_REDIRECTS in WordPress means two redirects are fighting: something sends the visitor from A to B, and something else sends them straight back from B to A, until the browser stops playing along and shows the error. The fix is never to guess at settings but to find which two layers are arguing. In practice it is nearly always one of five things: your host and a plugin both forcing HTTPS, two conflicting www rules, Cloudflare’s SSL mode set to Flexible, a cache still serving an old redirect, or a single rule that points at itself.

The frustrating part is that each of those looks correct on its own. Nothing in your dashboard says “loop”. So work through the layers in a fixed order rather than changing several settings at once, which is how people end up with a second loop on top of the first.

What a Redirect Loop Actually Is

Every redirect is an instruction: go to this other URL instead. A loop happens when following that instruction produces another instruction that leads back to where you started. Browsers follow a limited number of hops, usually around twenty, then stop and report too many redirects rather than spinning forever.

The important consequence is that a loop is a relationship between two rules, not a broken rule. Both rules can be individually correct and still be incompatible. That is why staring at your redirect plugin often reveals nothing: the other half of the argument is at your host, in your CDN, or in a WordPress setting.

The Most Common Cause: Two Things Forcing HTTPS

This one accounts for a large share of loops. Your host has an option to force HTTPS. Your security or SSL plugin has the same option. Something in htaccess may also be doing it. Turn on two of the three and they can hand the request back and forth, particularly when one of them decides the request is insecure based on information the other has already changed.

The fix is to pick exactly one layer to force HTTPS and turn it off everywhere else. Preference order: your host’s setting or server configuration first, then a single plugin, and nothing in htaccess as well. Check all three before you conclude none of them is on, because the host setting is often enabled by default on modern hosting.

www Rules That Collide

The second classic is a disagreement about www. One layer redirects the non-www version to www, another redirects www back to non-www, and the visitor bounces between them. This often appears after a migration, when new host settings meet old rules that were written years ago.

Check three places. In Settings, General, your WordPress Address and Site Address should both use the same version, with the same protocol. Your host’s domain settings should point the same way. And any rule in your redirect plugin or htaccess that mentions www should agree with both. If you are unsure which version to standardise on, either is fine for SEO as long as you commit to one.

Cloudflare’s Flexible SSL Mode

If the loop started when you added Cloudflare, check the SSL mode before anything else. Flexible means Cloudflare talks to your server over plain HTTP even though visitors reach Cloudflare over HTTPS. Your server sees an insecure request, dutifully redirects it to HTTPS, that request goes back to Cloudflare, and the cycle repeats.

Set the mode to Full (strict) once your origin server has a valid certificate, which most hosts now provide for free. This is not a WordPress bug and no amount of plugin fiddling will fix it, which is why it wastes so many hours. The same logic applies to any proxy in front of your site that terminates HTTPS and then talks to your origin in plain HTTP.

Caches and Self-Referencing Rules

Two smaller causes worth ruling out. First, caching: you may have already fixed the loop, but a cache is still serving the response from before your fix. Browsers also cache permanent redirects aggressively, so a 301 you have since removed can persist in your own browser long after it is gone from the server. Test in a private window, purge every cache layer, and read why caching keeps serving your old redirect if this is a recurring pattern.

Second, a rule that points at itself, or two rules that point at each other. Redirecting /old-page/ to /new-page/ while /new-page/ still redirects back to /old-page/ is easy to create over months of tidying, especially if two people manage the site or two redirect plugins are active at once. Never run two redirect plugins together.

Step-by-Step Diagnosis

Do this in order and change one thing at a time. Open the URL in a private window, and clear cookies for the site if the loop follows you there. Run the URL through a redirect checker so you can see the actual chain of hops and where it turns back on itself, which usually names the culprit outright.

Then check, in order: your CDN or proxy SSL mode; every force-HTTPS switch across host, plugins and htaccess; your WordPress Address and Site Address; your www rules in all three places; and finally your own redirect list for a self-referencing rule. If you are locked out of wp-admin, rename the suspect plugin’s folder over FTP to deactivate it and regain access. Purge all caches after each change, or you will be reading a stale answer.

How to Stop It Happening Again

Loops are a bookkeeping problem more than a technical one. They happen when nobody can see all the redirects at once, so decide up front which layer owns which job: one place forces HTTPS, one place handles www, and everything else lives in a single redirect tool where you can read the whole list on one screen.

Keeping rules in one auditable place is exactly why we built DevDome Redirect Manager around a visible list with an explicit type per rule, plus automatic cache purging so a fix reaches visitors immediately instead of being hidden behind a stale cache. Whatever tool you use, after any redirect change, test logged out, check the chain from outside, and make sure the status code is still the type you intended.