How to Fix ERR_TOO_MANY_REDIRECTS in WordPress
What ERR_TOO_MANY_REDIRECTS means
Normally a redirect is a one-time handoff: you ask for one URL and the server replies "that moved, go here instead," sending a 301 or 302 status with the new address. ERR_TOO_MANY_REDIRECTS happens when those handoffs form a circle. Your browser follows the first redirect, gets redirected again, then again — and after roughly twenty hops Chrome, Edge, and Firefox all refuse to continue and show you this error page instead of any content.
The loop is almost never your browser's fault. The classic server-side setup is a WordPress site behind Cloudflare with SSL mode set to Flexible: Cloudflare requests the page from the origin over plain HTTP, the origin — which forces HTTPS — replies "redirect to the https version," Cloudflare passes that redirect to the visitor, the visitor's browser asks Cloudflare for the https version, and Cloudflare again asks the origin over plain HTTP. Round and round. The same circular pattern shows up with WordPress home and site URLs disagreeing on the protocol, with a redirect plugin undoing what a server rule just did, or with two Cloudflare page rules pointing at each other. On the visitor side, the only thing that can keep a fixed loop looking broken is cached redirect state in cookies, which is why clearing them is step one.
Common causes
- Cloudflare Flexible SSL with an HTTPS-forcing origin: the number-one cause — Cloudflare fetches over HTTP, the origin redirects to HTTPS, and the loop repeats forever.
- WordPress home and site URLs disagree on protocol: Settings → General lists one address as http:// and the other as https://, so WordPress redirects to HTTPS while another layer redirects back.
- Competing redirect rules: a redirect plugin, a Cloudflare page rule, and an .htaccess or Nginx rule each "fixing" the URL in opposite directions — individually sensible, circular together.
- Double HTTPS redirects in .htaccess: two RewriteRules where the second one redirects the first one's target right back, often after a migration or an SSL plugin install.
- Stale cookies and HSTS pinning: your browser cached the looping behavior and keeps replaying it even after the server is fixed, especially if HSTS headers told it to insist on HTTPS.
How to fix ERR_TOO_MANY_REDIRECTS — step by step
Steps 1 and 2 are for visitors. Steps 3 through 6 are for site owners.
- Visitor: clear the site's cookies and hard-refresh. A redirect loop leaves bad redirect state in your cookies, and the browser can keep looping on the cached version even after the site owner fixes the server. Clear it: in Chrome go to Settings, then Privacy and security, then Cookies and site data, then See all site data, search for the site's domain, and delete its entries. Then hard-refresh with Ctrl+Shift+R on Windows or Cmd+Shift+R on Mac and try the page again.
- Visitor: test the page in an incognito window and on another device. Open the URL in a private or incognito window, which loads with a clean cookie jar and no extensions. If it works there, your normal profile's cookies or an extension were keeping the loop alive — clear all cookies for the domain and disable redirect-modifying extensions one by one. If incognito loops too, and a second device on a different network loops as well, the loop is on the server and only the site owner can break it.
- Site owner: fix the Cloudflare Flexible-versus-Full SSL mismatch. The single most common cause of ERR_TOO_MANY_REDIRECTS is Cloudflare set to Flexible SSL while the origin server itself forces HTTPS. Cloudflare talks plain HTTP to the origin, the origin replies 'go to HTTPS,' Cloudflare passes that to the visitor, the visitor asks for HTTPS, Cloudflare again asks the origin over HTTP — an infinite loop. Fix it in the Cloudflare dashboard under SSL/TLS, Overview: change Flexible to Full or Full (strict). If the origin truly has no certificate, keep Flexible and stop the origin from forcing HTTPS — never run both sides forcing at once.
- Site owner: make the WordPress home and site URLs agree on the protocol. In wp-admin go to Settings, then General, and check WordPress Address and Site Address. Both must start with the same protocol the site actually serves — if the site is HTTPS but one field says http://, WordPress redirects to https:// while something else redirects back, and the loop never ends. If wp-admin itself is unreachable, set them directly in wp-config.php with define('WP_HOME','https://example.com'); and define('WP_SITEURL','https://example.com'); using your real domain, then reload the site.
- Site owner: audit redirect plugins, Cloudflare page rules, and .htaccess. Loops love company: a redirect plugin plus a server rule plus a Cloudflare page rule can each be 'correct' alone and circular together. Deactivate redirect and SSL plugins (Really Simple SSL, Redirection, and similar) one at a time and retest after each. Check Cloudflare Rules for forwarding or 'Always Use HTTPS' rules that fight the origin's own redirects. Then inspect the site's .htaccess or Nginx config for RewriteRules that redirect to a URL which the next rule sends straight back — comment them out in pairs until curl -I shows the chain terminating in a 200.
- Site owner: purge every cache and verify with curl. CDN, page, and browser caches can keep serving the old redirect chain after the configuration is fixed. In Cloudflare go to Caching, Configuration, and purge everything for the site, then clear any page-cache plugin or server cache. Verify from the command line with curl -sIL https://example.com and read the chain: each Location header should move forward, never return to a URL already visited. When the final response is a 200 instead of another 301 or 302, the loop is broken — retest in a fresh incognito window before declaring victory.
Did this fix it? Quick checklist
- The page loads in an incognito window after the site's cookies were cleared and hard-refreshed
- Cloudflare SSL mode is Full or Full (strict) — not Flexible against an HTTPS-forcing origin
- WordPress Address and Site Address both use the same protocol the site actually serves
- No plugin, page rule, or .htaccess rule redirects the URL back the opposite way — curl -sIL ends in a 200
If the loop appeared right after installing an SSL plugin or switching Cloudflare SSL modes, that change is your culprit — revert it first and retest before digging deeper. Loops that started after a site migration usually trace back to the home and site URLs still pointing at the old protocol or domain, so check Settings → General (or wp-config.php) before touching anything else. And once the loop is broken, keep one redirect layer authoritative: pick either Cloudflare rules or the server config to own HTTPS enforcement, not both, and future you will never meet this error again.
Frequently asked questions
What does ERR_TOO_MANY_REDIRECTS mean?
ERR_TOO_MANY_REDIRECTS is Chrome's way of saying a page redirected the browser in circles until the browser gave up — usually after about twenty hops. In plain English: the site told your browser 'go here,' that page said 'no, go there,' and the chain never landed on a real page. It is almost always a server configuration problem — most famously a Cloudflare SSL-mode mismatch or two WordPress redirect rules pointing at each other — not a problem with your browser.
Is ERR_TOO_MANY_REDIRECTS my fault as a visitor?
No — a redirect loop is the site's doing. The one visitor-side wrinkle is that your browser can keep replaying a cached loop after the owner has fixed it, because cookies and cached redirects preserve the old bouncing behavior. Clear the site's cookies, hard-refresh, and try an incognito window. If incognito loops too, the loop is genuinely live on the server and only the site owner can fix it; your only move is to wait and try again later.
How is ERR_TOO_MANY_REDIRECTS different from Cloudflare Error 525 or 526?
They fail at different points. ERR_TOO_MANY_REDIRECTS means the server answered but kept redirecting in a circle, so the browser quit chasing. Error 525 means the SSL handshake between Cloudflare and the origin failed before any redirect could happen. Error 526 means the origin's SSL certificate was invalid. If you see ERR_TOO_MANY_REDIRECTS on a Cloudflare site, suspect the Flexible-versus-Full SSL mismatch; if you see 525 or 526, suspect the certificate itself.
I'm a site owner — should Cloudflare SSL be Flexible or Full?
Use Full (or Full strict) if your origin server has an SSL certificate and serves HTTPS — which is the normal case. Flexible means Cloudflare talks plain HTTP to your origin; if your origin then forces HTTPS, you get the classic infinite loop. Only use Flexible when the origin genuinely has no certificate and cannot get one, and in that case make sure nothing on the origin redirects HTTP to HTTPS. Pick one side to enforce HTTPS, never both.
I fixed the SSL setting but the error is still there — why?
Cached redirects are the usual suspect. Cloudflare edge cache, your page-cache plugin, and your browser can all keep serving the old redirect chain after the setting is fixed — purge everything in Cloudflare's Caching tab, clear the page cache, and retest in a fresh incognito window. HSTS headers can also pin the old behavior in your browser for a while. If curl -sIL shows the chain now ending in a 200, the fix worked and the remaining loop reports are just stale caches expiring.