Redirect error in Search Console: loops, long chains and bad URLs
Redirect error means Googlebot hit a loop, a chain that was too long, an overlong URL or a bad URL. Trace every hop with curl, then redirect in one step.
LLaunchScaler·Published ·8 min read
Redirect error in Search Console means Googlebot followed a URL's redirects and never reached a page it could crawl. Google names four causes: a redirect loop, a chain that is too long, a redirect URL that grew past the maximum URL length, and a bad or empty URL somewhere in the chain.
All four show up in one command. curl -sIL prints every hop and its status, which tells you which of the four you have and which rule produced it.
What does "Redirect error" mean in Search Console?
It means the redirect itself failed, not the page behind it. Search Console's help says 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." The URL is not indexed, because Google never got to a final page.
That separates it from Page with redirect, where a redirect worked and Google indexed the target instead. Here nothing was reached. The Crawl Stats report counts the same failures under its Redirect error response type, described as "too many redirects, empty redirect, or circular redirect," and it counts every hop in a chain as a separate request.
Cause Google names
What it looks like in curl
Typical source
Redirect loop
The same URLs repeat until the hop limit
Two layers with opposite rules
Chain that was too long
Many distinct hops before any 200
Questions, answered
What people ask about this
01
What does redirect error mean in Google Search Console?
Googlebot followed the URL's redirects and could not reach a final page. Google names four causes: a redirect chain that was too long, a redirect loop, a redirect URL that exceeded the maximum URL length, and a bad or empty URL in the chain.
Request the URL with curl, following redirects and printing only headers. Each hop prints its status line and Location, so you read the chain top to bottom. Capping the redirects at 10 mirrors Googlebot, which "follow[s] up to 10 redirect hops" by default, so a chain curl refuses to finish is one Google refuses too.
-I fetches headers only, -L follows each redirect, -s hides the progress meter and -S still prints errors. A healthy result is one redirect then a 200:
HTTP/1.1 301 Moved Permanently
location: https://example.com/new-page
HTTP/2 200
If curl stops with Maximum (10) redirects followed, you have a loop or a chain past Google's limit. Test each variant people and crawlers actually request, because the rules often differ: http:// and https://, with and without www, with and without a trailing slash, and with a query string.
Search Console's help also suggests "a web debugging tool such as Lighthouse to get more details about the redirect." In URL Inspection, the live test follows redirects without saying so, so curl is the clearer view of the chain itself.
Why do redirect loops happen?
Because two rules disagree, usually at two different layers. One layer sends the request to version A, the other sends it back to version B, and neither knows about the other. The loop only appears when both run, which is why each rule looks correct when you read it on its own.
Patterns that commonly cause loops:
A CDN talking to the origin over HTTP while the origin forces HTTPS. Cloudflare documents this exact loop: with the Flexible encryption mode, "Cloudflare sends unencrypted requests to your origin server over HTTP," and "redirect loops will occur if your origin server automatically redirects all HTTP requests to HTTPS."
The reverse: Full mode at the CDN with an origin that redirects HTTPS to HTTP.
A host rule adding www at the CDN while the app strips it.
A framework adding a trailing slash while a server rule removes it.
A locale or login redirect that sends a request to a page which redirects back when a cookie or header is missing that Googlebot does not carry over.
Google's rendering service "does not retain state across page loads," and its documentation says "HTTP Cookies are cleared across page loads," so a loop that depends on a missing cookie can hit Googlebot and first-time visitors while you, signed in, never see it. Test with curl, which sends no cookies by default.
To fix a loop, pick the layer that owns each decision and delete the opposing rule from the other. For the Cloudflare case, its docs give two options: "either remove HTTPS redirects from your origin server or update your SSL/TLS Encryption Mode to be Full or higher." The HTTP to HTTPS redirect guide covers setting that one up correctly.
How long can a redirect chain be?
Up to 10 hops for Googlebot, but aim for one. Google's documentation says its crawlers "follow up to 10 redirect hops" by default, and that "specific products' crawlers may have different limits." Its troubleshooting guide also says to "watch out for long redirect chains, which have a negative effect on crawling," because each hop is another request.
Chains grow as rules are added over the years. A URL that went through a protocol change, a host change, a slug change and a trailing-slash change can easily need four hops:
Collapse it by redirecting every old form straight to the final URL in one 301 or 308:
List the final URL for each page.
Rewrite the redirect map so each old URL points at a final URL, never at another redirecting URL.
Run the protocol and host normalisation at the first layer that sees the request, and have it build the final URL in the same step.
Update internal links, canonicals and sitemaps to the final URL so they need no redirect at all.
Google treats 301 and 308 as strong signals that the target should be canonical, and 302, 303 and 307 as weaker, temporary ones. The redirect chains and loops guide goes further into mapping and collapsing chains.
What makes a redirect URL too long or bad?
A rule that feeds its own output back into itself, or one built from a value that is sometimes empty. Google does not publish its maximum URL length. The HTTP specification, RFC 9110, recommends that software support URIs of "at a minimum, URIs with lengths of 8000 octets," so a URL near that size is always a bug, never a real page.
Signs of a growing URL in the curl output:
A path segment repeating: /en/en/en/en/pricing.
A query parameter doubling: ?next=%2F%3Fnext%3D%252F....
A return-to parameter that captures the whole current URL, including the previous return-to parameter.
Signs of a bad or empty URL:
A Location: header with no value.
A Location missing its scheme or colon, such as https//example.com/page.
A redirect to a variable that was empty for this request, producing https://example.com/undefined or just https://.
Spaces or unencoded characters in the target.
Fix the rule rather than the URL. Guard redirects so they only fire when the request is not already in the target form, strip existing return-to parameters before adding one, and refuse to redirect when the destination value is empty.
Do redirects on robots.txt and sitemaps matter too?
Yes, and they fail differently from page redirects. For robots.txt, Google's specification says it "follows at least five redirect hops" and then "stops and treats it as a 404," which means no crawl restrictions at all; it also ignores "logical redirects" such as meta refresh or JavaScript in that file. A robots.txt caught in the same loop as your pages quietly stops applying.
Sitemaps should not redirect either. Google's sitemap guidance asks for the URLs you want in search, and a sitemap URL that moves with your host or protocol change is one more thing to update. Serve robots.txt and sitemap.xml with a direct 200 on the final host, and check both with the same curl command you use for pages.
How do you confirm the fix and clear the error?
Re-run curl on every variant, check one URL in Google's live test, then validate. The row only clears after Google recrawls each affected URL, so start the validation once you are sure every instance is fixed; Google says validation stops as soon as it finds one still failing.
Run the curl command on each affected URL and each variant. Every one should end in a single 200 within one hop.
In URL Inspection, run Test live URL on a couple of them. Because the live test follows redirects to the final URL, a pass confirms the chain now resolves.
Open the Redirect error row in the Page indexing report and click Validate fix. Google says validation "typically takes up to about two weeks."
Keep the redirects in place afterwards. Removing them turns redirect errors into 404s.
Check your redirects before Google recrawls them
To test redirects on the URL you care about, run the free scan on LaunchScaler. It takes the URL, no account needed, and runs 156 checks across 6 of its 7 categories at no cost. Its checks flag redirect loops, chains longer than a single hop, internal links that resolve through a redirect, sitemap entries that redirect, and whether plain HTTP reaches HTTPS on the same host in the first hop. It reads your live responses, so fix what it reports, confirm with curl, and then validate the Redirect error row.
Trace every hop with curl -sIL, find the loop, the extra hops or the broken Location header, and change the rules so the old URL redirects straight to a final page that returns 200. Then click Validate fix on the Redirect error row.
03
How many redirects does Googlebot follow?
Google's crawlers follow up to 10 redirect hops by default. Aim for one hop from any old URL to its final destination.
04
What causes a redirect loop?
Usually two layers with conflicting rules, such as a CDN that sends requests to the origin over HTTP while the origin redirects HTTP to HTTPS, or one rule adding www or a trailing slash while another removes it.
05
What is the maximum URL length for Google?
Google does not publish a number. The HTTP specification recommends that software support URIs of at least 8,000 octets, and a URL that grows past that on every hop is almost always a rule that keeps appending to it.
Request indexing lives in URL Inspection and has an unpublished daily quota. Repeat requests don't help; a rejection means the live test found a blocker.
Six robots.txt and noindex checkers compared: LaunchScaler, Search Console's report and URL Inspection, Bing's tester, an extension and Google's parser.
