Redirect chains and loops: how many hops before Google gives up
Googlebot follows up to 10 redirect hops, then reports an error. How to map every chain on a site with curl, fix loops and collapse each to one hop.
LLaunchScaler·Published ·7 min read
A redirect chain is a URL that passes through more than one redirect before reaching the page, and Googlebot follows up to 10 hops before it stops and reports a redirect error. A redirect loop is a chain that never ends, so the URL cannot be crawled or indexed at all. The fix for both is the same: point each old URL straight at its final destination in one hop, and link only to final URLs.
Chains rarely come from one bad rule. They build up as a site changes protocol, host, URL structure and platform, each adding a redirect on top of the last. So the work is mostly mapping them.
How many redirects will Googlebot follow?
By default, Google's crawlers follow up to 10 redirect hops, and Googlebot generally follows 10 when crawling web content. Content returned by a redirecting URL is ignored; only the final target is processed. Some Google tools behave differently: Google's documentation notes that Google Inspection Tools don't follow redirects.
When the chain is longer than that, or loops, the URL lands under "Redirect error" in Search Console's page indexing report. Google lists four causes for that status:
A redirect chain that was too long.
A redirect loop.
A redirect URL that eventually exceeded the maximum URL length.
A bad or empty URL in the redirect chain.
Browsers have their own limit. The Fetch Standard tells a browser to return a network error once a request's redirect count reaches 20, which is when you see ERR_TOO_MANY_REDIRECTS. The redirect error guide covers each Search Console cause in detail.
Why are redirect chains bad for SEO?
Every hop is another request and response before the page can load, for every visitor and every crawler. Lighthouse's redirect guidance says each extra trip can delay loading by hundreds of milliseconds, and it failed a page with two or more redirects. A short chain still resolves, but it wastes time and crawl requests on every visit.
The costs, in order of how often they bite:
Questions, answered
What people ask about this
01
How many redirects will Googlebot follow?
Google's crawlers follow up to 10 redirect hops by default. Past that, or in a loop, the URL is reported as a redirect error in Search Console's page indexing report and is not indexed.
Speed. Each hop adds a round trip before the first byte of the real page. Lighthouse 13 moved this check into its document request latency insight.
Crawl requests. A crawler that follows a link through three hops makes four requests to fetch one page. On a large site, that is crawl effort spent on redirects instead of content.
AI crawlers. Vercel's crawl data showed ChatGPT's crawler spending 14.36% of its fetches following redirects, against 1.49% for Googlebot. The guide to how AI crawlers handle 404s and redirects covers what that means for citations.
Breakage. Long chains are fragile: one rule changed in the middle, and the whole chain ends in a 404 or a loop.
Mixed signals. A canonical tag, sitemap or hreflang entry that points at a redirecting URL tells Google one thing while the server says another.
How short should a redirect chain be?
One hop, wherever you control both ends. Google's site move guide says to redirect to the final destination directly, and if that is not possible, to keep the number of redirects in a chain low, "ideally no more than 3 and fewer than 5." Its 10-hop crawler limit is the point of failure, not a target.
The same guide sets the other half of the rule: keep redirects in place "for as long as possible, generally at least 1 year." So when you collapse a chain, you shorten the path from each old URL rather than removing old URLs from the map. A redirect deleted too early turns every link to that URL into a 404.
How do you see a redirect chain?
Request the URL with curl and follow every hop. -I asks for headers only, -L follows Location headers, and the grep keeps just the status line and target of each response, so the output reads as the chain itself.
That is four redirects (protocol, host, trailing slash, then the slug) before a 200, when https://www.example.com/new-page/ could have been one hop from anywhere. For a single number, curl -s -o /dev/null -L -w '%{num_redirects} %{url_effective}\n' <url> prints how many redirects curl followed and the final URL. curl follows up to 50 redirects by default and exits with code 47 when it hits its limit, which is how a loop shows up.
In a browser, open DevTools, tick Preserve log in the Network panel, and load the URL: each hop appears as its own request with its status code.
How do you map every redirect chain on a site?
List every URL that anyone might request, resolve each one, and record the hop count and final URL. A spreadsheet of those three columns tells you every chain, every loop and every redirect that ends in a 404.
Collect the URLs: every <loc> in your XML sitemaps, every internal link from a crawl of the site, old URLs from Search Console's page indexing report (the Page with redirect and Redirect error rows), and the URLs other sites link to from your backlink data.
Put them in urls.txt, one per line, including the http:// and www variants of your key pages.
Open redirects.tsv and sort by the hop count. Anything above 1 is a chain to collapse. A final status other than 200 means the chain ends in an error. A row that hit the 12-redirect limit is almost certainly a loop.
Group the chains by their first hop. A single rule, such as an old domain, the protocol and host rules, or a URL structure change, can account for many rows, and fixing it fixes all of them.
How do you fix a redirect loop?
Find the two rules that undo each other and remove one. The curl output of a loop shows the same two or three URLs repeating, which tells you which layer is fighting which. The usual pairs are the CDN versus the origin, a trailing slash rule versus the framework's own slash handling, and the host rule versus the app's canonical host setting.
Loop pattern in the curl output
Usual cause
Fix
https:// to http:// to https://
Cloudflare in Flexible mode while the origin redirects HTTP to HTTPS
Remove the origin redirect, or set the encryption mode to Full or Full (strict)
/page to /page/ to /page
One layer adds a trailing slash and another removes it
Decide on one form and configure it in one place
example.com to www.example.com to example.com
The host redirect points one way and the app or platform domain setting the other
Set the canonical host once, at the edge
Login page to dashboard to login page
Auth check redirects before the session cookie is readable
Exclude the login route from the auth redirect
/en to / to /en
Language or geo redirect fighting a default route
Redirect only from the root, and never back
Cloudflare's own troubleshooting page for ERR_TOO_MANY_REDIRECTS lists encryption mode misconfigurations, Edge Certificates settings and misconfigured redirect rules as the common causes, and describes the Flexible-mode loop in the first row. After you remove the offending rule, test with curl rather than your usual browser, because browsers can cache permanent redirects and keep replaying the loop you already fixed.
How do you collapse a chain to one hop?
Rewrite each old URL's redirect so it points at the final URL, not at the next hop, and stop linking to anything that redirects. Collapsing is mostly editing the redirect map: every entry's destination should be a URL that returns 200 without redirecting.
For each chain in your spreadsheet, change the first rule so it sends the old URL straight to the final URL from the url_effective column.
Keep protocol and host rules at one layer, ideally the edge, and apply them once. For a non-canonical http://www request, two hops (protocol on the same host, then host) is fine and is what HSTS needs; the HTTP to HTTPS redirect guide explains why.
Update internal links, navigation, canonical tags, hreflang entries and the XML sitemap to the final URLs, so no one you control ever starts a chain.
Keep the redirects themselves in place for old URLs that other sites link to. Collapsing means shortening them, not deleting them.
Use permanent codes (301 or 308) for every hop that is permanent; the 301 vs 302 vs 307 vs 308 guide covers which to use.
Re-run the script. Every row should show 0 or 1 redirects and end in a 200.
Google's redirects guide also orders redirect types by how reliably Google interprets them, with server-side redirects first. If any hop in a chain is a JavaScript or delayed meta refresh redirect, replace it with a server-side one while you are collapsing.
To find chains on a live site without building the URL list first, run the free scan on LaunchScaler. It needs only your URL and no account, and its free checks flag URLs that resolve through more than one redirect, redirect loops, internal links that depend on redirects (the case AI crawlers handle worst), and canonical tags or sitemap entries that point at redirected URLs, among 156 checks across 6 of its 7 categories.
Each hop adds a network round trip before the page loads and one more request for every crawler. Google still processes a short chain, but links and sitemaps that point at redirecting URLs waste crawl requests, so collapse chains to one hop.
03
How do I check a redirect chain?
Run curl -sIL https://example.com/old-url | grep -iE '^HTTP|^location'. It prints the status code and Location header of every hop until the final response.
04
What causes a redirect loop?
Two rules that undo each other: HTTP to HTTPS at the CDN and HTTPS to HTTP at the origin, a trailing slash added by one layer and removed by another, or www and non-www rules pointing at each other. Browsers give up after 20 redirects and show ERR_TOO_MANY_REDIRECTS.
05
Do AI crawlers handle redirects well?
Less efficiently than Googlebot. Vercel measured ChatGPT's crawler spending 14.36% of its fetches following redirects, against 1.49% for Googlebot, so internal links that point straight at final URLs matter more for AI crawlers.
The six security headers every site should send, the value for each, the Mozilla Observatory penalty for a missing one, and how to set them on any host.
