Home >Blog

What Is a Redirect Loop and How Do You Fix It?

Published 2026/09/03Updated 2026/09/03

What Is a Redirect Loop?

A redirect loop occurs when redirects return to a URL that has already appeared in the same path. The simplest pattern is A -> B -> A: a visitor requests URL A, is redirected to URL B, and URL B redirects back to A. Because the browser or crawler never reaches a final destination, the page cannot load normally.

Redirect Chain Checker is useful for confirming this behavior on public HTTP or HTTPS URLs. It follows each response one hop at a time and records the source URL, destination URL, HTTP status code, and response time. Its results also identify loops, broken targets, cross-domain changes, HTTPS downgrades, the hop count, and the final URL when one is reachable.

How to Check for a Redirect Loop

1. Enter the affected address

Open Redirect Chain Checker, paste the URL into the URL to check field, and select Check Redirects. The checker accepts public HTTP and HTTPS pages; you can enter a URL with or without https://.

2. Review every hop

Read the results in order. Compare each destination with earlier URLs in the chain. If a URL repeats, such as http://example.com -> https://www.example.com -> http://example.com, the path is looping instead of ending at a final URL.

3. Compare the first conflicting rules

Use the source and destination shown for the repeated hop to find the two rules that disagree. The checker shows the public effect of those rules, so it helps you distinguish a loop from a long but finite redirect chain or a broken destination.

Common Causes and Fixes

HTTP and HTTPS rules

A common loop happens when one rule forces HTTPS while another rule, proxy, or application setting sends the request back to HTTP. Choose HTTPS as the single canonical protocol, then remove or update the rule that reverses it. Recheck both the HTTP and HTTPS versions after publishing the change.

www and non-www rules

Another pattern is a rule that sends www to the non-www hostname while a second rule sends the non-www hostname back to www. Select one preferred hostname, point the opposite version to it, and make sure every redirect layer uses the same choice.

CDN or reverse-proxy settings

A CDN or proxy may see a different protocol or hostname than the origin server. For example, the edge can redirect to HTTPS while the origin believes the request is HTTP and redirects again. Compare the public hop sequence with the protocol and host settings at the CDN and origin, then keep only one consistent redirect decision.

Cached redirect responses

After a redirect rule changes, a browser, CDN, or intermediary cache can continue returning an older response. Test the affected URL again with Redirect Chain Checker to see the currently public chain. If the old hop remains, review the relevant cache behavior before changing unrelated rules.

CMS and server rule conflicts

A CMS may create a canonical URL redirect while server-level rules or a proxy redirect the same request differently. Review redirects in the order they are applied and keep one owner for each normalization decision: protocol, hostname, trailing slash, and URL path. Remove the rule that sends the request back to an earlier form.

Example: Diagnosing A -> B -> A

Suppose the checker reports http://www.example.com/page -> https://example.com/page -> http://www.example.com/page. The first hop changes both protocol and hostname. The second hop reverses both choices, which creates the loop.

To fix it, decide on one canonical version, such as https://example.com/page. Configure every layer to redirect the other variants directly to that version, then run the checker again. A successful result ends with the intended final URL rather than returning to a previous hop.

Verification Checklist

Check the HTTP and HTTPS versions, then check both www and non-www hostnames if both are reachable. Confirm that the report has a final destination, contains no repeated URL, and does not show an unexpected HTTPS downgrade. For a page that previously looped, rerun the check after each relevant rule or cache change so the public redirect path remains clear.

Frequently Asked Questions

How is a redirect loop different from a redirect chain?

A redirect chain eventually reaches a final destination. A redirect loop repeats an earlier URL, so it has no usable final destination.

Can Redirect Chain Checker find a redirect loop?

Yes. The checker follows public HTTP or HTTPS responses hop by hop and identifies loops in the returned path.

Should I test HTTP, HTTPS, www, and non-www versions separately?

Yes. These variants can be handled by different rules, and testing each one helps reveal conflicting protocol or hostname redirects.

Why might a loop remain after I change a redirect rule?

A CDN, browser, or intermediary cache may still return an earlier response, or another layer such as a CMS, proxy, or server rule may still reverse the redirect.

FAQ

What is a redirect loop?

A redirect loop repeats an earlier URL in the same path, such as A to B to A, so no usable final destination is reached.

Can Redirect Chain Checker find a redirect loop?

Yes. It follows public HTTP and HTTPS responses one hop at a time and identifies loops in the returned path.

Should I check HTTP, HTTPS, www, and non-www versions separately?

Yes. Different protocol and hostname rules can conflict, so each reachable variant should be checked.

Why can a redirect loop continue after a rule change?

A CDN, browser, or intermediary cache may still return an older response, or another CMS, proxy, or server rule may still reverse the redirect.

What Is a Redirect Loop and How Do You Fix It?