Redirect chains: how to find and fix extra hops

Imagine someone following an old http:// link to your homepage. The server first sends them to HTTPS, then adds www in a second redirect. I tested 1,000 domains selected from Tranco's top 100,000. Of 683 reachable domains, 327 had at least two redirects in one of four tested homepage-address variants.

That result describes the tested URLs, not the share of real visits affected. I'll show you why these chains appear, how to inspect your own redirects and how to send each old address directly to its intended destination. The measurements and scripts are described in the research pack.

What is a redirect chain?

A redirect chain occurs when a request follows two or more consecutive HTTP redirects before reaching its destination. A 301 means a permanent move, while a chain can also contain other redirect status codes. To shorten a chain, configure the old URL to point directly to the final relevant URL and update internal links.

A typical chain is http://example.com → https://example.com → https://www.example.com. That's two hops, and each one is a separate round trip between the browser and the server before the first byte of the real page arrives. A redirect loop is different: it repeats an address and can end in a “too many redirects” error.

327 of 683 reachable sites had a multi-hop address variant

I tested four homepage variants per domain: http:// and https://, each with and without www. Among the 683 domains reachable under the test conditions, 327 had a chain of at least two redirects for one or more variants. The chart counts chains rather than domains: 190 of 483 recorded multi-hop chains changed the protocol first and www second.

The http:// versions still matter. Old external links, bookmarks and printed materials can contain explicit HTTP URLs, and crawlers may discover them too. Typing example.com is a poor test of the HTTP path because modern browsers can try HTTPS first.

A frequent cause is split configuration. The hosting panel or CDN enforces HTTPS, while another rule adds or removes www. Each setting may be sensible on its own, but together they create two HTTP hops. Check which layer issues each response, then make the rules agree on the final URL.

Why extra redirects cost time

Each redirect sends another request before the browser can fetch the destination document. That increases document-request latency, especially on high-latency connections. A host change can also require DNS or TLS work when an existing connection cannot be reused.

These requests happen before the final HTML arrives, so image or script optimisation cannot remove their network cost. In Lighthouse 13 and later, redirect delays are covered by the Document request latency insight; the old standalone redirects audit was retired. See the Lighthouse 13 release notes.

Googlebot can follow short redirect chains, but that alone does not guarantee indexing. Google recommends redirecting directly to the final destination during site moves. The practical reasons to shorten chains are simpler crawling, clearer URL signals and less avoidable work for visitors.

Two homepage addresses create a second problem

In the sample, 124 sites served a homepage response on both the www and bare-domain addresses without redirecting one to the other. In 85 of those cases, the test did not find a canonical tag specifying a preferred version.

Google can choose a canonical URL using other signals even without a rel="canonical" tag. If both addresses represent the same page, choose one preferred host and redirect the other to it. Keep internal links, sitemaps and canonicals on that same host. See the related guide to canonicals, sitemaps and robots.txt.

Where redirect chains come from

A chain is rarely built on purpose. Usually it is two reasonable decisions made in different places or at different times:

• An HTTPS switch in the panel plus a separate www rule.
• A CMS plugin plus a server rule.
• A move to a new domain where the old HTTP address redirects before the new domain redirects to HTTPS.
• A trailing-slash rule that runs after the HTTPS redirect.

Check which layer creates each hop, then point the source URL directly at the final destination. The fix may involve one rule or several coordinated rules, depending on the hosting stack.

How to check redirects in a minute

The quickest way is the redirect checker. Paste in the four versions of your address: http://, http://www., https:// and https://www.. The tool shows every hop with its response code and Location header.

In Chrome, open DevTools → Network and enable Preserve log. Navigate to an explicit URL such as http://example.com, then inspect the status codes and Location headers. Browser HTTPS upgrades, cached permanent redirects and HSTS can hide the server's HTTP path, so cross-check with a command-line request:

curl -sSIL --max-redirs 10 http://example.com | grep -iE "^(HTTP|location)"

Count the 3xx responses, not the final 200. Aim for no redirects on the canonical URL and, where practical, one hop from each alternate variant. -I sends a HEAD request, which some servers handle differently from GET. Verify the same route with GET before changing production rules, and test representative paths and query strings too.

301 or 302: which redirect should you use?

301 and 308 indicate a permanent move. 302 and 307 indicate a temporary one. Google uses permanent redirects as stronger canonicalisation signals, though no redirect guarantees which URL will be indexed.

For forms and APIs, the request method also matters. 308 preserves it, while a 301 can change POST to GET in some clients. See MDN's reference for HTTP 301.

For a lasting HTTP-to-HTTPS or host change, use 301 or 308. Use 302 or 307 for a genuinely temporary change. A temporary outage may need 503 Service Unavailable, not a blanket redirect.

How to collapse a redirect chain into one hop

1. Pick one final address. With or without www makes no SEO difference, so choose the host most of your existing links already use.
2. Send each source URL directly to its appropriate destination. Preserve its path and relevant query parameters when they still identify the same content.
3. Use 301 or 308 for a permanent change.
4. Test all four versions again. Every version other than the final one should take exactly one hop.

For nginx, these illustrative blocks send HTTP and the bare domain straight to https://www.example.com:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

For Apache, use one rule that checks both the scheme and host:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

If TLS terminates at a CDN or reverse proxy, verify what the origin sees before changing the rule. A scheme mismatch between the CDN and origin can create a loop. On Cloudflare, check Single Redirect rules, Always Use HTTPS and the SSL/TLS mode, then test deep links as well as the homepage.

Fix links, sitemaps and canonicals after the redirect

Your own site should point directly to the final address. Update internal links, the XML sitemap, canonical tags and hreflang annotations so they do not target a URL that immediately redirects.

Once HTTPS works reliably, consider HSTS. A browser that already knows the policy can upgrade HTTP before making a network request, but other clients can still request http://. Review how HSTS works before opting into preload.

The research exposed a blind spot in CometWeb Insight: checking only the HTTP bare-domain entry could miss chains on other variants. I updated the Crawl host-variant checks and added regression tests for all four homepage entries. The broader crawl can also find links that still target redirected URLs. You can explore CometWeb Insight after checking your homepage with the free redirect checker.

Final thoughts

The homepage is straightforward to inspect, but it is only the entry point. Check deeper URLs and make sure your links, sitemap, canonicals and hreflang point directly to the correct destinations.

Start with the four homepage variants in the redirect checker. If one has two or more hops, identify which layer creates each one, change the rules in a test environment and recheck representative paths. The goal is a direct, correct destination.

Frequently asked questions

Sources

1. Google: How HTTP status codes affect Google's crawlers.
2. Google Search Central: Redirects and Google Search.
3. Google Search Central: Site moves with URL changes.
4. Chrome for Developers: What's new in Lighthouse 13.
5. HSTS preload list.
6. CometWeb: redirect chains on 1,000 popular domains.
7. WordPress: Giving WordPress Its Own Directory.