302 Found: The Temporary Redirect, and When It Is the Right Answer

A 302 Found response tells the client the resource it asked for is temporarily available at a different URL, given in the Location header. The browser follows it automatically, and crucially, keeps treating the original URL as the real one.

Redirects are the part of HTTP most likely to be configured once by someone who has left, and then inherited by people who assume every redirect is the same. They are not. The difference between 301, 302, 307, and 308 is two independent questions — is this permanent, and does the method survive — and getting either wrong causes problems that surface weeks later.

What the status code actually says
The POST-to-GET quirk that trips people up
Choosing between 301, 302, 307, and 308
When a 302 is genuinely correct
The SEO question, answered honestly
Finding what emitted the redirect
How this fits the rest of the stack
FAQ

What the status code actually says

A 302 carries a Location header with the URL to go to instead. The response looks like this:

HTTP/1.1 302 Found
Location: https://example.com/maintenance
Content-Length: 0

The name Found is a historical oddity — in the original specification the code meant Moved Temporarily, and the rename to Found made it considerably less descriptive. Read it as temporarily elsewhere and it makes sense.

Temporary is the operative word. It is an instruction to the client not to update anything: do not change the bookmark, do not rewrite the link, come back to this URL next time. That is the entire difference from a 301, which says the opposite.

Browsers do not cache a 302 by default, which is what makes it safe for something that changes. They do cache a 301 aggressively and often indefinitely, which is what makes a mistaken 301 so painful to undo.

The POST-to-GET quirk that trips people up

Here is the behaviour that surprises people. The specification says a client receiving a 302 in response to a POST should repeat the request to the new URL using POST. In practice, essentially every browser converts it to a GET, and has done since the 1990s. The specification eventually acknowledged reality and permits it.

Most of the time this is what you want. A form posts, the server processes it, and redirects to a confirmation page which should obviously be fetched with GET. This is the Post/Redirect/Get pattern, and it exists so that refreshing the confirmation page does not resubmit the form.

It becomes a problem when you are redirecting an API call. A client POSTs JSON to an endpoint, receives a 302, follows it, and arrives with a GET and no body. The request silently loses its payload and the server sees something it did not expect. Debugging that from the API-consumer side is genuinely unpleasant, because the failure has no obvious connection to a redirect.

Two codes exist to remove the ambiguity. Use 307 Temporary Redirect when the method and body must be preserved exactly. Use 303 See Other when you explicitly want the follow-up to be a GET regardless of the original method. For APIs, 307 is almost always the correct choice, and it is worth changing over even if the current 302 appears to work with your particular client.

Choosing between 301, 302, 307, and 308

Two axes, four codes. Permanent or temporary, method-preserving or not.

301 Moved Permanently — permanent, method may change to GET. The default for a URL that has genuinely moved for good.
308 Permanent Redirect — permanent, method strictly preserved. Use when a POST endpoint has permanently relocated.
302 Found — temporary, method may change to GET. Fine for browsers and web pages.
307 Temporary Redirect — temporary, method strictly preserved. The right choice for APIs and anything non-GET.

The practical advice is short. For a page a human visits that has moved permanently, use 301. For anything temporary, prefer 307 over 302 unless you specifically want the method to become GET. For a form submission that should land on a confirmation page, 303 states your intent precisely.

Consistency matters more than perfection here. A codebase where every redirect is a deliberate 301, 303, or 307 is easier to reason about than one where the framework default was accepted everywhere and nobody knows which are intentional.

When a 302 is genuinely correct

The SEO folklore around 302s has made people nervous about a status code that is often exactly right. Legitimate uses:

Maintenance. The real page is coming back; you do not want anyone caching the maintenance URL as its replacement.
A/B tests routing a share of traffic to a variant. The canonical URL has not moved.
Authentication bounces. An unauthenticated visitor is sent to a login page and will return.
Geographic or language routing where the original URL remains the correct entry point.
A temporary campaign page replacing a section for two weeks.
Regional stock or availability redirects that reverse when inventory changes.

