Most redirect advice stops at 301 and 302, which covers perhaps ninety percent of real cases. The remaining ten percent is where people get stuck — a 307 appearing in dev tools that nobody configured, a 308 from a framework’s default routing, a 303 after a form submission. None of these are exotic, but the documentation for them is written for developers rather than for anyone worrying about rankings. Here is the whole set, explained from an SEO perspective.
The Complete List
| Code | Name | Permanent? | Method preserved? | SEO treatment |
|---|---|---|---|---|
| 301 | Moved Permanently | Yes | No — may become GET | Passes signals, consolidates |
| 302 | Found | No | No — may become GET | Keeps original indexed |
| 303 | See Other | No | No — forced to GET | Like 302 |
| 307 | Temporary Redirect | No | Yes | Like 302 |
| 308 | Permanent Redirect | Yes | Yes | Like 301 |
The pattern is cleaner than it first appears. 307 is a stricter 302. 308 is a stricter 301. The only difference in each pair is whether the HTTP method survives the redirect.
Why Method Preservation Exists
When 301 and 302 were specified, the intended behaviour was that the request method carries over. In practice, browsers implemented it differently — a POST redirected via 302 frequently became a GET. The behaviour became so widespread that it was effectively standardised by accident.
That is fine for a page someone clicked to, where the method is GET anyway. It is a genuine problem for form submissions, API calls, and anything using POST, PUT or DELETE, where silently converting to GET drops the request body.
307 and 308 were introduced to fix this. They guarantee the method and body survive. For a normal web page being redirected, this distinction is irrelevant. For an API endpoint or a form handler, it matters a great deal.
307 Temporary Redirect
A 307 says: this resource is temporarily elsewhere, use the new URL for now, keep using the original afterwards, and do not change my request method.
Google treats 307 exactly as it treats 302. The original URL stays indexed and ranking signals are not transferred. There is no SEO reason to prefer one over the other for ordinary pages.
When you would genuinely use it: temporarily rerouting a form handler or API endpoint, or any redirect where a POST must remain a POST.
The 307 You Did Not Configure
This is the most common reason people search for 307s, and it is not a problem to fix.
If your site uses HSTS (HTTP Strict Transport Security), browsers will show a 307 Internal Redirect in dev tools when upgrading an HTTP request to HTTPS. It looks like a server redirect but is not — it is the browser refusing to make the insecure request at all, based on a header your server sent earlier.
You cannot remove it, and you should not want to. It is faster and more secure than a real redirect, since no insecure request ever leaves the browser. It has no SEO impact. If you see 307 Internal Redirect in Chrome DevTools, HSTS is working correctly.
You should still keep a server-side 301 from HTTP to HTTPS, because HSTS only applies after a browser has seen your header at least once. Crawlers and first-time visitors need the real redirect.
308 Permanent Redirect
A 308 is a 301 that guarantees method preservation. Google treats it as equivalent to a 301: signals transfer, the destination is indexed.
When you would use it: permanently relocating an API endpoint, or any permanent redirect where non-GET requests must survive.
Should you switch your 301s to 308s? No. 301 is universally understood by every crawler, proxy, and legacy client on the web. 308 is newer and, while broadly supported now, offers no benefit for normal page redirects. Use 301 for pages and reserve 308 for endpoints that need it.
Some frameworks and hosts emit 308 by default — Next.js does this for trailing-slash normalisation, for instance. That is fine and requires no action.
303 See Other
303 forces the follow-up request to be a GET, regardless of the original method. Its purpose is the Post/Redirect/Get pattern: a user submits a form via POST, the server processes it and responds with a 303 to a confirmation page, and the browser fetches that page with GET. Refreshing then re-requests the confirmation page rather than resubmitting the form.
Google treats it like a 302. You will rarely configure one deliberately; frameworks handle it. It is worth recognising so you do not mistake it for a misconfiguration.
The Ones That Are Not Redirects
Three codes get grouped with redirects and should not be.
200 OK with a JavaScript or meta refresh redirect. The server says the page exists, then the page moves the user somewhere else. Google can follow meta refreshes and often treats a fast one like a 301, but it is slower, less reliable, and invisible to anything that does not execute the page. Use a server-side redirect. If you have inherited meta refreshes, replacing them is usually a quick win.
503 Service Unavailable. The correct response for planned downtime or maintenance. Paired with a Retry-After header, it tells Google to come back later without disturbing your index. Redirecting your whole site to a maintenance page with a 302 is worse in every respect — use 503.
304 Not Modified. A caching response, not a redirect. It tells the client its cached copy is still current. Despite the 3xx prefix, it does not move anything.
Choosing in Practice
For nearly every SEO decision you will make, the choice is between 301 and 302, and we cover that in detail in 301 vs 302 redirects. The extended set matters in three situations:
- You are redirecting a non-GET endpoint — use 307 or 308 to preserve the method.
- You are diagnosing something you did not configure — 307 from HSTS, 308 from a framework, 303 from a form handler. Usually correct, usually leave alone.
- You are auditing an inherited site and want to understand what previous developers set up.
For deciding what happens to a page you are deleting rather than moving, the relevant comparison is different again — see 410 vs 404 vs 301 for deleted pages.
How to Check What You Are Actually Sending
Do not trust plugin dashboards or server config files. Check the wire:
curl -IL https://yoursite.com/some-page-I requests headers only, -L follows the full chain. You get every hop and every status code, which immediately surfaces redirect chains and unexpected intermediate codes.
For POST behaviour specifically:
curl -X POST -IL https://yoursite.com/api/endpointIf the method silently becomes GET partway through the chain, you have a 301 or 302 where a 308 or 307 belongs.
Browser DevTools works too — the Network tab shows the status of each request — but remember it will show you browser-internal 307s from HSTS that never touched your server. curl shows only what the server actually sent, which is usually what you want when debugging.
Most of the Time, It Is Still 301
The extended redirect codes exist for good technical reasons and solve real problems, but those problems are mostly not SEO problems. For pages, 301 remains the right permanent redirect and 302 the right temporary one. 307 and 308 belong on endpoints where the request method matters. 303 belongs after form submissions, and you will almost never write one yourself.
The genuinely useful takeaway is diagnostic: when you see a redirect code you did not configure, you now know whether it needs fixing or is working exactly as intended. In most cases — particularly the 307 from HSTS — it is the latter.
If you want a technical audit that maps every redirect on your site and finds the chains, loops, and mismatched codes, our SEO services cover exactly that. Reach out to the team at blogthememachine.com, and subscribe to our newsletter below for more technical SEO guides.
