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

A redirect is the server’s way of saying “this page now lives at another address.” There are several status codes, and the choice affects both SEO (signal transfer, indexing) and whether forms and APIs keep working. Let’s break down the four that matter: 301, 302, 307, 308.

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. This is 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.” For a permanent move that’s a mistake: signal consolidation is delayed and the old address lingers in the results.

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 (the request body is lost). For ordinary pages that’s fine — they’re opened with GET.

307 and 308 are strict: the method and body are preserved. POST stays POST. That’s critical when redirecting:

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

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 — the old address is gone. rel="canonical" keeps every URL working but tells the engine which is the primary version. Duplicates with parameters (?utm=, sorting, print version) are a canonical job; an actual page move is a 301.

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:

• 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. If a URL an AI cited answers with a broken or looping redirect, you lose the most valuable traffic there is: a visitor from an AI answer. And a “temporary” 302 on a permanent move confuses the engines — 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.

How to check your redirects

1. Run the URL through the redirect checker — see the whole chain and the final code.
2. Inspect the response headers — exactly which status the server returns.
3. Make sure permanent moves are 301/308, there are no chains or loops, and the target is relevant.

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).