301 vs 302 vs 307 vs 308 redirects: which one to use
301 and 308 are permanent, 302 and 307 temporary; 307 and 308 keep the request method. Which code to use for moved pages, domain changes and HTTPS.
LLaunchScaler·Published ·7 min read
301 and 308 are permanent redirects; 302 and 307 are temporary. The second difference is the request method: 307 and 308 must keep it, while after a 301 or 302 a browser may turn a POST into a GET. For SEO, use a permanent redirect (301 or 308) whenever a URL has moved for good, because Google treats it as a strong signal to index the new URL and a temporary one as only a weak signal.
Google treats 308 exactly like 301 and 307 exactly like 302, so for search the choice is permanent versus temporary. The method rule only matters for forms and APIs.
What is the difference between 301, 302, 307 and 308?
Two questions separate the four codes: is the move permanent, and must the browser repeat the same method at the new URL. The table answers both for each code, with how Google's crawlers treat it and the job each one fits.
Code
Name
Permanent?
Method kept?
How Google treats it
Use it for
301
Moved Permanently
Yes
Not guaranteed; POST may become GET
Strong signal the target should be processed
Moved pages, domain changes, HTTP to HTTPS
Questions, answered
What people ask about this
01
What is the difference between a 301 and a 302 redirect?
A 301 says the page has moved permanently, so Google treats it as a strong signal to index the new URL. A 302 says the move is temporary, which Google treats as a weak signal, so the old URL usually stays in search results.
The same jobs, plus URLs that receive POST, PUT or DELETE
302
Found
No
Not guaranteed; POST may become GET
Weak signal
Short-term detours for GET pages
307
Temporary Redirect
No
Yes, must not change
Same as 302
Short-term detours where the method matters
303
See Other
No
Changed to GET on purpose
Temporary
Sending the browser to a results page after a form submit
The method rules come from RFC 9110: a user agent may change POST to GET after a 301 or 302, is encouraged to use GET after a 303, and must not change the method on an automatic 307 or 308 redirect. MDN adds that in the Fetch Standard, browsers do switch POST to GET after a 301 or 302.
Does Google treat 301 and 308 the same?
Yes. Google's crawling documentation lists 308 as "equivalent to 301" and 307 as "equivalent to 302." For the permanent pair, Google follows the redirect and uses it as a strong signal that the target should be processed; for the temporary pair, it follows the redirect but treats it as only a weak signal.
Google's redirects guide puts the practical difference in terms of what appears in results. Permanent redirects show the new target in search results. Temporary redirects show the source page. Its canonicalization guide ranks redirects as "a strong signal that the target of the redirect should become canonical," alongside rel="canonical" and ahead of sitemap inclusion.
Google still asks you to pick the semantically right code. Its docs note that while it handles the codes the same way, other clients, such as other search engines and e-readers, may rely on the difference.
Why do 307 and 308 exist?
Because browsers changed POST requests to GET when following 301 and 302, which breaks any redirected form or API call. 307 and 308 were added as the temporary and permanent codes that forbid that change, so a POST /v1/users redirected to /v2/users arrives as a POST.
That is why Next.js uses them. Its docs explain that with a 302, a POST to /users redirected to /people would arrive as a GET, which makes no sense for creating a user. So Next.js returns 307 from redirect(), 308 from permanentRedirect(), and 307 or 308 from redirects in next.config.js depending on permanent: false or true. The one exception: when a Server Action form is submitted without JavaScript, both functions answer with a 303 so the browser follows up with a GET.
For ordinary pages visited with GET, 301 and 308 behave the same, and so do 302 and 307.
Which redirect should you use for each job?
Use a permanent code whenever the old URL should not come back, and a temporary one only when it will. Google's redirects guide lists the usual reasons to redirect at all: moving to a new domain, pages reachable at several URLs, merging two websites, and removing a page you want to send people on from. The table covers those and the other redirects most sites need, with the code to use and why.
Job
Code
Why
Page moved to a new URL for good
301 or 308
The new URL should replace the old one in results
Domain change, or merging two sites
301 or 308, page to page
Each old URL passes its signals to its own replacement
HTTP to HTTPS
301 or 308, same host first
Permanent, and first hop on the same host so HSTS works
www to non-www (or the reverse)
301 or 308
One canonical host
Trailing slash or lowercase normalisation
301 or 308
One canonical form of each URL
Deleted page with a close replacement
301 or 308 to the replacement
Only when the replacement really covers the same need
Deleted page with no replacement
No redirect: return 404 or 410
A redirect to an unrelated page, such as the homepage, sends people somewhere they did not ask for; a 404 or 410 says the page is gone
Page temporarily down for maintenance
302 or 307
Google's guide gives this case: keep the original URL in results
Seasonal or campaign page that will return
302 or 307
The original URL comes back
After a form POST succeeds
303
The browser loads the confirmation page with GET, so a refresh does not resubmit
API endpoint moved
308 (or 307 if temporary)
Clients keep POST, PUT and DELETE
For the HTTP to HTTPS move in particular, the HTTP to HTTPS redirect guide has the same-host rule and the setup for each host.
What happens if you leave a 302 in place for months?
Google does not document a point at which a temporary redirect becomes permanent. What it does document is that a temporary redirect is not used as a signal that the target should be canonical, and that the target "might still be indexed if other canonicalization signals are present," such as internal links and canonical tags pointing at it.
So a long-lived 302 leaves the outcome to Google's other signals. If the move is permanent, change the code to 301 or 308 rather than waiting for Google to work it out. The common source of accidental 302s is a framework or plugin default: check what yours sends with curl before assuming.
Browsers are the other half. Next.js's docs describe 308 as telling clients and search engines to cache the redirect forever, and 307 as temporary and not cached. Test a permanent redirect before you ship it, because a wrong one can stay cached in visitors' browsers after you fix the server.
Are meta refresh and JavaScript redirects treated as 301s?
Some are. Google interprets an instant meta refresh (<meta http-equiv="refresh" content="0; url=...">) as a permanent redirect and a delayed one as temporary. It supports JavaScript location redirects too, but says to use them only when server-side or meta refresh redirects are not possible.
Server-side redirects are always the first choice: Google's guide orders redirect types by how likely it is to interpret them correctly, and server-side redirects come first. A JavaScript redirect also only works for crawlers that run JavaScript, which many non-Google crawlers do not.
How do you set each redirect code?
Most servers and platforms let you choose the code explicitly. Set it deliberately, because the default differs between tools.
Nginx: return 301 https://example.com/new; (or 302, 307, 308), as in Google's own Nginx example.
Apache: Redirect permanent "/old" "https://example.com/new" for a 301, Redirect temp for a 302.
Next.js: redirects() in next.config.js with permanent: true (308) or false (307), or statusCode for a specific code; permanentRedirect() (308) and redirect() (307) in server code.
Vercel (vercel.json): "permanent": true or false on each entry in redirects, or "statusCode": 301 for a specific code.
Netlify (_redirects or netlify.toml): the status code defaults to 301 if you leave it out; add 302 or another code after the destination.
How do you check which redirect a URL returns?
Request it with curl and read the status line and Location header, following every hop with -L:
Each hop prints its status code and target. Run it on the old URL, and on its http:// and www variants, because each can take a different path through your rules. Look for a temporary code where you meant a permanent one, and for more than one hop. Chains add latency and give crawlers extra fetches; the redirect chains and loops guide shows how to collapse them. If Search Console lists redirected URLs under "Page with redirect," that is usually the report working as intended; the page with redirect guide explains when it needs a fix.
To check the redirects on a live site, run the free scan on LaunchScaler. It needs only your URL and no account, and its free checks flag redirect chains longer than one hop, redirect loops, an HTTP to HTTPS redirect that leaves the host, and canonical tags or sitemap entries that point at redirected URLs, among 156 checks across 6 of its 7 categories.
Both are temporary. After a 302, browsers may change a POST request to GET when they follow the redirect; after a 307, RFC 9110 forbids changing the method. Google treats the two the same way.
03
Is 308 better than 301 for SEO?
No difference for Google: its crawling docs say 308 is equivalent to 301. Use 308 when the redirected URL may receive POST, PUT or DELETE requests, because 308 keeps the method and 301 may not.
04
Which redirect should I use when I move a page?
A permanent one, 301 or 308, straight to the new URL. Then update internal links and your sitemap to the new URL so visitors and crawlers stop going through the redirect.
05
Does a 302 pass link value?
Google's docs say a temporary redirect is not used as a signal that the target should be canonical, though the target can still be indexed if other signals point to it. If the move is permanent, use a permanent redirect rather than relying on that.
Get a Bolt site indexed: check which framework it uses, publish publicly on your own domain, add robots.txt and a sitemap, then verify in Search Console.
