Redirect Loops

What redirect loops are, why they take a site down for users and crawlers, common causes (HTTPS/SSL-mode mismatches, www vs non-www conflicts, plugin vs server rules, trailing-slash bugs), and how to diagnose and fix them by cause.

First published: Jul 2, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #6 in Redirects#19 in HTTP Status Codes#162 in Technical SEO#219 on the site
AIAuthored byAI v2
1 evidence signal on this page

A redirect loop is a chain of redirects that circles back on itself — A → B → A, or a longer cycle — so no page ever returns a 200. Browsers surface it as ERR_TOO_MANY_REDIRECTS; in Google Search Console it's one of four documented causes of the 'Redirect error' status. It's a site-outage problem first (real visitors are locked out) and an SEO problem second (Google can't index what it can't reach), and Patrick's framing is that it harms three parties: users, crawlers, and your own server. A well-documented cause is an HTTPS/SSL-mode mismatch between a CDN and the origin (e.g. Cloudflare on 'Flexible' while the origin forces HTTPS); other common causes are www/non-www rules pointing at each other, a plugin rule fighting a server rule, and trailing-slash bugs — no single cause is the universal or most common one across every site. A loop is not a hop-count problem — raising the redirect limit never fixes it. The fix is always specific to the cause: break the cycle, get the final URL to return the correct non-redirect response, and update internal links.

TL;DR — A redirect loopA redirect loop is a chain of redirects that circles back on itself instead of ever reaching a live page — URL A redirects to B and B redirects back to A (or a longer cycle). No page ever returns a 200, so browsers show ERR_TOO_MANY_REDIRECTS and crawlers can't index anything. is a cycle of redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. (A → B → A, or longer) that never returns a 200, so it never resolves. It’s categorically different from a long chain — a chain is slow, a loop is broken — which is why raising a hop limit never fixes one. It surfaces as ERR_TOO_MANY_REDIRECTS in the browser and as one of four documented causes of the “Redirect errorA Google Search Console Page Indexing status meaning Googlebot couldn't follow a redirect — a chain too long, a loop, a URL over the max length, or a bad/empty URL in the chain. It's a broken redirect to fix, not the normal \"Page with redirect.\"” status in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. It harms three parties: users (locked out), crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (trapped, wasted crawl budget, nothing indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.), and your server (wasted resources, and — depending on traffic, whether the requesting clients back off, and your capacity/rate limits — potentially serious load). A well-documented cause is an HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'/SSL-mode mismatch between a CDN/proxy and the origin; others include www/non-www rules pointing at each other, a plugin rule fighting a server rule, and trailing-slash logic bugs — no single cause is universally “the most common” across every site. The fix is always specific to the cause.

A loop is a cycle, not a long chain

The defining property is cyclic routing, not a particular number of hops. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 9110: Redirection Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s label reports the failed redirect path, not the configuration layer that created it. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Page indexing report Treat a repeated URL as a strong trace heuristic, not automatic proof: request state — auth, consent, locale, cookies, or headers — can differ between visits, and a URL that looked like it was cycling can resolve once that state changes. Confirm a true loop by reproducing the cyclic transition under materially equivalent request state (same session, same cookies, same locale) before you call it a loop and go fix a rule.

This is the distinction that makes everything else make sense. Here’s how I define it in my Ahrefs guide to redirects: redirect loops are infinite loops of redirects that occur when a URL redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. to itself, or when a URL in a redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency. redirects back to a URL earlier in the chain.

A redirect chain (A → B → C → D → final) is a path — it’s just longer than it should be. It eventually reaches a page that returns 200. It’s slow and it’s worth collapsing, but it resolves.

A redirect loop is a circle. A → B → A. It never reaches a 200, no matter how long you follow it. That’s why “just increase the redirect limit” — a reasonable instinct if you’re thinking about chains — is not a valid fix for a loop. A loop doesn’t fail because a browser ran out of patience; it fails because there is no destination to reach. You have to break the cycle, not follow more hops.

How a loop shows up

In the browser. Chrome shows ERR_TOO_MANY_REDIRECTS. Firefox says “The page isn’t redirecting properly.” Safari says “too many redirects occurred.” Edge shows its own “too many redirects” message. Same root cause, different wording.

In Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. A loop is one of four documented causes of the “Redirect errorA Google Search Console Page Indexing status meaning Googlebot couldn't follow a redirect — a chain too long, a loop, a URL over the max length, or a bad/empty URL in the chain. It's a broken redirect to fix, not the normal \"Page with redirect.\"” status in the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason. — the others being a redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency. that was too long, a redirect URL that exceeded the max URL length, and a bad or empty URL in the chain. If you’re seeing “Redirect error” pile up in that report, a loop is one of the four things it could be. That report reflects what Google saw on its last crawl of the URL, not a live, permanently-current verdict — re-check with URL Inspection after you fix the cycle rather than assuming the report updates instantly. (The redirect error status has its own deep dive on this site that covers all four; this article is the one specifically about the loop.)

To crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. and in your logs. A crawler that hits a loop keeps requesting URLs that keep redirecting. Well-behaved bots detect it and stop; less well-behaved ones don’t, which is where the server-load problem comes from (below).

Why loops matter — three parties get hurt

I frame redirect loops as a three-way problem, because they don’t just cost you rankings — they hit users, bots, and your own infrastructure:

  • For users. They cut off access to the intended resource and trigger a “too many redirects” error in the browser. The page is simply unreachable. This is the headline: it’s a site-outage problem first.
  • For bots and search engines. They trap crawlers and waste crawl budgetThe number of URLs an engine will crawl in a timeframe.. A crawler can’t follow a loop to anything indexable, and Google’s own documentation reports this as a “Redirect error” — there’s nothing on the far side of the cycle to crawl through, so there’s nothing to index or rank. It’s not a penalty; the page just functionally can’t be reached. (None of Google’s normal redirect logic — like signals consolidating to a destination over time — applies, because there’s no destination Google ever reaches.)
  • For your server. Loops waste your resources. Some bots detect the loop and back off; others don’t, and a client that keeps re-requesting a looping URL without backing off adds sustained, wasted load. Whether that rises to a serious outage — potentially a self-inflicted DDoS-like event — depends on how much traffic is hitting the loop, whether the responses are cacheable, and your server’s capacity and rate limiting; it isn’t an inherent property of every loop, but it’s a real risk on high-traffic or heavily-crawled sites with no rate limiting in front of them, and it’s an angle most write-ups miss.

Common causes

There’s no single universal cause — every real-world loop traces back to conflicting canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. rules across layers that don’t share state. Two different systems each “know” what the correct URL should be, and they disagree, so they bounce the request back and forth. Here are the specific patterns worth checking; which one applies depends on your stack, not a fixed frequency ranking.

HTTP/HTTPS conflict between a CDN and the origin

If you put a proxy/CDN like Cloudflare in front of your site, the connection has two legs: browser → CDN, and CDN → origin. If those two legs disagree about HTTP vs HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', you get a loop entirely at that boundary. Cloudflare’s own troubleshooting doc names this family of causes directly: a misconfigured SSL/TLS Encryption mode, conflicting settings on the Edge Certificates page, or a misconfigured redirect rule — common within Cloudflare’s own product, not necessarily the single most common cause of loops everywhere. A few concrete branches:

  • Flexible mode + origin forces HTTPS. In Flexible SSL mode, Cloudflare talks to your origin over plain HTTP — even though the visitor is on HTTPS. If your origin is also configured to force HTTP → HTTPS (via .htaccess, nginx config, or a plugin): Cloudflare sends HTTP to the origin, the origin says “you must use HTTPS” and redirects, Cloudflare (still Flexible) sends HTTP again, and it repeats forever. Fix: switch Cloudflare to Full or Full (strict) SSL/TLS mode so the CDN→origin leg is also HTTPS (Full strict needs a valid cert on the origin).
  • Full/Full (strict) mode + origin redirects HTTPS → HTTP. Less common, but if the origin has a leftover rule that redirects HTTPS back to HTTP (e.g. from before you enabled Full/strict), the CDN keeps re-requesting over HTTPS and the origin keeps bouncing it to HTTP. Fix: remove the origin-side HTTPS→HTTP rule — the origin should serve HTTPS directly once the CDN is set to Full/strict.
  • “Always Use HTTPS” at the edge plus an origin-level HTTPS redirect. Double-forcing HTTPS at both the edge and the origin (or an HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. rule fighting a redirect rule) can build the same kind of loop. Fix: pick one place to force HTTPS, not two.
  • A misconfigured redirect rule (a Cloudflare Page Rule, Bulk Redirect, or Transform Rule that sends a URL back toward a form it’s already redirecting away from). Fix: audit edge-level redirect rules for one that contradicts the origin’s own canonicalization.

