When managing a website, you'll inevitably encounter situations where you need to temporarily redirect users from one URL to another. Whether you're performing server maintenance, testing new pages or handling temporary content changes, understanding 307 redirects becomes crucial for maintaining a smooth user experience while preserving your site's technical integrity.
A 307 redirect is a specific type of HTTP status code that tells browsers and search engines that a requested resource has been temporarily moved to a different location. Unlike permanent redirects, these temporary redirect signals indicate that the original URL will eventually become active again, making them perfect for short-term scenarios where you need to guide traffic elsewhere without permanently altering your site's structure.
What is a 307 redirect?
A 307 redirect is a temporary HTTP redirect that preserves the original request method. It’s most useful when you need to redirect users or requests for a short time without changing a POST request into a GET request. This redirect type belongs to the 3xx family of HTTP status codes, specifically designed to handle redirection scenarios where the client should repeat the exact same request to the new location.
The key characteristic that distinguishes 307 redirects from other redirect types is method preservation. When a browser encounters a 307 redirect, it maintains the original HTTP method (GET, POST, PUT, DELETE) when making the subsequent request to the new URL.
- GET retrieves data.
- POST submits new data.
- PUT updates existing data.
- DELETE removes data from a server.
This behavior ensures that form submissions, API calls and other method-specific requests continue functioning correctly after redirection.
Server redirects using the 307 status code communicate temporary relocation without suggesting any permanent change to the original URL's status. Search engines interpret this signal as an indication that they should continue indexing the original URL while temporarily following the redirect for content retrieval. This approach helps maintain your site's search engine optimization value during temporary changes.
A 308 redirect is the permanent version of a 307 redirect, meaning it preserves the original request method while signaling that the resource has moved permanently.
Modern web browsers handle 307 redirects automatically, creating a seamless experience for users who may not even realize they've been redirected. The browser receives the 307 response, reads the Location header containing the new URL and immediately requests content from that destination using the same HTTP method as the original request.
How 307 redirects work
The technical process behind 307 redirects involves a specific sequence of HTTP communications between the client and server. When a user's browser requests a URL that has been configured with a 307 redirect, the server responds with the 307 status code along with a Location header specifying where the browser should redirect the request.
Here's what happens during a typical 307 redirect process: the browser initiates a request to the original URL using a specific HTTP method. The server processes this request and determines that a 307 redirect should be applied. Instead of serving the requested content, the server sends back a response with the 307 status code and includes the new destination URL in the Location header.
Upon receiving the 307 response, the browser automatically creates a new request to the specified location. Crucially, this new request uses the same HTTP method as the original request, ensuring that POST requests remain POST requests, GET requests stay as GET requests and so forth. This method of preservation prevents issues with form submissions and API interactions that might break if the request method changes during redirection.
The destination server receives the redirected request and processes it normally, returning the appropriate content to the browser. From the user's perspective, this entire process happens transparently, with the browser's address bar showing the final destination URL.
This preservation of request methods makes 307 redirects particularly valuable for web applications that handle user-submitted data through forms or API endpoints. Unlike 301 and 302 redirects, which commonly cause browsers to change a POST request into a GET request, a 307 redirect requires the original request method to stay the same throughout the redirect.
302 vs 307 redirect differences
Both 302 and 307 indicate a temporary redirect, but they differ in how they handle the original HTTP request method.
A 302 redirect does not guarantee that the original request method will be preserved and in practice, browsers often change POST requests to GET when following it. That is usually fine for standard page loads, but it can cause problems for form submissions or API requests that depend on the original method.
When a 302 turns a POST into a GET, it changes both how the data is sent and what the server expects, which can break things in a few ways:
Form submissions lose their data
A POST request sends form data in the request body. If it gets converted to a GET, that body is dropped. The redirected request reaches the new URL without the submitted data, so the form either fails or submits incomplete information.

APIs receive the wrong request type
Many API endpoints are method-specific (e.g., POST to create, PUT to update). If a POST becomes a GET, the endpoint may reject the request (e.g., 405 Method Not Allowed) or return the wrong response entirely.

