Logo
WP Fix by Blimx

ERR_TOO_MANY_REDIRECTS — WordPress Causes and Fixes

Actualizado:
AccessErrors

What the browser is telling you

ERR_TOO_MANY_REDIRECTS (or its Firefox cousin "page isn't redirecting properly") means the browser made more than 20 redirect hops trying to load your site. It gave up.

For WordPress, this almost always traces to one of five causes. This article diagnoses each.

The diagnostic command

Before changing anything, see the redirect chain:

curl -IL https://yoursite.com/

The -L follows redirects. The output shows each redirect:

HTTP/2 301
location: https://www.yoursite.com/

HTTP/2 301
location: https://yoursite.com/

HTTP/2 301
location: https://www.yoursite.com/

In this example, the site redirects from non-www to www, then back to non-www, infinitely.

The pattern of the redirect chain points to the cause.

Cause 1 — siteurl/home mismatch with www/non-www

You have https://www.yoursite.com set in siteurl but Apache/Nginx redirects www to non-www. WordPress responds with a redirect to www. Apache redirects back. Loop.

Diagnose

wp option get siteurl
wp option get home
curl -I https://yoursite.com/      # without www
curl -I https://www.yoursite.com/  # with www

If siteurl is www but server redirects www→non-www (or vice versa), this is your cause.

Fix

Decide which version is canonical (we recommend non-www for new sites, www for legacy).

wp option update siteurl https://yoursite.com
wp option update home https://yoursite.com

In Apache/Nginx, redirect the other version to canonical. Make sure WordPress and server agree.

Cause 2 — Cloudflare SSL mode = Flexible

Cloudflare → SSL/TLS → Overview. If "Flexible" is selected:

  • Visitor → HTTPS → Cloudflare
  • Cloudflare → HTTP → Origin
  • Origin (WordPress) sees HTTP, redirects to HTTPS
  • Cloudflare → HTTP → Origin (again)
  • Loop

Diagnose

Check Cloudflare SSL/TLS mode. If Flexible, this is your cause.

Fix

Change to "Full" or "Full (strict)":

  • Full — Cloudflare accepts any cert (including self-signed)
  • Full (strict) — requires valid cert at origin

For production, use Full (strict) with Let's Encrypt or Cloudflare Origin CA.

Cause 3 — Force HTTPS plugin AND server-level redirect conflicting

You have a plugin (Really Simple SSL, WP Force SSL) doing PHP-level HTTPS redirect AND Apache .htaccess doing server-level HTTPS redirect. They redirect the wrong direction relative to each other.

Diagnose

# Check plugins
wp plugin list --status=active | grep -i ssl

# Check .htaccess
grep -i "RewriteRule.*https" /var/www/yoursite/.htaccess

If both have HTTPS redirect logic, conflict possible.

Fix

Pick one. We recommend server-level (.htaccess or Nginx) and disable the plugin.

Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Then deactivate the SSL plugin.

Cause 4 — Wrong reverse proxy headers

You're behind a load balancer or reverse proxy. The LB terminates HTTPS, sends HTTP to your server with X-Forwarded-Proto: https. But WordPress doesn't trust the header by default, sees HTTP, redirects to HTTPS, LB sends HTTP again. Loop.

Diagnose

curl -I https://yoursite.com/
# Check the Server and CF-Connecting-IP headers

If you're behind a load balancer (AWS ALB, Cloudflare, Sucuri), this is suspect.

Fix

In wp-config.php, ABOVE the require_once ABSPATH . 'wp-settings.php'; line:

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

This tells WordPress to treat requests with X-Forwarded-Proto: https as HTTPS internally.

Cause 5 — Plugin or theme adding own redirect

A plugin (often Multi-site Plugin, Geographic Redirect, Coming Soon Mode) does PHP-level redirects on every request. Configured wrong, it loops.

Diagnose

grep -rE "wp_redirect|wp_safe_redirect|header\s*\(\s*['"]Location:" wp-content/plugins/ | head -30

Look for plugins doing redirects without proper conditions.

Fix

Disable plugins one at a time until loop stops:

mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins

# Test

If site works with all plugins off, re-enable one at a time. The one that causes the loop is your culprit.

For Coming Soon Mode plugin specifically, ensure it doesn't redirect when user is logged in.

Bonus: Cause 6 — .htaccess RewriteRule loop

Your .htaccess has rewrite rules that send /page/ → /page and /page → /page/. Loop.

Diagnose

cat /var/www/yoursite/.htaccess

Look for any RewriteRule whose target could trigger another RewriteRule.

Fix

Replace .htaccess with default WordPress block:

# 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

If you had custom rules, add them back one at a time, testing.

The 5-minute diagnostic checklist

1. curl -IL <yoursite> — note redirect chain
2. wp option get siteurl, home — compare with chain
3. Cloudflare SSL mode = ? (Flexible is the cause if yes)
4. .htaccess has custom redirects?
5. Active plugin doing redirects?
6. Behind load balancer? X-Forwarded-Proto?

Each step rules out a cause. By step 6 you've identified it.

Common mistakes during redirect loop diagnosis

  • Clearing cache — doesn't fix the config issue
  • Reinstalling SSL plugin — only helps if the plugin was the cause
  • Trying random `wp-config.php` constants — without diagnosis, makes it worse
  • Restarting Apache/Nginx — doesn't change config; same loop returns

When to call a specialist

Redirect loops are diagnostic puzzles. We resolve them in 15-45 minutes via the curl chain approach above. For Cloudflare-fronted sites, sometimes we coordinate with their support team for edge config changes.

Redirect loop fix within hours. For broader emergencies see emergency support.