Developer
301 vs 302 vs 307 redirects: what's the difference?
Reviewed by the Tabreon team · Last updated: September 2026
Quick answer
301 signals a permanent move and passes SEO ranking signals to the new URL. 302 signals a temporary move but doesn't reliably preserve the original request method. 307 also signals temporary, but explicitly guarantees the method and body are preserved.
Why this matters
Picking the wrong redirect code has real consequences: a temporary code (302/307) used for a permanent move splits SEO signals between two URLs, while a redirect that silently converts a POST into a GET can drop form data or an API payload.
Definition
All three are HTTP status codes a server sends to tell a client "the resource you asked for is now at a different URL." They differ along two axes: whether the move is permanent or temporary, and whether the client is required to preserve the original request method (GET, POST, etc.) and body when it follows the redirect.
How it works
When a server responds with a 3xx status and a Location header, the client automatically issues a new request to that URL. 301 and 302 predate a strict method-preservation rule, so in practice most browsers convert a POST into a GET when following either of them. That long-standing inconsistency is exactly why 307 (and its permanent counterpart, 308) were added: they make method and body preservation an explicit requirement of the spec, rather than something every client handles differently.
301 vs 302 vs 307 at a glance
| 301 Moved Permanently | 302 Found | 307 Temporary Redirect | |
|---|---|---|---|
| Meaning | Permanent move | Temporary move (historically ambiguous) | Temporary move, method-safe |
| Preserves request method (e.g. POST stays POST) | Not guaranteed — often becomes GET | Not guaranteed — often becomes GET | Guaranteed by spec |
| Passes SEO ranking signals to the new URL | Yes | No — treated as temporary | No — treated as temporary |
| Cacheable by default | Yes, aggressively | No, unless explicit caching headers are sent | No, unless explicit caching headers are sent |
| Typical use case | Domain migration, permanent URL change, canonical redirects | Temporary maintenance page, A/B testing | Resubmitting a form or API request to a temporary endpoint |
Common mistakes
- Using 302 for a permanent URL change — search engines keep indexing the old URL and don't fully transfer its ranking signals to the new one.
- Assuming a 301 or 302 redirect will safely resubmit a POST request — most clients silently rewrite it to a GET, which can drop form data.
- Leaving a "temporary" redirect (302 or 307) in place for months or years instead of switching to a 301 once the move becomes permanent.
Best practices
- Use 301 for anything meant to be permanent — a domain change, a URL restructure, or a canonical redirect from a trailing-slash variant.
- Use 307 instead of 302 when the redirected request must keep its exact method and body, like resubmitting form data or an API call.
- Update internal links and canonical tags to point directly at the final URL rather than relying on a redirect chain long-term.
Frequently asked questions
Related tools
Related guides
Sources
- RFC 9110 — HTTP Semantics (redirection status codes)