HTTP Redirect Codes: 301 vs 302 vs 307 vs 308

HTTP Redirect Codes: 301 vs 302 vs 307 vs 308

HTTP redirect codes tell the browser or crawler where to go next. The 3xx class signals that the client must take an additional step to complete the request: follow the Location header to a new URI. Four codes dominate practical use: 301, 302, 307, and 308. Choosing the wrong one has lasting consequences for SEO, client behaviour, and HTTP method semantics. A 301 is intended to be cached indefinitely by browsers and CDNs: using it for a temporary redirect can leave clients stuck at the old URL for weeks. Furthermore, 301 and 302 allow clients to downgrade POST to GET on the redirect, while 307 and 308 require the client to repeat the same method.¹ Understanding these distinctions prevents subtle bugs in form submissions, API redirects, and site migrations.

Permanent vs temporary semantics

The permanent vs temporary distinction determines caching behaviour and crawl frequency. A 301 Moved Permanently tells the client the resource has moved and the change is definitive: browsers cache the redirect and stop checking the original URL, and search engines transfer link equity to the new URL.² A 302 Found tells the client the resource is temporarily at a different location: browsers do not cache the redirect, and search engines keep the original URL indexed.

Temporary redirects during A/B tests and promotions

Using 301 for a redirect you plan to reverse causes browsers to serve the old destination from cache for weeks after you change the route. 308 Permanent Redirect is the method-preserving counterpart of 301, and 307 Temporary Redirect is the method-preserving counterpart of 302. When migrating a site permanently, use 301 or 308; for temporary changes, use 302 or 307. The cost of choosing incorrectly is not theoretical: during a promotional campaign, a cached 301 can direct users to a defunct landing page long after the campaign ends, while a 302 ensures each visitor checks the current routing and receives the up-to-date destination.

Method preservation: 307 and 308 vs 301 and 302

The key difference between the older and newer redirect codes is how they handle the HTTP method of the original request. A 301 Moved Permanently and a 302 Found both allow clients to change a POST to a GET when following the redirect, and most browsers do exactly this without prompting the user. A 307 Temporary Redirect and a 308 Permanent Redirect require the client to repeat the same HTTP method on the new URL: a POST stays a POST, a PUT stays a PUT, and a PATCH stays a PATCH.¹

Why method preservation matters

This distinction matters whenever the original request carries a body. A form submission via POST that receives a 301 redirect will be retried as a GET, losing the form body and silently corrupting the user's input. A 307 forces the browser to resend the POST to the new URL, preserving the body and ensuring the application receives the data the user originally submitted.

When a redirect must repeat the original method instead of downgrading POST to GET, preserving the request body across a 307 or 308 is the reason these two codes exist. 307 is the correct code for redirecting API endpoints that receive POST or PUT requests, because clients that follow the redirect should not silently change the method and lose the request body. The same applies to 308 for permanent redirects of stateful endpoints: choosing 301 over 308 in this scenario introduces a subtle bug that only manifests when a client submits a form or uploads a file, making it particularly hard to catch in development environments that primarily exercise GET requests.

SEO and link equity transfer

Search engine treatment of redirect codes affects how link equity passes between URLs, how quickly old URLs are deindexed, and whether the new URL is indexed at full ranking strength. A 301 redirect passes link equity to the new URL and is treated by Google as a permanent change: after several crawl cycles, the new URL replaces the old one in the index. A 302 redirect is treated as temporary and Google continues to index the original URL.²

A site migration from HTTP to HTTPS should use 301 or 308 redirects, not 302, to transfer ranking signals to the HTTPS URLs. Redirect chains (A to B to C) dilute link equity with each hop and add a round trip per hop that delays page rendering.³ Flattening redirect chains to direct A-to-C redirects preserves more equity and speeds up crawler processing. Keeping redirect chains longer than two hops is a common technical SEO debt that accumulates during site restructuring.

HSTS and permanent redirects for HTTPS enforcement

HTTP Strict Transport Security (HSTS) instructs browsers to use HTTPS exclusively for a domain after the first successful HTTPS response.⁴ Once a browser processes an HSTS header, it refuses to make HTTP requests to that domain and converts them to HTTPS internally, even before receiving a redirect. Combining a 301 or 308 redirect from HTTP to HTTPS with an HSTS header on the HTTPS response creates a layered enforcement strategy: the redirect handles the first visit, and HSTS handles all subsequent visits without a round trip.

The Strict-Transport-Security: max-age=31536000; includeSubDomains; preload header on your HTTPS responses opts the domain into HSTS preload lists maintained by browsers. Once your domain is on the preload list, browsers ship with your domain hardcoded as HTTPS-only, eliminating the initial HTTP-to-HTTPS redirect entirely for all users.⁴ Preloading is irreversible without a delisting process that takes months: only preload when you are certain all subdomains can serve HTTPS permanently.

307 versus 308 for method-preserving HTTPS redirects

For the initial HTTP-to-HTTPS redirect, use 308 Permanent Redirect rather than 301 when any routes on your site accept POST requests over HTTP. A 301 from HTTP to HTTPS allows clients to downgrade POST to GET on the redirect, losing the request body. A 308 preserves the POST method, ensuring the HTTPS version of the endpoint receives the complete request. Most HTTP-to-HTTPS redirects serve browser GET requests where method preservation does not matter, but APIs that accept HTTP POST from legacy clients need 308 to avoid silent data loss.

When to use this

Use this guide when choosing a redirect code for a site migration, an HTTPS upgrade, a URL restructuring, or an API endpoint change. Reference it to determine whether method preservation and permanent vs temporary semantics affect your use case.

Examples