www / non-www rules that redirect into each other

You want one canonical host — either www.example.com or example.com. A loop happens when one rule sends example.com → www.example.com and another rule (often in a different place — a plugin, a CDN redirect rule, a WordPress “Site Address” setting) sends www.example.com → example.com. Each fires, the other undoes it, forever. Fix: decide on one canonical host, and make sure only one rule (in one place) enforces it, redirecting the other way.

A plugin/CDN rule conflicting with a server/origin rule

The theme running through the causes above is that the loop lives between layers. A WordPress SSL-forcing plugin (or the “WordPress Address” / “Site Address” fields in Settings → General) can disagree with a .htaccess rewrite or a CDN edge rule. Each layer is individually “correct” but they don’t share state, so they fight. “My .htaccess looks fine” doesn’t rule out a loop — the conflicting rule may live at the edge or in a plugin you forgot was there. Fix: find the two rules doing the same job in different places and remove one.

Trailing-slash vs no-trailing-slash logic bugs

A rule that adds a trailing slashA trailing slash is the forward slash (/) at the end of a URL — example.com/page/ versus example.com/page. Except at the bare root domain, the two versions are different URLs to search engines, so you pick one format and enforce it. (/page → /page/) can collide with a rule that strips it (/page/ → /page), producing a loop on that URL. This is usually a single misconfigured rewrite where the condition and the target don’t line up. Fix: decide slash or no-slash, and make the rule only redirect the wrong form to the right one (never redirect a URL to a form that then redirects back).

Leftover, stacked rules from a past migration

Migrations are a common real-world source of loops. HTTP → HTTPS moves, www consolidation, domain changes, and CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. replatforms all involve adding redirect rules — and when you stack a new layer on top of old rules nobody cleaned up, two of them can end up pointing at each other. If a loop appeared “out of nowhere,” check whether a migration left redirect rules behind.

How to diagnose a loop

You want to see the loop, not guess at it.

Trace it from the command line with an actual GET request — not a HEAD-only trace. Send the same kind of request a real visitor or crawler would, and record each status code and Location header without letting curl auto-follow first, so you can see every hop instead of just the final outcome:

# GET is curl's default method (no -I); -L follows redirects; --max-redirs caps how far
curl -sL --max-redirs 10 -D - -o /dev/null https://www.example.com/ | grep -i -E '^(HTTP/|location:)'
# A loop shows the same two (or few) URLs alternating and never a 200 —
# curl stops with "Maximum (10) redirects followed".

To see the effective URL at each stop:

curl -sL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/

Then compare against a HEAD-only trace (curl -sIL --max-redirs 10 ...) as a secondary check, not your primary evidence — HEAD and GET are different request methods, and application logic can occasionally handle them differently, so a HEAD-only trace can miss redirect behavior that only shows up on the real request. Never replay unsafe methods (like a form’s POST) just to trace a loop.

If the same host/scheme pair repeats and you never see a 200, that’s the loop — and the two URLs that keep alternating tell you exactly which canonicalization rule is fighting (scheme = HTTP/HTTPS mismatch; host = www/non-www; trailing slash = the slash bug). From there, map each hop to the layer that produced it — browser/HSTS, edge/TLS (CDN), reverse proxy, origin server, application/CMS, or session/auth logic — because a loop happens when two of those layers don’t share state and each insists it’s right.

