ERR_TOO_MANY_REDIRECTS is a browser error that appears when a browser gets stuck following a chain of redirects that never reaches a final destination. The browser follows redirect after redirect, each one pointing to another URL, until it hits its internal limit, gives up, and displays the error to the visitor.

It is the client-side manifestation of a redirect loop. The server is not broken, it is responding correctly to each individual request. The problem is that the redirect rules are configured in a way that creates a circular path with no exit. URL A sends the browser to URL B. URL B sends it back to URL A. Or the chain is longer, A to B to C to D and back to A, but the result is the same. The browser circles endlessly until it stops itself.

Different browsers display this error under slightly different names. Chrome shows ERR_TOO_MANY_REDIRECTS. Firefox shows “The page isn’t redirecting properly.” Safari shows “Safari can’t open the page because too many redirects occurred.” Edge shows ERR_TOO_MANY_REDIRECTS like Chrome. The underlying cause and fix are identical regardless of which browser surfaces it.

How ERR_TOO_MANY_REDIRECTS happens

Every browser has an internal limit on how many redirects it will follow for a single request before giving up. Chrome’s limit is around 20 hops. Firefox and Safari have similar thresholds. When a browser hits this limit without reaching a URL that returns a final response (typically a 200 OK) it stops and displays the error.

The error occurs because redirect rules somewhere in the chain create a loop. This can happen in several ways:

• Direct circular redirect: the simplest form. URL A has a redirect pointing to URL B, and URL B has a redirect pointing back to URL A. Every visit to either URL bounces between the two indefinitely.

• WWW to non-WWW loop: one of the most common real-world causes. A server rule redirects www.example.com to example.com while another rule, perhaps configured at a different layer, redirects example.com back to www.example.com. The two rules conflict and create a loop between the two variants.

• HTTP to HTTPS loop: a server is configured to redirect HTTP to HTTPS, but SSL is not correctly configured, causing the HTTPS version to redirect back to HTTP. Or a CDN handles HTTPS termination and forwards requests to the origin over HTTP, while the origin has its own HTTP to HTTPS redirect rule that fires on every request it receives from the CDN, including those already on HTTPS.

• Wildcard redirect catching its own destination: a catch-all redirect rule that redirects all traffic on a domain including the URL it is redirecting to. The destination gets caught by the same rule and redirected again, creating an instant loop.

• Conflicting redirect rules across multiple layers: redirect rules configured at the server level, the CDN level, the application level, and in .htaccess files can interact in unexpected ways. A rule that works correctly in isolation can create a loop when combined with rules at another layer.

• Cookie or session conflicts: in some cases ERR_TOO_MANY_REDIRECTS is caused not by redirect rules but by corrupted browser cookies or session data. A site may use redirects as part of its authentication or session management flow, and corrupted cookie data can cause the browser to be redirected repeatedly as the server tries to establish a valid session that the corrupted cookie prevents from completing.

ERR_TOO_MANY_REDIRECTS vs 508 Loop Detected

These two errors both result from redirect loops but occur at different points in the request cycle.

ERR_TOO_MANY_REDIRECTS is a client-side browser error. The browser follows redirect after redirect, receiving valid responses at each step, each one a 3xx status code with a Location header pointing to the next URL. The server is not detecting the loop. The browser is. It follows hops until it hits its limit, then stops and displays the error.

A 508 Loop Detected is a server-side response. The server itself detects the loop during request processing and returns a 508 before the browser has followed multiple hops. This requires the server or infrastructure to have proactive loop detection built in, it monitors the processing cycle and intervenes when it identifies a circular pattern.

In practice, ERR_TOO_MANY_REDIRECTS is far more commonly encountered than a 508 because most standard web server configurations do not implement proactive server-side loop detection. The browser almost always detects the loop before the server does.

ERR_TOO_MANY_REDIRECTS and SEO

From an SEO perspective, ERR_TOO_MANY_REDIRECTS is one of the most damaging errors a URL can return. A URL caught in a redirect loop is completely inaccessible, not just to human visitors but to Googlebot and every other web crawler.

When a crawler encounters a redirect loop it cannot follow the chain to its conclusion any more than a browser can. It eventually stops following the hops and marks the URL as unresolvable. Content at that URL cannot be indexed. SEO equity and link juice from backlinks pointing to looping URLs goes nowhere. Crawl budget is wasted on requests that never resolve.

If a looping URL previously had rankings, those rankings disappear as the URL becomes consistently inaccessible. Unlike a 404 where the server at least responds definitively, a redirect loop leaves the URL in a state of perpetual unresolvability that search engines handle less gracefully. Resolving redirect loops is one of the highest-priority technical SEO fixes on any site.

How to diagnose ERR_TOO_MANY_REDIRECTS

