301 vs 302 Redirect
Short answer
Use 301 when a URL has moved for good — it passes ranking signals to the new URL. Use 302 when the change is genuinely temporary and the original URL should stay indexed. Because browsers cache 301s aggressively, an incorrectly issued 301 is far harder to reverse than a wrongly issued 302, so when genuinely unsure, 302 is the safer error.
Side by side
| 301 | 302 | |
|---|---|---|
| Meaning | This URL has moved for good | The content is elsewhere for now |
| Which URL search engines index | The destination | The original |
| Passes ranking signals | Yes, to the destination | No — they stay with the original |
| Browser caching | Aggressive, sometimes indefinite | Not cached by default |
| Easy to reverse later | No — caches must expire or be cleared | Yes |
| Preserves the HTTP method | Not guaranteed — POST may become GET | Not guaranteed — POST may become GET |
| Strict equivalent | 308 Permanent Redirect | 307 Temporary Redirect |
When to use each
Use 301 when…
A permanent domain change, moving to HTTPS, consolidating duplicate URLs, or retiring an old URL structure. Anything you do not intend to undo, and where you want the new URL to inherit the old one's ranking.
Use 302 when…
A/B tests, a temporary maintenance page, geo or device routing, or sending a user somewhere after login. Anything where the original URL should remain the canonical one in search results.
The caching difference is the risk
The SEO distinction gets all the attention, but the operational risk lives in browser caching. A 301 is cacheable by default and browsers take it seriously — some cache it for a very long time, and historically some cached it until the user manually cleared their browser data.
That means a 301 issued by mistake does not simply stop when you fix the server. Every browser that already saw it keeps following the redirect, and you have no way to reach those caches. Visitors report a site that is 'still broken' long after the fix is deployed.
A 302 carries no such risk, because it is not cached by default. This asymmetry is the practical reason to reach for 302 when a redirect is new or experimental, and to switch to 301 once you are certain.
What each does to search rankings
A 301 tells search engines to transfer the old URL's accumulated signals to the destination and index the new URL in its place. This is what makes it correct for a genuine move: the ranking you built does not start over.
A 302 says the move is temporary, so search engines keep the original URL indexed and leave the signals with it. Using a 302 for a permanent move means the new URL never inherits anything, and the old one stays in the index pointing at content that no longer lives there.
Google has said it can eventually work out intent when a 302 stays in place for a long time, but relying on that is a gamble with no upside — the correct code costs nothing extra.
Where 307 and 308 come in
Neither 301 nor 302 guarantees that the HTTP method survives the redirect. In practice many clients turn a redirected POST into a GET, dropping the request body — behaviour that became so widespread it is now effectively expected.
307 and 308 were introduced to close that gap. 307 is a temporary redirect and 308 a permanent one, and both require the method and body to be preserved exactly.
The rule is simple: for a redirect on a URL that only ever receives GET requests, 301 and 302 are fine. For an API endpoint or a form target that receives POST, use 308 or 307 so the request arrives intact.
Frequently asked questions
Does a 301 redirect lose any ranking?
How long should I keep a 301 in place?
What about a meta refresh or a JavaScript redirect?
Can I redirect an entire domain with one rule?
Try the HTTP Status Code Lookup
Look up any HTTP status code by number or search by name to see what it means, whether it is cacheable and what usually causes it.