How to Check If Your Website's Redirects Are Sending Visitors in Circles

A visitor tells you your site will not load. You open it yourself and it works fine. Then a second visitor reports the same thing, this time with a browser error about too many redirects. The page is there and the server is up, yet the browser gives up. The cause is almost always redirects, and the fix starts with seeing the full path a request takes.

Chains and loops are not the same problem

A redirect chain is a sequence of redirects that fire one after another before a request reaches the final page. A visitor types your old address, the server sends them to the www version, that sends them to the https version, then to the new page: three hops before anything loads. A chain still works, it is just slow, and crawlers may give up before the end.

A redirect loop is worse. Two or more rules send traffic back and forth forever: A redirects to B, and B redirects back to A. Nothing ever loads. The browser goes round until it hits its limit and shows ERR_TOO_MANY_REDIRECTS in Chrome, or "The page is not redirecting properly" in Firefox. A chain needs shortening. A loop needs two rules that disagree to be made to agree.

The symptoms that point at redirects

Redirect trouble hides well, because it only shows up for some visitors and some URLs. A page loads for you but shows a too-many-redirects error for someone else, often because your browser cached an older, working redirect. A page works typed one way and fails typed another, for example with www and without, or http and https. A page drops out of the index after a crawler meets a loop and abandons the URL. If any of that sounds familiar, do not guess at the cause. Check the path.

See the whole path in one check

The fastest check is our HTTP Headers Checker. Paste the URL as the visitor typed it, http or https, www or not, because those details decide which rules fire. It asks the URL the way a browser would, then follows every Location header back, one hop at a time. For each hop you see its status code, destination, and time taken. A chain shows up as several 301 or 302 rows in a row. A loop shows the same URL twice.

Two other methods work too. On the command line, curl -IL https://example.com/your-page prints one header block per hop. The -I flag fetches headers only, and -L follows every redirect to the end. In the browser, open DevTools, go to the Network tab, tick Preserve log, and load the URL. A loop shows the same URLs repeating until the browser gives up. Use DevTools when the redirect only fires for a logged-in visitor, because it reproduces the exact conditions.

How to read what the checker shows

Start with the status codes. A 301 means moved permanently: the old URL is retired, and search engines should pass its standing to the new one. A 302 means temporary, and the old URL stays indexed. The common mistake is a 302 where a 301 belongs, for example after a site move or an http to https switch.

Then count the hops. Google advises no more than three hops, always under five. Googlebot follows up to ten before giving up, and browsers up to twenty. Those are ceilings, not targets. A healthy move is one hop: the old URL points straight at the final page, followed by a 200. Anything more is a chain you can usually collapse into a single rule at the server or CDN. Our Website Speed Test shows the same delay as extra time before the page starts loading.

The three loops that cause most of the trouble

Most loops come from two rules that contradict each other. The first is the www fight: one rule adds www to every address, and another removes it. example.com is sent to www.example.com, which sends it straight back, forever.

The second is the http and https fight behind a CDN or load balancer. The CDN talks to your server over http, your server redirects to https, and the CDN asks again over http. The server never sees the visitor's https request, so it redirects again.

The third is the login loop. A page sends visitors to a login page, and the login page sends them back to the page they came from, which sends them to login again. It often appears after a change to authentication or a membership plugin, and it is easy to miss because the site owner is already logged in.

In each case the fix is the same: find the two rules that disagree and make them agree on one final URL, then point every rule at that one version directly.

How to fix a chain or a loop

List every redirect rule that touches the URL: server configuration, content management system, CDN, and any redirect plugin. Most loops live in the gap between two layers, where a rule in one was written without knowing about a rule in the other.

For a chain, rewrite the rules so the starting URL points straight at the final destination. If a page moved twice, point the old redirect at the current address, not the intermediate one. One rule, one hop, one 301.

For a loop, decide the canonical URL first, then change the rule that disagrees. If your site is https with www, the rule that strips www has to go, or be flipped to add it. If a CDN sits in front of your server, the server must be told to trust the CDN's signal that the visitor arrived over https. After the fix, test in a private browser window, because browsers cache permanent redirects and an ordinary window may keep showing the old loop.

Then check the fix the same way you found the problem, plus the four versions of your homepage: http and https, with and without www. Each should reach the same final URL in one hop.

What to do first

Take the reported URL, paste it into the HTTP Headers Checker, and read the hop list. One hop to a 200 is healthy. More than three hops is a chain to collapse. The same URL twice is a loop, and the two rules that send traffic back and forth are the ones to reconcile. Redirects are invisible until they break, and a two minute check is the difference between quietly losing visitors and sending every request straight to the right page.