ERR_TOO_MANY_REDIRECTS means the page keeps redirecting in a circle, A sends the browser to B and B sends it straight back to A, and Chrome gives up after 20 hops rather than orbit forever. The page is not down. It is stuck in an argument with itself about where it lives.
Redirect loops are configuration disagreements, and nearly all of them are one of four arguments: HTTP versus HTTPS, www versus non-www, a CMS that believes it lives at a different address than the server does, or two layers both insisting on performing the same redirect. Visitors can occasionally clear the error with a cookie reset, but the durable fix always happens on the site, which is why this article spends one section on the visitor path and the rest on tracing the loop, matching it to its pattern, and ending the argument at the source.
How a loop forms
A redirect is a server telling a browser to go somewhere else, and it is a healthy, everyday instrument: HTTP upgrades to HTTPS, bare domains forward to www, old URLs forward to new ones. A loop forms when two of these instruments contradict each other. The canonical modern example involves a proxy such as Cloudflare running in flexible SSL mode: the visitor connects to the proxy over HTTPS, the proxy fetches from your origin over plain HTTP, and your origin, seeing an HTTP request, dutifully redirects to HTTPS. The proxy fetches again over HTTP, the origin redirects again, and the circle is complete. Neither layer is wrong by its own logic, which is what makes loops so stubborn.
WordPress contributes the second classic: the site URL saved in its settings disagrees with the address the server is actually using, often after a domain change or an SSL migration, so WordPress redirects every request toward its recorded address while the server redirects back. Add HSTS to any of these situations, the header covered in Odown's guide to HTTP Strict Transport Security, and the browser itself starts forcing HTTPS before the request leaves the machine, which changes the shape of the loop without changing the cause.
The visitor path: clear the site's cookies, then move on
Redirect logic frequently depends on cookies, a login state, a language choice, a consent flag, and a stale or corrupted cookie can trap one specific visitor in a loop that nobody else sees. Clear cookies for the affected site only, no need to sign out of the whole internet, and reload. Testing in an incognito window accomplishes the same thing faster and doubles as the diagnostic: if the page loads cleanly in incognito, cookies were the trap. Clearing cached redirects helps in a second scenario, because browsers remember permanent redirects aggressively, and a site that once redirected somewhere unwise can keep a visitor bouncing on memory alone.
If incognito loops the same way on multiple devices, the visitor path is exhausted. The loop is in the site's configuration, and everything from here on belongs to whoever operates it.
Tracing the loop before fixing it
Watch the chain with curl. Run curl -sIL followed by the URL and read the sequence of Location headers it prints. Two URLs alternating, HTTP to HTTPS to HTTP, or www to bare to www, is the loop made visible, and the pair of addresses tells you which argument you are in.
Identify every layer that can redirect. List them explicitly: the CDN or proxy, the load balancer, the web server configuration, and the application. Loops live between layers, so the fix starts with knowing how many opinions exist.
Check the proxy's SSL mode first. If Cloudflare or a similar proxy is in the picture and the chain alternates between HTTP and HTTPS, set the SSL mode to Full (strict) so the proxy speaks HTTPS to your origin, and give the origin a valid certificate. This single change ends the most common loop on the internet.
Make the application trust the forwarded protocol. Behind any proxy, the origin sees plain HTTP even when the visitor used HTTPS. The application must read the X-Forwarded-Proto header before deciding to redirect, otherwise it upgrades requests that were already secure, forever.
Fix the recorded address in the CMS. In WordPress, the site URL and home URL settings must match the canonical address exactly, scheme and hostname both. After a migration this one field mismatch explains the entire error.
One redirect layer, one canonical answer
The lasting fix is architectural rather than clever: decide the site's one canonical address, scheme and hostname, and let exactly one layer enforce it. If the CDN performs the HTTPS upgrade and the www normalization, the web server and the application should perform neither; if the web server does it, the application stays silent. Every additional layer with redirect rules is a future loop waiting for a configuration change to activate it. While you are consolidating, cap the chain length as a courtesy: even legitimate chains of four and five hops slow every first visit, and search crawlers treat long chains as a signal of a site that has lost track of itself.
Common mistakes in fixing ERR_TOO_MANY_REDIRECTS
Clearing cookies and declaring victory. For a visitor that is a fix; for the owner it is anesthesia. If cookies triggered the loop for one person, the logic that let them will trigger it again for others.
Fixing the symptom in the wrong layer. Adding yet another redirect rule to route around a loop adds a third opinion to an argument between two. Remove a redirect; do not add one.
Setting flexible SSL and forcing HTTPS at the origin. This combination is the loop, verbatim. Flexible mode and an origin HTTPS redirect cannot coexist; choose Full (strict) and a real certificate.
Forgetting HSTS during testing. Once HSTS is cached, the browser upgrades to HTTPS on its own, which can make a half-fixed site look still broken. Test in a fresh profile before concluding the fix failed.
Leaving the WordPress address stale after migration. The database remembers the old URL with total loyalty. Update the site URL settings, or the loop will outlive every server-side fix you apply.
FAQ
Why do I get this error when others do not?
Because your cookies or cached redirects are steering you into a loop others never enter. Clear cookies for that one site or use incognito; if the loop persists there, it is the site's configuration and everyone will hit it eventually.
How many redirects does Chrome allow before failing?
Twenty. After the twentieth hop Chrome stops and shows the error, on the reasonable theory that a journey with no destination should end somewhere.
Why did my WordPress site loop right after installing an SSL plugin?
The plugin began redirecting to HTTPS while another layer, often a proxy in flexible mode or a server rule, kept handing back HTTP. Align the site URL to https, set the proxy to Full (strict), and keep exactly one layer doing the upgrade.
Are redirects bad for SEO?
Redirects are fine; loops and long chains are not. A loop makes the page uncrawlable, and chains waste crawl budget and dilute signals, so the canonical-in-one-layer rule serves search visibility as much as uptime.
Closing thought
A redirect loop is two pieces of your own infrastructure disagreeing about where the site lives, so the cure is jurisdictional: one canonical address, one layer allowed to enforce it, every other opinion deleted. Trace the chain with curl, match the alternating pair to its pattern, and the fix is usually a single setting, the proxy's SSL mode, a forwarded-header check, or a CMS address field.
Loops also have a habit of arriving with deployments, a new plugin, a new proxy rule, a well-meant hardening change, and going unnoticed until customers complain. Odown monitors your pages continuously from 17 locations and alerts the moment a URL stops returning success, so the redirect argument that started at 4:58 on a Friday is a two-minute rollback instead of a weekend of quiet lost traffic.
