Redirect Chains: When 301s Start Hurting Your Rankings

A redirect is not a mistake. The mistake is five of them stacked in a row, so the browser and Googlebot have to walk the whole queue before anything renders. That's a redirect chain, and I find one on almost every site that has been through at least one migration.

What a redirect chain actually is

A chain happens when URL A redirects to B, B redirects to C, and C finally lands on the real page. A typical example from a shop that moved to HTTPS and later standardised on www:

`` http://shop.com/product → 301 → https://shop.com/product → 301 → https://www.shop.com/product → 301 → https://www.shop.com/product/ → 200 OK ``

Three redirects for one page. Every single one is technically correct, every one was added for a sensible reason, and nobody ever collapsed them into a single step. One rule sending http://shop.com/product straight to https://www.shop.com/product/ would do the same job.

Where chains come from

Almost always from layers of rules that nobody ever cleaned up:

• Moving to HTTPS. One sitewide redirect gets added.
• Picking www or non-www. That's the second.
• Trailing slash. The server forces /product/ instead of /product. Third.
• Changing category URL structure. A shop moves from /category/kids-shoes to /kids-shoes. Fourth.
• Changing platform. The new platform ships its own redirect logic, and the old rules stay in .htaccess or in a plugin.
• Renamed product or article. WordPress stores the old URL when you change a slug. Change the slug twice and the chain builds itself.

Every change adds a new rule at the bottom of the list. The old one never gets rewritten, because nobody wants to read a hundred lines of config hunting for the one that applies.

What a chain does, and what it doesn't

Let me start with the claim that's usually wrong. Google has said repeatedly that 301 redirects don't lose link value. So ignore the scare stories about "every hop costs you 15% of your link equity". The real problem is more practical.

Time to first byte. Each hop is a separate HTTP request. On a mobile connection with higher latency, three redirects can easily add a few hundred milliseconds before the HTML even starts downloading. That shows up in Core Web Vitals, specifically in LCP.

Googlebot's redirect limit. Google's documentation says the crawler follows a limited number of redirects in a single fetch attempt. Past that limit it doesn't fetch the page at all, and a redirect error appears in Search Console. At three hops this doesn't happen. At eight it does.

Wasted crawling. Every URL in the chain is a separate address the crawler has to process. On a shop with tens of thousands of products, part of your crawl capacity goes on intermediate steps instead of new products.

Slower signal transfer. It takes Google longer to work out that the final URL is the destination than it would with a single direct hop. During a migration that means extra weeks with rankings bouncing around.

Internal links pointing at dead ends. This is the worst part from where I sit. If your navigation, product copy or old articles link to the old URLs, the chain fires on every single visitor click. It isn't just a crawler problem.

When you can leave it alone

One redirect is fine. There is nothing to shorten and nothing is going wrong. If you moved an article a year ago and old-article points to new-article, leave it.

The same goes for a redirect nobody visits and nobody links to. Shortening chains matters where there is traffic: product pages, categories, articles with external links pointing at them.

Redirect loops

The worse version of a chain is a loop: A sends to B and B sends back to A. The browser shows ERR_TOO_MANY_REDIRECTS and Googlebot never fetches the page. The usual cause is rule ordering — one rule forces a trailing slash, another strips it.

A loop isn't "mildly bad for rankings". A loop means the page does not exist on your site. Fix it today.

How to find chains

Fastest from the command line. One line shows the whole path, including every intermediate step:

`` curl -sIL https://shop.com/product | grep -iE "^HTTP/|^location:" ``

The output gives you every status code and every target. Three HTTP/2 301 lines in a row means you have a chain.

Search Console. In the Pages report, look for "Redirect error" and "Page with redirect". The first category includes chains that are too long, plus loops. The URL Inspection tool shows you what Google finally resolved the address to.

Crawl the whole site. Any crawler that walks your pages like a bot will list internal links pointing at URLs that return 301. That's the list you can actually work with — it tells you exactly which page needs the link fixed.

Your sitemap. Only URLs returning 200 belong in a sitemap. Redirected addresses in there give Google work it doesn't need to do. More on that in the piece on robots.txt and sitemap errors.

How to fix it

1. Cut the chain to one hop. Rewrite every rule so it points straight at the final URL. Turn A → B → C into A → C and B → C. Don't delete the old rule — external links may still hit the old URL.

2. Fix the rule order on the server. In .htaccess and nginx, order decides everything. Put the HTTPS and www rules before the per-URL rules, otherwise the hops always stack.

3. Fix your internal links. No link on your own site should point at a redirected address. That covers navigation, footer, banners, product copy and old articles. On a shop this is also a good moment to look at internal linking between categories.

4. Check your canonical tags. The canonical has to point at the final URL, not at an intermediate step. If the canonical points somewhere that redirects, Google picks the destination itself. I go into detail in the article on canonical tags.

5. Don't bulk-redirect everything to the homepage. A discontinued product redirected to the homepage often gets treated as a soft 404. If there's no relevant replacement, serve a 404 or a 410. That's cleaner than a fake redirect.

6. Keep redirects running for a long time. Google recommends holding them for at least a year. For URLs with external links pointing at them, keep them permanently — they cost you one line of config.

301 or 302

301 means moved permanently, 302 means temporary. Changing URL structure, moving to HTTPS, merging pages — those are all 301. A 302 makes sense for an A/B test or a temporary outage.

Google does eventually treat a long-running 302 as permanent, but processing takes longer and Search Console reports get harder to read. If the move is permanent, write 301.

How I handle this in Seonal, and what I can't do

When I crawl a site, I find the internal links pointing at redirected addresses and the sitemap URLs that don't return 200. For links inside content I prepare the corrected text ready to paste — the actual final address, not a note saying "shorten the chain".

What I can't do: I have no access to your .htaccess or your nginx config. Server-level redirect rules have to be rewritten by someone with hosting access. I can tell you exactly which chains exist and what they should look like, but I won't save the rule for you.

One more thing about expectations. Shortening chains is hygiene, not a jump in rankings. You'll see the effect in load time and in how fast Google processes changes on your site. Whether it showed up in traffic is something you check by comparing 28 days before and after the fix went live — I cover how to read that in the article on measuring SEO impact.