How Much Link Equity Do 301 Redirects and Redirect Chains Really Lose?

In July 2016, Google's Gary Illyes stated directly that 30x redirects "don't lose PageRank anymore," and John Mueller confirmed the same week that this wasn't new. Google's systems had already worked this way for some time. That's real, and it's the correct starting point. What it doesn't mean is that every redirect is risk-free: chains, irrelevant destinations, and long delays before re-evaluation all still affect how much signal actually reaches the destination in practice.

Do 301 redirects lose link equity?

Not by design, and not because of the redirect type. Google's public position has been consistent since 2016: a 301 and a 302 are treated equivalently for PageRank purposes. That's a real departure from older SEO folklore, which circulated for years before the clarification and claimed redirects lost anywhere from a small slice up to a significant share of link equity, depending on which forum thread or agency blog you happened to read. There was never one agreed-upon figure behind that belief, just a persistent assumption that some value evaporated with every 301, traceable back to an ambiguous 2010-era comment about redirects not passing 100% of signal that got amplified into "digital kryptonite" territory over the following years. That framing predates Google's 2016 clarification and shouldn't be repeated as current fact. Google's own current documentation describes redirects qualitatively, as canonicalization signals that consolidate a page's ranking signals onto the destination URL, rather than publishing a specific transfer percentage.

How does redirect signal consolidation actually work?

The mechanism is more specific than the old folklore ever was, and it splits cleanly by redirect type. Google's own redirects documentation states that for a permanent redirect (a 301, a 308, or an instant meta refresh), Googlebot follows the redirect and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical. For a temporary redirect (a 302, 303, or 307), Googlebot still follows it, but the indexing pipeline does not treat it as a canonicalization signal at all.

In practice, that means a permanent redirect tells Google to fold the old URL into the same duplicate cluster as the new one and treat the new URL as that cluster's representative page going forward, the same clustering mechanism covered in canonical tags and canonicalization. Once that happens, the ranking signals already gathered about the old URL, its backlinks, its internal link context, its historical performance, get attributed to the new URL instead of sitting stranded on a page that no longer serves content. A temporary redirect never triggers that reattribution, which is exactly why using a 302 for something meant to be permanent quietly stalls signal consolidation indefinitely.

Consolidation also isn't a one-time event that fires the moment a redirect goes live. Google has to crawl the redirect, confirm it's stable rather than flickering between the old and new page, and reprocess the URL cluster before the destination reflects the full weight of what the old URL had. That's the timing factor in the table below: a redirect that went live yesterday and one that's been stable for months are both technically "a 301," but they behave differently in practice until the newer one has had time to be recrawled and reprocessed.

What actually reduces how much signal reaches the destination

The practical rule that falls out of this: a single, direct 301 to a genuinely relevant destination is the clean case Google's 2016 statement describes. Multi-hop chains, redirects to unrelated content, and expecting an instant result are the three things that actually cause the signal loss people attribute to "redirects" generically.

Does 301 vs. 302 matter for SEO?

Both get crawled the same way, and neither is treated as a spam signal. What differs is intent signaling and, as covered above, whether the redirect actually gets used to consolidate ranking signals onto the destination at all: a 301 tells search engines the move is permanent, updates the index toward the new URL, and gets used as a canonicalization signal; a 302 signals the original URL should stay canonical, with the destination treated as a temporary stand-in that doesn't inherit the old URL's signals. Use a 301 for a genuine permanent move, and a 302 only when the original URL is meant to keep its place.

301 vs. 302 vs. 307 vs. 308: the full comparison

Most sites only ever need two of these in practice. A 301 covers a permanent move where the request method doesn't matter, which is nearly every page-level SEO redirect. A 308 covers a permanent move where a non-GET request needs to keep its method, such as an API endpoint or a form-submission target. A 307 exists for the same method-preserving reason on the temporary side, and genuinely temporary situations (an A/B test, a maintenance page, geographic routing) are the only cases where a 302 or 307 is the right call at all. A 302 left in place long after the underlying situation stopped being temporary is one of the more common implementation mistakes, and it quietly prevents the destination from ever being treated as canonical.

How do I fix redirect chains?

• Map every redirect directly to its final destination: A → B → C should become A → C, not left as a chain.
• Audit for chains during any site migration, not after. They compound fastest during URL restructuring.
• Watch specifically for redirects pointing at unrelated content left over from old migrations; these are the ones most likely to be treated as soft-404s rather than genuine redirects.
• Give a new redirect time to be recrawled before concluding it "isn't working". Signal consolidation isn't instant.