In each of those, the original URL is still the canonical one and you want search engines and bookmarks to keep pointing at it. That is precisely what a 302 communicates. Using a 301 here would be the actual mistake.

The SEO question, answered honestly

The old advice was that 302s do not pass link equity and will damage rankings. That is no longer how it works, and repeating it leads people to convert correct 302s into incorrect 301s.

Search engines now interpret redirect intent rather than mechanically applying rules. A 302 that has pointed at the same target for a year gets treated much like a permanent move, because the observable behaviour is permanent regardless of the number. Equally, a 301 on a page that keeps changing target gets treated with suspicion.

So the guidance is simply to state the truth. If the move is permanent, say 301, because it is faster to consolidate and unambiguous. If it is temporary, say 302 or 307, because you want the original URL to stay indexed. The failure mode that actually costs you is neither of these — it is a redirect chain.

Chains are where real damage lives. A URL that 301s to a URL that 302s to a URL that 301s again wastes crawl budget, adds a full round trip per hop for every visitor, and tends to accumulate as redirects are added over the years without anyone auditing the old ones. Every hop is latency on a real user’s connection. Collapse chains to a single hop whenever you find one.

Finding what emitted the redirect

In a modern stack a redirect can come from at least five places: the application framework, a middleware layer, the web server config, a platform-level redirect rule, or a CDN edge worker. Working out which one is responsible is most of the job.

Start by following the whole chain and printing every hop:

curl -sIL https://example.com/old-page | grep -Ei '^(HTTP|location|server)'

That prints the status, target, and often the software for each step. If you see three HTTP lines, you have a three-hop chain and the fix is to point the first one straight at the last one.

Then bisect. Request the origin directly, bypassing the CDN. If the redirect vanishes, it is an edge rule. If it persists, request the application port directly, bypassing the web server. If it vanishes there, it is in your nginx or platform redirect config. If it survives all the way down, it is in application code, and the framework’s routing table or a middleware is where to look.

One more: a redirect that appears only for some visitors is almost always conditional on something — a cookie, a header, a geo lookup, or an authentication state. Reproduce it with curl and the relevant header set rather than trying to reason about why it works in one browser and not another.

How this fits the rest of the stack

Redirects are cheap to add and expensive to leave unaudited, and most sites accumulate a layer of them nobody has read in years. Keeping them in one place — declared with the rest of the site configuration rather than scattered across a framework, a proxy, and an edge rule — is what makes them auditable later. Redirect and header rules on RunxBuild static sites are part of the project config, so they ship with the deploy and are visible in the same repository as the code. If a redirect is part of a larger move between hosts, the RunxBuild hosting calculator is a reasonable place to see what the destination costs before you point anything at it.

Useful related references:

FAQ

Is a 302 redirect bad for SEO?

Not inherently. A 302 tells search engines the original URL is still canonical, which is exactly right for maintenance pages, A/B tests, and login bounces. The genuine SEO problem is a redirect chain or a permanent move mislabelled as temporary. Search engines increasingly judge redirect intent by observed behaviour rather than the status code alone.

What is the difference between 302 and 307?

Both are temporary. The difference is method handling. A 302 allows the client to change a POST into a GET, which browsers do universally. A 307 requires the method and body to be preserved exactly. For web pages either works; for APIs and any non-GET request, use 307 so the payload is not silently dropped.

When should I use 301 instead of 302?

Use 301 when the URL has moved for good and you want search engines and bookmarks updated. Use 302 when the original URL is still the real one and the diversion is temporary. Be careful with 301 — browsers cache it aggressively, sometimes indefinitely, so an accidental one is hard to undo for visitors who already received it.

Why did my POST request lose its body after a redirect?

Because a 302 permits the client to convert the request to a GET, and most clients do. The body goes with the method. If the redirect is required, return a 307 instead so the method and body survive. If the redirect is not required, have the API return the resource or an error rather than redirecting at all.

How do I see the full redirect chain for a URL?

Use curl -sIL and filter for the HTTP and Location headers. Each pair is one hop. If there is more than one, point the first redirect directly at the final destination — every extra hop is a round trip on the visitor’s connection and wasted crawl budget.