Side effects don’t happen
POST requests often trigger actions like creating a record, processing a payment or sending data. If the method changes to GET, those actions may never execute because the server treats it as a read-only request.
Unexpected or invalid behavior
Some systems rely on request bodies, headers or authentication tied to POST requests. Converting to GET can strip or alter that context, leading to errors or inconsistent results.
A 307 redirect, by contrast, preserves the original HTTP method. If the first request was a POST, PUT or DELETE, the redirected request uses that same method at the new URL. This makes 307 the safer choice when request behavior must remain unchanged.
| Redirect | Temporary? | Preserves method? | Best for |
|---|---|---|---|
| 302 | Yes | No | General temporary page redirects |
| 307 | Yes | Yes | Temporary redirects where the request method must stay the same |
When to use 307 redirects
One common use case is maintenance. If server updates, database work or other short-term issues make a page or endpoint unavailable, a 307 can temporarily send traffic to a maintenance page or alternate location without signaling a permanent change.
307 redirects are especially useful for form handling. If you temporarily move a form submission endpoint, a 307 ensures the browser repeats the request using the same method, such as POST, which helps prevent broken submissions or lost data.
They can also help with load balancing or temporary server distribution. If one server is overloaded or unavailable, a 307 can route requests to another server while preserving the original request behavior.
Other good use cases include testing and staging and some temporary migration scenarios, where you need to reroute traffic for a short time without permanently changing the original URL structure.
When not to use a 307 redirect
Do not use a 307 redirect for a permanent move. In that case, use a 301 for standard page redirects or a 308 if the request method must be preserved. You also do not need a 307 for a simple temporary page redirect where the request is just a normal GET request. In those cases, a 302 is usually sufficient.
SEO considerations for 307 redirects
A 307 redirect tells clients that a resource has moved temporarily and that the original HTTP request method must be preserved. That distinction matters for browsers and API clients, but for search crawling, it usually does not change the SEO outcome. Google treats 307 Temporary Redirect as equivalent to 302 Found: it follows the redirect, but uses it only as a weak canonicalization signal, unlike 301 and 308, which are treated as permanent moves.
The reason 307 rarely changes crawler behavior is simple: search and AI crawlers generally retrieve pages with safe request methods. HTTP defines GET and HEAD as safe methods and explicitly notes that this distinction exists so automated retrieval processes, such as crawlers can fetch content without triggering unsafe actions. Common Crawl documents this directly by stating that CCBot fetches pages with HTTP GET requests. Google’s public crawler documentation likewise describes crawlers that fetch and process page content, not clients that submit forms or call write-oriented endpoints.
That means 307 usually provides no special ranking benefit over 302 for normal page URLs. If Googlebot or another crawler is making a GET request, a 302 and a 307 both lead to the same practical SEO result: the crawler follows the temporary redirect and the original URL generally remains the one associated with the move unless other signals point elsewhere. Use 307 when method preservation matters for users or applications, not because you expect extra SEO value.
POST requests are a different case, but mostly outside normal SEO crawling. Public web crawlers are designed to retrieve documents, not submit forms or trigger server-side actions. If a workflow requires POST to reveal content, that content is generally not accessible as a standard crawlable page. PUT and DELETE matter even less in this context: they are unsafe methods for updating or removing resources and they are not part of normal search indexing flows.
The practical rule is straightforward: use 302 or 307 when a move is temporary and choose 307 specifically when non-GET requests must stay unchanged. For SEO alone, Google treats 307 like 302. For application correctness, 307 is the safer option when a redirected request must remain a POST, PUT or DELETE.
Common mistakes with 307 redirects
The most common mistake is using a 307 redirect for a move that is no longer temporary. If the new URL is permanent, use 308 or 301 so search engines receive a permanent signal instead of a temporary one. Google’s documentation is clear that temporary redirects and permanent redirects are processed differently for canonicalization.
Another mistake is assuming that 307 improves rankings because it is more technically precise than 302. It is more precise at the HTTP level, because RFC 9110 says a 307 redirect must not change the request method, but Google still treats it as the temporary equivalent of 302 for Search.
A third mistake is overexplaining POST, PUT and DELETE behavior in an SEO section. For most readers, the important point is simply that crawlers mostly fetch pages with safe retrieval methods, so 307’s method-preservation benefit is usually about application behavior rather than search rankings.
Final thoughts
Understanding 307 redirects ultimately comes down to using the right redirect for the right situation. Because a 307 is meant for temporary redirects that preserve the original request method, it is most useful in technical scenarios like form submissions, API requests and short-term infrastructure changes.
For most teams, the broader goal is to manage redirects in a way that keeps user journeys smooth, protects site performance and avoids unnecessary complexity.
Frequently asked questions about 307 redirects
What is a 307 redirect and when should I use it?
A 307 redirect is an HTTP status code that indicates a temporary move of a resource to a different URL while preserving the original request method. You should use 307 redirects when you need to temporarily redirect traffic during maintenance, testing or other short-term scenarios where the original URL will eventually become active again. They're particularly useful for preserving form submissions and API calls that require specific HTTP methods.
What's the difference between 307 and 302 redirects?
The main difference lies in how they handle HTTP request methods during redirection. A 302 redirect allows browsers to change the request method, often converting POST requests to GET requests, which can break form submissions. A 307 redirect explicitly requires browsers to maintain the same HTTP method throughout the redirection process, making it safer for applications that handle user-submitted data or API interactions.
What’s the difference between 307 and 308 redirects?
Both 307 and 308 redirects preserve the original HTTP request method (like POST or PUT), but they differ in intent. A 307 redirect is temporary, meaning the original URL is expected to be used again. A 308 redirect is permanent, indicating the resource has moved for good and future requests should use the new URL.
How do I implement a 307 redirect on my server?
Implementation depends on your server technology. In Apache, use RewriteRule with the R=307 flag, in Nginx use the "return 307" directive and in application code use appropriate functions to set the 307 status code and Location header. The key is ensuring your server responds with the 307 status code along with a Location header pointing to the destination URL.
Do 307 redirects pass SEO value?
Unlike permanent redirects, 307 redirects don't transfer ranking signals to the destination URL. Search engines treat them as temporary moves and continue to index the original URL while following the redirect to access current content. This means the original URL retains its search engine value, which is beneficial if you plan to restore the original content later.
When should I use 307 instead of 301 redirects?
Use 307 redirects when the move is temporary and you plan to restore the original URL's functionality. Examples include maintenance windows, temporary testing periods or short-term content changes. Use 301 redirects when content permanently moves to a new location and you want search engines to transfer ranking signals to the new URL.
Are 307 redirects bad for SEO performance?
307 redirects aren't inherently bad for SEO, but they can impact performance if overused. They require additional HTTP requests, which increases page load time and consumes more crawl budget since search engines must process both original and destination URLs. When used appropriately for genuine temporary scenarios, they help maintain SEO value during transitions without negative long-term effects.


















