ERR_TOO_MANY_REDIRECTS: Causes, Diagnosis, and Fixes

Tired of redirect loops? This guide provides a definitive ERR_TOO_MANY_REDIRECTS fix, covering causes, crawler-based diagnosis, and step-by-step solutions for SEOs.

What is ERR_TOO_MANY_REDIRECTS (And Why Should SEOs Care)?

Nothing stops a user—or a search engine crawler—in its tracks quite like the `ERR_TOO_MANY_REDIRECTS` error. It’s the digital equivalent of a revolving door that you can’t escape. This error message is a browser’s cry for help, signaling that it’s been sent on a wild goose chase from one URL to another and back again, never reaching a final destination. For SEOs, this isn’t just a user experience problem; it’s a critical technical issue that demands an immediate ERR_TOO_MANY_REDIRECTS fix.

At its core, a redirect loop occurs when a URL redirects to another URL, which in turn redirects back to the original URL, or to another URL in the same chain. Browsers and crawlers have a built-in limit to how many redirects they’ll follow (usually around 10-20 hops) before they give up. When that limit is exceeded, the browser displays the error, and the crawler simply stops, marking the page as inaccessible.

The SEO implications are severe. A URL trapped in a redirect loop is effectively a dead end for Googlebot. It consumes crawl budget without any possibility of the content being indexed. Any link equity pointing to that URL evaporates into the digital ether. It’s a black hole for search performance, and if it happens on a large scale—say, during a botched HTTP-to-HTTPS migration—it can be catastrophic.

The Usual Suspects: Common Causes of Redirect Loops

Redirect loops rarely appear out of nowhere. They are almost always the result of a misconfiguration—a conflict between two or more rules that are each trying to control how a URL is served. Before you can fix the problem, you need to understand where it’s coming from. Here are the most common culprits we see in the wild.

• Conflicting Server Rules: This is the classic cause. Two rules in your `.htaccess` (Apache) or `server block` (Nginx) file are at odds. A common example is one rule forcing HTTPS and another forcing a non-WWW domain, but the second rule sends the user back to an HTTP URL, starting the loop all over again.
• Faulty CMS Plugins: In the world of WordPress and other content management systems, plugins are a double-edged sword. A poorly coded redirection manager, an aggressive SSL enforcer, or a caching plugin can easily create sitewide redirect loops, especially if they conflict with existing server rules.
• Incorrect HTTP vs. HTTPS Settings: A site might have URLs hardcoded with `http://` in its database or theme files, while a server rule or plugin forces all traffic to `https://`. If the HTTPS redirect isn’t configured correctly, it can bounce back and forth with the insecure assets.
• CDN and Proxy Misconfigurations: Services like Cloudflare are fantastic, but their settings can be a minefield. The infamous ‘Flexible’ SSL mode can cause a loop if your origin server also tries to redirect HTTP traffic to HTTPS. The CDN sends an HTTPS request to your server, which then sees an HTTP connection (because the SSL is terminated at the CDN) and tries to redirect it back to HTTPS, ad infinitum.
• WWW vs. Non-WWW Canonicalization Errors: Similar to the HTTP/HTTPS issue, you might have conflicting rules for enforcing your preferred domain. One rule sends `example.com` to `www.example.com`, while another (perhaps at the DNS or CDN level) sends `www.example.com` back to `example.com`.

A Reliable ERR_TOO_MANY_REDIRECTS Fix Starts with Diagnosis

You can’t fix what you can’t find. While a user might report a single broken page, the problem is often more widespread. A comprehensive ERR_TOO_MANY_REDIRECTS fix requires a systematic diagnosis, and that means you need to crawl.

Manually checking URLs with browser developer tools or `curl` is fine for spot-checking, but it doesn’t scale. To find every redirect chain and loop on a site with thousands of pages, you need a dedicated crawler. This is precisely what tools like ScreamingCAT are built for. By crawling your site from a list of seed URLs, you can identify every redirect path.

In ScreamingCAT, you can run a crawl and then navigate to the ‘Redirects’ report. Look for the ‘Redirect Chains’ tab. While this report is designed to find long redirect chains, a loop is simply an infinite chain. Our crawler will detect this, flag the URL with a ‘Loop’ status code, and show you the exact path of the redirect so you can pinpoint where the circle begins. This data is your roadmap to the fix.

# Use curl to trace the redirect path for a specific URL
curl -ILv https://www.example.com/problem-page

The ERR_TOO_MANY_REDIRECTS Fix: A Step-by-Step Guide

