302 Redirect

A 302 redirect is a server response meaning the resource lives somewhere else for now — the client should follow the redirect this time but keep the original URL on file, because the move isn't permanent. Users can't tell a 302 from a 301; search engines absolutely can, and they make different indexing decisions based on which one you send.

Why this matters: a 302 asks Google to keep the source URL in the index and treat the destination as a stand-in. That's exactly right for a promo page or a maintenance detour. It's exactly wrong for a migration — and because 302 is the default redirect type in a depressing number of frameworks and load balancers, "temporary" redirects that were never meant to be temporary are one of the most common things I flag in audits. They can hold a completed site move in limbo for months.

Spotting a 302 and knowing whether it's intentional

Same inspection method as any status code:

curl -I https://example.com/summer-sale/

HTTP/2 302
location: https://example.com/promotions/summer-2026/

The tell that a framework issued it without anyone deciding: in nginx, a bare rewrite ... redirect emits 302, while Express's res.redirect('/target') defaults to 302 unless you pass a code. If you inherited a site, assume nobody chose the 302s on purpose until proven otherwise. Making one deliberate looks like this:

# nginx — explicit temporary redirect
location = /black-friday/ {
    return 302 https://example.com/deals/holiday/;
}

# Express — explicit, not the silent default
res.redirect(302, '/deals/holiday/');

What actually happens to a long-lived 302

The dirty secret of the 301-vs-302 debate is that a 302 left in place long enough stops behaving like one. Here's how the players treat a "temporary" redirect that never ends:

"Google figures it out eventually" is true and useless. The ambiguity window is where rankings wobble, and there is no reason to gift Google an ambiguity window when you already know the move is permanent. The full decision framework lives in 301 vs 302: when to use each.

How to check it on your own site

1. Crawl with Screaming Frog and filter the Response Codes tab to Redirection (3xx). Export, then sort by status code — every 302 in that list needs a justification with an expiry date attached.
2. For each 302, ask: is the source URL genuinely coming back? If nobody can name the date it returns, it's a 301 wearing a costume. Change it.
3. Check GSC's Indexing → Pages for source URLs stuck in "Page with redirect" or, worse, still ranking with stale titles months after a "move." That pattern surfaced an entire buried 302 problem in this case study — the crawler data and GSC's coverage report disagreed, and the disagreement was the clue.
4. Test your login-gated and geo-routed paths with a Googlebot user agent (curl -I -A "Googlebot") — auth layers and geo-IP layers love throwing 302s at crawlers that they never show logged-in humans.
5. Watch for 302s that bounce a URL back to itself with a session parameter attached. That's a self-redirect loop, and crawlers handle it badly.

Common mistakes

• Migrating a site on framework-default 302s. The dev wrote res.redirect(), nobody reviewed the status code, and the migration stalls with old URLs still ranking. Fix: grep the codebase for redirect calls and make every status code explicit.
• Geo-redirecting every visitor — including Googlebot — with a 302. Googlebot crawls mostly from US IPs, so it gets bounced to your US version and may never see the others. Fix: serve all locale versions at stable URLs with hreflang, and use banner suggestions instead of forced redirects.
• 302 in the HTTP→HTTPS hop. The protocol move is as permanent as anything gets; a 302 there tells Google to keep the insecure URL around. Fix: 301, at the load balancer, one hop.
• Using a 302 to "test" a URL change before committing. Feels prudent, but you're just delaying signal transfer and doubling the settling period. If the change is decided, send the 301 once.
• Forgetting the promo 302 after the promo. The campaign ends, the redirect stays, and a year later Google has quietly canonicalized your evergreen URL onto a dead campaign page. Fix: every temporary redirect gets a removal ticket with a date the day it ships.

FAQ

Does a 302 pass link equity?

Not while it's behaving as designed — signals stay with the source URL. Google says all 30x redirects pass PageRank once it decides the move is real, but with a 302 you're betting rankings on when Google changes its interpretation.

When is a 302 genuinely the right choice?

Short-term promos and seasonal swaps, maintenance windows, A/B test variants, and any detour where the original URL demonstrably returns. The test: can you name the end date? No date, no 302.

What's the difference between 302 and 307?

Both are temporary. A 307 additionally guarantees the HTTP method survives the hop (a POST stays a POST), where a 302 historically let clients downgrade to GET. For indexing purposes Google treats them the same; 307 matters for forms and APIs, not rankings. You'll also see browser-internal 307s on HSTS sites — those never touch the network.

Google eventually treats a long 302 as a 301 — so why care?

Because "eventually" is unbudgeted downtime for your signals. The reinterpretation can take months, is not announced, and can flip back if the crawler sees inconsistency. Sending the correct code costs one line of config.

How do I find every 302 on a large site quickly?

Screaming Frog's Response Codes export filtered to 302, or your CDN/access logs aggregated by status. Logs are better on huge sites because they show what real crawlers hit, including redirect paths your site crawl never reaches.