ERR_TOO_MANY_REDIRECTS on WordPress: four loops we reproduced and what fixed each

What does ERR_TOO_MANY_REDIRECTS mean on a WordPress site?

ERR_TOO_MANY_REDIRECTS on a WordPress site means the browser asked for a page, was told to go somewhere else, and kept being told that until it stopped. Chrome shows it as “This page isn’t working. The site redirected you too many times.” Visitors see nothing else, so for them the site is down.

The odd part, in our lab, was where the loop pointed. With one setup the https home page redirected to the https home page, the exact address the browser had just asked for, 11 times in a row.

Fixes like this sit under one-off fixes on our WordPress maintenance page, where we take a backup or a staging copy before we touch anything.

How did we test it?

On 13 Oct 2026 we ran WordPress 7.1.2 on PHP 8.4.26 and Apache 2.4.68 in Docker, with nginx in front as the proxy. The nginx container stood in for Cloudflare or any other service that handles https for you. It could talk to WordPress over http or https, and send the X-Forwarded-Proto header or not.

We did not use a real Cloudflare account. When we say Flexible below, we mean our simulation of it: https from the visitor to the proxy, plain http from the proxy to the server.

For every case we ran one command and counted the redirects:

curl -skIL --max-redirs 10 https://yoursite.com/ | grep -i location

A working page gave 0 or 1 Location lines. A loop gave 11, and curl ended with exit code 47, which means it hit its redirect limit. Chrome and Firefox follow up to 20 before they show the error, but an endless loop ends there either way.

Two notes on the command. Drop the -k on a live site; we needed it only for the lab’s self-signed certificate. And -I sends a HEAD request, which some servers answer differently from a normal page load. We ran HEAD only, so if HEAD shows no loop, try curl -sL --max-redirs 10 -o /dev/null -D - https://yoursite.com/ | grep -i location as well.

Does the Location output tell you which loop you have?

It tells you that you have a loop and what the loop is bouncing between. It does not name the cause.

In our runs the pattern gave a hint. An address that redirected to itself meant the server could not see the request was already https. Two addresses taking turns, with and without www, meant two rules disagreed. But the same pattern can come from more than one setting, so check each of the four below.

Does a WordPress Address and Site Address mismatch cause the loop?

Not on its own, in our lab. We set the WordPress Address (siteurl) to http and the Site Address (home) to https. The home page loaded with no redirect, and /wp-admin/ made one hop to the login page.

The loop came when we added the most common force-https rule to .htaccess, RewriteCond %{HTTPS} !=on, with the proxy talking http to the server. Then the home page and /wp-admin/ both looped, 11 hops, from the http and the https entry.

What cleared it: both addresses set to the same https URL, and the server seeing real https from the proxy. After that the https home page made 0 hops and the http entry made 1.

If the loop has locked you out of wp-admin, our post on fixing a WordPress Address change that locks you out has the two wp-config.php lines that get you back in.

Why does Cloudflare Flexible SSL loop with an https redirect?

Flexible sends the visitor’s request to your server over plain http. If the server redirects every http request to https, the visitor is sent back to https, the proxy asks over http again, and it repeats. Cloudflare’s own ERR_TOO_MANY_REDIRECTS page (checked 13 Oct 2026) describes the same loop.

Cloudflare’s “Always Use HTTPS” setting is a redirect at the edge, not on your server. It is the origin’s https redirect that loops under Flexible.

In our simulation the home page and wp-login.php both looped at 11 hops. Two things fixed it:

1. Switching the proxy to talk https to the server (Full in Cloudflare’s terms). The same .htaccess rule stayed in place, and both pages made 0 hops.
2. Staying on Flexible and removing the origin’s https rule. This fixed the home page only.

The second one surprised us. The home page went to 0 hops, but wp-login.php kept looping with 302 redirects. WordPress itself was sending the login page to https, because it still saw every request as http.

Is a reverse proxy hiding the https request from WordPress?

If your login page or wp-admin loops behind a proxy, probably. WordPress decides whether a request is https from what the web server tells it. When the proxy ends https and talks http to the server, WordPress cannot tell.

The fix has two halves. The proxy sends X-Forwarded-Proto: https, and wp-config.php reads it, above the line that says “That’s all, stop editing!”:

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

The WordPress HTTPS documentation (checked 13 Oct 2026) gives the same check. Only add it when your own proxy sets that header. Otherwise any visitor could send it.

We tested each half alone with FORCE_SSL_ADMIN on:

One thing we did not expect: the official WordPress Docker image already ships these lines in wp-config.php. We switched them off for the test, to match a host that does not have them.

Does an .htaccess https rule see the wp-config.php fix?

No. The wp-config.php lines change what PHP sees. Apache reads .htaccess before PHP runs, so a plain %{HTTPS} rule still saw http and looped, with the header and the lines both in place.

The rule needs its own check of the header:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

With that second condition the home page made 0 hops. (Our lab rule used a fixed address because of its test ports. On a real site %{HTTP_HOST} fills in your own domain.)

If you would rather not edit wp-config.php or .htaccess on a live site, this is a one-off fix we do: we take a backup first, find the rule behind the loop, and tell you what we will change before we change it.

Are two redirect rules fighting over www?

That is the loop where the Location lines take turns: www, then without www, then www again.

We built it three ways and each looped at 11 hops:

• The Site Address set to www, with an .htaccess rule sending www to the address without it.
• The Site Address without www, with a redirect plugin rule sending visitors to www.
• The plugin rule and the .htaccess rule both on, pointing at each other.

The plugin was a small stand-in we wrote that redirects on every page load, not a real redirect plugin from wordpress.org. The fix was the same each time: decide which address is the real one and keep one rule. When we set the Site Address to match the .htaccess rule, or removed the plugin rule, the main address made 0 hops and the other made 1.

To find the second rule on your site, read the .htaccess lines above # BEGIN WordPress, then check your redirect plugin’s list. Your host’s control panel or your CDN may have one too.

What did we not test?

• Real Cloudflare. Our proxy was nginx simulating Flexible and Full.
• A real redirect plugin. The www tests used a stand-in that calls wp_redirect.
• How each browser words the error page. We counted redirects with curl.
• Whether HEAD and GET requests differ on any of these setups.
• nginx as the web server behind the proxy, multisite, and redirects set by managed hosts.

The database side of a broken site is a different fault. Our test of the Error establishing a database connection page covers it.

If the loop is gone but the https page still shows a warning or a missing image, that is mixed content, not a redirect. Our guide to WordPress mixed content shows how to find the old http:// links.

Is your site stuck in a redirect loop right now?

Send us your address and the Location lines from the curl command, or just the message you see, and we will tell you which rule is sending visitors round in circles.

Not sure what is wrong yet? Ask for the free site check: send the site address and we reply in writing within 2 business days. If you already know what to fix, the one-off fixes are listed here.