Once you’ve diagnosed the issue and identified the looping URLs, it’s time to get your hands dirty. The fix almost always involves correcting a faulty configuration. Follow these steps methodically.

1. Identify the Scope: Is the loop affecting a single URL, a directory, or the entire site? Your crawl data will tell you this. A sitewide loop points to a central configuration file (`.htaccess`, `nginx.conf`) or a CDN setting. A single-page loop might be a faulty redirect set in a CMS.

2. Audit Server Configuration Files: This is ground zero. Open your `.htaccess` file (for Apache servers) and look for conflicting `RewriteRule` directives. The most common error is having separate, non-cooperating rules for HTTPS and WWW canonicalization. They must be combined into a single, logical block.

Here’s an example of a bad `.htaccess` configuration that creates a loop:

And here is the correct way to write it, combining the conditions so they don’t conflict:

3. Deactivate and Audit CMS Plugins: If the server config looks clean, your CMS is the next suspect. The easiest way to test this is to temporarily deactivate plugins, especially any related to SSL, security, or redirection. If the loop disappears, reactivate them one by one until the error returns. You’ve found your culprit.

4. Check Your CDN/Proxy Settings: If you use a service like Cloudflare, log in and check your SSL/TLS settings. If it’s set to ‘Flexible’, your origin server must not force a redirect to HTTPS, as Cloudflare is already handling it. The recommended setting is almost always ‘Full (Strict)’ which ensures a secure connection end-to-end and avoids these types of loops.

5. Clear All Caches: This is a critical final step. After you’ve applied a fix, you must clear every layer of caching: your browser cache, your plugin/CMS cache, your server cache (like Varnish), and your CDN cache. A lingering cached 301 redirect can make it seem like your fix didn’t work, sending you on a pointless troubleshooting mission.

# CORRECT .htaccess: Combining HTTPS and WWW rules

RewriteEngine On

# Condition 1: Is it NOT HTTPS? OR...
RewriteCond %{HTTPS} off [OR]
# Condition 2: Is the host NOT starting with www?
RewriteCond %{HTTP_HOST} !^www. [NC]

# If either condition is true, redirect to the canonical https://www version
RewriteRule ^(.*)$ https://www.example.com%{REQUEST_URI} [L,R=301,NE]

Advanced Scenarios: When the Usual Fixes Fail

Sometimes the problem is more esoteric than a simple `.htaccess` typo. If you’ve gone through the standard checklist and are still tearing your hair out, consider these less common but equally frustrating scenarios.

A particularly nasty issue involves cookie-based redirects. The server might try to redirect a user to a specific version of a page based on a cookie (e.g., for A/B testing or language preference). If the cookie-setting logic is flawed, it can create a loop that only affects certain users or bots, making it incredibly difficult to replicate. You may need to use your browser’s developer tools to inspect and clear cookies for the site to break the cycle.

Geolocation and multi-language setups are also ripe for redirect loops. A rule that sends users from the US to `/en-us/` and another that sends users without a specific language cookie to the root domain can conflict, sending the user on a merry-go-round. This requires a careful audit of your internationalization logic.

Finally, remember the distinction between a long redirect chain and a true loop. A chain of 15 redirects before reaching a final 200 OK page isn’t a loop, but it’s still terrible for performance and SEO. Our guide to HTTP status codes explains why every hop matters. A good crawler will report on both, but fixing them requires different approaches: a loop is about breaking a circle, while a chain is about consolidating hops.

Prevention: Building a Redirect-Loop-Resistant Website

Fixing a redirect loop is a reactive task. The goal of a mature technical SEO strategy is to be proactive. Preventing these errors from happening in the first place saves time, protects your rankings, and lets you sleep at night.

First, establish a single source of truth for your redirects. Don’t manage some redirects in a plugin, some in `.htaccess`, and others at the CDN level. Pick one location—preferably as close to the server as possible—and stick to it. This centralization makes auditing and debugging infinitely simpler.

Second, never deploy changes to redirect logic directly to production. Use a staging or development environment that mirrors your live setup. Test your changes thoroughly before pushing them. This is non-negotiable for major changes like a domain migration or a move to HTTPS.

Finally, make proactive crawling a part of your regular maintenance schedule. Run a full crawl of your site with ScreamingCAT weekly or monthly. Set up alerts for high-priority issues like redirect loops or new temporary redirects that might indicate a problem. Catching a loop the day it happens is a minor inconvenience; finding it three months later is a recovery effort.

An ounce of prevention is worth a pound of cure. And in SEO, a pound of cure often involves months of trying to win back lost rankings.

Every SEO who's ever fixed a sitewide redirect loop