Redirect Loops: Why They Matter and How to Fix Them

What a Redirect Loop Is

A redirect loop occurs when one URL sends a browser or crawler to another URL, and a later redirect sends it back to a URL it has already visited. The request never reaches a final page or other terminal response.

https://www.example.com/page-a
  → https://www.example.com/page-b
  → https://www.example.com/page-a
  → repeats

The HTTP specification says clients should detect and intervene in cyclical redirections. Browsers therefore stop after a limited number of hops and may display messages such as ERR_TOO_MANY_REDIRECTS or “The page isn’t redirecting properly”. The wording varies by browser; the important fact is that no usable destination was reached.

A redirect loop is different from a redirect chain. A chain eventually ends at a page, file or deliberate error response. A loop revisits an earlier URL and has no end. Any redirect status can be involved: changing a 301 to a 302, for example, does not remove a cycle.

Redirect Loop Diagnosis in 60 Seconds

Start by defining what the URL should do. For a normal public page, that usually means reaching one preferred HTTPS URL and returning 200 OK. A download, login-protected route or deliberately removed page may have a different valid final response.

1. Reproduce the problem with the exact affected URL. Test both a normal browser session and a private window. If only one fails, cookies, login state, locale or cached rules may be part of the condition.
2. Trace the response headers rather than repeatedly refreshing. The following commands use a normal GET request, follow redirects, print each response header and stop after ten hops.

Windows Command Prompt:

curl -sS -L --max-redirs 10 -D - -o NUL https://www.example.com/problem-url

macOS or Linux:

curl -sS -L --max-redirs 10 -D - -o /dev/null https://www.example.com/problem-url

Read the HTTP/ status lines and Location: headers in order. A repeated URL, or a repeated pair such as HTTP → HTTPS → HTTP, identifies the cycle. The curl manual explains the redirect-following and maximum-redirect options.

3. Do not treat a Search Console “Redirect error” as proof of a loop. Google’s current Page indexing report documentation says that label can also mean a chain was too long, a URL became too long, or a redirect target was bad or empty.
4. Identify which system issued each redirect. Check the content management system (CMS), application routes, web-server rules, content delivery network (CDN), reverse proxy, authentication logic and domain-forwarding settings. The URL sequence shows what happened; configuration and logs reveal who caused it.

What a Loop Breaks—and How Urgent It Is

A loop is first an availability fault. A visitor, browser, API client or crawler following the affected route cannot reach the intended resource. The practical impact depends on which URLs and users are affected.

• User journeys fail: a loop on a product, booking, checkout, login or password-reset route can stop a task completely.
• Crawling through that route fails: Google cannot fetch the intended final content through a redirect path that never resolves. Search Console may report the source URL as a redirect error.
• Migration and canonicalisation signals become unreliable: a redirect can only communicate a destination when it resolves to one. Avoid describing this as a guaranteed “ranking penalty” or a fixed percentage of lost authority.
• Operations become noisier: repeated requests can inflate logs, obscure the original rule and create unnecessary work at the browser, edge and origin layers.

If the destination is independently discoverable through another clean URL, a search engine may still find it by that other route. That does not make the looping URL acceptable; it means the SEO effect must be diagnosed rather than assumed.

Crawl budget is rarely the main reason a small site should fix a redirect loop. Google’s crawl-budget guidance is primarily for very large or rapidly changing sites. For most businesses, the immediate reasons are simpler: the URL is broken for users, the intended page cannot be reached through that path, and monitoring data becomes harder to trust.

ScanMySEO recommends this fix order:

1. Immediate: sitewide HTTP/HTTPS or www/non-www loops, and loops affecting checkout, login, lead generation or many public pages.
2. High: important landing, product, category or migrated URLs, especially where internal or external links still point to them.
3. Normal maintenance: isolated legacy URLs with no meaningful traffic or links, provided they do not reveal a wider rule conflict.

Common Causes: Match the Pattern to the Responsible Layer

Most loops are created by two individually reasonable rules that disagree. Diagnose the pattern before changing settings.

Ordinary DNS records do not send HTTP status codes or Location headers. A provider may offer “domain forwarding” alongside DNS, but that forwarding is an HTTP service. Inspect the forwarding, CDN or hosting rule rather than changing A, AAAA or CNAME records without evidence.

How to Fix a Redirect Loop Safely

1. Record the intended outcome and back up the current rules.

   Write down the preferred final URL, the expected terminal status and whether the move is permanent or temporary. Export plugin rules or copy the relevant server, CDN and application configuration before editing.

2. Define the scope.

   Test the exact affected URL plus relevant variants: HTTP and HTTPS, www and non-www, trailing slash and no slash, logged in and logged out. Avoid changing a sitewide rule because one browser session has stale state.

3. Capture the complete redirect sequence.

   Use curl, a browser network panel or a crawler that exposes status codes and Location headers. Save the before-state so you can prove what changed.

4. Map each hop to its owner.

   Compare the sequence with CDN rules, server rewrites, CMS/plugin redirects, application middleware and authentication logic. Server and edge logs are especially useful when the loop is conditional or intermittent.

5. Remove the cycle at the authoritative layer.

   Each outdated URL should point forward to the intended final destination, not to another URL that points back. Where practical, keep one source of truth for scheme, host and path canonicalisation.

   Use a permanent server-side redirect such as 301 or 308 for a permanent move, and a temporary redirect such as 302 or 307 for a genuinely temporary move. Google documents these distinctions in its redirect guidance. The status code communicates intent; it does not repair a circular destination.

