301 vs 302 vs 307 vs 308 redirects: which one to use

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.

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.

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:

curl -sIL https://example.com/old-page | grep -iE "^HTTP|^location"

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.