Internal URL Redirect Chain: How to Find and Flatten It

What a redirect chain flags, and why it matters

This check fires when an internal URL redirects to another URL that also redirects — A → B → C instead of a clean A → C. Every extra hop adds a round trip before the reader (and Googlebot) reaches the real page, slowing load, burning crawl budget, and risking equity loss at each link in the chain.

One or two chains are a nuisance; hundreds — the usual result of stacking a new redirect on top of an old one during migrations — measurably drag crawl efficiency and page speed. Chains also fail silently: the page still loads, so nobody notices until an audit surfaces the pileup.

A real failing example, and the fix

Point curl at a URL with -IL to follow and print every hop. This real request walks three responses before landing — two redirects in a chain:

$ curl -sIL -A 'Mozilla/5.0' http://www.wordpress.com/ | grep -iE '^HTTP|^location'
HTTP/1.1 301 Moved Permanently
Location: https://www.wordpress.com/
HTTP/2 301
location: https://wordpress.com/
HTTP/2 200

That is http://www.wordpress.com/ → https://www.wordpress.com/ → https://wordpress.com/. The fix is to collapse the chain so the first URL jumps straight to the final destination in a single 301:

# Apache .htaccess: one hop, http+www straight to the canonical https host
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www. [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://wordpress.com/$1 [R=301,L]

The rule sends every non-canonical variant directly to the final host in one 301, so curl -IL now shows exactly one redirect followed by the 200. Apply the same principle to any internal chain: rewrite the first hop to target the final URL and delete the middle rules.

What each extra hop costs

Google will follow a limited number of hops before giving up on a URL, so long chains can leave the destination effectively undiscovered.

How to detect it

1. Screaming Frog. Enable Configuration → Spider → Always Follow Redirects, crawl, then run Reports → Redirects → Redirect Chains. The export lists every chain with each hop, its status code, and the number of redirects, so you can prioritise the worst offenders.
2. curl -IL. For any single URL, curl -sIL -A 'Mozilla/5.0' https://example.com/old-url/ | grep -iE '^HTTP|^location' prints every hop and status code. More than one 3xx before the 200 means a chain.
3. Redirect checker tool. Paste a URL into a hop-by-hop redirect checker to visualise the full path when you are auditing a handful of URLs by hand.
4. Google Search Console. The URL Inspection tool shows the final resolved URL and flags redirect issues; the Page indexing report groups URLs under Page with redirect, which is a good hunting ground for chains after a migration.

How to fix it

1. Map every chain: record the starting URL, each intermediate hop, and the true final destination.
2. Rewrite the first redirect so it points straight at the final URL — a single 301.
3. Remove the now-redundant intermediate redirect rules so nothing re-creates the chain.
4. Update your internal links to point at the final URL directly, so pages do not even trigger the first redirect.
5. Re-crawl and confirm each former chain now resolves in one hop with a clean 200.

FAQ

How many redirects is too many?

Aim for exactly one. Two hops is worth fixing; three or more risks crawlers abandoning the URL before they reach the destination. There is no benefit to any hop beyond the first.

Do redirect chains lose link equity?

Modern 301s pass most signals, but risk compounds with each hop and some equity can leak, especially across mixed 301/302 chains. A single clean redirect is the safest way to preserve authority.

What is the difference between a chain and a loop?

A chain eventually reaches a real page (A → B → C); a loop never does (A → B → A), so the URL is unreachable and returns an error. Loops are always urgent.

Should I fix the redirect or the internal link?

Both. Collapse the chain at the server so external and old links resolve cleanly, and update your own internal links to hit the final URL so they skip the redirect entirely.

Why did a migration create so many chains?

Each migration adds a new redirect on top of the last without removing the old ones, so URLs stack A → B → C → D over time. Auditing and flattening after every move prevents the pileup.

Related checks and reading

• Redirect Chains and Loops: Why They Hurt and How to Fix Them — the full explainer behind this check.
• Internal URL Redirects Back to Itself — the self-redirect loop, a chain's worst relative.
• Internal URL Not Found (4XX) — when the chain ends at a broken URL instead of a real page.
• 301 vs 302 Redirects — choosing the right status code for each hop you keep.