ERR_TOO_MANY_REDIRECTS: Breaking a WordPress Redirect Loop

The browser tries your site, gets told to go somewhere else, goes there, gets told to go somewhere else again — and after about twenty attempts it stops and shows "ERR_TOO_MANY_REDIRECTS".

A WordPress redirect loop is almost always two things disagreeing about where a page should live. Neither is wrong on its own; together they form a circle.

Diagnose the loop before changing anything

This is worth doing first, because guessing produces new loops rather than fixing the existing one.

Open your browser's developer tools, go to the Network tab, tick "preserve log", and load the failing URL. You will see the chain of requests and exactly which URL redirects to which.

The pattern tells you the cause immediately:

• http:// → https:// → http:// — an HTTPS configuration conflict
• example.com → www.example.com → example.com — a www conflict
• A page redirecting to itself — a redirect rule with the same source and destination
• Everything redirecting to /wp-login.php — a login or permissions issue

Thirty seconds of looking beats an hour of trial and error.

Cause 1: HTTPS configured in two places

The most common cause by far, and it usually appears right after installing an SSL certificate.

The scenario: your host redirects HTTP to HTTPS at server level. You also install an SSL plugin that does the same thing. Meanwhile WordPress still has http:// in its settings, so it redirects HTTPS back to HTTP — and round it goes.

To fix it, pick one place to handle the redirect and remove the others:

1. Set both WordPress Address and Site Address to https:// under Settings → General
2. Keep the redirect at server level in .htaccess or your host's panel
3. Remove the redirect from any SSL plugin, or remove the plugin if that was all it did

If you cannot reach the dashboard to change the settings, define them in wp-config.php temporarily:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

This overrides the database values and usually gets you back in.

Cause 2: A reverse proxy or CDN

A subtle variant worth knowing. If you use a CDN or load balancer that terminates SSL, it talks to your server over plain HTTP. WordPress sees an insecure request, decides it should be HTTPS, and redirects — but the visitor was already on HTTPS.

The fix is to tell WordPress to trust the proxy's header. In wp-config.php, above the line that says to stop editing:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }

If you use Cloudflare, also check the SSL mode. "Flexible" is a common cause of exactly this loop — "Full" or "Full (strict)" is generally correct when your origin has its own certificate.

Cause 3: www and non-www disagreeing

WordPress redirects to whichever form is in its settings. If your server or a plugin redirects to the other form, they fight.

Decide which version is canonical, set it in WordPress settings, and make sure every other redirect rule agrees. It genuinely does not matter which you choose — only that everything chooses the same one.

Cause 4: Conflicting redirect rules

Over time sites accumulate redirects in several places: a redirection plugin, .htaccess, the host's panel, an SEO plugin. Nobody has the full picture, and eventually two rules point at each other.

Check all four locations. A rule redirecting a URL to itself is a loop of one, and it is easier to create than you would think — particularly after changing a page slug.

Cause 5: Cookies and cached redirects

Sometimes the loop is already fixed and your browser has not noticed. Redirects get cached aggressively, especially 301s, which browsers treat as permanent.

Always test in a private window, or clear cookies for the domain, before concluding a fix did not work. Clear your caching plugin and CDN cache too.

This catches people out constantly — the fix worked, the browser is just still following its cached instruction.

The emergency route back in

If you are fully locked out, work at file level rather than through the dashboard.

1. Rename .htaccess to .htaccess-old to disable all server-level rules
2. Rename wp-content/plugins to disable every plugin
3. Set WP_HOME and WP_SITEURL in wp-config.php
4. Load the site in a private window

With all three done, the loop will almost certainly break. Then restore things one at a time until it returns, and you have found your culprit.

One thing to rule out

If the loop appeared with no changes on your side, read .htaccess carefully before assuming it is a configuration fault.

That file is a favourite target, because rules there execute before WordPress does. A compromised site can end up with redirect rules pointing somewhere else entirely, and a badly written one produces a loop rather than a working redirect.

If there are RewriteRule lines pointing at domains you do not recognise, this is not a configuration problem.

Our guides to the WordPress redirect hack and removing malware cover what to do next.

Keeping redirects manageable

The underlying problem on most sites is that nobody knows where all the redirects live. Some habits that help:

• Manage redirects in one place and document where that is
• Handle the HTTP-to-HTTPS and www decisions at server level only
• Remove SSL plugins once the certificate is properly configured — they are a migration tool, not a permanent fixture
• Review the redirect list periodically and remove rules for pages that no longer exist
• Always test redirect changes in a private window

If you are locked out right now

A redirect loop takes the entire site offline for everyone, including you — which makes it one of the more stressful errors, because the usual fix route is the thing that is broken.

Our WordPress error fixing service works at file and server level to break the loop, then sorts out the redirect configuration so it does not recur.

Send us your web address and what changed just before it started — usually an SSL certificate, a CDN, or a migration.