Two or three redirects do not break indexing, but each one costs a request
Googlebot follows up to 10 redirects in a row, so a page behind a chain of two or three hops is indexed normally. The damage is of another kind: every hop is a separate request to the server and an extra round of waiting for a person. Google's site move documentation also asks you to keep a chain to no more than 3 hops and under 5 in any case.
When I ran this scheme over my own site on 12 October 2026, the longest path on adlab.ee turned out to be 4 redirects.
Google's limits: 10 redirects for pages, 5 for robots.txt
Three numbers from Google's documentation, checked on 12 October 2026, decide where a chain is merely redundant and where it is already dangerous.
| What is requested | Limit | What happens next |
|---|---|---|
| Ordinary page, Googlebot | up to 10 redirects | following the chain stops; which status you will see in Search Console, the documentation does not say |
| robots.txt | at least 5 redirects | the file is treated as a 404: there are no crawl restrictions and Disallow rules are not applied |
| Site move, recommendation | no more than 3, under 5 in any case | a chain adds delay for users, and not all browsers support long chains |
The robots.txt row is the most dangerous. The limit is five, yet the file often sits behind the same rules as the whole site (http → https and www → non-www). If an old redirect from a previous domain lies on top, the chain easily goes past five hops, the Disallow rules stop applying and closed sections get crawled. What to put in that file in the first place I covered in the article on sitemap.xml and robots.txt.
One more caveat about codes. For Google, 301 and 308 are a strong signal that the final URL should become canonical, while 302 and 307 are a weak one. How it weighs a temporary redirect in the middle of a chain, the documentation does not say, and I will not guess: in the chains I fix I keep only 301 or 308.
What a chain looks like on a live site: four rules, four hops
This is what adlab.ee returns for the old address of a renamed article if you arrive from http://www with a trailing slash. Measured on 12 October 2026, each hop is a 308.
Each rule is correct on its own. The first two hops, protocol and host, come from the hosting platform (the headers say Server: Vercel), not from my application code. The third, the trailing slash, is removed by Next.js. The fourth is a line in my next.config.mjs: the article seo-mebelnogo-magazina-estoniya-2017 moved to the Estonian slug eesti-mooblipoe-seo-liiklus-kasvas-3x, and the old address leads to the new one with a single rule. I have nowhere to merge those four hops: three of them are not in my code.
What is in my power is the addresses that get linked. I checked: of the 141 addresses in the adlab.ee sitemap.xml, all 141 answer 200 on the first request, with no redirects at all. The robots.txt file at http://www.adlab.ee/robots.txt goes through 2 redirects, which is below the limit of 5. I did not check this against server logs, so I do not know whether Googlebot ever arrives by the four-hop path. It is reachable only through an external link in the old form.
The price of a chain is measurable. Five curl runs from my computer gave 0.12–0.17 s for the direct address and 0.23–0.42 s for the path through three 308s. This is not a lab test: one machine and one network. The order of magnitude is visible, though: each hop adds one round trip to the server and back.
Where chains come from
A chain grows in layers: on adlab.ee, 4 rules were written at different times and in different places. Whoever adds a rule looks at the address in front of them, not at the whole path. The same mechanism works on any site with a history, but I have no sample across clients, so I do not name frequencies. There are four layers:
- Protocol and host: http → https and www to non-www. Two hops that every site has and that are normal in themselves.
- Slash and letter case: a CMS or framework brings the address to one form, and that is one more hop.
- Structure change: a section was renamed, old addresses lead to new ones, a year later it was renamed again, and nobody updated the first rule. The result is
A → B → Cwhere it should beA → C. - Domain change: the old domain redirects to an intermediate one, which redirects to the new one. How such tails are put together during a move I covered in the website migration checklist.
How to find every chain
One address is checked with one command. The -L flag follows redirects (--max-redirs 15 stops at the fifteenth, while Googlebot stops at the tenth), and -w prints the number of redirects and the final address.
curl -sIL --max-redirs 15 -o /dev/null -w '%{num_redirects} %{url_effective} %{http_code}\n' http://www.example.com/old-page/
A whole sitemap is checked with a loop. --max-redirs 0 forbids following redirects, so what remains is the first code of each address: anything that is not 200 is a candidate for a fix.
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' \
| while read u; do curl -s -o /dev/null --max-redirs 0 -w '%{http_code} %{url_effective}\n' "$u"; done \
| grep -v '^200'
If the output is empty, as mine was, the sitemap is clean. If it holds 301s and 308s, the fix is not in the redirects but in the sitemap itself: only final addresses belong there, more on which in the article on duplicate content.
For the whole site you need a crawler. In Screaming Frog it is the report Reports → Redirects → Redirect Chains: it shows the start of a chain, each hop and the end, and you can see at once which pages hold links to the start. In Search Console, look at the status "Page with redirect" in the Page indexing report: it lists what Google found behind a redirect, not a ready list of chains, but it shows where to look.
Check four places separately, where the start of a chain lands most often: robots.txt (the limit there is only 5 redirects), sitemap.xml, canonical and hreflang. An hreflang link to a redirecting address, as I analysed in the hreflang article, breaks the tie between language versions silently.
In what order to fix them
- Write out the end of every chain: the final address that answers 200 and that you want to see in search results.
- Rewrite the rules so that every start leads straight to the end. Do not add a rule on top, replace the old one:
A → C, notA → BplusB → C. - Fix the sources: menu, footer, breadcrumbs, canonical, hreflang, sitemap. In the same site move documentation Google separately asks you to replace internal links with the new addresses using the URL mapping. This step gives more than the redirect itself, because it removes the hop where you control it: internal links should not lead to redirects at all.
- Keep the old rules. Google advises keeping redirects as long as possible, generally at least a year, and allows keeping them indefinitely.
- Check again with the command from the previous section and with a crawler, a week after the fix.
When to leave a chain alone
Not every chain is worth a working day. If the site has up to a few hundred addresses (adlab.ee has 141 in its sitemap), the chain consists of the standard http → https and www → non-www, and links to the start exist only in old external sources, there is nothing to fix: the first 2 hops belong to the platform and the loss is limited to one request.
Time is worth spending in three cases: the chain is longer than 3 hops (the threshold from Google's site move documentation), the start of the chain sits in your menu, sitemap or canonical, or it touches robots.txt with its limit of 5 redirects. Catalogues with a history of several moves and sites that went through a migration fall into this group first. There chains also eat part of the crawl budget: three hops instead of one means three requests for the same page.
Deleted pages are outside this analysis. If an address has no replacement, a 301 to the homepage is harmful, and I wrote about that in the article on 404, 410 and redirects.
