Fix ERR_TOO_MANY_REDIRECTS in WordPress (2026): The 6 Real Causes

ERR_TOO_MANY_REDIRECTS is not a mystery - it's a loop. Your site bounces the browser between two URLs until Chrome gives up. The fix is always the same idea: find the two URLs in the loop, then remove the rule that creates one of them. Work the 6 causes below in order - 80% of cases die at step 2 or 3.

Step 0: Read the Loop First

Open DevTools (F12) > Network, reload the page, and watch the 301/302 chain. The two alternating URLs tell you the cause before you touch anything:

• -http vs https versions looping = SSL/proxy mismatch (steps 2-3)
• -www vs non-www looping = Site Address mismatch (step 2)
• -Loop on /wp-admin or /wp-login only = plugin or cookie issue (steps 1, 5)

1. Clear Browser Cache and Cookies

WordPress login and HTTPS upgrades both depend on cookies - a stale cookie can replay the loop forever. Test in an incognito window first: if the site loads, just clear cookies for your domain in normal browsing. Two minutes, and it rules out the client side entirely.

2. Match WordPress Address and Site Address

The #1 cause. In Settings > General, both "WordPress Address (URL)" and "Site Address (URL)" must be identical - same protocol, same www preference, all lowercase. If the error locks you out of wp-admin, override via wp-config.php (above the "stop editing" line):

Use the exact URL your site actually serves - including www if your site uses it. wp-config defines override the database values; for a permanent fix, update siteurl and home in the wp_options table via phpMyAdmin, then remove the defines.

3. Fix Cloudflare's SSL Mode

If the loop started the day you enabled Cloudflare, this is your fix. Flexible SSL makes visitors connect to Cloudflare over HTTPS while Cloudflare calls your origin over HTTP - WordPress sees HTTP and redirects to HTTPS, forever.

1. 1.Cloudflare Dashboard > SSL/TLS > Overview > change Flexible to Full (Full Strict once a valid origin cert is installed).
2. 2.Tell WordPress it is behind a proxy - add to wp-config.php:

That pairing resolves the large majority of Cloudflare redirect loops.

4. Reset .htaccess

A corrupted or hand-edited .htaccess accumulates redirect rules from plugins, migrations, and manual "force HTTPS" snippets that fight each other. Via FTP or file manager:

1. 1.Download .htaccess as a backup, then rename it to .htaccess_old
2. 2.Reload the site. Loop gone = a bad rule in the old file
3. 3.Regenerate: wp-admin > Settings > Permalinks > Save Changes (no edits needed) - WordPress writes a clean default file

Classic loop-causing snippet: an HTTPS-force rule that checks %{HTTPS} off behind a proxy - the proxy terminates SSL, so the origin always sees HTTP and always redirects. Check %{HTTP:X-Forwarded-Proto} =http instead, or let your host/CDN handle it.

5. Deactivate Plugins (Start With Redirect/SSL/SEO)

Plugins that touch redirects are the usual suspects: Redirection, SSL-forcing plugins (Really Simple SSL), SEO plugins with redirect modules, caching plugins serving a cached redirect. If you can't reach wp-admin, rename wp-content/plugins to plugins_old via FTP - WordPress deactivates everything. Site loads? Rename back and reactivate one by one until the loop returns.

Note: a redirect plugin can also serve a loop from cache - after fixing the real cause, purge all caches (plugin + server + CDN) before concluding the fix failed.

6. Check Server-Level Redirects

Some managed hosts force HTTPS or www at the server level, above .htaccess. If your .htaccess also forces a different canonical form, they fight. Fix by picking one enforcement layer - ideally let the host handle HTTPS/www forcing and keep .htaccess clean. If nothing else worked, ask your host's support to check for server-level redirect rules.

Prevention Checklist

• VSet Site Address once, correctly, at install - never leave http when https is active
• VCloudflare on Full or Full Strict, never Flexible, with a real origin SSL cert
• VOne redirect authority: either the host, the CDN, or a plugin - never two
• VAfter migrations, update URLs in the database, not just in one layer

Related: white screen of death fix - 500 internal server error - nameserver changes without downtime - SSL certificates explained.