301, 302, 307, 308 — the difference and when to use each redirect

Short version, if you won’t read to the end: moved for good → 301 (or 308 when the request method has to survive); genuinely temporary → 302 (or 307, same caveat). Everything else is corner cases.

I was poking through the response headers of a site that had just moved to https, and the same URL bounced from http to https to www before it finally landed — a chain where one hop would do. Nobody had broken anything on purpose; someone had picked a redirect code by habit, the way you pick a font. A redirect is the server’s way of saying “this page now lives at another address,” but there are several ways to say it, and the choice affects both SEO (signal transfer, indexing) and whether forms and APIs keep working. Here are the four that matter — 301, 302, 307, 308 — and the two questions that pick between them.

The table: how they differ

Code	Type	Request method	Use it for
301 Moved Permanently	Permanent	May change (POST→GET)	A page moved for good — the main SEO redirect
302 Found	Temporary	May change (POST→GET)	Temporary: A/B test, promo, maintenance
307 Temporary Redirect	Temporary	Preserved (POST stays POST)	Temporary move where the method/body must survive
308 Permanent Redirect	Permanent	Preserved	Permanent move that keeps the method (e.g. APIs)

Permanent vs temporary (axis #1 — for SEO)

• 301 / 308 — permanent. They tell search engines: “move the signals to the new URL.” The old address drops out of the index over time and the new one replaces it, which is exactly what you want for a page move, a URL change, or consolidating http→https / www.
• 302 / 307 — temporary. The engine keeps the original URL indexed because you said “this is short-term.” Say it about a permanent move and you’ve asked for trouble — signal consolidation is delayed and the old address lingers in the results.

The uncomfortable question I ask on every audit: how many of the “temporary” redirects here are older than anyone remembers? If a 302 has been live for a year, it isn’t temporary — it’s a 301 nobody has admitted to yet.

Method preservation (axis #2 — for forms and APIs)

The older 301 and 302 historically let the client change the method: after the redirect a browser usually turns POST into GET, and the request body is simply gone. For ordinary pages nobody notices, because they’re opened with GET anyway.

307 and 308 are strict: the method and body are preserved, so POST stays POST. That stops being a footnote the moment you redirect:

• a form submission (POST);
• an API endpoint that accepts POST/PUT;
• any request with a body that can’t be dropped to GET.

“Where did the form data go?” is usually what makes someone open the RFC for the first time (myself included).

Which redirect for which job

From the most common to the more specific:

Job	Code	Why
Page moved for good, URL changed	301	Permanent → consolidates signals onto the new address, the old one drops out
Domain change, http→https, www / duplicate consolidation	301	Same consolidation; collapse it into one hop to the final URL
Product removed / promo expired	301 to a relevant category	Passes equity and avoids 404s — but not to the homepage (that’s a “soft 404”)
Maintenance, “back soon”, seasonal page	302	Temporary → the engine keeps the original URL indexed
A/B test, temporarily serving content from another URL	302	You don’t want the engine to replace the original with the test URL
Affiliate / outbound commercial link via a /go/… tracker	302 (or 307)	The offer is temporary and rotates, the tracker shouldn’t be indexed; see the callout below
Temporarily redirect a form submission (POST)	307	Preserves the method and body — POST stays POST
API endpoint moved for good	308	Permanent + method preservation (POST/PUT won’t become GET)

canonical or a redirect?

In short: a redirect (301) physically moves you to another URL and the old address is gone, while rel="canonical" keeps every URL working but tells the engine which one is the primary version. Duplicates with parameters (?utm=, sorting, print version) are a canonical job; an actual page move is a 301. My test: do I want the old URL to keep opening? If yes, I probably don’t want a redirect at all.

It’s a subtle but important difference — we covered it separately: canonical vs redirect — which to choose and when.

302 vs 307 in practice

Both are temporary; the whole difference is the request method, which is why I check what the client actually does rather than what the spec says:

• 302 — the client may “replay” POST as GET (browsers historically do). For ordinary link navigation (GET) that’s invisible and fine.
• 307 — strictly preserves the method and body: POST stays POST.

In practice:

• Temporarily redirecting an ordinary page or link → 302 (simpler and universally understood).
• Temporarily redirecting a POST (form submission, request with a body) → 307, otherwise the data is lost when it switches to GET.
• Note: a browser-side 307 is generated internally by HSTS when forcing http→https — that’s not your server redirect and needs no configuration.

For SEO the choice between 302 and 307 doesn’t matter — both are temporary and the engine treats them the same. Only the request-method scenario does.

Impact on AI search (GEO)

AI crawlers (GPTBot, PerplexityBot, ClaudeBot) follow redirects too, and here’s what stings: if a URL an AI answer cited responds with a broken or looping redirect, you lose the most valuable visitor there is — the one who arrived from the answer itself. Does a “temporary” 302 on a permanent move confuse them any less than it confuses Google? It doesn’t; they keep holding the old address. For AI visibility the rule is the same — close permanent moves with 301/308 to a relevant page.

Common mistakes

1. 302 instead of 301 on a permanent move — delays signal consolidation, the old URL lingers in the index.
2. Redirect chains (A→B→C) — each hop loses a little equity and slows crawling. Keep it to one hop.
3. Mass-redirecting everything to the homepage — Google treats that as a “soft 404,” no equity passes. Redirect to a relevant page.
4. Several hops for http→https→www — collapse into one 301 to the final URL.
5. Meta-refresh or a JS redirect instead of a server-side 3xx — slower and a weaker signal. Redirect on the server.
6. Not updating internal links — even with a working redirect, link straight to the final URL instead of routing through a hop.

All obvious on paper — and I still find at least one on almost every site. Habit beats documentation!

How to check your redirects

My routine, in this order:

1. Run the URL through the redirect checker — see the whole chain and the final code. (My working hypothesis is always “one hop.” The chain, more often than I’d like, disagrees.)
2. Inspect the response headers — exactly which status the server returns, not what the CMS settings page claims.
3. Make sure permanent moves are 301/308, there are no chains or loops, and the target is relevant. Relevant to the visitor, not to the sitemap!

And if you catch yourself typing 302 “just for now” — write down the date. Future you will want to know how long “now” lasted.

Sources

• MDN Web Docs — HTTP redirections (301/302/303/307/308).
• Google Search Central — Redirects and Google Search (permanent vs temporary, signal transfer).
• RFC 7231 / RFC 7238 — 3xx semantics and the 308 code.
• Google Content Warehouse API leak (2024) — urlAfterRedirectsFp, forwardingdup fields (redirect-chain resolution and signal attribution to the final URL).