Redirect error is the Page indexing status people confuse with its harmless neighbour. Page with redirect means Google followed your redirect and indexed the destination, which is usually exactly what you wanted. Redirect error means Google tried to follow it and gave up before reaching any content at all. Nothing got indexed, because Google never arrived anywhere.
Google’s help entry lists precisely four ways this happens, and in the audits I do, the first one accounts for most of the cases.
The four causes Google names
The help documentation for the Page indexing report says Google experienced one of the following:
- A redirect chain that was too long
- A redirect loop
- A redirect URL that eventually exceeded the max URL length
- A bad or empty URL in the redirect chain
“Too long” has a number behind it. Google’s crawling infrastructure documentation states that its crawlers follow up to 10 redirect hops by default. Past hop ten, the crawl stops and the URL fails. Ten sounds like a lot until you watch chains assemble themselves out of individually reasonable rules.
How a site builds a long chain without noticing
Nobody writes a 10-hop redirect on purpose. Sites accumulate them, one migration at a time, because each redirect rule is added without checking what the destination already does. The pattern I keep finding on client sites stacks like this:
Every internal link that still uses the old http, non-www or unslashed form pays the whole chain on every crawl. Layer a second migration on top and hop counts double, because the old rules never get removed, only added to. That is how a real site reaches ten. I wrote about the slash half of this in trailing slash SEO: the redirect is fine, the inconsistency that triggers it constantly is the cost.
Loops are the same story with worse luck: the HTTPS rule redirects to www, and a stale www rule redirects back to non-www HTTP. Each rule was correct in the year it was written.
The gotcha in URL Inspection
Here is the detail that makes this status annoying to debug inside Search Console itself: Google’s documentation notes that the Inspection Tools do not follow redirects. So the live test on a redirecting URL tells you there is a redirect, and nothing about where the chain goes or where it breaks. The report told you Google gave up; the inspection tool cannot show you the journey.
Google’s own suggestion in the help entry is to use a web debugging tool such as Lighthouse. My faster version, for one URL, is to fetch it from a terminal and read the Location headers hop by hop:
curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/pageRun with -I alone on each hop if you want to see every Location header in the chain rather than just the final landing. For a whole sitemap of URLs, checking hop by hop stops scaling, which is why my sitemap health check fetches every URL a sitemap lists and flags the ones that redirect at all. A sitemap should contain final URLs only; any redirect in it is a chain you are paying for on purpose.
Fixing it, in order
- Map the chain first. You cannot collapse what you have not seen. Trace the failing example URLs from the report with curl or Lighthouse and write down every hop.
- Collapse to one hop at the server. The origin URL should answer with a single 301 straight to the final destination. Which permanent code you use matters less than people think; I covered the 301 versus 308 distinction in 301 vs 308 redirects, and both carry the same canonical signal.
- Delete stale rules, do not just outrank them. Old migration rules left in place are how the next chain starts. Every rule that no longer receives traffic it needs is a liability.
- Fix the internal links. The chain only runs when something points at its start. Update internal links, sitemap entries and canonicals to the final URL and most of the chain traffic disappears regardless of the rules.
- Re-inspect and request indexing on the fixed URLs, then let validation run. The status clears on recrawl, not on deploy.
When to worry
A handful of URLs in Redirect error after a migration is normal debris and clears once the rules are collapsed. Two situations deserve real attention. First, when the count grows without a migration to explain it, because something is generating bad redirect targets dynamically, and cause four on Google’s list, a bad or empty URL in the chain, is almost always a template bug rather than a config file. Second, when the affected URLs still carry traffic or backlinks, because a URL stuck in Redirect error passes nothing to anywhere; the equity a working redirect would move is parked until the chain resolves. The rest of the statuses in this family are catalogued in every Search Console indexing status, and Redirect error is one of the few marked worth acting on every time it appears.
Of the four causes, a redirect loop is the one that most often comes from a CMS rather than from a deliberate redirect, and on WordPress it is usually two settings disagreeing about www or https. Fixing a WordPress redirect loop walks the places that rule can be hiding.
Sources
- Google Search Console Help, Page indexing report, the Redirect error status and its four listed causes, checked 2 September 2026
- Google crawling infrastructure documentation, how HTTP status codes affect Google’s crawlers, for the 10-hop default and the note that Inspection Tools do not follow redirects, checked 2 September 2026
- Google Search Central, redirects and Google Search, for permanent versus temporary handling and server-side redirects as the most reliably interpreted type