A redirect loop is a configuration error where redirect rules create a circular path that has no exit. URL A redirects to URL B. URL B redirects back to URL A. Or the loop is longer, A redirects to B, B to C, C to D, D back to A, but the result is the same. The browser or crawler follows redirect after redirect, cycling through the same URLs indefinitely, never reaching a final destination that returns a 200 OK.

Browsers detect this by counting redirect hops. When the count exceeds the browser’s internal limit, typically around 20 hops, the browser stops, gives up, and displays an ERR_TOO_MANY_REDIRECTS error. The page is completely inaccessible. Not slow, not degraded: completely broken for every visitor and crawler attempting to reach it.

A redirect loop is distinct from a redirect chain in one critical way. A redirect chain has a final destination: it reaches a 200 OK eventually, just through more hops than necessary. A redirect loop has no final destination. It cycles indefinitely with no exit condition. The difference between a chain and a loop is the difference between a performance problem and a complete outage.

How a redirect loop forms

Redirect loops almost always form when redirect rules are configured at multiple layers of infrastructure without a complete picture of how those rules interact. Each individual rule looks correct in isolation. The loop only appears when the rules are evaluated together.

The most common formation patterns are:

Direct circular redirect: the simplest form. URL A has a redirect rule pointing to URL B. URL B has a redirect rule pointing back to URL A. Every request to either URL bounces between the two indefinitely. This most commonly occurs when redirect rules are added in two different places, perhaps one in an .htaccess file and another in a CDN configuration, without awareness of each other.

WWW to non-www loop: one of the most common real-world redirect loop causes. A server rule redirects www.example.com to example.com. Another rule, perhaps at a different infrastructure layer, redirects example.com back to www.example.com. The two rules point at each other and neither ever reaches a final destination. This is the most classic multi-layer conflict loop.

HTTP to HTTPS loop: a server is configured to redirect HTTP to HTTPS. But SSL is misconfigured or absent, causing the HTTPS version to fail and redirect back to HTTP. Or a CDN or reverse proxy terminates SSL and forwards requests to the origin over HTTP, while the origin has its own HTTP to HTTPS redirect rule, creating a loop where the CDN forwards HTTP to the origin, the origin redirects to HTTPS, the CDN intercepts the HTTPS request and forwards HTTP again.

Wildcard redirect catching its own destination: a catch-all redirect rule on example.com redirects all traffic to newdomain.com. But newdomain.com has a rule redirecting back to example.com. Or more subtly, the wildcard rule on example.com includes the destination URL in its match scope, redirecting newdomain.com traffic back through example.com in a loop.

Canonical enforcement conflict: two domains each configured to redirect to the other as the canonical version. domainA.com redirects to domainB.com as the canonical domain. domainB.com redirects to domainA.com as the canonical domain. Neither ever serves content.

Application-level session loops: web applications that use redirects as part of authentication or session management can create loops when session state is corrupted or when authentication logic redirects to a page that requires authentication, which redirects to the login page, which redirects to the authenticated destination, which requires authentication again.

Redirect loops vs redirect chains

Understanding the distinction between a redirect loop and a redirect chain is important because they present differently, have different severity, and require different responses.

A redirect chain is a sequence of redirects that eventually reaches a 200 OK destination, just through more hops than necessary. A → B → C → D → 200 OK. The page is accessible, just slower than it should be and leaking SEO equity through the unnecessary hops. A redirect chain is a performance and SEO problem that should be fixed systematically but does not cause immediate access failure.

A redirect loop is a sequence of redirects that never reaches a 200 OK. A → B → A → B → A… The page is completely inaccessible. Visitors see ERR_TOO_MANY_REDIRECTS. Googlebot cannot index the content. Backlinks pointing to the URL pass no link juice anywhere. A redirect loop is an outage requiring immediate resolution.

The diagnostic tools for both are the same, curl, browser developer tools, redirect checkers, but the urgency is completely different. A redirect loop on any important URL should be treated as a critical incident and resolved as quickly as possible.

Redirect loops and SEO

A redirect loop is one of the most harmful configurations a URL can have from an SEO perspective. The damage is immediate and total for the affected URLs.

Complete loss of indexability: Googlebot follows redirect loops the same way browsers do, hop by hop until it hits its limit. Googlebot follows up to five redirect hops before stopping. A loop means Googlebot never reaches a 200 OK destination. It cannot index content it cannot access. Any URL caught in a redirect loop is completely absent from search results for as long as the loop persists.

Link juice goes nowhere: backlinks pointing to a URL in a redirect loop have nowhere to pass their SEO equity. The redirect chain never resolves to a final destination so there is no URL to receive the equity. All of the accumulated link value pointing to that URL is effectively lost for the duration of the loop.

Crawl budget waste: Googlebot attempting to crawl a looping URL wastes crawl budget following hops that never resolve. On sites with multiple redirect loops, a meaningful portion of crawl budget is consumed by unresolvable requests rather than productive crawling of live content.

Rankings disappear immediately: if a page that was previously ranking in search results enters a redirect loop, its rankings disappear quickly. Search engines cannot serve a looping URL in results because it is not accessible. Recovery depends on resolving the loop and waiting for the next crawl, which can take days to weeks depending on crawl frequency.

