English
Deutsch
PolskiChoosing the Right Website Redirect: 301, 302, 307 and 308 Explained
Management Summary
A redirect tells a browser or another program that the requested resource is available at a different address. This is common when websites move, but the choice matters especially for submitted forms. Some redirects may turn a data submission into an ordinary page request and lose its original content. The article explains why codes 307 and 308 preserve the request type for temporary and permanent moves, while 301 and 302 can behave differently. The right choice helps keep submissions intact.
Contents
A redirect asks a client to use another URL. Two decisions matter: whether the move is permanent, and whether the next request should repeat the original method and body. GET commonly requests a page; POST commonly sends data such as a completed form. The distinction is especially important for forms and APIs.
Receiving a redirect does not prove that a client followed it or that the destination accepted the data. Browser behavior, library settings and the whole chain need separate checks.
Two questions, four common status codes
| Code | Meaning | POST handling |
|---|---|---|
| 301 | Permanent move | HTTP permits a change to GET; browsers normally make that change. |
| 302 | Temporary destination | HTTP permits a change to GET; browsers normally make that change. |
| 307 | Temporary destination | An automatically followed request must keep its method. |
| 308 | Permanent move | An automatically followed request must keep its method. |
With a POST-to-GET change, the original request body is not resent. For 307 and 308, following the redirect normally resends the body; a client can instead refuse to follow or fail when the body cannot be replayed. Method preservation does not guarantee identical cookies, authentication headers or application results.
303 See Other serves a different purpose: after processing a POST, the server can point to a result page retrieved with GET. This is useful for a post/redirect/get flow. It is not the code for resending the same form submission to another endpoint.
What happens at each hop
The Location field can contain a relative URI reference, resolved against the request URL. If following is enabled, the client makes another request. A redirect response may contain a body, which can be inspected or displayed when automatic following is disabled. Not every 3xx response is a navigation redirect: 304, for example, concerns reuse of a stored response.
An extra network request adds work, but does not necessarily require another DNS lookup or connection. DNS caches, connection reuse and HTTP caches affect the cost. HSTS can also upgrade HTTP locally without a server returning a 301. A fixed number of milliseconds per hop is therefore not a general rule.
Caching is not the same as permanence
301 and 308 are eligible for heuristic caching under the HTTP caching rules. Temporary responses such as 302 can also be cached when suitable explicit freshness information is present. Temporary does not mean “never stored”. Request method, cache directives and other restrictions still matter.
Cache-Control: max-age=3600 specifies a freshness lifetime, not guaranteed deletion after one hour. A stale response can remain stored and be revalidated; other rules can affect reuse. Changing the origin rule does not instantly recall a previously cached redirect from every client.
A mistaken permanent redirect needs a coordinated correction. Sending the destination back to the old URL can create a loop for clients still holding the first redirect. Tests should cover fresh and existing cache states, while links and clients are updated to the intended final URL.
Search signals are not guaranteed rankings
Google treats permanent redirects as a strong signal for the target as canonical, the main URL selected for indexing, and temporary redirects as a weaker signal. This is not a promise that a 302 keeps the old URL indexed forever or that a 301 transfers a specific ranking immediately. Recrawling and other signals remain relevant.
Google’s migration guidance says permanent redirects do not inherently lose PageRank. Shortening chains is still useful for latency, reliability and crawler limits; a claim that ranking credit necessarily leaks at every hop is misleading. Direct redirects to the correct final destination are preferable where the required behavior permits them.
Cookies, referrers and authentication
An origin consists of the scheme, hostname and port, without the page path. A hostname change does not automatically erase the Referer header. With the common strict-origin-when-cross-origin policy, a secure cross-origin request usually retains the origin while dropping the path; a downgrade to HTTP omits it. The actual policy and request context decide the result.
A host-only cookie does not extend to subdomains. A valid Domain attribute can include subdomains, subject to Path, Secure, SameSite and browser policies. Credentials and authorization headers have additional redirect restrictions. Testing only the final page title cannot establish preservation of a login or API authorization.
A small reproducible method check
An isolated loopback test with curl 8.14.1 sent the harmless body test=1 to five synthetic redirects. With normal --location --data test=1, 301, 302 and 303 arrived as GET with an empty body; 307 and 308 arrived as POST with the body intact. Adding curl’s explicit --post301 kept POST after 301. This illustrates why client settings matter.
The test covers that curl configuration only. It does not measure browser caches, real forms, external websites or credential forwarding. No historical twelve-site results are presented as a verified measurement here.
The whole chain
A useful record lists the initial URL and method, every status and Location, the final URL, final method, request-body handling and final response status. A 403 at the destination is an access refusal, not proof of a particular redirect cause. A redirect loop or a client’s hop limit can stop the chain before a final page exists.
A GET-based indexing checker is useful for URL routing, but does not prove POST behavior. Form and API migrations need the actual supported client and harmless test data. For a permanent endpoint move, 308 is a suitable method-preserving signal, while updating clients to the new URL avoids ongoing dependence on redirect support.
Questions and answers
Why does a 303 after a form submission prevent the data from being sent again on reload?
After a 303 response, the browser fetches the result page with GET, and that GET request is then what a reload repeats. The form data therefore does not reach the server a second time. This does not protect against a double click on the submit button, though; that needs a separate check in the application.
An API endpoint is moving permanently. Is a 308 redirect enough?
As a transition, yes; as a permanent solution, rarely. A 308 states that the move is permanent and that the method must be preserved if the client follows the redirect automatically. Whether it does depends on the client: some libraries do not follow redirects at all or only after a setting is changed, and a request body that cannot be read again, such as a stream, can fail on the second send.
Authentication and caching add to this. Credentials and Authorization headers are subject to their own redirect limits; when the host changes, many clients do not forward them, and the new endpoint then rejects the request even though the method is correct. A 308 is also eligible for heuristic caching, so a mistaken permanent redirect can stay in effect for some clients after the server rule has been changed.
A reliable check therefore uses the clients that actually call the API, with harmless test data, logged through to the final method and response status. After that, clients should use the new address directly; the redirect then only catches stragglers.
Sources
Related articles