How to audit your own site's redirect chains

Fixing chains starts with knowing where they actually are, and that means crawling the site the way a search engine does rather than checking redirects one URL at a time by hand.

1. Crawl with a tool that follows redirects and logs the full chain, not just the first hop. Screaming Frog's SEO Spider, with "Always Follow Redirects" enabled in its spider configuration, and Sitebulb both report a redirect's total hop count and final destination in one pass instead of stopping at the first 3xx response.
2. Filter the results to anything with two or more hops. A single 301 that lands directly on its destination isn't the problem; anything with an intermediate stop is a candidate for collapsing into a direct redirect.
3. Cross-reference against internal links, not just external backlinks. A page can carry a healthy backlink profile and still sit behind a two-hop internal chain simply because nobody updated the site's own navigation or old blog posts after a URL changed. Fixing the internal link at the source, pointing it straight at the final URL, removes the chain for crawlers and visitors alike, and it's the fix that matters more often than people expect, since internal links are entirely within a site's own control.
4. Prioritize chains sitting on pages with real authority or traffic, using whichever backlink or analytics tool is already in use. A two-hop chain on an obscure, rarely-linked page is a lower priority than the same chain sitting on a page with meaningful external links or organic traffic behind it.
5. Re-crawl after fixing to confirm the hop count actually dropped to one. A common mistake is pointing the most recent redirect in a chain straight at the final destination while leaving an even older redirect still pointing at the URL that just got fixed, which relocates the chain instead of removing it.

What about a full domain move or an HTTPS migration?

A site-wide migration (domain change, subdomain to root domain, or a long-overdue HTTP-to-HTTPS switch) is where redirect chains do the most damage, because a single mistake gets multiplied across every URL on the site rather than one page. Google Search Console has a dedicated "Change of Address" tool specifically for domain moves, which tells Google directly rather than relying on it to infer the move purely from crawled redirects. It doesn't apply to a same-domain HTTPS or subdomain change, only a genuine domain-to-domain move.

A few migration-specific failure modes worth checking for directly, since they don't show up in a single-page redirect audit:

• Redirecting everything to the new homepage instead of the matching page. A 1:1 old-URL-to-new-URL map preserves relevance; a blanket homepage redirect is exactly the "irrelevant destination" pattern covered above, applied site-wide.
• www and non-www, or HTTP and HTTPS, redirecting inconsistently across the site. If some internal links still point to the old version, every one of those clicks adds an unnecessary extra hop before landing on the canonical version.
• The old domain or subdomain's DNS or hosting getting torn down before Google has recrawled and processed the redirects. Search Console's own guidance is to keep the old setup live and serving 301s for an extended period, since re-evaluation isn't instant, and a dead redirect is worse than a slow one.

Other common redirect implementation mistakes

A few mistakes show up constantly on both single-page redirects and full migrations, and get less attention than they deserve because they're less dramatic than a broken migration:

• Redirect loops. A redirects to B, and B, through some leftover rule, a plugin conflict, or an old server config entry nobody removed, redirects back to A. Browsers and crawlers alike give up after a handful of hops, treating the whole loop as inaccessible. These are usually the result of two separate redirect rules added at different times by different people, not one single mistake.
• A client-side redirect used where a server-side one belongs. A JavaScript redirect or an HTML meta refresh can work for search engines that render pages, but Google's own guidance is direct here too: use a permanent server-side redirect whenever possible, since it's what most reliably gets both Google and real visitors to the right page without depending on a script executing correctly first.
• Redirecting a removed page to an unrelated page just to avoid a 404. Covered above as a signal issue, but it's also a usability one: a visitor looking for a discontinued product who lands on the homepage instead of a genuinely related replacement is more likely to leave than to keep browsing. If there's no good replacement, a real 404 or 410 is the honest answer, not a forced redirect (see crawl budget and log files for how a soft-404 keeps getting crawled anyway).
• A canonical tag left pointing at the old URL after the redirect goes live. The redirect and the canonical tag should agree with each other. A canonical tag still referencing a URL that now 301s elsewhere sends Google conflicting signals about which page is actually preferred, the same conflict covered in canonical tags and canonicalization.

Related: canonical tags and canonicalization, indexed but not ranking.