Both codes send a visitor from one URL to another, and to a person they are indistinguishable — you click a link, you land on a page.
To a search engine they say opposite things. A 301 says "this has moved, update your records". A 302 says "the original URL is still the right one, this is a detour". Choose wrong and everything appears to work while your rankings quietly stay with a URL you have abandoned.
The short answer
Use a 301 when the move is permanent. Ranking signals transfer to the destination, and browsers cache the redirect so it stops costing a round trip on repeat visits.
Use a 302 when the original URL will be used again. Signals stay with the original, and nothing is cached.
Permanent covers most real cases: moving to HTTPS, changing domain, consolidating www and non-www, restructuring URLs, retiring a page in favour of a replacement.
What actually differs
Ranking signals
The consequential difference. A 301 tells search engines to treat the destination as the canonical URL and pass accumulated authority to it. A 302 explicitly tells them not to.
Google has said it can eventually treat a long-lived 302 as permanent if the pattern is obvious enough. That is not a reason to rely on it — it means an indeterminate period during which the wrong URL is canonical, and there is no way to know when it resolves. Sending the correct signal from the start costs nothing.
Caching
Browsers cache 301s aggressively, often indefinitely. That is a performance benefit and an operational hazard, covered below.
302s are not cached by default, so the redirect runs on every single request. For a high-traffic URL that is a permanent round-trip tax you did not need to pay.
Request method
The distinction people forget. Historically, browsers changed a POST to a GET when following a 301 or 302 — behaviour that was never in the specification but became universal.
307 and 308 were introduced to fix exactly this. They are the strict versions: 307 is a temporary redirect that preserves the method, 308 is a permanent redirect that preserves it.
| Code | Permanent | Preserves method | Cached |
|---|---|---|---|
| 301 | Yes | No (in practice) | Yes |
| 302 | No | No (in practice) | No |
| 307 | No | Yes | No |
| 308 | Yes | Yes | Yes |
For ordinary page redirects, 301 and 302 are fine and are what everything expects. For API endpoints or anything receiving form submissions, use 308 and 307 so a POST does not silently become a GET and lose its body.
When a 302 is genuinely correct
It has real uses, and treating "always use 301" as a rule causes its own problems:
- Maintenance pages. The URL is coming back; you do not want search engines re-canonicalising to a temporary notice.
- A/B tests. You are deliberately sending some traffic elsewhere without saying the original is obsolete.
- Geographic or language routing, where the destination depends on the visitor rather than on the URL having moved.
- Login redirects, where an unauthenticated visitor goes to a sign-in page and will return.
- Temporary out-of-stock products, where the item returns and the URL should keep its history.
The test is simple: will the original URL ever serve content again? Yes means 302. No means 301.
The hazard with 301s
Because browsers cache them aggressively and often permanently, a 301 published by mistake is genuinely difficult to undo. Every browser that saw it will keep following it without asking your server, and clearing that is not something you can do remotely.
Three practical consequences:
Test with a 302 first if you are unsure. Confirm the destination is right, then switch to 301. A wrong 302 is forgotten in minutes; a wrong 301 can persist for months on individual machines.
Test in a private window. Otherwise you will keep seeing cached behaviour and conclude your fix did not work.
Be careful redirecting a homepage. A mistaken 301 on your root URL, cached in visitors' browsers, is about the worst version of this problem.
Checking what you actually have
The status code is invisible in normal browsing — the browser follows the chain silently and shows you the destination. A 301 and a 302 look identical.
Run the URL through the Redirect Checker. It follows each hop without automatic redirect handling and shows every status code and its timing, so a 302 you thought was a 301 is immediately visible.
From a terminal:
curl -sSI -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://example.com/old-page
Common mistakes worth checking for
A 302 left over from testing. Someone set it temporarily during a migration and it was never changed. This is by far the most common cause of a permanent move using the wrong code.
Redirect chains. Two rules stacking — an HTTPS upgrade and a www rule applied in sequence rather than combined. Each hop is a full round trip, and signals dilute across the chain. Collapse them into a single rule that jumps straight to the final URL.
Redirecting everything to the homepage. When retiring pages, a bulk redirect to the homepage is tempting and mostly worthless: search engines treat an irrelevant redirect as a soft 404 and pass little or nothing. Redirect to the closest equivalent page, and where there is none, returning a 410 Gone is more honest and more useful.
Redirecting to a 404. Worse than no redirect. The original URL loses its ranking and visitors get an error instead of content.
Mixing permanence within one chain. A 301 followed by a 302 makes the overall effect ambiguous. Keep a chain consistent.
In practice
Whatever issues your redirects — server config, CMS plugin, CDN rule — the code is normally a setting rather than something you compute. In Apache, Redirect permanent and RedirectMatch 301 are explicit; a bare Redirect defaults to 302. In Nginx, return 301 versus return 302. In most CMS redirect plugins it is a dropdown, and the default is frequently 302 — worth checking rather than assuming.
Trace your own redirects and confirm every hop with the Redirect Checker.