Other ways in:

  • Browser DevTools → Network tab. Watch the redirect requests stack up before the error, with each Location header visible.
  • Test with and without the CDN. If you can hit the origin directly (bypassing Cloudflare) and it doesn’t loop, the conflict is between the CDN and origin — that points you straight at the SSL-mode cause.
  • Google Search Console. URL Inspection on an affected URL, and the “Redirect error” bucket in the Page Indexing reportThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., tell you which URLs Google is choking on. Google’s Inspection Tools documentation states that Inspection Tools do not follow redirects — so read a URL Inspection result as a report on the exact URL you tested, not as confirmation of what’s on the other side of the loop.
  • A site-wide crawler — Ahrefs’ Site Audit or Screaming Frog — catches loops you don’t know about. In Ahrefs Site Audit: crawl the site (free with an Ahrefs Webmaster Tools account) → Redirects report → Issues tab → look for the “Redirect loop” error, then “View affected URLs” to see the full chain.
TIP Trace the cycle until a URL repeats

A redirect loop has no final destination. The useful evidence is the repeated URL and the rule owner responsible for each hop.

Expose the full cycle with my free Redirect Checker Free

  1. Test the failing public URL without relying on a cached browser session.
  2. Find the first repeated URL and map every hop to its edge, server, application, or CMS owner.
  3. Remove the conflicting rule, point the source directly to the final destination, and rerun the trace.
The repeated URL proves the cycle; the mixed 301 and 302 statuses are secondary findings.

The result labels the redirect broken and fix now. It shows 301 from URL A to URL B, 302 from B back toward A, and 301 to A, with no final URL. It states that the chain revisits a URL and never resolves.

How to fix a loop

Once you know the cause, the structural fix is the same decision every time. The best way to fix a loop depends on whether the last URL in the chain — the one right before the loop closes — is the intended final destination:

  • If it is the intended destination: remove the redirect from that final URL, and make sure the resource is actually accessible and returns the correct non-redirect response for that endpoint — usually 200, though the right status depends on the resource (a removed page, for instance, should return its own correct status, not a fake 200).
  • If it isn’t: change the looping redirect to point at the intended final destination instead.

In both cases, also swap out any internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. that point at a redirecting URL for direct links to the final URL — don’t keep feeding the machine URLs that redirect.

Platform-specific fixes:

  • Cloudflare (by SSL mode): move from Flexible to Full or Full (strict) so the CDN→origin leg matches the browser→CDN leg, and don’t force HTTPS at both the edge (“Always Use HTTPS”) and the origin. Full (strict) needs a valid certificate on the origin.
  • WordPress: check Settings → General — “WordPress Address (URL)” and “Site Address (URL)” should match your real canonical scheme/host. Then look for an SSL-forcing plugin (or a FORCE_SSL_ADMIN / redirect snippet in wp-config.php or the theme) that duplicates whatever your server or CDN is already doing, and remove the duplicate. A corrupted .htaccess can also loop — regenerating it from Settings → Permalinks is a common reset.
  • Apache (.htaccess): make sure your HTTPS-forcing and www-forcing RewriteRules have conditions that exclude the already-correct form, so they only redirect the wrong version once.
  • nginx: the same principle — a return 301 for HTTPS or host canonicalization must not fire on requests that are already in the canonical form.

A note on hop limits (the myth to avoid)

Because a loop can look like “too many redirects,” people reach for hop-count solutions — raising max-redirs, bumping a redirect limit in a plugin. That never fixes a true loop. A loop is not a “how many hops is too many” problem the way a long chain is; it fails on the first pass regardless of any hop tolerance, because the cycle never terminates. The only fix is to break the cycle.

A note on Bing

Google formally names “redirect loop” as one of four “Redirect error” causes in its Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. documentation. Bing’s public guidance is more general: use 301s for permanent moves and avoid unnecessary redirect chains. This research didn’t surface a Bing page specifically named “redirect loop” — but that’s a gap in what was checked, not confirmation that Bing has no such guidance anywhere, so treat the four-cause framework above as Google-specific rather than assuming Bing documents loops the same way.

A redirect chain is the sibling problem — a chain that’s too long is a different one of the four “Redirect error” causes, and unlike a loop it does eventually resolve. A 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. is the permanent redirect you’ll usually collapse a loop down to; a 302 redirectA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. is its temporary counterpart. And the redirect error status in Search Console is the GSC report where a loop most often surfaces for SEO purposes.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.