Updated
Search Console lists a URL under Redirect error when Googlebot started following redirects from it and never reached a page. Google's help page gives four causes: "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."
Google doesn't say which of the four it hit. You find out by following the redirect yourself, hop by hop, from the exact URL in the report.
Lists every hop with its status code and what it changed, and flags chains, temporary redirects, https to http and a missing Location header. It stops after 5 hops (Googlebot after 10). Free, no signup.
Redirect error vs Page with redirect
- Page with redirect: the redirect works. The old URL stays out of the index and Google indexes the target. Usually fine; see when to fix it and when to leave it.
- Redirect error: the redirect never ends on a page, so nothing gets indexed, neither the URL nor a target. Visitors usually see ERR_TOO_MANY_REDIRECTS or "The page isn't redirecting properly". Always worth fixing if the URL matters.
Step 1: follow the redirect hop by hop
Run the URL from the report, not your home page, and run both the http:// and https:// forms. With curl, sent as Googlebot so a firewall or bot rule answers the way it answers Google:
Or paste it into the redirect checker. Then match what you see to Google's cause:
| Google's cause | What the hops show | Fix |
|---|---|---|
| "A redirect loop" | A URL comes back that is already in the list: https to http and back, or /page to /page/ and back. | Find the two rules that undo each other (step 2). |
| "A redirect chain that was too long" | Different URLs every hop, more than 10 of them. Google's crawler docs: "Googlebot generally follows 10 redirect hops when crawling for general web content". | Redirect the first URL straight to the final one (step 3). |
| "A redirect URL that eventually exceeded the max URL length" | Each hop is longer than the one before: ?lang=en&lang=en&lang=en, or a path segment that repeats. | Fix the rewrite that appends instead of replacing; it often keeps the query string and adds it again. |
| "A bad or empty URL in the redirect chain" | A 301 or 302 with no Location header, an empty one, or a malformed target. | Make the redirect send a full, valid URL. |
Google gives no number for the maximum URL length, so don't hunt for one. If the URLs keep growing, that rule is the bug.
Step 2: the usual loop causes
A loop almost always means two layers each think they own the redirect: a CDN and the server, the server and the CMS, or a plugin and .htaccess.
| Where | What happens | Fix |
|---|---|---|
| Cloudflare SSL/TLS mode Flexible | Cloudflare fetches your server over http, and the server redirects every http request to https. Cloudflare's docs on Flexible mode: "Redirect loops will occur if your origin server automatically redirects all HTTP requests to HTTPS." | Cloudflare's fix: "either remove HTTPS redirects from your origin server or update your SSL/TLS Encryption Mode to be Full or higher (requires an SSL certificate configured at your origin server)." |
| WordPress behind a proxy or load balancer | The proxy handles https and passes plain http to WordPress, which redirects it again. WordPress's HTTPS docs: these setups "will initially send any requests into an infinite redirect loop." | Configure WordPress to read the HTTP_X_FORWARDED_PROTO header in wp-config.php, as those docs show (and make sure the proxy sets it). |
| www, slash or case rules that fight | One rule adds www or a trailing slash, another removes it. Common after moving a site to a new host or CDN that has its own default rule. | Keep one rule per change, in one place. Check the CDN, the server config and any redirect plugin. |
| Language or country redirects | The site redirects by IP or browser language. Google: its crawler's default IP addresses "appear to be based in the USA" and it "sends HTTP requests without setting Accept-Language". A rule that bounces between language versions, or sends US visitors somewhere that sends them back, loops for Googlebot only. | Don't redirect by language; Google's advice is to "Avoid automatically redirecting users from one language version of a site to a different language version". Link the versions with hreflang and show a language banner. |
| Cookie, consent or login redirects | The page redirects to set a cookie and then back. A browser keeps the cookie; Google's rendering service doesn't: "HTTP Cookies are cleared across page loads." Googlebot is sent round again on every request. | Serve the page without the cookie, and show the consent or region choice on the page instead of a redirect. |
Test after every change, from outside your own network. A loop that only happens without a cookie won't show in the browser you're logged in with; curl or a private window will show it.
Step 3: chains after a migration
Every migration that only adds redirects makes the chain one hop longer: http://old.com/a to https://old.com/a to https://www.old.com/a to https://new.com/a to https://new.com/a/. Each step was right when it was added. Together they get long, and more than 10 is an error for Googlebot.
- Point every old URL straight at its final URL in one
301. Update the old redirect map, don't add a new rule on top. - Put the protocol and host change in one rule, so
http://+ non-www becomes the final https + www URL in one hop. - Update internal links, the XML sitemap and canonicals to the final URL, so Google doesn't start at the top of the chain at all.
Step 4: validate the fix
When the redirect checker shows the chain ending on a 200 in one or two hops, check the final URL is indexable with the noindex checker. Then open the Redirect error row in the Page indexing report and click Validate Fix.
Don't rely on URL Inspection's live test to judge the redirect itself. Google's documents disagree: the Page indexing help says the live test "follows redirects and then tests the final URL", while the crawler docs say "Google Inspection Tools doesn't follow redirects". Test the redirect with curl or the checker, then inspect the final URL. If Google reports an error on the final page instead, see Server error (5xx) or Blocked due to other 4xx issue.
Hear about the next broken redirect first
A loop can start with one CDN or plugin setting and hit every page at once. NoindexWatch checks the URLs you choose and tells you by email, Slack or Discord when one stops reaching a page (too many redirects, a redirect to an error), picks up a chain of 3 or more redirects, a noindex or a robots.txt block, and again when it recovers. It follows up to 5 hops, so it reports a loop as 'more than 5 redirects' rather than by name. The free plan covers 1 site with up to 20 URLs, checked once a day, no card; paid plans check every hour.
Sources: Google Search Console Help, Page indexing report; Google Search Central documentation on HTTP status codes and network errors, redirects, locale-adaptive pages, managing multi-regional sites and fixing JavaScript Search problems; Cloudflare SSL/TLS docs, ERR_TOO_MANY_REDIRECTS; WordPress Advanced Administration, HTTPS. Related: Page with redirect · Server error (5xx) · Soft 404 · My site disappeared from Google.