Pick the wrong redirect code and you can silently leak SEO equity, turn a POST into a GET, or cache a "temporary" redirect in browsers for months. The 3xx family looks interchangeable — they all "send the browser somewhere else" — but the differences between 301, 302, 303, 307, and 308 decide whether search engines pass ranking signals, whether the HTTP method is preserved, and whether the redirect sticks forever.
This guide explains each 3xx code, the two distinctions that actually matter (permanent vs temporary, method-preserving vs method-changing), which to use when, and how to monitor redirects so a bad one doesn't quietly cost you traffic. It completes our HTTP status series alongside 4xx client errors and 5xx server errors.
What 3xx Means
A 3xx status code is the server saying: "What you want is somewhere else — go here instead." The new location is provided in the Location response header, and the browser (or crawler) follows it, usually automatically.
The codes differ along two independent axes:
- Permanent vs temporary — is this move forever (search engines should update their index and pass ranking signals) or just for now (keep indexing the original)?
- Does the HTTP method change? — if the original request was a
POST, does the redirect re-issue it as aPOST, or downgrade it to aGET?
Almost every redirect mistake comes from getting one of those two axes wrong.
The 3xx Codes at a Glance
| Code | Meaning | Permanent? | Method preserved? | Passes SEO signals |
|---|---|---|---|---|
| 301 | Moved Permanently | Yes | Not guaranteed (often → GET) | Yes |
| 302 | Found (temporary) | No | Not guaranteed (often → GET) | No (keeps original indexed) |
| 303 | See Other | No | No — forces GET | No |
| 307 | Temporary Redirect | No | Yes — method preserved | No |
| 308 | Permanent Redirect | Yes | Yes — method preserved | Yes |
| 304 | Not Modified (caching) | — | — | n/a (not a redirect) |
A useful mnemonic: 301/302 are the "classic" pair (method behavior historically inconsistent), while 307/308 are the "strict" modern equivalents that guarantee the method is preserved. 303 is the odd one that always switches you to GET.
301 — Moved Permanently
The page has permanently moved to a new URL. This is the workhorse of site migrations, HTTP→HTTPS upgrades, and URL restructures.
- SEO: Search engines transfer ranking signals to the new URL and update their index. This is the redirect you want when consolidating or moving content for good.
- Caching: Browsers cache
301s aggressively — often indefinitely. That's the catch: if you set a301by mistake, returning visitors may keep getting redirected long after you've fixed the server, because their browser never re-checks. Never use a301for anything you might reverse. - Method caveat: Historically, browsers often changed
POSTtoGETon a301. If method preservation matters, use308.
Use it for: permanent moves where you want SEO equity to follow — migrations, canonicalization, HTTPS enforcement.
302 — Found (Temporary)
The resource is temporarily at a different URL. The original is still the "real" one.
- SEO: Search engines keep the original URL indexed and generally don't pass ranking signals to the target. Using a
302for a permanent move is one of the most common — and costly — SEO mistakes: you move a page, slap a302on it, and wonder why the new URL never ranks. - Method caveat: Like
301, browsers historically may switchPOSTtoGET. For guaranteed method preservation, use307.
Use it for: A/B tests, temporary promos, geo/device routing, "back in a minute" maintenance detours — anything genuinely temporary.
303 — See Other
Tells the client to fetch the target with a GET, always, regardless of the original method.
Its classic job is the Post/Redirect/Get (PRG) pattern: a user submits a form (POST), and you respond with a 303 pointing at a confirmation page. The browser fetches that page with GET, so a refresh doesn't re-submit the form. It's about controlling method, not SEO.
Use it for: redirecting after a form submission so reloads don't double-submit.
307 — Temporary Redirect
The strict, modern version of 302: temporary and the HTTP method and body are guaranteed preserved. A POST stays a POST.
- SEO: Temporary — original stays indexed, like
302. - Why it exists: to remove the method ambiguity of
302. If you're temporarily redirecting an API endpoint or a form target and must keep thePOST,307is correct.
Use it for: temporary redirects where the method must not change (APIs, form posts). Also what HSTS uses internally to force HTTPS.
308 — Permanent Redirect
The strict, modern version of 301: permanent and method-preserving.
- SEO: Permanent — passes ranking signals like
301. - Why it exists: a permanent move that must keep
POSTasPOST. For a plain content page move,301is still the convention and is universally understood; reach for308when method preservation genuinely matters (e.g., permanently relocating an API endpoint).
Use it for: permanent moves where the method must be preserved.
Which Redirect Should I Use?
A quick decision guide:
- Permanent move, want SEO to follow →
301(or308if you must keep the method). - Temporary detour →
302(or307if you must keep the method). - After a form POST, to stop re-submits →
303. - HTTP → HTTPS, www canonicalization, retiring old URLs →
301. - Never use a permanent code (
301/308) for something you might undo — the aggressive caching will haunt you.
Note on
304 Not Modified: it lives in the 3xx range but isn't a redirect. It's a caching response telling the browser its cached copy is still fresh, so no body is sent. Different mechanism entirely.
How Redirects Go Wrong (and Why Monitoring Matters)
Redirects are deploy-time configuration, which means they break silently and you rarely find out until traffic drops:
302used for a permanent move — the new URL never accrues ranking; you lose organic traffic with zero error in your logs.- Redirect chains —
A → B → C → D. Each hop adds latency and dilutes SEO signals. A migration that stacks redirects on top of old redirects is death by a thousand hops. See redirect chain monitoring. - Redirect loops —
A → B → AreturnsERR_TOO_MANY_REDIRECTSand the page is simply dead. - Accidental permanent caching — a mistaken
301that browsers refuse to forget. - Mixed HTTPS/redirect misconfig — endless HTTP↔HTTPS bouncing.
- Redirecting to a
404or5xx— the redirect "works" but lands on a broken page (4xx / 5xx).
The insidious part: a wrong redirect code returns no error. The request succeeds, the page loads — and only weeks later does the ranking drop show up in analytics. That's why redirects need active monitoring, not just a one-time check after launch. Migrations are the highest-risk moment — pair this with a migration monitoring checklist.
How Webalert Helps
Webalert watches your redirects so a wrong code or broken hop doesn't quietly cost you traffic:
- Status code monitoring — alert when an endpoint returns an unexpected 3xx (or a redirect that should be
301starts returning302). - Redirect chain & loop detection — catch added hops and loops after a deploy, before they bleed SEO equity. See redirect chain monitoring.
- Final-destination validation — confirm a redirect actually lands on a healthy
200, not a404/5xx. - Migration safety — verify your redirect map behaves as designed during HTTP→HTTPS or domain moves (migration monitoring).
- Fast alerting to Slack, email, and SMS the moment redirect behavior changes.
For the rest of the HTTP status landscape, see HTTP status codes explained.
Summary
The 3xx family splits along two axes: permanent (301/308) vs temporary (302/307/303) and method-preserving (307/308) vs not (301/302, and 303 which always forces GET). Use 301 for permanent moves you want SEO to follow, 302 for genuine temporary detours, 303 after form posts, and the strict 307/308 when the HTTP method must be preserved.
Get the code right, avoid chains and loops, and never use a permanent redirect for something reversible. Then monitor your redirects continuously — because a wrong 3xx throws no error and the only symptom is traffic you slowly stop receiving.