A 308 redirect is a permanent HTTP status code that tells browsers and search engines a URL has moved to a new location forever, while strictly preserving the original HTTP request method. If the original request was a POST, the browser sends a POST to the new location. If it was a GET, it sends a GET. The method never changes, and the move is permanent.

It belongs to the 3xx redirect family and completes a logical set of four redirect codes introduced to cover every combination of permanent versus temporary and method-preserving versus method-switching. The 308 is the permanent, method-preserving counterpart to the 307 redirect, and the method-preserving alternative to the 301 redirect.

How a 308 redirect works

When a server responds with a 308, it includes a Location header pointing to the new permanent URL. The browser follows the redirect and repeats the original request at the new location using exactly the same HTTP method and request body as the original.

Like a 301, the 308 response is cacheable by default. Browsers store the redirect and will go directly to the new URL on future visits without making a request to the original URL first. Search engines treat it as a permanent move and update their index accordingly over time.

Why the 308 exists

To understand why the 308 was introduced it helps to look at how the permanent and temporary redirect codes evolved together.

• HTTP/1.0 gave us the 301 as the permanent redirect and the 302 as the temporary redirect. Both were intended to preserve the request method, but browsers consistently switched POST requests to GET when following either of them. This inconsistency was widely accepted as standard browser behaviour even though it contradicted the specification.

• HTTP/1.1 introduced the 303 and 307 to address the temporary redirect ambiguity, 303 for explicit method switching to GET, 307 for explicit method preservation. But this still left a gap on the permanent side. There was no permanent redirect that guaranteed method preservation the way 307 guaranteed it for temporary redirects.

• The 308 was introduced to fill that gap. It is the permanent, method-preserving redirect that the HTTP specification was missing, completing the full matrix of redirect behaviour.

308 redirects and SEO

Search engines treat the 308 as a permanent redirect, similar to a 301. Googlebot and other web crawlers will follow a 308, update their index to reflect the new URL as the canonical destination, and transfer SEO equity and link juice from the old URL to the new one over time.

For standard SEO use cases: page migrations, domain rebranding, URL restructuring, both 301 and 308 are valid permanent redirect options. In practice the 301 remains the default choice for most SEO-driven redirects because it has broader browser and crawler support and has been the standard for decades. The 308 is the better choice specifically when the HTTP method matters and must be preserved through the permanent redirect.

When to use a 308 redirect

The 308 is the right choice when a resource is moving permanently and the HTTP request method must be preserved at the new location. The most common use cases are:

• Permanent API endpoint changes: when a REST API endpoint is permanently moving to a new URL and clients making POST, PUT, PATCH, or DELETE requests need to be redirected without losing their method or request body. A 301 would cause many clients to switch to GET, breaking the API. A 308 ensures the full request is repeated correctly at the new permanent location.

• Permanent form action changes: if a form’s action URL is permanently changing and the POST submission must reach the new URL intact, a 308 handles this correctly where a 301 would not.

• Webhook endpoint migrations: when permanently migrating webhook receivers to a new URL, a 308 ensures the POST payloads sent by third-party services are forwarded correctly to the new endpoint.

• Application-level permanent moves requiring method integrity: any scenario where a resource is permanently relocated and the semantics of the original HTTP method must be preserved through the redirect.

308 vs 301

This is the most important comparison to understand. Both are permanent redirects that pass SEO equity and tell search engines to update their index. The single difference is method handling.

A 301 redirect permits browsers to switch the request method from POST to GET when following the redirect. Most browsers do this in practice, and it has become the accepted behaviour even though the original specification said otherwise.

A 308 redirect strictly prohibits method switching. The browser must repeat the original request exactly, same method, same body, at the new URL. There are no exceptions and no browser-dependent inconsistencies.

For the vast majority of web redirects, page moves, domain migrations, HTTP to HTTPS, www to non-www, the method distinction does not matter because they involve GET requests from browsers navigating to pages. In these cases a 301 is perfectly appropriate and more universally supported. The 308 becomes the correct choice only when POST, PUT, PATCH, or DELETE requests need to survive the redirect intact.

308 vs 307

The 307 redirect and 308 share the same method-preservation behaviour but differ on permanence.

A 307 is temporary. Search engines keep the original URL in their index and SEO equity is not transferred to the destination. It is used when a resource has moved for now but is expected to return or change again.

A 308 is permanent. Search engines update their index to reflect the new URL and SEO equity transfers to the destination. It is used when a resource will never return to its original location.

If you are unsure whether a move is permanent or temporary, default to temporary. It is easy to upgrade a 307 to a 308 later. Changing a 308 back is harder because browsers will have cached the permanent redirect and may continue going directly to the new URL even after the redirect is removed.

Browser and client support

The 308 is a relatively newer addition to the HTTP specification compared to 301 and 302, which means browser and client support is something worth checking for older environments. All modern browsers (Chrome, Firefox, Safari, Edge) support 308 correctly. However some older HTTP clients, legacy systems, and certain server frameworks may not handle 308 as expected and could fall back to unexpected behaviour.

For consumer-facing web pages where broad compatibility is paramount, a 301 remains the safer choice. For API clients, webhooks, and modern application infrastructure where you control both ends of the connection, 308 support can be reliably assumed.

Common mistakes with 308 redirects

• Using 308 when 301 is sufficient: for standard page redirects involving browser navigation, the method distinction is irrelevant. Using a 308 adds no benefit over a 301 and may cause issues with older clients. Use 308 only when method preservation genuinely matters.

• Using 308 for temporary moves: because the 308 is permanent and cacheable, browsers will store it and skip the original URL on future visits. If there is any chance the redirect needs to be reversed or changed, use a 307 instead.

• Assuming 301 preserves POST: if your application sends POST requests to a URL that returns a 301, do not assume the POST will reach the destination intact. Most clients will switch to GET. If POST preservation is required, switch to a 308.

• Creating redirect chains: as with all redirect types, chaining 308s through multiple hops adds latency and unnecessary complexity. Always redirect directly to the final destination and regularly audit for redirect chains.