How to Fix ERR_TOO_MANY_REDIRECTS in WordPress

ERR_TOO_MANY_REDIRECTS means your site keeps sending the browser from one address to another in a circle, until the browser gives up. In WordPress there are three usual causes: Cloudflare’s SSL mode is set to Flexible while your server redirects to HTTPS, the site address saved in WordPress disagrees with the address your server redirects to (http against https, or www against non-www), or WordPress sits behind a proxy and does not realise the visitor is already on HTTPS. One curl command shows which addresses are bouncing, and that pattern tells you which of the three you have.

This guide covers every common cause, including the case where only /wp-admin loops, on Nginx, Apache and behind Cloudflare.

Step 1: See the loop#

Browsers hide the detail. Ask for the page from a terminal and print only the status and the address each response sends you to:

curl -sIL --max-redirs 8 https://example.com/ | grep -iE "^HTTP|^location"

On Windows, run it in PowerShell as curl.exe with the same options and read the HTTP and location lines. You will see one of these patterns:

Fix 1: Cloudflare SSL mode is Flexible#

This is the single most common cause for sites behind Cloudflare. In Flexible mode, Cloudflare talks to your server over plain HTTP, even though the visitor used HTTPS. Your server sees an HTTP request and redirects it to HTTPS. Cloudflare receives that redirect, asks again over HTTP, and the circle never ends.

In the Cloudflare dashboard, open SSL/TLS → Overview and set the mode to Full (strict). That makes Cloudflare connect to your server over HTTPS, so the server no longer needs to redirect.

Full (strict) requires a valid certificate on your server. If it has none yet, install one first, as described in how to set up free SSL on Nginx with Certbot, or on cPanel run AutoSSL. Then check that Cloudflare’s own Always Use HTTPS setting and your server’s redirect are not both adding www or removing it in opposite directions.

Fix 2: The WordPress address disagrees with the server#

WordPress stores its own address in two settings, and redirects any visitor who arrives at a different one. If your server or CDN redirects the other way, they chase each other. Look at what WordPress has stored:

wp option get home
wp option get siteurl

Without WP-CLI, look in phpMyAdmin at the siteurl and home rows of the wp_options table. Both values must be exactly the address you want visitors to end on: the same scheme (https), the same host (with or without www), and no trailing slash.

Since you cannot reach the dashboard during a loop, set them in wp-config.php, above the line that says “That’s all, stop editing”:

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

These override the database, and the site should load at once. Then make every other layer agree with that one address:

• Nginx: the server_name block that redirects should send www to non-www (or the reverse), never both ways. Search with grep -Rn "return 301" /etc/nginx/sites-enabled/.
• Apache: look for RewriteRule lines above the # BEGIN WordPress block in .htaccess. An old “force www” rule left over from a previous setup is a frequent culprit.
• cPanel: check Domains → Redirects for a redirect someone added by hand.
• Cloudflare: check Rules → Redirect Rules and Page Rules for a forwarding rule.

Fix 3: WordPress behind a proxy does not know it is on HTTPS#

When a load balancer, a reverse proxy or a CDN handles HTTPS and passes requests to your server over HTTP, WordPress sees plain HTTP, decides the visitor needs redirecting to HTTPS, and sends them back to the address they are already on. In the curl output this is the pattern where the same https:// address repeats.

The proxy tells you the original scheme in a header. Tell WordPress to believe it by adding this to wp-config.php, above the “stop editing” line:

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

If the proxy is your own Nginx in front of the site, make sure it actually sends the header:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;

Use this fix only when a proxy you trust is in front of the site. On a server that visitors reach directly, the header can be sent by anyone.

Fix 4: Only wp-admin loops#

If the public site loads and the login page keeps returning to itself, the cause is one of four things:

• The same proxy problem as Fix 3. WordPress forces HTTPS for the admin area, so it shows up there first. Apply Fix 3.
• Mismatched addresses. If siteurl has www and home does not, the login cookie is set for one host and checked on the other. Apply Fix 2 so both match.
• A stale cookie. Clear the cookies for your domain, or use a private window.
• A page cache caching the login page. /wp-admin/ and /wp-login.php must never be cached. If you set up caching yourself, check its bypass rules, as in our guide to caching WordPress pages on Cloudflare.

Fix 5: A plugin is redirecting#

If none of the above matches, a plugin is the next suspect: SSL helpers, redirect managers, multilingual and security plugins all add redirects. Since you cannot log in, switch plugins off from the file system. Rename the folder, test, and rename it back:

mv wp-content/plugins wp-content/plugins.off
curl -sI https://example.com/ | head -1
mv wp-content/plugins.off wp-content/plugins

If the site answers 200 with plugins off, the loop is in one of them. Log in, then activate them one at a time until it returns. On shared hosting, rename the folder in cPanel’s File Manager instead. “Really Simple SSL” and similar plugins are a common cause when they are left active after the server or Cloudflare has taken over the HTTPS redirect: one layer should own that redirect, not three.

Check the result#

Run the first command again. A healthy site shows at most two hops and ends on 200:

HTTP/2 301
location: https://example.com/
HTTP/2 200

Test all four starting points, because each takes a different path through your rules: http://example.com, http://www.example.com, https://example.com and https://www.example.com. All four should end at the same address.

Common mistakes to avoid#

• Clearing cookies and stopping there. It only helps when a stale cookie was the cause. If the loop shows in curl, it is on the server.
• Adding another redirect rule to “fix” it. Loops come from too many rules. Remove one.
• Leaving Cloudflare on Flexible. Besides loops, it sends your visitors’ data to your server unencrypted.
• Setting WP_HOME with a trailing slash or the wrong scheme. It must match the final address exactly.
• Trusting the X-Forwarded-Proto header on a server with no proxy. Only use Fix 3 when a proxy really is in front.
• Testing in the same browser window. It replays the redirect it remembered.

Hosting with HTTPS already set up#

On SiteHarbour WordPress hosting, a free SSL certificate is in place from the start, so there is one HTTPS redirect, owned by the server, and nothing to conflict with it. If you put Cloudflare in front, choose Full (strict) and it works without further changes.

Frequently asked questions#

Is ERR_TOO_MANY_REDIRECTS a problem with my browser?#

Rarely. If the site fails in a private window and in curl, the cause is on the server or CDN. If it fails only in your usual window, clearing that site’s cookies fixes it.

Why did it start right after I enabled Cloudflare?#

Cloudflare’s SSL mode was Flexible while your server already redirected to HTTPS. Change the mode to Full (strict).

Why did it start after installing an SSL certificate?#

The WordPress address was still http:// while the server now redirects to https://. Update both WordPress addresses to https, as in Fix 2.

Can I fix it without access to wp-admin?#

Yes. Every fix here is made in wp-config.php, the server configuration, the Cloudflare dashboard or the plugins folder. None needs the WordPress dashboard.

Does this error hurt my search ranking?#

While it lasts, search engines cannot read the affected pages. Fixed within a day or two, it leaves no lasting effect.

The short version: run curl -sIL and look at which addresses alternate. Same address repeating means the server does not know it is on HTTPS; http and https, or www and non-www, alternating means two rules disagree. Make one layer own each redirect, and make WordPress’s two addresses match where it ends.