You know the feeling. You click a link, see the browser bar flicker, flicker again, then finally land somewhere. Maybe it happened so fast you didn't notice. Google's crawler notices every single time — and it keeps score.
Redirect chains are one of those technical SEO issues that nobody talks about until they're already causing damage. They're less dramatic than a 404 error, and harder to spot than a missing image. But left unchecked, they bleed your PageRank, eat into your crawl budget, and make your pages load slower than they have to. In this article, we'll cover exactly what they are, why they're a problem, and — most importantly — how to get rid of them.
What is a redirect chain?
A redirect chain happens when getting from URL A to URL Z requires passing through one or more intermediate URLs first. Instead of a direct one-hop redirect, you end up with a sequence of redirects that must all be followed before the browser (or crawler) reaches the actual content.
Here's what a clean, single redirect looks like:
Now here's what a redirect chain looks like:
Every hop adds a separate HTTP request, a DNS lookup, and a server response. For a human visitor on a fast connection, the difference might be 200 milliseconds. For Google's crawler, it means spending more time on your site just navigating to content — time that could be spent indexing more of your pages.
How do redirect chains happen in the first place?
Nobody sits down and deliberately creates a redirect chain. They build up gradually, through a series of individually reasonable decisions that accumulate into a messy tangle. Here are the most common culprits:
Site migrations gone in layers
You migrated from HTTP to HTTPS two years ago, so you set up a redirect from http://example.com to https://example.com. Then you moved to a new URL structure, adding another redirect. Then you switched from www to non-www. Each redirect made sense at the time. Now every HTTP link on the web passes through three hops before reaching your content.
CMS auto-redirects stacking on top of manual ones
WordPress, Shopify, and most other platforms will automatically create redirects when you change a URL slug. If you then add your own redirect in an .htaccess file or a plugin, you can end up with both running in sequence without realising it.
Trailing slash inconsistency
Many servers redirect /page to /page/ (or vice versa). If you also have a redirect pointing from an old URL to /page, that trailing-slash redirect silently adds a hop to every visit.
Campaign and tracking URLs
Short links, UTM redirectors, affiliate tracking links — these often go through a tracking domain before reaching the destination. Pile a site migration on top of that and you've got a chain before you even reach your own server.
Google has stated that PageRank is diluted with each redirect hop. The exact amount is debated, but the principle is consistent: the more hops between a linking page and your final destination, the less link equity gets passed through. For pages with hard-won backlinks, this is genuinely costly.
The real SEO impact of redirect chains
It's tempting to dismiss redirect chains as a minor technical annoyance. In practice, the consequences range from mildly frustrating to genuinely damaging, depending on how long the chain is and how important the affected pages are.
| Issue | Chain length | Impact level |
|---|---|---|
| Slower page load for visitors | 2+ hops | Moderate |
| Reduced crawl budget efficiency | 2+ hops | Moderate |
| PageRank dilution on linked pages | 3+ hops | High |
| Google stops following chain | 5+ hops | Severe |
| Redirect loop (infinite cycle) | Any | Critical |
| Single clean redirect (301) | 1 hop | Acceptable |
Crawl budget
Google allocates a crawl budget to each site — essentially the number of pages its crawler will visit in a given timeframe. For small sites (under a few thousand pages), this is rarely a limiting factor. But for larger sites with tens of thousands of pages, every wasted crawl request matters. A chain of four redirects means Google uses four crawl requests just to index one page. That's budget you'd rather spend on actual content.
PageRank and link equity
When another website links to your page, they pass link equity through that link. If the URL they linked to redirects through a chain before reaching your content, some of that equity is lost at each hop. For pages that depend on external links for their rankings — product pages, blog posts, landing pages — this can measurably affect where they rank.
User experience and Core Web Vitals
Each redirect adds latency. On a fast fibre connection, you might not notice. On a mobile network in a weak signal area, three redirect hops can add several hundred milliseconds before the first byte of actual page content is even requested. Google's Core Web Vitals include Time to First Byte (TTFB) as a contributing factor to Page Experience signals, and redirect chains work directly against it.
How to find redirect chains on your site
The tricky thing about redirect chains is that they're invisible during normal browsing. Your browser follows each hop automatically and shows you the final page — you'd never know there were three steps in between. There are a few reliable ways to uncover them:
Use a site scanner (the easiest way)
A dedicated crawler like Broken Link Checker will crawl your site, follow every redirect, and flag any URLs that involve more than one hop. This is by far the most efficient approach for sites with more than a handful of pages — manually checking URLs one by one simply doesn't scale.
When scanning, look for results flagged as redirect chains rather than just redirect (301). A single 301 is expected and harmless. A chain of two or more hops is what needs fixing.
Check individual URLs in your browser's DevTools
If you suspect a specific URL has a chain, open Chrome DevTools (F12), go to the Network tab, and type the URL into your address bar. Filter by "Doc" and look at the entries — you'll see each redirect hop listed as a separate request with its status code. This method works well for investigating specific pages but isn't practical at scale.
Use curl from your terminal
If you're comfortable with the command line, curl with the -L flag will follow redirects and show you each hop in detail:
curl -L -I https://yoursite.com/old-page
The -I flag shows only the response headers for each hop. You'll see each HTTP status code (301, 302, etc.) and the Location header pointing to the next URL in the chain.
Pay special attention to your most important pages — your homepage, top-ranked blog posts, high-traffic product or service pages, and any URLs that have significant backlinks pointing to them. These are where redirect chains do the most damage to your rankings.
How to fix redirect chains
The fix is conceptually simple: collapse each chain into a single direct redirect from the original URL straight to the final destination. In practice, how you do that depends on your server setup.
Identify the final destination for each chain
Before touching anything, map out each chain completely: starting URL → hop 1 → hop 2 → final URL. You need the true final destination before you can create a direct redirect to it. Your scanner results will show you these chains clearly.
Update the original redirect to point directly to the final URL
In your .htaccess file, Nginx config, redirect plugin, or server rules: change the destination of the very first redirect to point straight to the final URL. Delete or disable any intermediate redirects that are now no longer needed.
Update internal links to point to the final URL directly
Even after collapsing the chain, any internal links on your own site that still point to the original URL will still trigger the (now single) redirect. It's better practice to update those internal links to point directly to the final URL — eliminating the redirect hop entirely for internal traffic.
Handle HTTP-to-HTTPS and www redirects at the server level
If your chain begins with an HTTP→HTTPS or www→non-www redirect, make sure these happen in a single server-level rule before any other application redirects fire. Many chains are caused by these canonical redirects running before an application-level redirect, adding unnecessary hops.
Re-scan to verify
After making changes, run another scan to confirm the chains are gone. It's easy to accidentally leave an intermediate redirect in place, or to discover that your CMS regenerated one automatically.
Example: fixing a chain in .htaccess
Suppose your scanner found this chain:
/blog-post → /2019/blog-post → /articles/blog-post → /content/blog-post
Your .htaccess probably has three separate rules stacking on each other. Collapse them to one:
Redirect 301 /blog-post /content/blog-post Redirect 301 /2019/blog-post /content/blog-post Redirect 301 /articles/blog-post /content/blog-post
Now all three starting URLs go directly to the final destination in a single hop. The intermediate URLs are gone from the chain — but they still redirect cleanly in case anyone has them bookmarked or linked.
A quick note on redirect loops
A redirect loop is the worst-case version of a chain: URL A redirects to URL B, which redirects back to URL A. Browsers detect these immediately and show an error ("This page isn't working — too many redirects"). Google simply cannot index the affected page at all.
Loops are usually caused by misconfigured .htaccess rules, conflicting plugin settings, or a server-level rule that catches the redirected URL and sends it back. If your scanner reports a redirect loop, prioritise fixing it above everything else — those pages are completely inaccessible to both users and search engines until the loop is broken.
Preventing redirect chains going forward
Once you've cleaned up existing chains, a few habits will prevent them from creeping back:
- Always redirect to the current final URL. When a page moves again, update the existing redirect rather than adding a new one pointing to the interim location.
- Audit after every migration. Any URL structure change, platform move, or domain switch is a chain-creation event. Scan immediately afterwards.
- Keep a redirect map. A simple spreadsheet of old URL → new URL, maintained every time you add a redirect, makes it easy to spot when a new redirect would create a chain.
- Handle canonical redirects at the server level. Your HTTPS and www/non-www redirects should be handled by your web server (or CDN), not by your CMS, so they never stack with application-level redirects.
- Schedule regular scans. Even careful sites accumulate redirects over time. A monthly crawl will catch chains before they compound.
One well-placed 301 redirect is a completely healthy and expected part of running a website. The goal isn't to eliminate all redirects — it's to make sure each redirect goes directly to its final destination in a single hop, with no unnecessary stops along the way.
Summary
Redirect chains are a slow drain on your site's SEO performance. They waste crawl budget, dilute the link equity flowing to your best pages, and add unnecessary latency for every visitor who clicks an affected link. The good news is that they're completely fixable once you know where they are.
Start with a full-site scan to map every redirect chain on your domain. Prioritise the chains affecting your most important pages — homepages, high-traffic posts, pages with significant backlinks. Collapse each chain into a single direct redirect, update your internal links, and make a habit of auditing after any URL change. Done consistently, this is one of the higher-impact technical SEO improvements you can make with a relatively small amount of effort.