ERR_TOO_MANY_REDIRECTS: Fix a WordPress Redirect Loop

← Back to all WordPress fixes

Introduction

Your browser shows “ERR_TOO_MANY_REDIRECTS” or “This page isn’t working — redirected you too many times” and your entire site is unreachable — not just the login page. This is different from a login page redirect loop, which only affects wp-login.php; this happens on every URL, including the homepage. Here’s how to find and fix the actual cause.

What Causes a Site-Wide Redirect Loop

• WordPress Address and Site Address don’t match in Settings → General — if you can even reach wp-admin. A mismatch here (especially http vs https) can send the browser bouncing between the two.
• SSL/HTTPS misconfiguration. Your site forces HTTPS, but your host or CDN (like Cloudflare) is set to a conflicting SSL mode, creating an infinite loop between “redirect to HTTPS” rules on both ends.
• A caching or security plugin’s redirect rule conflicts with the server’s own redirect rule (e.g., both are trying to force HTTPS or force www, in slightly different ways).
• Corrupted .htaccess file with conflicting or duplicated rewrite rules.
• A recently changed domain or migration where the database still references the old URL.

Fix 1: Check the SSL Setting If You Use Cloudflare (or Any CDN)

This is the single most common cause. If your site forces HTTPS and you use Cloudflare (or a similar CDN/proxy):

1. Log in to Cloudflare, go to SSL/TLS.
2. If it’s set to “Flexible”, change it to “Full” or “Full (Strict)”.

Here’s why: “Flexible” means Cloudflare talks to your server over plain HTTP, while your WordPress site is simultaneously forcing everything to HTTPS — the two redirect rules fight each other forever. “Full” tells Cloudflare to also use HTTPS to your server, breaking the loop.

Fix 2: Check WordPress Address and Site Address

If you can reach wp-admin at all (try an incognito window, sometimes that avoids a cached loop):

1. Go to Settings → General.
2. Confirm WordPress Address (URL) and Site Address (URL) use the identical protocol (both https://) and domain.

Can’t reach wp-admin? Edit wp-config.php via FTP and add these two lines above /* That's all, stop editing! */ (replace with your actual domain):

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

Fix 3: Rename .htaccess to Reset It

Via FTP or File Manager, rename .htaccess (in your site’s root) to .htaccess-old. WordPress will regenerate a clean default version the next time you visit any page or resave permalinks (Settings → Permalinks → Save Changes). If the loop disappears, the old file had a conflicting custom rule — re-add any custom rules one at a time afterward.

Fix 4: Deactivate Plugins That Manage Redirects or SSL

Security and SSL-forcing plugins are common culprits. Deactivate all plugins via FTP (rename the plugins folder in wp-content), check if the loop stops, then reactivate them one at a time to isolate which one is conflicting.

Frequently Asked Questions

How is this different from the login redirect loop?
The login redirect loop only affects wp-login.php — the rest of your site loads fine. ERR_TOO_MANY_REDIRECTS on every URL, including the homepage, points to a site-wide SSL or URL configuration issue instead.

I just moved to a new host — is that related?
Very likely. New hosts often handle SSL differently (or don’t have a certificate active yet), which is the most common trigger right after a migration.

Will this affect my SEO?
Yes, if left unresolved for long — Google can’t crawl a site stuck in a redirect loop. Fix it as soon as possible; a brief outage from a redirect loop typically doesn’t cause lasting ranking damage.

Can a backup help here?
If the loop started right after a change you made (plugin update, SSL setting, migration), restoring a backup from before that change is often faster than debugging the exact cause.

Conclusion

A site-wide redirect loop is almost always an HTTPS/SSL configuration conflict — most often between Cloudflare’s SSL mode and WordPress’s own HTTPS enforcement. Check that first, then WordPress Address/Site Address, then a corrupted .htaccess. One of these three resolves the vast majority of cases.