Redirect Error in Search Console: Google Gave Up Before the Last Hop

Search Console has two statuses with "redirect" in the name, and they mean opposite things. "Page with redirect" means Google followed your redirect and indexed the destination. That's working as intended. "Redirect error" means Google started following the chain and gave up before it reached a page.

Only the second one is a problem, and it's usually easy to trace once you know what Google counts as a failure.

What Google says it means

The Page indexing report help lists four causes, and nothing else:

Google experienced one of the following redirect errors:

• 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 [1]

Every redirect error you'll see is one of those four. A 404 at the end of a chain isn't on the list, and neither is a redirect to a page Google doesn't want to index. Those get their own statuses. A redirect error means Google never reached a final page at all.

How long is too long

Google's crawler documentation gives the number: its crawlers follow "up to 10 redirect hops", and Googlebot "generally follows 10 redirect hops when crawling for general web content" [2].

Ten sounds generous, and a single well-planned redirect never comes close. Chains build up over the years instead. An HTTP-to-HTTPS rule goes in first. Later someone adds a bare-domain-to-www rule, then a trailing-slash rule, then a redirect from an old URL structure, then another migration on top of that. Each rule was reasonable when it was added. Together they turn one old URL into six hops, and if two rules disagree, the chain never ends.

Our own bare domain takes two hops: http://enfect.com/ goes to https://enfect.com/, which goes to https://www.enfect.com/. That's well within the limit, but it's one hop more than it needs to be. Google's redirect guide says a permanent redirect tells Google the target "should be canonical" [3]. That signal is clearest when every legacy URL points straight at its final destination, and a chain that's never allowed to grow can't grow past ten.

Why your manual test looks fine

This is the most common source of confusion in these threads. A site owner tests the URL, sees a clean 301 and a 200 at the end, and can't see what Google is complaining about.

One r/TechSEO post from August 2026 is exactly that case. A high-authority site linked to example.com/de, which 301s to example.com/de/ under a site-wide trailing-slash rule, and /de/ returns 200 directly. The owner confirmed Googlebot received the 301 and wasn't blocked by the CDN, but Search Console still reported a redirect error [4].

There are three likely explanations, and they're worth checking in this order.

The report is older than your fix. Page indexing statuses reflect Google's last crawl of that URL. If the chain was broken on that date and fixed afterwards, the error stays until Google comes back. URL Inspection shows the last crawl date, so compare it with when you changed anything.

Google's live test doesn't follow redirects. Google's crawler documentation says that "Google Inspection Tools doesn't follow redirects" [2]. A live test on a redirecting URL tells you the first hop works. It doesn't tell you what Googlebot hit at hop three.

Googlebot sees a different chain. Redirects based on language, country, cookies or device can send Googlebot somewhere your browser never goes. Googlebot mostly crawls from the US, without your cookies or your Accept-Language header. A /de path is the classic setup for a language redirect. If a geo rule sends a US visitor from /de/ to /en/ and another rule sends /en/ back, you get a loop that only Googlebot sees. We haven't confirmed that's what happened in that thread, but it's the first thing we'd test.

So test the way Googlebot fetches: no cookies, no language preference, and a Googlebot user agent. Follow every hop yourself, because the live test won't.

The redirect loop we shipped

On 23 September 2026 we added a redirect from our bare domain to www. It was one rule in next.config.mjs, matched on the host enfect.com.

Our hosting adapter treats that host value as an unanchored pattern, so enfect.com also matched www.enfect.com. It also didn't fill in the destination. Every page on www, including the home page, redirected to the literal path /:path*. That path is on www too, so it matched the same rule and redirected to itself.

That single rule produced two of Google's four causes at once: a bad URL in the chain and a redirect loop. We caught it within minutes because the home page stopped loading, and rolled the deploy back. The bare-domain redirect now lives in the Worker entry that runs before the app, where the host check is an exact comparison.

Two lessons came out of it. Redirect rules are code and should be tested on the production host, not only in a local dev server that matches rules differently. And after any change to redirects, check the chain from outside: request the old URL, count the hops, and confirm the last response is a 200.

A spike after a change is almost always the change

In an r/SEO thread from April 2026, a healthcare site reported a sudden spike in redirect errors, with pages moving to "Crawled – currently not indexed", starting around 18 March. The top reply ignored content and authority and asked one question: what changed on or around that date, on the site or at the host [5]? The owner said they had changed the schema, not the page content.

Schema edits don't usually cause redirect errors. Plugin updates, CDN settings, SSL mode changes and host migrations often do, and a site owner may not know the host changed anything. When redirect errors jump on a particular date, start with the deploy log and the host's changelog.

Common causes, sorted by Google's four categories

Too long. Stacked protocol, hostname, trailing-slash and legacy-path rules. Fix it by pointing each old URL straight at its final destination.

Loop. The server forces HTTPS while the CDN talks to it over HTTP. Trailing-slash rules in the app and the server disagree. The app and the host each think a different hostname is canonical. The browser version of this is ERR_TOO_MANY_REDIRECTS, and our guide to it covers the usual suspects.

URL too long. A redirect that appends a parameter on every hop, often a login or tracking wrapper that re-encodes ?redirect_to= into itself until the URL passes the length limit.

Bad or empty URL. A Location header with an unfilled placeholder like our /:path*, a malformed absolute URL, or an empty header.

How to fix it

1. Open URL Inspection for an affected URL and note the last crawl date. If you've changed redirects since, the error may already be gone.
2. Trace the chain with a Googlebot user agent and no cookies. Record every status code and Location header.
3. Check which of the four causes you're looking at: more than a handful of hops, a URL that repeats, a URL that grows each hop, or a malformed Location.
4. Collapse the chain so the first URL redirects straight to the final one, with a 301 or 308.
5. Update internal links and the sitemap to point at the final URLs. Neither should list a URL that redirects.
6. Click Validate fix in Search Console. Google says validation typically takes up to about two weeks [1].

For step 2, our redirect checker follows a URL hop by hop and shows the status code of each response. It stops at 10 hops, the same limit Googlebot uses, and flags loops, so a chain that fails there would most likely fail for Google as well.

Sources

1. Google Search Console Help, Page indexing report.
2. Google for Developers, How HTTP status codes affect Google's crawlers.
3. Google Search Central, Redirects and Google Search.
4. r/TechSEO, Googlebot got a clean 301 (verified, not blocked by CDN) but never followed it — "Redirect error" in GSC even though everything tests fine manually, 16 August 2026.
5. r/SEO, Sudden deindexing + redirect errors after March 18 – need help diagnosing, 1 April 2026.

The redirect chains for enfect.com were traced on 24 September 2026. The 23 September incident is described from this site's own deploy history.