Redirect Checker Example: 3-Hop Chain with HTTP Codes

The chain above is worth fixing. The reason usually given for fixing it is wrong, and believing it leads people to panic about the wrong things.

Google has stated repeatedly and unambiguously that no PageRank is lost through a 301 or a 302 redirect. The idea that each hop bleeds off a percentage of authority — that a three-hop chain arrives with 85% of what it started with — is folklore. It dates from a much older era of the algorithm and it has not been true for many years. There is no decay function. There is no per-hop tax.

Read the three hops. This is not carelessness; it is three entirely reasonable decisions made at different times, by different people, each of which worked.

1. HTTP → HTTPS. Someone installed a certificate and added a rule forcing HTTPS. Correct.
2. non-www → www. Someone standardised on the www host. Correct.
3. old domain → new domain. The site migrated. Correct.

Each rule is right. Stacked in sequence they produce a three-hop chain, and nobody ever decided that. This is how essentially every redirect chain on the internet comes into existence — accumulated one sensible rule at a time.

The fix is to collapse the destinations, not to remove the rules. The first rule should point directly at the final URL, in one hop, on the canonical protocol and host:

Every hop above is a 301, which is right. The distinctions between the four codes are routinely explained in terms of link equity, which is the wrong axis. Here is what actually separates them:

That method-preservation column is the genuinely important one, and it has nothing to do with SEO. Redirect a form submission with a 301 and the request body can be silently discarded, turning a POST into a GET. If you are redirecting anything that carries data — a form, an API endpoint, a checkout step — use 307 or 308.

And the real difference between 301 and 302 for search: not equity, but which URL gets indexed. A 301 tells Google to consolidate on the destination and drop the old URL. A 302 says "this is temporary, keep the original indexed". Use a 302 for a permanent move and Google may keep showing the old URL in results indefinitely — because you told it to. That is the cost of the wrong code, and it is quite different from losing authority.

What is a redirect chain?

A redirect chain occurs when URL A redirects to URL B which redirects to URL C. Each hop adds latency and consumes crawl budget. Google follows a limited number of redirects — around ten — before abandoning the crawl for that pass. Chains of 3 or more hops should be fixed so URL A redirects directly to the final destination.

What is the difference between 301 and 302?

A 301 is a permanent redirect: it tells Google to consolidate on the destination and drop the old URL from the index. A 302 is temporary: it tells Google to keep the original URL indexed. The difference is about which URL gets indexed, not about link equity — Google has said that neither code loses PageRank. Use a 302 for a permanent move and Google may keep showing the old URL in results indefinitely, because that is what you told it to do.

Do redirect chains lose link equity?

No. Google has stated repeatedly that no PageRank is lost through a 301 or 302, and the idea that a three-hop chain arrives with 85% of its authority is folklore from a much older era of the algorithm. There is no decay function and no per-hop tax. Chains are still worth fixing, but for real reasons: latency on every hop, crawl budget spent on requests that return no content, Googlebot abandoning long chains, and the fact that every additional hop is another point of failure that can silently break the whole path.

How do redirect chains affect SEO?

Each hop is a full round trip, so latency lands directly on TTFB and therefore on LCP. Each hop is also a request Googlebot spends receiving no content, which on a large site burns real crawl capacity. And if the chain is long enough, Googlebot abandons it — which is a hard indexing failure rather than a gradual decline. The most underrated cost is fragility: a three-hop chain has three points of failure, spread across systems and years, and when one breaks it does so silently.

When should I use 307 or 308 instead?

When the request carries data. 301 and 302 permit a POST to be converted to a GET, which silently discards the request body — so redirecting a form submission, an API endpoint or a checkout step with a 301 can break it. 307 and 308 preserve the HTTP method. 308 is the method-preserving equivalent of 301, and 307 of 302. This distinction has nothing to do with SEO and everything to do with not losing data.

Can I just redirect all my old URLs to the homepage?

No. Google treats a redirect to an unrelated page as a soft 404 — it can see the destination has no relationship to what was requested, and it transfers nothing. You gain nothing over a clean 404 while losing the honest signal. Redirect to the closest equivalent page, or return a 410 and let the URL go. An irrelevant redirect is worse than an honest error.

How long should I keep migration redirects?

At least a year, which is Google's own guidance. External links to your old URLs are never updated by the people who created them, and traffic keeps arriving through those links indefinitely. Removing the redirects after a few months because the config looks untidy throws away everything the migration was designed to preserve. Meanwhile, update your own internal links to point at the new URLs directly — a redirect is a safety net for links you do not control, not a substitute for fixing the ones you do.

A checker following one URL tells you about one URL. Three habits turn that into an actual audit:

• Test with an empty cache, from outside your network. Browsers cache 301s aggressively and permanently — a 301 is a promise that the move is forever, and the browser believes you. Ship a wrong 301 and your own machine may keep obeying it long after the server has been corrected, which is why the bug you cannot reproduce is so often a redirect you fixed an hour ago. Use curl -IL, or a private window, or a different device. This is also the reason to be certain before issuing a 301: a mistaken 302 is trivially reversible, a mistaken 301 is cached on every machine that saw it.
• Test the URLs that actually receive links, not the ones in your navigation. Your homepage links are fine; the URL from an eight-year-old blog post is the one silently chaining through four hops. Pull your top linked-to pages from Search Console and run those.
• Test the whole set after any infrastructure change. A new CDN, a certificate renewal, a hosting migration, a plugin update — each can insert a hop nobody authorised. Redirect chains are almost never designed; they accumulate.