HTTP 308 Permanent Redirect
HTTP 308 Permanent Redirect tells the client that the requested resource has moved permanently to the URL in the Location header — and that the same HTTP method used in the original request must be used when following the redirect. Unlike 301 Moved Permanently, the method is never changed.
Quick reference
| Code | 308 |
|---|---|
| Name | Permanent Redirect |
| Category | 3xx Redirects |
| Specification | RFC 9110 §15.4.9 |
| IANA status | Assigned |
| Method preserved | Yes — POST stays POST, PUT stays PUT |
| Client behavior | Update bookmarks/links to the new URL. Follow the redirect using the same method and body. |
| Caching | Cacheable by default. Browsers and caches store the redirect target permanently. |
| In-depth guide | HTTP 308 redirect implementation guide → |
What it means
The key distinction between 308 and 301 is how they handle non-GET methods. When a browser follows a 301 redirect, it switches any POST request to a GET at the redirect target — this was originally a quirk of browser behavior that became the de facto standard. RFC 9110 codifies this: 301 does not guarantee method preservation for POST requests.
308 closes that gap. Defined in RFC 7538 (later incorporated into RFC 9110), it guarantees the client must use the same method at the new URL. A POST to a URL returning 308 must be followed as a POST. A PUT returning 308 must be followed as a PUT. This makes 308 the correct permanent redirect for API endpoints, form submissions, and any context where the HTTP method carries semantic meaning.
Why 301 changed POST to GET historically
Early browsers implemented 301 redirects for POST as GET because the specification at the time was ambiguous, and users found it confusing when a POST was re-submitted after a redirect (e.g., a form submit followed by a redirect would re-submit the form). The behavior became standard despite being technically non-compliant with later RFC interpretations. 308 was introduced specifically to provide a permanent redirect that does not exhibit this behavior for API and machine clients.
When to use 308 vs 301
Use 308 when redirecting API endpoints, webhook receivers, form action URLs, or any URL that receives non-GET requests that must not be silently converted to GET. Use 301 for redirecting web pages, static assets, or any URL that is only accessed via GET and HEAD requests.
For browser-facing pages, 301 and 308 are largely equivalent in practice since page navigation uses GET. The distinction matters primarily for programmatic API clients and for correctness of non-idempotent method handling.
SEO implications
Google treats 308 the same as 301 for the purposes of PageRank consolidation and indexing. Both signal a permanent move and pass link equity to the destination URL. Google will index the destination and eventually drop the source URL from its index, just as with 301. Use either for SEO purposes — the method-preservation distinction only matters for non-GET requests, which search engine crawlers do not typically make.
Both 308 and 301 should be used with care: verify the destination URL resolves correctly before deploying either redirect, as incorrectly chained permanent redirects can cause SEO equity loss and are harder to undo than temporary redirects (307, 302).
308 vs 301 vs 307 vs 302
| Code | Permanence | Method preserved | Best for |
|---|---|---|---|
| 308 | Permanent | Yes | API endpoint moves, non-GET permanent redirects |
| 301 | Permanent | No (POST→GET) | Web page moves, GET-only URL changes |
| 307 | Temporary | Yes | Temporary API endpoint redirect |
| 302 | Temporary | No (POST→GET) | Temporary web page redirect |
See also: 301 vs 308 comparison
Related resources
On this site: HTTP 308 redirect implementation guide · HTTP 301 Moved Permanently · HTTP 307 Temporary Redirect · HTTP 302 Found · All 3xx redirect codes
Comparisons: 301 vs 308 · 303 vs 308
Standards: RFC 9110 §15.4.9 · IANA Registry · MDN Web Docs: 308