Diagnosing ERR_TOO_MANY_REDIRECTS requires tracing the full redirect chain to find where the circular reference occurs.

• Browser developer tools: open the Network tab in browser developer tools before visiting the affected URL. Each redirect hop appears as a separate request showing the status code and Location header. Following the chain through the Network tab makes the loop visible, you will see the browser cycling back to URLs it has already visited.

• curl command line: running curl -Lv https://example.com with the -L flag to follow redirects and -v for verbose output traces the full redirect chain including every status code and Location header. The loop becomes obvious when the output starts cycling through the same URLs repeatedly.

• Redirect checking tools: dedicated redirect checker tools follow chains automatically and flag loops explicitly, showing every hop in sequence. These are faster than manual tracing for complex chains involving multiple domains or redirect layers.

• Clear browser cookies first: before spending time diagnosing server-side redirect rules, try clearing cookies for the affected domain. If clearing cookies resolves the error, the cause is cookie or session corruption rather than misconfigured redirect rules. This is a quick way to rule out one of the most common causes before diving into server configuration.

• Review all redirect rule sources: redirect loops often occur because rules exist at multiple layers simultaneously. Check .htaccess files, Nginx config blocks, Apache virtual host configuration, CDN redirect rules, application-level redirects, and any redirect management tools in use. The conflict is frequently between rules at two different layers that each look correct in isolation.

How to fix ERR_TOO_MANY_REDIRECTS

The fix depends on the underlying cause identified during diagnosis.

• Fix circular redirect rules: if the loop is caused by conflicting redirect rules, identify the two or more rules that are creating the circular path and remove or correct the conflict. Ensure that redirect rules at every layer (server, CDN, application) are consistent and pointing in the same direction.

• Fix www and non-www conflicts: ensure that only one canonical version of the domain is configured as the destination and that all redirect rules point toward it consistently. A rule at the server level and a conflicting rule at the CDN level pointing to opposite versions is a classic cause of this specific loop.

• Fix HTTP to HTTPS loops in proxied environments: if a CDN or reverse proxy is handling HTTPS termination and forwarding requests to the origin over HTTP, disable the HTTP to HTTPS redirect rule on the origin server. The HTTPS handling is already done at the proxy layer, adding it again at the origin creates a loop.

• Clear browser cookies: if the error is caused by corrupted cookie or session data, clearing cookies for the affected domain in the browser resolves it immediately for that visitor. On the server side, review session management and authentication redirect logic to prevent the issue recurring for other users.

• Audit wildcard redirect rules: ensure catch-all redirect rules explicitly exclude their own destination domain or URL pattern. A wildcard rule on example.com that redirects all traffic to newdomain.com is fine, unless newdomain.com has a rule that redirects back to example.com.

• Test at every layer: after making fixes, verify the full redirect chain using curl or a redirect checker before testing in a browser. Confirm that the chain resolves to a 200 OK response in the fewest possible hops with no loops.

How to prevent ERR_TOO_MANY_REDIRECTS

Prevention is more reliable than diagnosis and repair. Most redirect loops are caused by a lack of visibility into the full set of redirect rules across all layers of the infrastructure.

• Manage redirects centrally: using a single redirect management tool rather than configuring rules across multiple .htaccess files, server configs, CDN settings, and application code gives you a complete picture of all redirect rules in one place. Conflicts are far easier to spot when all rules are visible together.

• Test redirect chains after every change: any time a redirect rule is added, modified, or removed, verify the full chain for affected URLs immediately. A loop that is caught in testing before deployment is a minor inconvenience. A loop that reaches production is an outage.

• Use staging environments: redirect configuration changes should always be tested in a staging environment before being applied to production. Staging environments should mirror the full infrastructure, including CDN configuration, so that cross-layer conflicts are caught before they affect real visitors and crawlers.

• Audit redirect rules regularly: redirect configurations accumulate over time as sites evolve. Rules added for specific scenarios can interact unexpectedly with newer rules. Regular audits of the complete redirect rule set help identify potential conflicts before they cause problems.

• Document redirect rule intent: keeping clear documentation of what each redirect rule does, why it was added, and what it depends on makes it easier to identify conflicts when new rules are being considered and easier to diagnose loops when they do occur.

Quick checklist when you see ERR_TOO_MANY_REDIRECTS

1. Clear browser cookies for the affected domain and retry

2. Open browser developer tools Network tab and trace the redirect chain

3. Run curl -Lv [URL] to see the full chain in the terminal

4. Check redirect rules at every layer: server, CDN, application, .htaccess

5. Look specifically for www vs non-www conflicts

6. Look specifically for HTTP vs HTTPS conflicts in proxied environments

7. Check for wildcard redirects that may be catching their own destinations

8. Fix the conflicting rules and verify the chain resolves to 200 OK

9. Test across multiple browsers to confirm the fix