Fix WordPress ERR_TOO_MANY_REDIRECTS

Symptoms

The browser tab says ERR_TOO_MANY_REDIRECTS and the WordPress site never renders. The same URL loads on a different network, or over http, or in a private window, because those requests do not hit the same rules. The loop is usually a mix of three layers fighting each other: the web server, the WordPress site URL, and a CDN or security plugin.

What an ERR_TOO_MANY_REDIRECTS loop sounds like

How to fix, in order

1. Reset to a known-good URL. The most common fix is forcing the request out of the loop by temporarily bypassing the redirect. Use a plugin, a wp-config.php define, or the host tool to look at the site and site URL values first:

SELECT option_value FROM wp_options WHERE option_name IN ('siteurl','home');

Both must match what the browser types, scheme and www included. If they are wrong, correct them (or wp search-replace after a moved domain), purge, and the loop usually dies.

1. Check the HTTPS layer. Ask: who redirects http to https, the web server, the plugin, the CDN, or WordPress itself? If two layers force HTTPS, the origin answer can be http while the edge answers https, so the origin sends the visitor to an https URL that the edge then reforces, and the loop is a self-feed. Choose exactly one owner and tell the other to stop. In Cloudflare the SSL mode matters too: Full strict demands the origin certificate match, while Flexible makes the edge forward HTTP to the origin, which can loop when the origin still forces HTTPS.
2. Clear the cached redirect. The loop may not be live at all; a page cache, object cache, or CDN copy of the 301/302 lives for a day or more. Purge the caches (URL, prefix, and the WAF/edge cache), then test from a fresh network. A loop that survives the purge is real.
3. Inspect .htaccess or the nginx config for a repeating rule. A real loop needs two rules that fight each other. The common accidental pair is a www rule and a non-www rule, where the first adds www and the second strips it:

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}/ [L,R=301]

RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://%{HTTP_HOST}/ [L,R=301]

Each request matches the opposite rule, so the visitor bounces between the two hosts forever. Pick one canonical host and delete the other block. Two identical conditional rules (a duplicated HTTPS redirect, for instance) do NOT create a loop on their own, because a request that is already https matches neither condition. Be suspicious of any block that repeats itself, but only rewrite rules forcing opposite states actually self-feed. On nginx the same mistake is a duplicated return 301 inside a location or server block.

1. Fix the cookie-based loop. A security plugin sets a cookie and then requires it on the next request, but the cookie never lands (blocked storage, or a caching layer serving the response without the Set-Cookie header). If a cache plugin is caching the login page, add /wp-login.php to its exceptions so the login path is served uncached, then clear the login cookie for that site and retry in a private window.
2. Test the raw chain to confirm you broke it:

curl -sI --max-redirs 5 http://example.com/

The final hop should be a 200 (or a 301 to www if that is your design), not a binary loop. Repeat over https:// and the bare domain.

Prevention

• One redirection layer per site: pick the CDN or the plugin, not both, and keep the SSL mode documented.
• Test http, https, www, and the bare domain in one pass after any HTTPS or SSL-mode change.
• If the loop interplay of full, flexible and strict SSL modes is new, review the two: ssl-for-wordpress and err-too-many-redirects cover the pieces.

When to involve a professional

If the loop persists with a plain URL, no plugin involved, and the CDN mode already strict, the site might have a Nagios-style redirect file, a redirect service (a metered CDN or security suite) in the path, or a DNS CNAME chain that loops a host. That is a hosting-layer problem, best solved with the host's reverse proxy diagnostics in hand.