The difference is permanence: a 301 says “this resource has moved permanently, update your links and pass authority to the new URL,” while a 302 says “this is a temporary detour, keep using the original URL.” That single distinction drives everything downstream — how browsers cache the response, how search engines treat your rankings, and whether a bookmarked link ever updates. This article explains what each code means at the HTTP level, when to use which, how caching and SEO diverge, and where the method-preserving cousins 307 and 308 fit in.
What does a redirect actually look like on the wire?
A redirect is just a 3xx status code plus a Location header telling the client where to go next. There is no magic; the server responds, and the client decides whether to follow. A minimal 301 looks like this:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-path
Content-Length: 0The client reads the status code, sees it is a redirect, and issues a fresh request to the URL in Location. A 302 is structurally identical — same Location header, different status line reading 302 Found. Because the shape is the same, the only thing distinguishing them is the number, and the number carries the meaning that browsers, proxies, and crawlers act on.
The Location value can be absolute or relative. An absolute URL like https://example.com/new-path is unambiguous and is the safest choice, especially when you redirect across hosts or between HTTP and HTTPS. A relative value such as /new-path is resolved against the requested URL, which is fine within one site but a frequent source of surprises when a request arrives through a proxy that rewrote the host. When in doubt, emit an absolute Location so every client resolves the destination the same way.
When should you use a 301?
Use a 301 when the change is permanent and you never intend to serve the old URL again. Typical cases: you renamed a page, moved to HTTPS, consolidated www and non-www, or migrated to a new domain. A 301 tells every client — humans, browsers, and search engines — to treat the new URL as the canonical replacement.
The consequences are what make 301 the right or wrong choice. Search engines transfer the ranking signals associated with the old URL to the new one and, over time, drop the old URL from the index in favour of the destination. Browsers cache the 301 and may stop requesting the old URL entirely, going straight to the new one on future visits. Both behaviours are exactly what you want for a permanent move — and exactly what you do not want if the move might be reversed, because undoing a widely cached 301 is slow and unreliable.
When should you use a 302?
Use a 302 when the redirect is temporary and the original URL should retain its identity and authority. Good examples: showing a maintenance page, routing users to a seasonal promotion, sending someone to a login page before returning them, or steering traffic during an A/B test. In all of these the canonical resource still lives at the original URL; you are just detouring for now.
Because a 302 is temporary, search engines generally keep the original URL indexed rather than passing its authority to the destination, and browsers do not cache the redirect unless you explicitly add caching headers. That means you can change or remove a 302 rule freely and clients will pick up the change on their next request. The failure mode here is using a 302 for what is really a permanent move: you split signals between two URLs and never consolidate ranking on the destination.
How do 301 and 302 differ in caching and SEO?
The two codes diverge on three axes — caching, indexing, and reversibility. This table summarises the practical differences:
| Behaviour | 301 Moved Permanently | 302 Found |
|---|---|---|
| Meaning | Permanent move | Temporary move |
| Default browser caching | Cached aggressively | Not cached unless headers say so |
| Search-engine treatment | Passes ranking to new URL; indexes destination | Keeps original URL indexed |
| Reversibility | Hard — caches persist | Easy — change any time |
| Typical use | Renames, HTTPS, domain moves | Maintenance, promos, A/B tests, login flows |
The reversibility row is the one that bites in production. Once browsers and intermediaries have cached a 301, changing your mind means users keep hitting the old destination until their caches expire — and a 301 carries no expiry of its own, so that can be a very long time. The safe habit is to reach for a 302 by default and upgrade to a 301 only when you are certain the move is permanent.
It also helps to remember that a redirect status code and the caching of that redirect are two separate mechanisms. A 301 is cacheable by default, but you can still attach an explicit Cache-Control header to bound how long clients hold it. Conversely, a 302 is not cached by default, yet adding Cache-Control: max-age=3600 makes clients cache it for an hour. So the code communicates intent — permanent versus temporary — while the caching headers, when present, give you finer control over how long that intent is honoured. If you are nervous about committing to a 301, a 302 with a short, explicit cache lifetime is often the pragmatic middle ground.
Where do 307 and 308 fit in?
They are the method-preserving versions: 307 is a temporary redirect that keeps the HTTP method and body, and 308 is the permanent equivalent. To see why they exist, you have to know a piece of history. The original 302 specification said the method should be preserved, but real browsers instead changed POST requests to GET when following a 302. Enough software relied on that behaviour that the standard could not simply be corrected, so two unambiguous codes were added.
| Code | Permanence | Method preserved? |
|---|---|---|
| 301 | Permanent | Not guaranteed (often GET) |
| 302 | Temporary | Not guaranteed (often GET) |
| 307 | Temporary | Yes — method and body kept |
| 308 | Permanent | Yes — method and body kept |
The practical rule: if a client sends a POST and you need the redirected request to remain a POST, use 307 (temporary) or 308 (permanent). This matters most for APIs. If a POST endpoint moves and you redirect it with a 301 or 302, many clients will retry with GET, silently dropping the request body — the write never happens. A 308 keeps the POST intact so the call completes at the new URL. For ordinary pages fetched with GET, the distinction is moot, and a plain 301 or 302 is fine.
How do you verify which code a URL returns?
Check the status line and Location header directly, without letting your client follow the chain. On the command line, curl -I https://example.com/old-path issues a HEAD request and prints the response headers, so you can read the exact status — 301, 302, 307, or 308 — and the destination. Add -L only when you deliberately want to follow the full chain and see every hop.
The subtlety a raw request hides is a redirect chain: an old URL 301s to an intermediate URL that then 302s somewhere else, mixing permanent and temporary hops in a way that confuses both browsers and crawlers. A dedicated redirect tester lays out each hop with its status code and target so you can spot a stray 302 in a chain meant to be permanent, or an accidental loop. Because it runs client-side in your browser, you can paste internal or staging URLs without sending them to a third-party server — useful when you are testing a migration before it goes public.
A short decision guide
Ask two questions. Is the move permanent? If yes, lean 301 (or 308 to preserve a POST); if no, use 302 (or 307 to preserve a POST). Does the request carry a method and body you must keep — a POST to an API? If yes, choose the 307/308 pair; if it is a plain page load, 301/302 is enough. Default to temporary when you are unsure, because a 302 is cheap to undo and a cached 301 is not, and always verify the deployed rule with a test before you trust it.