6. Make the proxy, CDN and origin agree about HTTPS.

   When an application sits behind a reverse proxy, it must correctly understand the original scheme and host. Configure trusted forwarded headers according to your platform rather than blindly accepting client-supplied values.

   For Cloudflare, a common loop occurs when Flexible encryption sends HTTP to the origin while the origin redirects every HTTP request to HTTPS. Cloudflare’s current redirect-loop troubleshooting guide says to remove the conflicting origin redirect or use Full or higher with an origin certificate. Do not change TLS mode without confirming that the origin is correctly configured.

7. Purge only the caches that can retain the old behaviour.

   Clear the relevant application, server and CDN cache after deploying the rule. A private window or cleared browser cookies can help distinguish client state from server behaviour, but clearing a browser does not fix a live server-side loop for everyone else.

8. Update references to the final URL.

   Change internal links, navigation, canonicals and XML sitemap entries that still point to unnecessary redirecting URLs. This reduces extra hops and prevents old routes from remaining the main way users and crawlers reach the page.

9. Deploy, retest and monitor.

   Repeat the same request sequence used before the change. Then crawl the affected section and watch error logs after deployment for a recurrence or a new loop created by the replacement rule.

Who Should Fix What—and What Not to Do

Assign the fix to the layer that owns the redirect rather than passing the URL between teams without evidence.

• Content or CMS owner: check permalink/domain settings, redirect plugins, internal links and sitemap URLs.
• Developer: inspect routing, middleware, authentication, locale handling and the application’s use of forwarded scheme/host headers.
• Hosting or DevOps owner: inspect Apache/Nginx rules, reverse proxies, TLS termination, CDN redirects and server-side caches.
• SEO owner: define the preferred destination, identify affected URL groups, preserve the before/after evidence and verify Google-facing results.

Avoid these common “fixes”:

• Do not add another redirect to counter an existing redirect without first tracing the full path.
• Do not switch 301 to 302 and assume the loop is solved; the circular target remains circular.
• Do not declare success because clearing your own cookies made the page load. Test a fresh client and the actual response sequence.
• Do not use robots.txt to hide the symptom. Users will still be unable to reach the page, and the underlying routing fault remains.
• Do not disable production plugins or sitewide rules without a backup, rollback path and awareness of other URLs they control.

Worked Example: An HTTPS Loop Behind a CDN

This hypothetical example shows why changing one visible rule without understanding the connection between systems can make the problem worse.

Before the fix

Visitor requests:  https://www.example.com/products/widget
CDN contacts origin over:  http://www.example.com/products/widget
Origin responds:  301 Location: https://www.example.com/products/widget
CDN contacts origin over HTTP again
The same response repeats

The browser shows an error even though both settings appear sensible in isolation: the visitor-facing connection is HTTPS, and the origin has a rule that upgrades HTTP to HTTPS. The conflict is that the CDN keeps presenting HTTP to the origin.

Possible correction

After confirming an origin certificate and the intended architecture, the site owner configures encrypted CDN-to-origin traffic and keeps one clear HTTP-to-HTTPS policy. In another setup, the correct answer might be to remove the origin redirect and let the edge own it. The correct choice depends on where TLS terminates and which layer is authoritative.

Observable result

http://www.example.com/products/widget
  → 301 https://www.example.com/products/widget
  → 200 OK

The useful proof is not a claimed ranking increase. It is that the repeated Location value has disappeared, the page loads for affected users, and automated tests reach the intended terminal response.

Verify the Fix Before Calling It Done

Use the same test inputs before and after the change. A redirect fix is complete only when the affected variants behave intentionally.

• The exact problem URL reaches the expected final response without revisiting an earlier URL.
• HTTP/HTTPS, www/non-www and slash variants converge consistently where those variants are supported.
• Both ordinary and private sessions work; logged-in and logged-out behaviour is correct where relevant.
• The page and its important resources load, not just the initial HTML request.
• A crawler finds no remaining loop across the affected URL group.
• Internal links and sitemap entries point to the preferred final URLs rather than relying on redirects.
• Monitoring shows no recurring spike in redirect or application errors after deployment.

For an important public URL, use Search Console’s live URL Inspection test after the technical checks pass. The indexed result reflects Google’s most recently indexed version, not necessarily the page as it exists now. Request indexing for an important corrected URL when appropriate; resubmitting a sitemap is not a mandatory step for every isolated loop.

Redirect Loop Prevention Checklist

• Choose one preferred scheme, host and path format.
• Give one system clear ownership of each canonicalisation rule where practical.
• Redirect retired URLs directly to the current destination.
• Export and review existing rules before a migration, HTTPS change, CDN change or CMS plugin rollout.
• Test redirects in staging and again through the production CDN or reverse proxy.
• Add automated checks for repeated URLs and unexpectedly high redirect counts on critical routes.
• Keep internal links, canonicals and XML sitemaps aligned with final URLs.
• Re-crawl affected sections after releases that change routing, domains, authentication or localisation.

A browser error tells you that redirection did not resolve; it does not tell you which rule is responsible. Trace the hops, identify the owner, remove the circular instruction, and verify the final response from more than one client.