301 Versus 302 and What Each Does to Link Equity
Four status codes do redirects: 301, 302, 307 and 308. Two of them matter for most SEO work, and the difference between those two is smaller than folklore suggests and larger than “it doesn’t matter.”
Here’s the mechanical picture.
What the codes mean
These semantics come from the HTTP specification, and they’re about permanence and method preservation:
| Code | Meaning | Method on the follow-up request |
|---|---|---|
| 301 | Moved Permanently | May be changed to GET |
| 302 | Found (temporary) | May be changed to GET |
| 307 | Temporary Redirect | Must be preserved |
| 308 | Permanent Redirect | Must be preserved |
The 307/308 pair exists because clients historically converted POSTs to GETs when following 301s and 302s, and the spec needed codes that forbid that. For a redirect on a GET-only content URL — which is nearly every redirect an SEO configures — 307 behaves like 302 and 308 like 301.
That’s the spec. How a search engine treats these codes is a separate question, documented separately by each search engine, and it’s the one that matters here.
How crawlers treat them
The short version, as documented by Google and consistent with observed behaviour: both permanent and temporary redirects are followed, and both pass signals. The difference is in which URL ends up in the index.
- A permanent redirect (301, 308) is a strong signal to use the target as the canonical URL. Over time the source drops out of the index and the target takes its place.
- A temporary redirect (302, 307) is a signal to keep the source as the canonical URL. The content is served from elsewhere for now, but the original address is still the one that’s supposed to exist.
Two things follow that people get wrong in opposite directions.
People who think a 302 “doesn’t pass link equity” are working from outdated information. Google has stated for years that 302s pass signals. A temporary redirect left in place for a long time also tends to be treated as permanent eventually, because the observed behaviour contradicts the declared intent.
People who conclude from that “so it doesn’t matter which you use” are also wrong. It matters for canonicalisation. If you permanently moved a page and served a 302, you’re telling the index to keep the old URL indexed — which means the old URL is what appears in results, and any future change to it has to be handled again.
The rule is simple and it’s about honesty rather than optimisation: use the code that describes the truth. Moved for good → 301. Temporarily elsewhere, coming back → 302.
The 85% figure
Somewhere in your reading you’ve encountered a claim that a 301 passes 85% of link equity, or 90%, or “loses about 15%.”
That number has no source. It appears to originate in a much older discussion of how PageRank damping applied to links generally, got attached to redirects, and has been repeated ever since with increasing confidence and decreasing provenance. Google has publicly stated that it does not lose PageRank through 3xx redirects.
The honest position, and the one this site takes: redirects pass signals; no search engine publishes a decay fraction; anyone quoting one is quoting folklore.
This isn’t pedantry about a small number. It changes decisions. Teams have declined to fix URL structures on the grounds that “we’d lose 15% each time,” which is a plan built on a figure nobody can attribute.
What is worth minimising is chains — not because of a per-hop tax, but for latency, crawl efficiency, and the fact that long chains break in ways short ones don’t. That’s a separate mechanism, covered in redirect chains and how to flatten them.
Where to implement them
Same status code, meaningfully different operational properties:
Server config (nginx, Apache). Fast, close to the origin, versioned with your infrastructure. The default choice.
# nginx — single permanent redirect
location = /old-guide/ {
return 301 /guides/new-guide/;
}Edge / CDN rules. Faster still, and they work even if the origin is down or is a static host with no redirect capability. The catch is precedence: an edge rule fires before the origin ever sees the request, so an edge rule and a server rule for the same path will silently disagree, with the edge winning. This is a common source of “I fixed the redirect and nothing changed.”
Application-level. Fine, and often the only option in a CMS. Slower — you’ve booted a framework to emit a header — and easy to lose in a deploy.
Meta refresh. An HTML tag, not a status code. The response is a 200 containing an instruction to navigate. Search engines can interpret an instant meta refresh as a redirect, but it’s a weaker, slower signal and there’s no reason to choose it when you control the server.
JavaScript redirects. Same category, worse. The redirect only exists after the page renders and the script runs. Avoid where an HTTP redirect is possible.
The ordering rule to remember: the first system in the request path wins. CDN before origin, origin before application. When a redirect doesn’t behave, work out which layer is answering before you change any config.
Checking what you actually serve
Don’t infer redirect behaviour from your config file — request the URL and read the response.
curl -sIL https://example.com/old-guide/ | grep -E '^(HTTP|location)'-I sends a HEAD request, -L follows the chain, and the output gives you one HTTP/… line and one location: per hop. If you see more than two HTTP lines you have a chain. If you see a 200 where you expected a 301, something upstream is intercepting.
Worth doing on the http:// version too, and on the www/non-www variant, and with and without a trailing slash. Those four requests catch a surprising share of real problems.
The short answer
Use 301 when the move is permanent, 302 when it isn’t, and don’t lose sleep over signal decay because the numbers you’ve seen for it were invented. Spend the attention you save on chain length, on which layer is serving the redirect, and on whether the target is a genuinely equivalent page — a 301 to a category page instead of the article someone linked to is technically correct and practically a soft 404, which is its own problem.