Avoid Multiple Page Redirects: Flatten Redirect Chains

This check fires when a URL resolves through multiple redirects, A → B → C instead of A → C. Each extra hop adds a DNS lookup, connection, and server round trip before the browser sees a single byte of the destination. On mobile networks those milliseconds stack up fast, and Googlebot follows only so many hops before it gives up, so a long enough chain can leave the final page uncrawled.

What this check flags and why it matters

A single redirect is normal and cheap. Chains are the problem. They appear when you stack fixes over the years, HTTP to HTTPS, then non-www to www, then a slug change, and never collapse them into one hop. The cost is latency the user feels on the request that matters most, the first one, plus wasted crawl. Google says it follows up to around ten hops per URL, but you never want to be anywhere near that ceiling; every hop is delay you are choosing to keep.

A real chain, and the flattening

Here is a classic four-hop chain built up over three site migrations, exactly the kind curl -IL exposes in seconds:

curl -sIL -A 'Mozilla/5.0' http://example.com/old-page | grep -iE '^(HTTP|location)'

HTTP/1.1 301 Moved Permanently
location: https://example.com/old-page          # http -> https
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/old-page       # non-www -> www
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/new-page       # slug change
HTTP/1.1 200 OK                                  # finally

Four requests to load one page. The fix is a direct rule so the very first request lands on the destination:

# Apache .htaccess - one hop, http+non-www+old-slug straight to final
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [OR]
RewriteCond %{HTTPS} off
RewriteRule ^old-page$ https://www.example.com/new-page [R=301,L]

Keep the general HTTPS and www canonicalisation rules too, but add explicit one-hop rules for high-traffic old URLs so they never walk the chain.

What each hop costs

Rough per-hop overhead on a typical mobile connection. Numbers vary, but the shape is always the same, latency scales with hop count.

How to detect it

1. curl: the fastest check. Run curl -sIL -A 'Mozilla/5.0' <url> and count the 301/302 lines before the 200. Every redirect status before the final response is a hop.
2. PageSpeed Insights: run the URL and look for the "Avoid multiple page redirects" opportunity, which lists the chain and the time it costs.
3. Lighthouse: the same audit under Performance, handy in Chrome DevTools against staging before you ship.
4. Google Search Console: the Page Indexing report groups URLs under "Page with redirect", and the URL Inspection tool shows the redirect trail Googlebot walked.
5. Crawler export: a site crawl exports every redirect and its number of hops, so you can sort the whole site by chain length and fix the worst offenders first instead of checking URLs one at a time.

How to fix it

Update the redirect rules so the original URL points directly at the final destination in a single 301, skipping every intermediate. Then chase the sources: update internal links, the XML sitemap, and canonical tags to reference the final URL so nothing re-enters the chain. Keep redirects permanent, a 302 where you meant a 301 both fails to pass full equity and can keep the old URL indexed. Audit periodically, because chains rebuild themselves quietly after every migration. Related reading: the duplicate content guide for why redirect targets matter, the self-redirect loop for the pathological case, and the redirect map generator to plan a clean set before you touch the server.

FAQ

Is one redirect bad for SEO?

No. A single 301 is normal, expected, and passes equity. The flag is about chains of two or more hops, where latency and crawl waste add up. Do not obsess over one clean redirect.

Do redirect chains cause a loss of link equity?

Modern Google passes equity through 301s well, so the bigger cost of a chain is latency and crawl budget rather than lost PageRank. That said, a mix of 302s or broken hops in a chain absolutely can leak signals, so keep them permanent and clean.

How many redirects will Googlebot follow?

Around ten hops per URL before it stops for that crawl and tries again later. You never want to test that limit; every hop past the first is delay and risk you are choosing to keep.

Should I use 301 or 302 to flatten a chain?

Use 301 for permanent moves, which is what a flattened chain almost always is. Reserve 302 for genuinely temporary redirects. A 302 in place of a 301 keeps the old URL eligible for indexing and muddies the signal.

Do chains rebuild themselves after I fix them?

They can. Each migration or slug change adds a new redirect on top of the old ones, and unless you rewrite the source rules to point at the final destination, the chain grows one hop at a time. Re-run a redirect audit after every migration so a two-hop chain never quietly becomes a five-hop one.