stillindexedStart monitoringOpen the app

Search Console Page indexing: Why pages aren't indexed

Redirect error in Search Console: loops and long chains

Google hit a redirect loop, a chain too long to follow, an overlong URL or an empty URL. How to find the broken hop and collapse the chain.

Google followed a redirect from this URL and never reached a final page: a loop, a chain too long to follow, a target that grew past the maximum URL length, or a bad or empty URL in the chain. Trace every hop, point the first URL straight at the final 200 page, then validate the fix.

What "Redirect error" means

Google lists four cases: "A redirect chain that was too long", "A redirect loop", "A redirect URL that eventually exceeded the max URL length" and "A bad or empty URL in the redirect chain". Googlebot generally follows up to 10 redirect hops when crawling for web content. Past that, or round a loop, it never gets a page to index.

Is it a problem?

Usually a problem

Yes, if the URL or its target should be in Search: nothing at the end of a broken chain gets indexed. If the URL is retired and nothing replaces it, a 404 or 410 says so more clearly than a redirect that goes nowhere.

Causes, most likely first

  1. Two layers redirecting against each other: the CDN forcing HTTPS while the origin forces HTTP, or one adding www while the other strips it. Each hop undoes the previous one.
  2. Trailing slash rules in the server and the framework disagreeing, so /page and /page/ redirect to each other.
  3. Chains built up over several migrations, where an old rule points at a URL that a newer rule redirects again.
  4. A redirect that appends to the URL on every hop (a query parameter, a language prefix, a return path) until it passes the maximum length.
  5. A rule that produces an empty or malformed Location header, for example a template variable that resolves to nothing.

How to confirm it

  1. Run the redirect chain checker on the exact URL from the report. It lists every response with its status, hostname and scheme, so a loop shows as URLs repeating and a long chain as a long list.
  2. Repeat with the http, https, www and non-www variants. Loops between two layers often appear from one starting variant only.
  3. In browser DevTools, open the Network tab with Preserve log on and load the URL to see each 3xx response and its Location header.
  4. After the fix, run a live test in URL Inspection on the final URL to confirm Google can fetch it.

Redirect chain checker

How to fix it

  1. Decide the one final URL this address should end on, and make sure that URL returns 200.
  2. Point the original URL straight at it with a single 301 or 308, and update older rules so they skip the intermediate hops.
  3. If two layers disagree, choose one to own host and scheme redirects and remove the rule from the other.
  4. Update internal links, canonical tags and sitemap entries to the final URL, so Google stops starting from the old one.
  5. Re-run the redirect chain checker until the chain ends in 200 after one hop, then click Validate fix.

How long recovery takes

Google has to recrawl the original URL to see the repaired chain, which can take "anywhere from a few days to a few weeks". A 301 or 308 is a strong signal that the target should be canonical, so the target is what gets indexed, not the redirecting URL.

After a fix, Validate fix on the issue asks Google to recheck the affected URLs. Google says validation "typically takes up to about two weeks, but in some cases can take much longer". Without it, the count still updates as Google recrawls, and an issue leaves the table once 90 days pass with no instance.

Would monitoring have caught it?

A change to the redirect chain of a monitored URL is a warning, and a redirect that starts landing on a different domain is critical. A loop, or a chain past ten hops, makes our check fail rather than finish, and three failed checks in a row raise a critical "unreachable" change carrying the fetch error.

stillindexed checks each monitored URL every 30 minutes on Starter and every 15 minutes on Agency, so the change is found on the next check and confirmed before it alerts, rather than waiting for this report to update.

See what monitoring covers

A broken or chained redirect, platform by platform

Further reading

Sources

Every claim above about how Google behaves is from Google's own documentation, read on 2026-10-06. If Google has changed a page since, Google's page wins and we would like to know.