A redirect chain is what you get when one URL sends visitors to a second URL that then sends them somewhere else again, before the page they wanted finally loads. They are easy to create by accident and easy to ignore, because the page still opens at the end of the trip.
This is a practical guide to finding every chain on your site, flattening it down to a single hop, and, just as important, deciding which chains are actually worth your time. I will show you two real chains on my own site, and I will be honest about one number the whole internet repeats that does not hold up.
Key Takeaways
- A redirect chain is one URL that redirects to another that redirects again before a page finally loads; each step is a “hop”.
- The real cost of a chain is crawl and speed, not a special per-hop loss of link equity; that widely quoted percentage has no primary source behind it.
- Google’s John Mueller has said to keep chains under five hops for frequently crawled URLs, because Googlebot follows up to five per crawl attempt; the ideal is a single hop.
- Find chains with a
curl -sILrequest, a free redirect checker, your browser Network tab, or a crawler like Screaming Frog. - Flatten any chain by pointing the very first redirect straight at the final URL.
- Fix the chains you control first: internal links, sitemap URLs, canonicals, and your own mis-targeted redirects; external backlink chains you handle by keeping your side to one hop.
What is a redirect chain, and how is a redirect loop different?
A redirect chain is a single URL that redirects to another URL, which itself redirects again, before a final page returns a 200 OK. Each redirect in that path is called a hop, so a two-hop chain passes through two redirects before the real page loads. A redirect loop is the broken version of the same idea: the path points back on itself and never reaches a real page, which is what throws the ERR_TOO_MANY_REDIRECTS error you sometimes see in a browser.
Chains usually appear quietly. You change a URL slug, you switch the site to HTTPS, you move to a new domain, and a new redirect gets stacked on top of an old one. Most of the time the page still loads fine at the end, so nobody notices; the cost sits under the hood where you have to go looking for it.
If you are not sure how a 301 differs from a 302, I cover the difference between the redirect status codes in a separate guide. This piece assumes you know that much, and spends its time on chains: finding them, fixing them, and knowing which ones matter.
Do redirect chains actually hurt your SEO?
Yes, chains can hurt, but not in the way most guides say. They slow the page for real users, and they make Google work harder to reach your final URL, so you do want them flattened. What they do not do is leak a fixed percentage of your link equity at every hop, and that distinction changes which problems you should actually chase.
Here is the claim to watch out for. A lot of ranking guides repeat a specific number, that a redirect bleeds around 5% of your link equity per hop. I went looking for a primary source for it, and there is not one. It travels from post to post because it sounds precise, but no Google statement backs it, so it does not go on this page as a fact.
Google’s own people have actually addressed this directly. Asked whether redirect chains lose link equity, Google’s John Mueller
John MuellerSearch Advocate, GoogleGoogle's Search Advocate and the main on-the-record voice of Google Search Relations.LinkedInXSearch Central said back in 2018 that “for the most part that is not a problem. We can forward PageRank through 301 and 302 redirects.” On chains specifically, he put it this way:
In that sense it’s not a matter of link equity loss across redirect chains, but more a matter of almost usability and crawlability. Like, how can you make it so that Google can find the final destination as quickly as possible?
John Mueller, Google, 2018
Matt Cutts
Matt CuttsFormer Head of Webspam, GoogleMatt Cutts is a software engineer who led Google's webspam team and was Google's best-known public voice on SEO for years before leaving in 2017 to run the US Digital Service.mattcutts.com@mattcuttsWikipedia, back when he led Google’s webspam team, put the single-redirect case even more plainly in 2013: “The amount of PageRank that dissipates through a 301 is almost exactly, is currently identical to the amount of PageRank that dissipates through a link.”
So read those two together and the picture is clear. A 301 does not carry a special hop tax; it dissipates roughly what a normal link does.
A chain’s real damage is that every extra hop is another round trip, sometimes another DNS lookup to a new host, which Mueller specifically said hurts most on mobile. Treat chains as a speed and crawl problem, not an equity leak, and you will spend your effort on the right things.
There is one honest caveat, and it is the equity risk that is actually real. A 301 only passes value when it points at a closely matching page.
Mueller has also said that “301-redirecting for 404s makes sense if you have 1:1 replacement URLs, otherwise we’ll probably see it as soft-404s and treat like a 404.” Redirect an old page to something unrelated, or dump everything onto the homepage, and Google can treat it as a soft 404 that passes nothing. That, not the per-hop myth, is the equity loss worth guarding against.
How many redirects is too many?
Aim for one hop, and treat five as the ceiling for any URL Google crawls often. The most cited figure here comes from Mueller, who said in 2020 to keep frequently crawled URLs under five hops, because Googlebot follows “up to 5 hops in the chain per crawl attempt.” Go past that in a single crawl attempt and Googlebot may not land on your final URL at all that time around.
You will also see people say Google’s documentation states a 10-hop limit. I read Google’s current redirects documentation (last updated April 2026) and it does not state any hop number, and no equity percentage either. It explains the redirect types and how they signal a canonical, and that is it.
Older versions of Google’s guidance did mention following at least 10 hops, but the current doc dropped that line, so the defensible number today is Mueller’s: under five, and ideally just one.
How to find redirect chains on your site
The fastest way to see a chain is a single command. Run curl -sIL followed by the URL, and it will follow every redirect and print each hop, so you can read the whole path at a glance. The flags are simple: -s keeps it quiet, -I asks for headers only (not the full page), and -L tells curl to follow the redirects instead of stopping at the first one.
If you would rather not touch a terminal, you have a few other ways to find chains, and each one shows you the same thing from a different angle:
- A free online checker like wheregoes.com or httpstatus.io: paste a URL and it maps the hops for you. This is the fastest route for a one-off check, and it is exactly what the “redirect chain checker” tools are built for.
- Your browser Network tab (open Chrome DevTools, go to the Network panel, and load the URL) or the Redirect Path extension: both show the same 301, 301, 200 sequence in a visual list, which helps if you prefer a GUI over a command line.
- A site crawler like Screaming Frog for a whole-site sweep: its Redirect Chains report lists every chained URL on the site at once, so you are not checking pages one by one. This is the tool to reach for on anything larger than a handful of pages.
A real audit: two live redirect chains on our own site
Here is what the audit looks like in practice. I ran curl -sIL against my own site and found two real chains, both two hops, and both fixable. Every header line below is the actual output, not a mockup.
The first is the classic one almost every site has: someone types the bare http:// address with no www, and the server normalizes the protocol and the host in two separate 301s instead of one.
$ curl -sIL http://wpconsults.com/
HTTP/1.1 301 Moved Permanently # hop 1: http to https, still non-www
Location: https://wpconsults.com/
Server: LiteSpeed
HTTP/2 301 # hop 2: non-www to www
location: https://www.wpconsults.com/
server: LiteSpeed
HTTP/2 200 # final page, served from the LiteSpeed cache
x-litespeed-cache-control: public,max-age=604800
server: LiteSpeedTwo hops to reach the canonical URL. That is the single most common chain on the web, and it happens because the naked http:// plus non-www entry point has to fix two things, the protocol and the host, and the server does them one at a time. (For what it is worth, that server: LiteSpeed line is our real stack, a LiteSpeed page cache, not Cloudflare.)
The second chain is more interesting, because it is a mistake I made myself, and it is the kind you will find on your own site once you start looking. When I re-slugged an old post from seo-for-moving-company-website to seo-for-moving-companies, the redirect I set pointed at the version with no trailing slash, so WordPress adds a second 301 of its own just to put the slash back.
$ curl -sIL https://www.wpconsults.com/seo-for-moving-company-website/
HTTP/2 301 # hop 1: old slug to new slug, no trailing slash
location: https://www.wpconsults.com/seo-for-moving-companies
HTTP/2 301 # hop 2: WordPress appends the trailing slash
location: https://www.wpconsults.com/seo-for-moving-companies/
HTTP/2 200 # final pageThat second hop is completely avoidable. The fix is exactly this article’s thesis: point that first redirect straight at seo-for-moving-companies/ with the trailing slash, and the chain collapses to a single hop.
For contrast, here is what a clean redirect looks like. Enter with the correct host and only the protocol upgrade fires, which is one hop, exactly what you want:
$ curl -sIL https://wpconsults.com/
HTTP/2 301 -> location: https://www.wpconsults.com/ # one hop, correct
HTTP/2 200
$ curl -sIL https://www.wpconsults.com/
HTTP/1.1 301 Moved Permanently -> https://www.wpconsults.com/ # one hop, correct
HTTP/2 200So the site is mostly clean. The chains only show up at the naked-http plus non-www corner and on that one mis-targeted old slug. That is usually how it goes: a site is not riddled with chains, it has a handful in predictable spots, and once you can see them the fix is quick.
How to flatten a redirect chain
Flattening a chain is really one move: point the very first redirect straight at the final 200 URL, so the whole path becomes a single hop. Everything else is just finding the start and the end of the chain reliably.
Flattening a redirect chain
- Map the full chain with curl -sIL or a checker
- Note the very first URL and the final 200 URL
- Repoint the first redirect straight at that final URL
- Re-test until you see one 301, then 200
Take our post from a moment ago as the worked example. The old-slug rule currently targets seo-for-moving-companies with no slash, which is what forces WordPress to add the second hop.
Change that single rule to target seo-for-moving-companies/ with the slash, re-run the curl check, and you should see one 301 followed by a 200. That is the entire fix, and it is representative of almost every chain you will meet.
Which redirect chains actually matter (and which to leave)
Not every chain is worth fixing, and “fix everything” advice quietly burns time on the ones you cannot control. The chains that cost you are the ones inside your own site and your own crawl path. The ones you mostly cannot control are external backlinks pointing at an old URL that now chains, and the honest answer there is to fix your side, not chase the person who linked to you.
| Chain type | In your control? | Why it matters | The one fix |
|---|---|---|---|
| Internal links pointing through a redirect | Yes, fully | Every internal click and every Googlebot hop travels the chain, wasting crawl and slowing users | Update the link to point at the final live URL |
| Sitemap URLs that 301 | Yes | You are handing Google a list of redirects to crawl instead of real pages | List only final 200 URLs in the sitemap |
| Canonical tags pointing at a redirect | Yes | You are naming a redirecting URL as the canonical, which is a mixed signal | Set the canonical to the final URL |
| Your own mis-targeted redirects (like our old slug) | Yes | Your redirect points at a URL that redirects again, a chain you built | Point the redirect straight at the final URL |
| External backlinks to an old URL that chains | Mostly no | You cannot edit someone else’s link | Keep your side one clean hop so the chain stays short |
The internal-link row is the one people skip, and it is the highest-value fix on the list, because you are sending both readers and Googlebot through a hop on every single click. Fixing it is the same muscle as any internal linking audit: find the links that point at a redirecting URL and repoint them at the live one.
How to fix redirect chains at scale
On a large site you do not fix chains URL by URL; you fix them by pattern. Almost every chain falls into one of a few families, and each family has a single rule that fixes all of its chains at once:
- Protocol (http to https) and host (www vs non-www): set both to resolve in a single 301 at the server or CDN level, so the naked-http chain from earlier becomes one hop instead of two.
- Trailing slash and letter case: pick one canonical form and enforce it in one rule, rather than letting a mis-targeted redirect and the CMS argue over it.
- Old-slug families from past migrations: these are where most real chains live, since a site migration stacks a fresh set of redirects on top of the old ones. Map old URLs straight to their final destinations in one pass.
You can manage all of this from a redirects tool like the Rank Math Redirections module, the dedicated Redirection plugin, or straight in your server config with .htaccess or Nginx rules. Whichever you use, the discipline is the same: change the rule, not the individual URLs, and re-test with curl afterward so you know the chain is really gone.
So, how worried should you be about redirect chains?
Honestly, less worried than the scary per-hop numbers want you to be, but not careless either. A chain will not quietly drain a fixed slice of your rankings at every hop; that number was never real, and Google’s own people have said as much. What a chain does do is slow real users and make Google work harder to reach your pages, and that alone is reason enough to keep things tidy.
If this were your site, I would spend the time where it pays: flatten the chains inside your own control, the internal links, the sitemap, the canonicals, and your own mis-targeted redirects like the one I just showed you, aim for a single hop everywhere, and stop losing sleep over an external backlink chain you can only half fix. Clean redirects are cheap insurance. Chasing an imaginary equity tax is not.
Common questions about redirect chains
Do redirect chains slow down page speed?
Yes. Each hop is another round trip, and sometimes another DNS lookup when the redirect crosses to a new host, which Mueller specifically said hurts most on mobile. On a fast desktop connection it is milliseconds, but on mobile a multi-hop chain is noticeable, so keep it to one hop.
Can a CDN cache my redirect?
Yes. A CDN or page cache can store a 301 at the edge, so a redirect you already fixed can keep firing until that cache clears. If a chain refuses to go away after you fix the rule, check whether your CDN is caching the old response.
Does a chain of 301s lose more link equity than a single 301?
Not in the way the “5% per hop” claim suggests. Google’s position is that a 301 passes signals much like a normal link, and a chain’s real cost is crawl and speed, not a stacked equity tax. Still, keep chains short so Google reaches the final URL in one crawl attempt.
Need a hand untangling your redirects?
If you are cleaning up years of messy redirects or migrating a site and want a second pair of eyes, work with WpConsults or email me directly. A clean redirect map is one of the cheapest ways to protect rankings you already earned.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
