How Many Redirects Does Your Homepage Actually Take?

Quick answer: a surprising number of sites don't redirect straight to their final homepage, they hop through two, three, or more intermediate redirects first, one for forcing HTTPS, another for adding or removing "www," another left over from a migration a few years back. Each of those hops is a full round trip, and none of it is visible to a normal visitor, since browsers follow the whole chain silently in the background before showing you anything. You can see your own chain in one line: run curl -IL https://yoursite.com and read the full sequence of status codes it prints back.

Nobody notices this by browsing their own site, because browsing doesn't show you the hops, it only shows you the destination. The chain builds up slowly, one redirect rule added at a time over years of small changes, and nothing about using the site ever points back at it.

In short: every redirect hop is a separate request and response, not a free pass. A chain that's grown to three or four hops is adding real, measurable latency on every single load, and it's worth checking directly rather than assuming your redirects are clean.

What a Redirect Chain Actually Looks Like

A single redirect is normal and fine: a browser asks for one URL, the server says "actually, go here instead," and the browser follows that instruction once. A redirect chain is what happens when that destination is itself another redirect, which points to another, before finally landing on a page that actually responds with content.

A fairly ordinary-looking chain might go: http://example.com redirects to https://example.com, which redirects to https://www.example.com, which redirects to https://www.example.com/ with a trailing slash, before the server finally returns the homepage. That's three redirects before a single byte of the actual page arrives, and each one happened as its own separate request.

Where These Chains Actually Come From

They're almost never built on purpose. They accumulate from a handful of common, individually reasonable decisions:

Protocol and host normalization stacked instead of consolidated. Forcing HTTPS is its own rule. Adding or removing "www" is often a separate rule, sometimes enforced by a different layer entirely (your DNS provider or CDN forces HTTPS, while your CMS or application forces the www version). When each rule redirects to the next rule's input instead of straight to the final form, you get a chain instead of a single hop.

Redirects left over from past migrations. When a site moves to a new URL structure, the old URLs get redirected to whatever the new structure was at the time. The next time the site migrates, old links often get pointed at the previous new structure instead of the current one, so a visitor following an old link now passes through two migrations' worth of redirects instead of landing directly on today's URL.

Marketing and tracking links adding their own hop. A link from an email campaign, an ad platform, or an affiliate tool often already redirects through that platform's own tracking domain before it ever reaches your site, and then your site's own redirect rules run on top of that.

Small normalization rules layered over time. Trailing slashes, uppercase versus lowercase paths, an old /index.html suffix, each one usually gets added as a new rule rather than being folded into the existing one, and each addition is one more hop for requests that trigger more than one of them.

Why Each Hop Has a Real Cost

Every redirect is a full request and response cycle. The browser has to send the request, wait for the server's reply, then start over with the new URL. On a fast connection this can feel instant, but it's not free, and it compounds exactly the way any added network round trip does, worse on a slower mobile connection than on the fast desktop connection most people test from.

It also matters to crawlers, not just human visitors. Google's own crawling documentation describes a limit on how many redirect hops its crawler will follow in a single attempt, commonly cited as up to ten, after which it stops and Search Console reports it as a redirect error rather than successfully reaching the page. Staying under that limit doesn't mean a chain is free, though. Every additional hop still adds delay and complexity to how a crawler processes that URL, even well within the limit.

How to Check Your Own Links

You don't need a crawling tool to see this. A single terminal command shows you the entire chain for any URL:

curl -IL https://yoursite.com

This follows every redirect and prints the status code and headers for each hop in order, so you can count exactly how many there are and see what each one points to. If you'd rather see it visually, open your browser's DevTools, go to the Network tab, enable "Preserve log," and reload the page, every intermediate redirect shows up in the request waterfall before the final page loads.

It's worth checking more than just your homepage. Check the links in your main navigation, the URLs in any active email or ad campaigns, and any older URLs you know still get backlinks or traffic, since those are often the ones that have accumulated the most hops over time.

Fixing It

The fix is almost always the same: point every redirect rule directly at the final destination instead of at another redirect. If HTTPS, the www version, and a trailing slash are all meant to end at the same canonical URL, that should be one rule with one hop, not three separate rules chained together. For migration-era redirects, it's worth periodically updating old rules to point straight at the current URL rather than at whatever the "new" URL was during the last migration, so visitors following an old link don't pay for every migration since.

None of this requires touching your actual content or page structure, it's a configuration fix in whatever layer handles your redirects, your CDN, your DNS provider, or your CMS. A free infrastructure check can surface chains like this across more of your site's pages than you'd want to check one curl command at a time.

Final Thoughts

Redirect chains aren't the kind of problem that announces itself. The site works, pages load, visitors get where they're going, and nothing in normal use ever shows you the hops happening underneath. That's exactly why they're worth checking on purpose instead of assuming they're clean.

The fix, once you find a chain, is almost always small: point the rule at the real destination instead of at another redirect. It's a few minutes of configuration work for a cost that's been quietly adding up on every single page load.

If you haven't checked your own homepage's redirect chain recently, especially if your site has been through a migration or two, it's worth running that one curl command today.