How to Find and Fix Redirect Chains

Short answer

A redirect chain is two or more redirects in a row before a page finally loads. Each hop adds latency and leaks a little link equity, and Google stops following after a handful. The fix is always the same: make the first URL point directly at the final destination.

A redirect chain is when a URL redirects to another URL, which redirects to another, before the visitor finally lands on a page. One redirect is normal. Two or more in a row is a chain, and chains are one of the most common technical SEO problems on sites that have been around for a few years.

What a redirect chain looks like

Here is a real one from a site that migrated from HTTP to HTTPS, then added www, then changed its URL structure:

http://example.com/blog/post
  → 301 → https://example.com/blog/post
  → 301 → https://www.example.com/blog/post
  → 301 → https://www.example.com/articles/post
  → 200

Three hops. Each one was reasonable at the time. Together they cost about 400 milliseconds and lose a little link value at every step.

Why chains hurt

Speed. Every hop is a full round trip to the server: DNS, connection, request, response. On mobile networks that can be 100–300 ms per hop. Google's own guidance is to keep pages under a few hundred milliseconds to first byte; a three-hop chain can blow that budget before the page even starts loading.

Link equity. Google has said that 301 redirects pass "full" PageRank, but in practice SEOs consistently measure a small loss per hop. Over three or four hops, the loss adds up. If a valuable backlink points to the first URL in the chain, the page at the end gets less benefit than it should.

Crawl budget. Googlebot follows a limited number of redirects per URL (historically five, now up to ten). If a chain gets too long, Google simply stops and the final page is never crawled from that path. On large sites, chains also waste crawl budget that could go to real content.

Fragility. Every hop is a place where something can break. Change one rule in .htaccess and a chain that used to work now loops or dead-ends.

How to find them

You can't see chains in a browser; it follows them silently. You need a tool that requests each hop separately and shows you the path.

Paste any URL into the Redirect & Status Checker and you'll see every hop with its status code and how long it took. Paste up to twenty at once to check a whole section of a site.

The URLs most worth checking:

The fix is always the same

Make the first URL point directly at the last one. Don't delete the intermediate rules yet, because other URLs may still depend on them; just add a rule earlier in the chain that skips straight to the destination.

Apache (.htaccess)

Put the most specific rule first:

# Direct: old HTTP path straight to the final HTTPS URL
Redirect 301 /blog/post https://www.example.com/articles/post

If you're redirecting whole patterns:

RewriteEngine On
# One rule that handles protocol AND host in a single hop
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

The [OR] is the important part. Without it, HTTP → HTTPS and non-www → www become two separate rules and two separate hops.

Nginx

# Catch everything that isn't the canonical host, in one server block
server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Then a separate server block for https://www.example.com that actually serves content. One hop for every variant.

WordPress

Most chains on WordPress come from a redirect plugin plus a server-level rule doing overlapping work. Open your redirects plugin (Redirection, Rank Math, Yoast Premium) and search for the source URL. If its target is itself a redirect, change the target to the final destination.

Also check Settings → General. The WordPress Address and Site Address should both be the canonical form (https://www.example.com or https://example.com, whichever you use). If they don't match your server rules, WordPress adds its own redirect and you get a chain.

Cloudflare

If you use Cloudflare's "Always Use HTTPS" and a server-level HTTP→HTTPS rule, you may get a hop at the edge and another at the origin. Keep one. Cloudflare's Redirect Rules (Rules → Redirect Rules) can handle host and protocol in a single rule.

After fixing

Re-run the same URLs through the checker. Every chain should now show one redirect and a 200. Then, in Google Search Console, use URL Inspection on a couple of the affected pages and request indexing so Google picks up the shorter path faster.

Common questions

Should I use 301 or 308? Both are permanent. 301 is universally understood; 308 additionally preserves the request method (POST stays POST). For normal page redirects, 301 is fine.

What about 302? Temporary. Search engines keep ranking the old URL. If the move is permanent, don't use 302; it's one of the most frequent mistakes the checker flags.

Is one redirect bad? No. A single HTTP→HTTPS redirect is expected and Google handles it without issue. The problem starts at two.

Can I just delete the old URLs instead? If nothing links to them, yes. If anything does, redirect them. A 404 on a URL with backlinks throws that link value away entirely.

Frequently asked questions

What is a redirect chain?

Two or more redirects in a row before the visitor reaches the final page, for example http to https to www to a new path.

Are redirect chains bad for SEO?

Yes. Every hop adds latency, leaks a little link equity, and Google stops following after several hops, so the final page may never be crawled from that path.

How many redirects are acceptable?

One. A single http-to-https or non-www-to-www redirect is normal. Two or more in a row should be collapsed.

How do I find redirect chains on my site?

Request each URL without following redirects and read every hop. A redirect checker does this and shows the full chain with status codes.

Try it on your site

Free, no signup. Takes about ten seconds.

Open the tool

Keep reading