Skip to content

How to fix ERR_TOO_MANY_REDIRECTS in WordPress

ERR_TOO_MANY_REDIRECTS means the site keeps sending the browser from one address to another and never to a page. Two parts of the setup disagree about the site's address, usually over https or www. Find the addresses the loop runs between, then make WordPress and the server agree.

By
WP Ministry
Published
Tested on
WordPress 7.1.3, PHP 8.3.35

In short

  • Your content is untouched. Two parts of the setup disagree about the site's address and pass visitors back and forth.
  • Test in a private window first. A browser can keep following a redirect the site no longer sends.
  • A redirect checker shows each hop. How the looping addresses differ, by www or by https, points at the cause.
  • WordPress sends visitors to the www or non-www form in its Site Address. The server must not send them to the other.
  • Behind a CDN or proxy that connects to your server over plain http, WordPress has to be told the visitor is on https.
  • If the addresses agree, look for a redirect rule in .htaccess, then for a redirect or SSL plugin.

ERR_TOO_MANY_REDIRECTS means the browser asked for a page, was sent on to another address, then another, and gave up because the chain never reached a page. Chrome heads it "This page isn't working" and says your domain "redirected you too many times." Firefox heads it "The page isn't redirecting properly". Two parts of the setup disagree about the site's address, and each keeps sending the visitor to the other.

Nothing has been lost. Your posts, pages and uploads are as they were, and every fix below changes a setting, not your content.

See which addresses the loop runs between

Put your site's address into the redirect checker. It shows what an address answers and every redirect on the way: each hop, its status code and where it sends you next. In a loop, the last hop leads back to an address already in the list. Look at how the addresses in the circle differ.

  • One has www and the other does not. WordPress and the server each insist on a different form of the domain. Use the second fix.
  • One is http and the other https, or an https address redirects to itself. Something forces https and never sees it arrive. If a CDN or proxy sits in front of the site, use the third and fourth fixes. If none does, use the fifth.
  • Neither. Use the fifth fix, then the sixth.

If the login page loads and comes back empty after you press Log In, that is a different fault: see the login page that keeps refreshing or redirecting.

Where it goes wrong

A page request passes through each of these in turn. This one comes from the web server.

  1. Browser
  2. DNS
  3. HTTPS
  4. CDN or firewall
  5. Web server (this error comes from here)
  6. PHP
  7. WordPress
  8. Database and files

What causes it

  • WordPress and the server want different forms of the domain

    Common

    WordPress sends every visitor to the form of the domain in its Site Address, with www or without. If the host, a CDN or a server rule sends visitors to the other form, each hands the visitor back to the other.

    Fix: Give WordPress the form of the address the server uses

  • A CDN or proxy connects to your server over plain http

    Common

    The visitor's https connection ends at the proxy, which asks your server for the page over http. WordPress, or a rule on the server, answers by redirecting to https. The proxy asks over http again.

    Fix: Tell WordPress the visitor is on https, or Have the CDN or proxy connect to your server over https

  • A redirect rule in .htaccess contradicts WordPress or the proxy

    Sometimes

    A rule that forces https or one form of the domain loops when WordPress's address names the other form, or when the rule tests for https behind a proxy that has already removed it.

    Fix: Replace .htaccess with WordPress's standard one

  • A redirect or SSL plugin sends visitors in a circle

    Sometimes

    A redirect plugin can hold a rule that points an address back at itself. A plugin that forces https or www can contradict what the server does.

    Fix: Switch off the redirect or SSL plugin

  • The browser is following a stored redirect or a bad cookie

    Sometimes

    A browser may store a 301 and follow it again without asking the server. Chrome and Firefox both name cookies as a cause of this error. The site can be fixed and one browser still loop.

    Fix: Try a private window, then delete the site's cookies

How to fix it

Try a private window, then delete the site's cookies

  • Easy
  • No risk
  • About 5 minutes

A browser may store a 301 redirect and follow it again without asking the server. Chrome and Firefox both name cookies as a cause of this error. So test in a private window, now and after each fix below.

  1. Step 1: Open the site in a private window

    In Chrome this is an Incognito window. Chrome removes an Incognito session's cookies and site data when the session ends, so each one starts clean.

  2. Step 2: If the site loads there, delete its cookies in your usual browser

    Chrome's own help for this error says to try deleting your cookies. Delete the cookies and cached files stored for your site's address, then reload.

  3. Step 3: If it fails there too

    The loop is on the site. Go to the next fix.

Give WordPress the form of the address the server uses

  • Takes care
  • Back up first
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

WordPress stores two addresses, "WordPress Address (URL)" and "Site Address (URL)". It redirects a visitor who arrives at the www form of the domain to the form without, or the other way round, to match the Site Address. If your host or CDN redirects to the opposite form, the two never agree.

The checker's hops show both forms. Give WordPress the one your host or CDN is set up for.

  1. Step 1: Open wp-config.php

    It is in the site's main folder, beside the wp-content folder.

  2. Step 2: Add these two lines above "That's all, stop editing"

    Replace https://example.com with the address the server uses: the same https, the same www or none, and no slash at the end.

    wp-config.php
    define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

  3. Step 3: Reload the site

    If it loads, the saved addresses were the cause. The two lines overrule the addresses in the database without changing them.

With WP-CLI, read the saved addresses:

bash
wp option get home
wp option get siteurl

And correct them:

bash
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

How to change your WordPress URL covers the dashboard and the database as well, and replacing an old address stored in your content.

