301 vs 302 vs 307 vs 308: How to Stop Mixing Up Redirect Codes
There are only four redirect status codes, yet they're easy to mix up every time. Most people remember "301 is permanent, 302 is temporary," but far fewer know why 307 and 308 exist at all. The truth is that these four codes weren't invented for four separate purposes — they're the same two properties (permanent vs. temporary, and whether the method is preserved) defined differently at different points in HTTP's history. Once you see that structure, you don't need to memorize four codes separately; one table does the job.
1. Two axes explain everything
The four redirect codes split along exactly two questions. First: is the move permanent or temporary? Second: when the redirect happens, is the original HTTP request method (GET, POST, etc.) and body preserved as-is?
| Code | Permanent/Temporary | Method preserved |
|---|---|---|
| 301 | Permanent | Not guaranteed (historically ambiguous) |
| 302 | Temporary | Not guaranteed (historically ambiguous) |
| 307 | Temporary | Guaranteed |
| 308 | Permanent | Guaranteed |
In other words, 307 is "302 that preserves the method," and 308 is "301 that preserves the method." You don't need to memorize all four separately — just remember the relationship: "301/302 are old and ambiguous," "307/308 came later and are explicit."
2. Why "the method can change" is a problem with 301/302
301 and 302 were defined in the early 1990s, back in the HTTP/1.0 era, and the spec didn't clearly define how the method should be handled during a redirect. As a result, most early browsers implemented the convention of "whatever the original method was, re-request the redirect target with GET" — and that convention hardened into de facto standard behavior. So if a user submits a form via POST and the server responds with a 301 or 302, the browser may discard the form data and re-request the next URL with GET instead. The problem is that this is a "convention," not a "specification," so actual behavior can differ from browser to browser.
3. What 307/308 explicitly fixed
When 307 and 308 were newly defined in the HTTP/1.1 spec (RFC 7231, later RFC 9110), the rule was made explicit: "when following a redirect, the original request's method and body must never be changed." So if a request sent via POST receives a 307 or 308 redirect, the re-request is guaranteed to also be POST, with the original body sent unchanged. For paths where the request body actually matters — API endpoints, payments, login flows — using 307/308 instead of 301/302 prevents data loss or unintended behavior changes.
POST /old-api/submit request is redirected to /new-api/submit· With 301/302: depending on browser implementation, it may be re-requested as GET /new-api/submit (risking loss of form data)
· With 307/308: it is guaranteed to be re-requested as POST /new-api/submit with the original body intact
4. From an SEO standpoint, when should you use 301/302 vs. 307/308?
Typical webpage URL moves — HTTPS migration, URL restructuring, domain moves — almost always involve only GET requests, so method preservation isn't a practical concern. In these cases, it's fine to stick with the conventional 301 (permanent) or 302 (temporary), which search engines handle well. 308/307 should be reserved for redirecting paths that carry non-GET requests, such as form submissions or API calls. You can check exactly which codes appear in a real site's redirect chain, and how many hops the chain runs, with a redirect chain checker.
5. A common mistake: using 302 for permanent moves
When server configuration is done in a hurry, it's common to leave 301 and 302 undifferentiated and just use 302 (or a framework's default) regardless. If content has actually moved permanently but the server responds with 302, search engines may treat the move as potentially temporary and hold back from fully transferring the original URL's index status and link authority to the new URL. The end result is that SEO rankings don't fully carry over to the new URL. If a URL has changed permanently, double-check your server configuration to make sure it responds with 301 (or 308 for non-GET requests). When building redirect rules with an .htaccess generator or an Nginx config generator, it's safest to explicitly specify the status code.
Frequently Asked Questions
Q. Why isn't 303 See Other in the table?
303 was created for a different purpose — telling the client to fetch the result of a PUT or POST via GET — and it's explicitly specified to always re-request with GET. Unlike 302, the method change with 303 isn't an informal convention but a deliberate, spec-mandated behavior, so it doesn't fit the "permanent/temporary + method preservation" framework this guide covers.
Q. Is a long redirect chain bad for SEO?
Yes. As a chain like A→B→C grows longer, each hop loses a little link authority, and search engine crawlers may give up following a chain beyond 5–10 hops. Use a redirect chain checker to review the full chain and shorten it so it points directly to the final destination.
Q. Do both 301 and 302 pass PageRank?
Google has officially stated that both 301 and 302 pass PageRank (link authority) today. That said, because 302 implies a "temporary" move, search engines tend to keep the original URL indexed rather than fully replacing it, so 301 remains the safer choice for permanent moves.
Q. Which code should I use when migrating to HTTPS?
An HTTP to HTTPS migration is almost always a GET-based page move, so 301 is the standard choice. The same applies when standardizing on www or non-www.