Guide
301 vs 302 redirects, and when to use 307 or 308
Permanent or temporary is the whole decision. Pick wrong and search engines keep showing the URL you meant to retire.
Short answer
Use a 301 (or 308) when a URL has moved for good, because search engines then show the new address; use a 302 (or 307) only when the old URL will come back, such as during a short test or maintenance.
Key takeaways
- 301 and 308 are permanent and tell Google to treat the target as the canonical URL.
- 302 and 307 are temporary and keep the original URL in search results.
- 307 and 308 keep the request method, which matters for forms and APIs, not for normal page moves.
- Server-side redirects beat meta refresh and JavaScript redirects, which Google treats as a fallback.
- Check the status code you actually serve; many platforms send 302 by default.
A redirect status code is a one-line decision, and it is easy to get wrong because both main options look identical to a visitor. The page loads at the new address either way. The difference shows up weeks later in search, when the old URL is still listed or the new one never appears.
What is the difference between a 301 and a 302?
A 301 says the page has moved permanently, and a 302 says it is somewhere else for now and will come back.
Both send the browser to a new URL with a Location header. The status code tells clients how to treat the change:
| Code | Meaning | Keeps method? | Search engines show |
|---|---|---|---|
| 301 Moved Permanently | Moved for good | Not guaranteed | The new URL |
| 302 Found | Temporary | Not guaranteed | The old URL |
| 307 Temporary Redirect | Temporary | Yes | The old URL |
| 308 Permanent Redirect | Moved for good | Yes | The new URL |
Google's documentation groups them simply: 301 and 308 are permanent, while 302, 303 and 307 are temporary. Permanent redirects are a strong signal that the target should become the canonical URL. Temporary ones keep the source URL as the version shown in results.
When should you use a 301?
Use a 301 for anything that won't be undone: a new domain, an HTTPS switch, a renamed page or a merged article.
Typical cases:
- Moving from
http://tohttps://. - Choosing between
wwwand the bare domain (our guide on www vs non-www redirects covers that choice). - Changing a URL slug or folder structure.
- Merging two thin pages into one stronger page.
- Moving to a new domain.
In each case you want search engines to forget the old address and rank the new one. A 301 tells them so.
When is a 302 the right choice?
Use a 302 when the original URL will return: a short A/B test, a maintenance page, a seasonal page or a geo or language switch.
If you send /pricing/ to /pricing-test-b/ for two weeks, you want Google to keep /pricing/ in results. A 302 does that. Same for a temporary "we'll be back" page during maintenance, though for real downtime a 503 with a Retry-After header is the better signal.
The common mistake runs the other way. Many CMS plugins, frameworks and hosting panels send a 302 by default. A site move done with 302s can leave the old URLs in search for a long time.
What are 307 and 308 for?
307 and 308 behave like 302 and 301 but forbid the client from changing the request method, which matters for forms and APIs.
Historically some clients turned a redirected POST into a GET. The HTTP specification now allows that for 301 and 302, and forbids it for 307 and 308. For ordinary page moves this makes no difference, and 301 is the most widely understood choice. For an API endpoint or a form handler that moved, 308 keeps the POST intact. You will also see 307 from browsers themselves when HSTS forces HTTPS; that one is internal and never reaches the server.
What about meta refresh and JavaScript redirects?
They work as a fallback, but server-side redirects are faster and more reliable for both visitors and crawlers.
Google treats an instant meta refresh as permanent and a delayed one as temporary. JavaScript redirects are a last resort, because Google has to render the page to see them and rendering can fail. Static hosts without redirect support are the main reason to use either. Most of them, including Cloudflare Pages and Netlify, support a _redirects file, which sends real status codes.
How do you check which code you are sending?
Request the old URL and read the status line, or run it through a redirect checker that shows every hop.
From a terminal:
curl -sI https://example.com/old-page/
The first line shows the code, and the location: header shows the target. Follow the chain with curl -sIL to see every hop. For the home page, paste the domain into the Robotto checker. It requests the four http/https and www/bare versions, follows each redirect one hop at a time, and flags 302 or 307 used for a site-wide move.
Watch for chains. A http://www request that goes 301 to https://www, then 302 to https://, then 301 to /en/ is three hops with a temporary one in the middle. Our guide on reading a redirect chain explains how to collapse it into one.
A short decision list
- Will the old URL ever be used again? No: 301. Yes: 302.
- Is it a form handler or API that receives POST requests? Use 308 or 307 instead.
- Is the site down for maintenance? Send 503 with
Retry-After, not a redirect. - After deploying, check the real status code. Defaults surprise people.
Questions
Does a 302 pass link equity?
Google has said for years that all its redirect types pass signals. The practical difference is canonical choice: with a 302 Google keeps showing the old URL, so the new one may not get the visibility you wanted.
How long should I keep a 301 redirect in place?
Keep it as long as you can, ideally for good. Old links on other sites, bookmarks and emails keep sending visitors to the old URL for years. Google's guidance also suggests keeping redirects for at least a year after a site move.
Can a 301 be undone?
Yes, but browsers cache 301s, sometimes for a long time, so returning visitors may keep landing on the target. Only use a permanent redirect when you are sure.
Is a meta refresh the same as a 301?
Google treats an instant meta refresh (0 seconds) as a permanent redirect and a delayed one as temporary. It is a fallback for hosts that can't send real redirects.