308 Permanent Redirect 3xx

What does 308 mean?

A 308 Permanent Redirect is to 301 what 307 is to 302: it carries the same "this has permanently moved, transfer ranking signals to the new URL" meaning as 301, but with a spec-guaranteed promise that the HTTP method and request body are preserved when the client follows the redirect.

308 is the newest of the four primary redirect codes (301, 302, 307, 308), introduced specifically to give developers a permanent-redirect option that doesn't carry 301's historical ambiguity around method preservation — useful any time a permanent redirect needs to apply cleanly to POST, PUT, or DELETE requests, not just GET.

How a 308 behaves

• It includes a Location header pointing to the new permanent URL, same as 301
• The method and body are guaranteed to be preserved — a POST redirected via 308 must be repeated as a POST (with the same body) at the new URL
• It's cached aggressively, like 301 — clients may remember the redirect long-term, since it represents a permanent change
• Search engines transfer ranking signals, same as 301 — 308 carries full SEO-equivalent weight to 301 for permanence purposes
• It's the most "modern" of the four redirect codes but is functionally a precise superset of 301's intent for non-GET requests

Common causes

If you're building the API or website:

• You're permanently moving an API endpoint that accepts POST/PUT/DELETE requests, and need clients to retry with the same method and body at the new location without any ambiguity
• A permanent domain or path restructuring affects endpoints that aren't just simple GET pages — e.g., a webhook receiver URL that's permanently moving and must continue accepting POST payloads at the new address
• HTTPS upgrades for non-GET requests sometimes use 308 to permanently redirect HTTP to HTTPS while guaranteeing POST bodies survive the redirect

If you're calling an API:

• An API provider has permanently relocated an endpoint (e.g., during a major version migration) and is using 308 to ensure your existing POST/PUT integration continues working at the new URL without modification, other than updating the URL you originally requested

If you're a website visitor:

• Functionally invisible for typical browsing — like 307, this mostly matters for non-GET requests that aren't part of normal page navigation

How to fix it / use it correctly

As an API/website builder:

• Use 308 instead of 301 specifically when the redirected resource accepts non-GET requests and you need to guarantee the method/body survive the redirect — for purely GET-based page redirects, 301 remains perfectly adequate and far more universally recognized
• For API endpoint migrations involving webhooks or other POST-receiving endpoints, 308 is the more precise choice than 301
• As with 301, only use 308 when you're confident the move is genuinely permanent — clients may cache it aggressively

As an API consumer:

• Update your integration to point directly at the new URL once you discover a 308 redirect, rather than continuing to rely on the redirect indefinitely — 308 (like 301) implies the old URL may eventually stop being supported
• Confirm your HTTP client correctly follows 308 redirects while preserving method/body — most modern libraries handle this correctly, but older or custom clients built before 308 was standardized might not

As a website visitor:

• Nothing to do — handled transparently by your browser/client

301 vs 302 vs 307 vs 308

Real-world examples

API providers undergoing major version migrations (e.g., moving all /v1/ endpoints to /v2/ permanently) sometimes use 308 specifically for endpoints that receive webhooks or other POST-based integrations, ensuring third-party systems sending data to the old URL continue working correctly at the new one without losing their payloads. Some HTTPS-enforcement configurations use 308 instead of 301 specifically to guarantee that POST-based form submissions and API calls aren't broken when permanently upgrading HTTP URLs to HTTPS.

SEO implications

308 carries the same SEO weight as 301 — search engines treat it as a permanent move and transfer ranking signals to the new URL accordingly. For typical page-level redirects (which are GET requests), there's no practical SEO difference between using 301 or 308; 301 remains far more commonly recognized and used simply due to its age and ubiquity. 308's value is specifically for non-GET, permanent redirects.

FAQ

What's the actual difference between 301 and 308?

Both signal a permanent move with full SEO ranking-signal transfer. The difference is that 308 guarantees the HTTP method and request body are preserved when following the redirect, while 301 historically doesn't guarantee this for non-GET requests.

Should I switch all my 301 redirects to 308?

Not necessary for typical page redirects (GET requests), where the practical difference is negligible and 301 remains more universally recognized. 308 is worth using specifically for permanent redirects of endpoints that receive POST/PUT/DELETE requests with bodies that must survive the redirect intact.

Is 308 as well-supported as 301?

301 has been supported since the earliest days of HTTP and is universally recognized by every client, browser, and search engine. 308 is newer (standardized considerably later) but is well-supported by modern browsers, HTTP libraries, and search engines at this point — the main consideration is whether any older clients in your specific ecosystem might not handle it correctly.

Does 308 affect caching differently than 301?

Both are treated as cacheable, permanent redirects by clients and can be remembered long-term, similar to 301. The caching behavior itself isn't meaningfully different between the two — the distinguishing feature of 308 is method/body preservation, not caching behavior.

When would I actually need 308 over 301?

Specifically when permanently redirecting an endpoint that receives non-GET requests (a webhook receiver, an API endpoint accepting POST/PUT) and you need certainty that the method and body will be preserved at the new location, rather than risking a client converting the request to a GET and losing the payload.

Fun fact

308 and 307 were both introduced in the same specification update, explicitly designed as a matched pair — they're essentially "301 and 302, but with the ambiguity removed," making them one of the cleanest examples in HTTP of new codes being added not to introduce new concepts, but to make existing concepts behave more predictably.