Recovery is not instant: even after a redirect loop is resolved, the URL does not immediately reappear in search results. The crawler needs to recrawl the URL, confirm it now returns a 200 OK or appropriate redirect, and reprocess its ranking signals. For important pages this recovery should be accelerated by submitting the URL for crawling through Google Search Console.

Diagnosing a redirect loop

Redirect loops are diagnosed by tracing the full redirect chain to identify where the circular reference occurs. Several tools make this straightforward.

Browser developer tools: open the Network tab before visiting the affected URL. Each redirect hop appears as a separate request. A loop becomes visible when the same URL appears multiple times in the request list, the browser cycling back to URLs it has already visited. The browser will stop after its limit and display the ERR_TOO_MANY_REDIRECTS error.

curl command line: curl -IL https://example.com/url with -I for headers only and -L to follow redirects traces the full chain. With the --max-redirs flag the number of followed redirects can be limited for safety. A loop becomes visible when the output starts repeating the same URLs. Without a redirect limit curl may follow the loop for a very long time; add --max-redirs 10 to cap it at ten hops.

Redirect checking tools: dedicated redirect checker tools detect loops automatically and display them clearly, showing the circular path and identifying exactly which hop creates the circle. These are the fastest way to diagnose loops on specific URLs.

Checking all redirect layers simultaneously: because loops typically form from conflicts between redirect rules at different layers, the most effective diagnostic approach reviews all redirect rules across all layers, .htaccess files, Nginx config, CDN rules, application code, redirect management tools, in one place. The conflicting rules are usually immediately obvious when seen together.

Clearing browser cookies first: before diving into server-side configuration, clear cookies for the affected domain and retry. Some loops are caused by corrupted session cookies rather than misconfigured redirect rules. If clearing cookies resolves the error, the cause is application-level session management rather than infrastructure redirect configuration.

Fixing a redirect loop

Once the loop is identified, which hop creates the circular reference, the fix is removing the circular reference from the redirect rules.

Identify the conflicting rules: trace the full loop and identify every redirect rule involved. Note where each rule is configured: which .htaccess file, which CDN rule, which application redirect, which redirect management tool entry.

Remove or correct the rule creating the circle: determine which rule in the loop is incorrect or misplaced and remove or update it. In a two-URL loop — A → B → A — one of the two rules is wrong. In a multi-URL loop, the rule that redirects back to an earlier URL in the chain is the one creating the circle.

Fix www and non-www conflicts: ensure redirect rules at every layer consistently redirect toward the canonical version of the domain, never away from it. If the canonical version is non-www, every rule that touches www should redirect to non-www. No rule should redirect non-www back to www.

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

Fix session and cookie loops: application-level loops caused by corrupted session state require identifying the authentication or session logic that is creating the circular redirect flow and adding a guard condition that prevents the redirect from firing when the session is in the problematic state. Clearing the affected user’s cookies resolves the immediate symptom but the underlying logic needs to be fixed to prevent recurrence.

Verify the fix: after making changes, verify the redirect chain using curl or a redirect checker tool before testing in a browser. Confirm the chain resolves to a 200 OK in the expected number of hops. Test all URL variants, HTTP and HTTPS, www and non-www, to confirm the fix holds across all entry points.

Submit for recrawl: after resolving a loop on an important URL, submit it for recrawl through Google Search Console to accelerate reindexing rather than waiting for Googlebot to return on its regular crawl schedule.

Preventing redirect loops

Preventing loops is more reliable than diagnosing and fixing them. Most loops are preventable through process discipline and infrastructure hygiene.

Manage redirects centrally: configuring redirect rules across multiple layers simultaneously — .htaccess files, CDN rules, application code, redirect management tools, without a complete picture of how they interact is the primary cause of loops. Managing all redirects through a single tool or layer eliminates the possibility of conflicts between layers that neither layer can see.

Test after every redirect change: any time a redirect rule is added, modified, or removed, trace the full chain for the affected URLs immediately. A loop that is caught in a staging environment before deployment is a minor inconvenience. A loop in production on an important URL is a significant SEO incident.

Use staging environments that mirror production: redirect loops caused by CDN configuration conflicts only appear when the CDN layer is present. A staging environment that does not include CDN configuration will not reproduce CDN-related loops. Staging environments should mirror the full infrastructure stack for redirect testing to be meaningful.

Audit redirect rules regularly: redirect configurations accumulate over time. Rules that worked correctly when added can create loops when new rules are added later. Regular audits of the complete redirect rule set, looking specifically for rules whose destinations are themselves redirect sources pointing back toward earlier URLs, catch potential loops before they activate.

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

Redirect loops in development environments

Redirect loops are particularly common during active development and site migration phases when redirect rules are being added rapidly and multiple team members may be configuring different infrastructure layers simultaneously.

During development, a loop that appears in one environment but not another is often a sign that the environments have different redirect configurations: a rule exists in production that does not exist in development, or a CDN layer present in production is absent in development. Ensuring development environments accurately mirror production redirect configuration is essential for reliable redirect testing.

During site migrations, loops frequently form when old redirect rules from the previous infrastructure are preserved alongside new redirect rules for the migration, creating conflicts between old and new rules. Auditing and clearing legacy redirect rules before adding migration redirects, rather than layering new rules on top of old ones, prevents this.