Redirect chain contains a loop

In the recorded redirect chain we look for the same URL appearing twice. When one does, that is evidence of a cycle in the site's redirect graph, and the finding is raised, with the hop count.

Here is something easy to miss and key to understanding the finding: a genuinely infinite loop will never show up here. When redirects spin forever, the crawler aborts at a hard limit and the page never reaches analysis at all. That case is invisible to the audit, not silently ignored.

So what SEO-35 catches is: a chain that returned to an already-visited URL on the way and then did reach its destination (A → B → A → target). This particular visit succeeded, but the cycle is in the graph, and with a different entry point it may end differently.

What the check further does not do: it will not name the rule producing the loop, it cannot separate a server-level loop from an application-level one, and it cannot see redirects performed by JavaScript.

When the check has no chain recorded (the audit ran over stored HTML), it stays quiet rather than reporting zero. The finding is page-level; severity is warning.

For visibility in AI answers we have no documented effect, and we will admit straight away that on this particular page the problem may not occur at all: we did reach the content, just by a detour.

So why report it. A redirect cycle is a configuration defect that behaves unreliably: it surfaces depending on which URL a visitor arrives from, whether there is a trailing slash, whether they go via www. Today the crawler got through; tomorrow it may arrive from another side and hit an error.

And that does connect to what the product measures: a page a crawler cannot reach does not get indexed, and being in the index is a necessary condition for appearing in Google's AI features. But we cannot claim it will happen, because this time it did not. Hence a warning rather than a critical finding, and hence the “not demonstrated” class.

The practical conclusion: treat it as a warning about a fragile spot in your configuration, not as a confirmed fault. It is usually one surplus condition in a rule set, not a systemic problem.

First print the whole chain; without it you are searching blind:

curl -sIL https://your-domain/problem-url | grep -iE '^HTTP/|^location'

The listing shows which URL repeats. The cause is usually one of these three, and they all arise from layering rules that do not know about each other:

1. Two rules that contradict each other. One adds a trailing slash, the other removes it. Each makes sense on its own.
2. Redirects at both the application and the server level. The framework redirects to its canonical form and nginx to a different one.
3. A condition evaluated after the redirect. The www → non-www rule runs again on the already-redirected URL.

• Write down every redirect rule in one place: server configuration, application, CDN and CMS. Loops nearly always come from two layers being unaware of each other.
• Pick one canonical URL form (with or without www, with or without a trailing slash) and redirect to it with one rule, not a chain.
• After editing, test every entry variant: http/https, with/without www, with/without a trailing slash. That is eight combinations and one failing is enough.