302 Status Code: The Temporary Redirect That Overstays

Aug 09, 2026 · HTTP Status Codes

Here's a config mistake I've corrected on at least a dozen client sites. Someone writes an nginx rewrite rule during a site restructure:

rewrite ^/old-section/(.*)$ /new-section/$1 redirect;

Looks fine, works in the browser, ships to production. Except redirect in nginx means 302, not 301. The permanent move they intended is now announced to every crawler as "temporary — keep the old URLs, we'll be right back." The same trap exists in Apache, where a bare Redirect directive without an explicit status also defaults to 302.

The 302 status code isn't broken. It's just the wrong default for what most people are actually doing.

What the 302 status code means — and what it doesn't

A 302 Found response says: the resource you asked for is temporarily answering at the URL in my Location header, but the original address is still the real one. Come back to it next time. Browsers follow the redirect but, unlike a 301, don't cache it long-term — every future visit re-asks the original URL.

For search engines the distinction is sharper. A 302 tells Google to keep the original URL in the index and treat the destination as a stand-in. Signals stay attached to the old URL. That's precisely what you want for genuinely temporary situations, and precisely what you don't want when the move is forever.

One more spec detail: a 302 allows the client to change a POST into a GET when following the redirect. If method preservation matters — API endpoints, form handlers — the strict temporary redirect is 307, which forbids that switch.

Where accidental 302s come from

• Server defaults, as above — nginx redirect flag, Apache Redirect without a code, Express's res.redirect() which sends 302 unless told otherwise.
• CDN and load-balancer rules. Cloudflare's "Forwarding URL" page rule offers both, and the person clicking chooses 302 because "temporary sounds safer."
• Login and geo systems that bounce every URL through a locale or auth check, wrapping the whole site in a layer of 302s.
• HTTP-to-HTTPS redirects configured years ago as 302 and never revisited — a permanent protocol change announced as temporary, indefinitely.

Framework code has the same bias. Express's res.redirect("/new") sends 302 unless you pass the status explicitly: res.redirect(301, "/new"). Django's redirect() shortcut returns a temporary redirect by default; you need permanent=True for a 301. Flask, Rails, Laravel — same story. The pattern to internalize: in nearly every tool you'll touch, 302 is what you get when you don't say what you mean. Any redirect created without an explicit status code deserves a second look.

How Google handles a 302 that never ends

Google is pragmatic here: a 302 left in place long enough gets treated as a 301. The index eventually swaps to the destination URL and signals consolidate. So a forgotten 302 is rarely fatal — but "eventually" is doing a lot of work in that sentence. During the weeks or months before Google decides your temporary redirect is actually permanent, you can see split signals, the wrong URL ranking, and canonicalization flapping between old and new. Why leave that to inference when one word in a config file states your intent explicitly?

302, 301, and 307 side by side

The permanent, method-preserving fourth member of the family is 308 — the same relationship to 301 that 307 has to 302.

Tracking down the 302s on your site

Spot-check any suspicious URL from the terminal and read the first status line:

curl -sI https://example.com/old-section/page/ | head -1

If it says HTTP/2 302 and the move is permanent, you've found one. For full coverage, crawl your site and filter the report to 3xx responses — a good crawl lists every redirect with its type, source, and destination, so 302s that should be 301s stand out in a single sorted column. Pay special attention to redirects on URLs that still receive backlinks; those are the ones where the wrong code delays signal transfer the most. Cross-check against your existing 301s too, because mixed chains — a 301 hopping into a 302 — inherit the weakest link's ambiguity.

When a 302 is exactly right

Don't swing to the other extreme and 301 everything. Reach for a 302 when:

1. Maintenance or outage pages — the real URL will be back within hours, and you want zero risk of caches or crawlers memorizing the detour.
2. A/B tests that route some visitors to a variant URL. Google specifically recommends 302s here so the canonical URL keeps its place.
3. Seasonal swaps — a Black Friday landing page temporarily answering for a category URL that returns in December.
4. Device or language detection, when a URL redirects by visitor context and the original must stay indexed as the canonical entry point.

The test is one question: will the original URL serve content again? Yes → 302. No → 301. If you can't answer, the move isn't ready to ship.