Home / Learn / 301 vs 302

301 vs 302 vs 307 vs 308 redirects

Two questions decide the code: is the move permanent, and must the request method survive the redirect? Everything else follows from those.

Code	Name	Permanent?	Keeps POST?	Google Search	Use for
301	Moved Permanently	Yes	No (browsers switch to GET)	Strong signal the target is canonical	Page moves, domain moves, HTTPS/www
308	Permanent Redirect	Yes	Yes	Same as 301	Permanent moves of forms and APIs
302	Found	No	No (browsers switch to GET)	Weak signal; source often stays indexed	A/B tests, short promotions, geo or login bounces
307	Temporary Redirect	No	Yes	Same as 302	Temporary moves where POST must be retried
303	See Other	No	Always GET	Temporary	"POST, then show the result page"

Sources: RFC 9110 sections 15.4.2–15.4.9; Google Search Central, Redirects and Google Search.

The method question, hands on

301 and 302 predate the web's heavy use of forms. Early browsers turned a redirected POST into a GET, and the spec eventually accepted it. 307 and 308 were added so servers could insist on keeping the method. Pick a code and follow the request.

For ordinary page URLs, which are always fetched with GET, 301 and 308 behave identically, and so do 302 and 307.

A form on /checkout POSTs its data. The server answers with a redirect to /v2/checkout. What does the browser send next?

POSTBrowser → /checkout, with form body
301Server → Location: /v2/checkout
GETBrowser → /v2/checkout with no body: the order data is gone

Permanent. The spec allowed clients to keep POST, but browsers switched to GET long ago and RFC 9110 now permits it. Fine for pages, risky for form endpoints.

Does a 302 lose rankings?

Not in the way old SEO lore claims. Google says redirects of any kind don't cause a loss of PageRank. The difference is which URL gets indexed: a permanent redirect tells Google to show the target; a temporary one tells it the source may come back, so the source often stays in results. If a "temporary" redirect stays in place for a long time, Google may eventually treat it as permanent, but that is a guess you don't need it to make.

Meta refresh and JavaScript redirects

Instant meta refresh (content="0; url=…") is treated as permanent by Google; a delayed one as temporary. Some browsers and assistive tech handle them poorly.
JavaScript redirects (location.href = …) only work after Google renders the page, which can be delayed. Use them only when you can't configure the server.
HSTS "307 Internal Redirect" in Chrome DevTools never touched the server; the browser upgraded to HTTPS on its own because of an earlier Strict-Transport-Security header.

A decision you can make in five seconds

Will the old URL ever show its own content again? No → permanent (301 or 308). Yes → temporary (302 or 307).
Is the URL a form handler or API endpoint that receives POST, PUT or DELETE? Yes → the method-keeping code (308 or 307). No → either.

Then check the result: trace the redirect and confirm it's a single hop with the code you meant, or generate the rule.

Questions

What is a 301 redirect?

An HTTP response with status 301 Moved Permanently and a Location header naming the new URL. Browsers go there automatically and search engines transfer indexing to the new URL.

What is a 308 redirect?

A permanent redirect like 301 that also requires the client to repeat the request with the same method and body. Google treats 308 the same as 301.

How long should I keep a 301 in place?

Google recommends keeping redirects for at least a year after a move, and longer is better: backlinks and bookmarks to the old URL keep working as long as the redirect exists.

Are 301s cached by browsers?

Yes, often indefinitely unless Cache-Control says otherwise. That is why a mistaken 301 is hard to undo for returning visitors; test with 302 first if unsure, then switch.