301 Redirect loop (a 301 or 302 cycle)

Two or more redirects that point back at each other. The crawler follows the first, gets sent to the second, and is sent back to where it started.

There is no HTTP status code for this. The loop is a property of the sequence, not of any one response, so nothing in a single log line shows it. A crawler follows about five hops and stops. Browsers stop near twenty and show ERR_TOO_MANY_REDIRECTS.

The result for the URL is the same as an error. It never resolves, so it is never indexed, and if it was indexed it drops out.

What causes it

Two rules that each look correct alone. This is nearly always the shape of it.

A trailing slash rule that adds a slash meeting a framework rule that removes one. An http to https rule at the application layer behind a load balancer that terminates TLS, so the application never sees https and redirects forever. A www canonicalization rule at the CDN and a bare-host rule in the application, pointing opposite ways. A locale redirect that sends / to /en/ while a default-locale rule sends /en/ back to /.

Then there are the single-rule cases: a case-normalizing rule on a path that is already lowercase, an authentication redirect that sends an unauthenticated user to a login page which itself requires authentication, and a canonical URL pointing at a URL that redirects back to the original.

How to diagnose it

Follow the chain and print every hop:

curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/page

Better, print each step so you can see where it turns around:

curl -sI https://example.com/page | grep -i -E "^(HTTP|location)"

Repeat on each Location value until you see a URL you have already visited. That URL is where the second rule lives.

Test the shapes separately: with and without the trailing slash, with and without www, http and https, uppercase and lowercase. A loop that appears in only one combination tells you which pair of rules is fighting.

Check the layers too. A loop usually spans a CDN rule and an application rule, and reading either configuration alone shows nothing wrong. Compare the request as it arrives at the origin with the request as it left the client, and look at what the proxy headers say about the original scheme.

How to fix it

Decide the canonical form once: scheme, host, trailing slash, case. Write it down. Then implement it in exactly one place, and make every other layer pass through rather than correct.

One rule per decision is the whole discipline. Most loops exist because two teams each fixed the same problem in their own layer, and neither fix was wrong.

Point redirects directly at the final destination. Chains cost a fetch per hop against your crawl budget, and every added hop is another chance for a future rule to close the circle.

After fixing, check that the destination actually returns 200 and not a 404 or a soft 404. Redirect targets rot quietly, and a chain that ends in a missing page is only slightly better than one that ends in a loop.