scalpel@labs: ~/glossary/302-redirect.mdx5 sections

302 redirect

A 302 tells the client a resource is temporarily at the URL in the Location header. Browsers don't cache it by default, and search engines usually keep the original URL as the canonical one.

extension: Scalpel Redirectsupdated: 2026-08-14read_time: 2 min
less 302-redirect.mdx

Why it matters

The 302's reputation ("it loses your PageRank") is just wrong. Google states all 3xx redirects pass signals. The real concern is canonicalisation. A long-lived 302 can leave the wrong URL in the index if Google decides to index the target instead. But the real win is reversibility. Because it isn't cached by default, a 302 is the safe way to stage, A/B test, or trial a move before hardening it to a 301.

How it works

When a browser receives a 302, it fetches the Location header and makes a new request there. Unlike a 301, it doesn't cache the redirect. So the next visit goes back to the original URL and receives the 302 again. Search engines treat a 302 as temporary and usually keep the original URL as the indexed version. If the 302 stays in place for weeks or months, Google may eventually consolidate onto the target, but the signal stays tied to the original.

RFC 9110 permits clients to rewrite POST to GET when following a 302; most browsers do this. That makes the 302 convenient for form handlers that need to land on a results page without resubmitting the data.

What doesn't matter

A 302 doesn't incur a ranking penalty. All 3xx status codes pass ranking signals in Google's systems. Countless permanent moves use 302 in staging, and ranking doesn't degrade. The cost of a long-lived 302 is pragmatic, not algorithmic. Searchers may see either URL in results, and the wrong one being indexed is confusing, not penalising.

The number of 302s in a chain isn't itself a problem. Chains are costly because of latency and crawl budget, not because of the specific status codes. Collapse them to improve real speed, not out of fear of a ranking loss.

Code example

Use a 302 while testing or staging a change before making it permanent.

return 302 https://new-url.example.com$request_uri;

Once you've confirmed the move is correct, convert it to a 301:

return 301 https://new-url.example.com$request_uri;

Here's the difference in response headers.

HTTP/1.1 302 Found
Location: https://new-url.example.com
Cache-Control: no-cache

versus:

HTTP/1.1 301 Moved Permanently
Location: https://new-url.example.com

The 302 carries Cache-Control: no-cache by default, so browsers don't cache it. A 301 is cacheable by default.

How Scalpel shows it

A 302 hop renders with an amber status chip and a "302 Found" connector. If you've left a 302 in place for weeks pointing to the same target, Scalpel flags it with a hint suggesting it should become a 301 instead.

Sources