To undo it: Remove the two lines from wp-config.php, or set the old values again.

Tell WordPress the visitor is on https

  • Takes care
  • Back up first
  • About 10 minutes
  • Steps tested on WordPress 7.1.3

This applies when a CDN, a load balancer or another proxy takes the visitor's https connection and asks your server for the page over plain http.

When the WordPress Address begins with https, WordPress insists on https for the login page and the dashboard. A request for either that arrives over http is redirected to its https address. Behind such a proxy every request arrives over http, so those two loop while the rest of the site loads. If every page loops, a rule in .htaccess or a plugin is forcing https as well: do this fix, then the last two.

A proxy can say what the visitor used in a header named X-Forwarded-Proto. These lines make WordPress count such a request as https.

  1. Step 1: Add these lines to wp-config.php, above "That's all, stop editing"

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

  2. Step 2: Open the login page in a private window

    If the login form appears at /wp-login.php, WordPress's own loop is gone. If nothing has changed, your proxy does not send that header. Ask its support which header says the visitor used https.

To undo it: Remove the three lines from wp-config.php.

Have the CDN or proxy connect to your server over https

  • Takes care
  • Low risk
  • About 15 minutes

The lasting arrangement is https all the way to your server. WordPress and the server's rules then see https for themselves.

On Cloudflare the setting is the SSL/TLS encryption mode. Its documentation says that in Flexible mode it sends requests to your server over HTTP, and that redirect loops occur if the server redirects all HTTP requests to HTTPS. It gives two ways out: remove the https redirects from your server, or change the mode to Full or higher, which needs a certificate on your server.

  1. Step 1: Check that your server has a certificate of its own

    Ask your host if you are not sure. A mode that connects to your server over https requires one.

  2. Step 2: Change the mode in the CDN's or proxy's settings

    Other services name the setting differently. Look for how the service connects to your server, which it may call the origin.

  3. Step 3: Reload the site in a private window

    If it loads, the plain http connection was the cause.

To undo it: Set the proxy's mode back to what it was.

Replace .htaccess with WordPress's standard one

  • Easy
  • Back up first
  • About 5 minutes
  • Steps tested on WordPress 7.1.3

This applies to sites on Apache or LiteSpeed. nginx has no .htaccess: its rules are in the server's own configuration, so ask the host to look there for a redirect.

  1. Step 1: Download a copy of .htaccess

    It sits in the site's main folder, beside wp-config.php. Its name begins with a dot, so turn on "Show hidden files" if you cannot see it.

  2. Step 2: Replace everything in it with this

    This is what WordPress itself writes for a site at the root of its domain.

    .htaccess
    # BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

  3. Step 3: Reload the site

    If it loads, a rule in the old file was the cause. Put your other rules back one section at a time from the copy. Leave out the ones that force https or www, and let one place decide each: WordPress's address for www, the CDN or the host for https.

If WordPress is installed in a subfolder, such as example.com/blog, two lines carry the folder's name: RewriteBase /blog/ and RewriteRule . /blog/index.php [L]. How to set up redirects in WordPress explains how these rules are written and how loops and chains start.

To undo it: Put your copy of the old .htaccess back.

Switch off the redirect or SSL plugin

  • Takes care
  • Low risk
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

  1. Step 1: Rename the plugin's folder

    In your host's file manager or over SFTP, open wp-content/plugins and add -off to the name of the plugin's folder. The plugin can no longer load. If you cannot tell which plugin it is, rename the whole plugins folder instead.

  2. Step 2: Reload the site

    If it loads, that plugin was sending visitors round.

  3. Step 3: Open the Plugins screen, then rename the folder back

    Renaming alone does not switch a plugin off: named back, it loads again at once. Opening the Plugins screen while the folder is renamed makes WordPress deactivate what it cannot find. After that the plugin stays off, with its settings kept, until you activate it.

Over SSH, the rename is one command from the site's main folder. Use the plugin's folder name in place of plugin-name, here and below.

bash
mv wp-content/plugins/plugin-name wp-content/plugins/plugin-name-off

WP-CLI deactivates a plugin with its folder left as it is:

bash
wp plugin deactivate plugin-name

Before you switch the plugin on again, decide what it should do. A redirect list must not hold an address that points back at itself. An option that forces https or www must match what the server and WordPress's address already do.

To undo it: Rename the folder back, or activate the plugin again.

When to get help

If a private window still loops when the addresses agree, .htaccess is the standard one and every plugin is off, the redirect is added outside WordPress. It can be the host's own server configuration or a redirect rule at the CDN. Finding it takes access to those accounts and reading what every hop answers.

Common questions

Why did it start when I moved to https or added a CDN?

A likely reason is that a CDN or proxy now takes the https connection and asks your server over plain http. Whatever on the server redirects http to https then does so on every request, and the visitor never arrives. The third and fourth fixes deal with it. With no CDN or proxy in front of the site, look at the fifth and sixth.

The site loads for other people and loops for me. Why?

Your browser is following something it stored: a redirect the site used to send, or a cookie. The first fix clears it.

Why do only the login page and the dashboard loop?

WordPress insists on https for those two when the WordPress Address begins with https. Behind a CDN or proxy that asks your server over http, they loop even while the rest of the site loads. The third fix covers it.

More on this subject

Would you rather we fixed it?

Emergency Fix is $99. Site down or checkout broken. Goes to the front of the queue. No fix, no fee. 30-day warranty. It starts with a free diagnosis.

Get a free diagnosis