HTTP Redirect Codes
Deep-dive on 301, 302, 303, 307, 308 — differences, use cases, SEO implications, browser caching behavior, and common mistakes.
| Code | Name | Permanent? | Method preserved? | Browser-cached? | SEO equity passed? |
|---|---|---|---|---|---|
| 301 | Moved Permanently | Yes | No (→ GET) | Yes | Yes |
| 302 | Found | No | No (→ GET) | Sometimes | Partial |
| 303 | See Other | No | Always GET | No | No |
| 307 | Temporary Redirect | No | Yes | No | Partial |
| 308 | Permanent Redirect | Yes | Yes | Yes | Yes |
301
Moved Permanently
The resource has permanently moved to a new URL. Clients should update their links.
Permanent
Yes
Method preserved
No — converts to GET
Browser caches
Yes (indefinitely)
SEO equity
Passed to new URL
RFC
RFC 9110 §15.4.2
When a browser (or crawler) receives a 301, it updates its bookmark/cache to the new location permanently. Most browsers will never re-check the old URL — the redirect is stored locally. POST requests are typically reissued as GET to the new URL (not standards-compliant but universally implemented). Use 301 for domain migrations and permanent URL restructuring.
Use cases
- Migrating a site to a new domain (example.com → newdomain.com)
- Consolidating www/non-www to a canonical version
- Permanently restructuring URL paths (/old-path → /new-path)
- Redirecting HTTP to HTTPS (though 308 preserves method)
Common mistakes
- Using 301 for temporary A/B tests — the redirect gets cached and is hard to undo
- Forgetting that browsers cache 301s aggressively; clearing requires cache busting or user action
- Using 301 for POST-redirect-GET flows — use 303 instead
Example response
HTTP/1.1 301 Moved Permanently Location: https://www.example.com/new-path Cache-Control: max-age=31536000
302
Found
Temporary redirect. The resource is temporarily at a different URL — use the original URL for future requests.
Permanent
No
Method preserved
No — converts to GET
Browser caches
Only with explicit Cache-Control
SEO equity
Partial / inconsistent
RFC
RFC 9110 §15.4.3
302 is the most overloaded and misunderstood redirect. Originally meant to preserve method (like 307), all browsers historically switched POST to GET. Clients should not cache 302 unless Cache-Control/Expires headers say so. Crawlers treat 302s as temporary — PageRank is not transferred. In practice, use 307 when you want explicit "temporary + method preserved" semantics, and 303 for POST-redirect-GET.
Use cases
- Maintenance pages where the site will return to the original URL
- Login walls — redirect to /login, then back after auth
- Feature flags routing users to different pages temporarily
Common mistakes
- Using 302 when you mean 301 — search engines won't pass link equity
- Relying on 302 to preserve POST method — use 307 for that
- Long-lived 302s that should have been 301s from the start
303
See Other
Always redirects as GET. The canonical response to a POST that should show a different resource.
Permanent
No
Method preserved
Always GET
Browser caches
No
SEO equity
Not applicable
RFC
RFC 9110 §15.4.4
303 is the correct code for the Post/Redirect/Get (PRG) pattern. After a form submission (POST), the server responds 303 → redirect to a confirmation page (GET). This prevents the "resubmit form?" browser prompt on back/refresh. The redirect always becomes a GET regardless of the original method. Unlike 301/302, 303 was explicitly designed for method-changing redirects.
Use cases
- Post/Redirect/Get (PRG) — form submission → confirmation page
- After creating a resource via POST, redirect to the new resource
- OAuth callbacks — after POST auth, redirect to the app as GET
PRG pattern
POST /submit-order → 303 See Other Location: /order/12345/confirmation GET /order/12345/confirmation ← 200 OK
307
Temporary Redirect
Temporary redirect that explicitly preserves the HTTP method and body.
Permanent
No
Method preserved
Yes
Browser caches
No (without explicit headers)
SEO equity
Partial
RFC
RFC 9110 §15.4.8
307 is the HTTP/1.1 fix for 302's method-changing behavior. The browser must resend the same method (POST, PUT, DELETE, etc.) and the same request body to the new URL. This is important for APIs where you can't afford to lose the original method. Browsers may ask the user for confirmation before resubmitting a POST — unlike GET redirects which are silent.
Use cases
- API endpoints that temporarily move — preserve PUT/POST/DELETE body
- Temporary HTTP → HTTPS redirect where the POST body must survive
- Load balancer failover to a backup server, same method required
Common mistakes
- Confusing 307 with 302 — they look similar but 307 strictly preserves method
- Using 307 for PRG (post-redirect-get) — use 303 so the browser issues GET
308
Permanent Redirect
Permanent redirect that preserves the HTTP method and body. The 301 equivalent for non-GET methods.
Permanent
Yes
Method preserved
Yes
Browser caches
Yes
SEO equity
Passed to new URL
RFC
RFC 9110 §15.4.9
308 combines the permanence of 301 with the method-preservation of 307. The browser caches the redirect permanently and resends the original method and body. It's the cleanest choice for permanent HTTP → HTTPS migrations where you want POST requests to stay POST. Browser support is excellent in modern browsers (IE is the exception).
Use cases
- Permanent HTTP → HTTPS migration where POST bodies must not be lost
- Permanent API endpoint moves where method matters (REST APIs)
- Domain migrations for services that accept non-GET requests
Common mistakes
- Using 308 without testing in older browsers — IE11 does not support it
- Forgetting that 308 is cached permanently — same caveats as 301