Redirect chain checker

A four-hop chain, taken apart

This is the shape that turns up after a site has had two or three owners. Each rule made sense when someone added it:

1. 301  http://www.example-shop.com/sale    -> https://www.example-shop.com/sale
2. 301  https://www.example-shop.com/sale   -> https://example-shop.com/sale
3. 302  https://example-shop.com/sale       -> https://example-shop.com/sale/
4. 200  https://example-shop.com/sale/

Hop 1 is the host's "force HTTPS" switch. Hop 2 is a CDN rule that drops www. Hop 3 is the CMS adding a trailing slash, and it uses a 302 because that is the framework default. None of them is wrong alone. Together they mean three extra requests, and the 302 tells Google the final URL might be temporary.

The checker marks it "Worth fixing". Its notes name each problem: three redirects where one would do, a temporary code at hop 3, the host dropping www after the HTTPS switch, and a trailing slash added at the very end. The fix:

• Send every variant straight to https://example-shop.com/sale/ with one 301. That means the HTTPS rule and the www rule live in the same place and build the final URL in one step.
• If the trailing slash rule has to stay for other URLs, make it a 301 or 308. For this URL it never fires, because the first redirect already lands on /sale/.
• Change internal links, the canonical tag, hreflang and the sitemap to the final URL, so the redirect only catches old outside links.

ToolPetal had a smaller version of this. A request for https://www.toolpetal.com/page.html got a 301 to the apex and then a 308 to strip .html. One rule now does both in a single 301. The plain http://www form still takes two hops, because Cloudflare's own HTTP to HTTPS upgrade answers before that rule runs. The second sample button above shows it: a chain that works, and one hop longer than it needs to be.

301, 302, 303, 307 and 308 side by side

The checker marks 301 and 308 hops green and 302, 303 and 307 hops amber. Amber is not an error, but for a page that moved for good, it is the wrong code.

What a long chain actually costs

Google has said that 3xx redirects do not lose PageRank, so the old fear of a percentage lost per hop is out of date. The real costs are plainer:

• Every hop is another request before the page starts loading. When the host changes, it can also mean another DNS lookup and TLS handshake. On a slow phone connection that is visible.
• Googlebot stops at 10 hops. Long chains rarely get there, but a loop always does, and the URL drops out of the index with a redirect error.
• Each rule is a place for the next person to make a loop. Two rules that disagree about a trailing slash or www are the usual cause.
• Temporary codes in the chain blur which URL is the one to index. Google may keep showing the old URL.

Collapsing a chain at the source

The goal is one rule that knows the final scheme, host and path. On Nginx, give the variants their own server blocks and redirect to the final host with the path intact:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example-shop.com;
    # ssl_certificate lines for www go here
    return 301 https://example-shop.com$request_uri;
}
server {
    listen 80;
    server_name example-shop.com;
    return 301 https://example-shop.com$request_uri;
}

On Apache, one condition block catches both plain HTTP and www, so neither needs a second hop:

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

On a CDN, the trap is a scheme setting in one layer and a host rule in another, each adding its own hop. Put both into one redirect rule in the same layer, or turn one of them off. Page-level moves in a _redirects file (Cloudflare Pages, Netlify) should point at the final URL, not at another old one:

/old-sale   /sale/   301
/summer     /sale/   301

Then run the variants button and the list mode again. All four host variants should end at the same URL with one hop each, or zero for the preferred one.

What the checker cannot see

• JavaScript redirects. The page is not rendered, so window.location and framework router redirects are invisible. Google renders pages and can follow them, but its own docs say to use them only when a server-side redirect is not possible.
• Meta refresh is detected, not followed. Only the final page's first 64 KB is scanned. A Refresh response header is reported the same way.
• It is one request from a Cloudflare datacenter, as ToolPetalBot, with no cookies. Sites that redirect by country, language, device, login state or bot rules can send you or Googlebot somewhere else. A 403 at the end usually means the site blocked the bot.
• No HSTS memory and no cache. Your own browser may skip the http hop or replay a cached 301, so it can show fewer hops than this.
• The # part of a URL is never sent to a server, so redirects cannot see or keep it. Browsers carry it over on their own.
• Public hosts on ports 80 and 443 only. A redirect to a private or internal address is refused and the chain stops there.
• 10 hops, 8 seconds per URL, 20 checks a minute, 10 URLs per list. A small set of headers is kept per hop (server, cache, HSTS); use the HTTP header checker for all of them.

Questions people ask