{"id":13504,"date":"2026-10-14T07:35:00","date_gmt":"2026-10-14T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13504"},"modified":"2026-09-25T09:45:53","modified_gmt":"2026-09-25T07:45:53","slug":"301-302-307-and-308-which-redirect-changes-the-request-method","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/tutorials-en-web-development\/301-302-307-and-308-which-redirect-changes-the-request-method\/","title":{"rendered":"301, 302, 307 and 308: Which Redirect Changes the Request Method"},"content":{"rendered":"

A redirect is a short answer: not here, but there. It costs a round trip, it is invisible to the visitor, and almost every address on the web goes through at least one.<\/p>\n

Four codes do this job. They look like two matched pairs – permanent and temporary, twice over – and that reading is wrong in a way that quietly breaks forms.<\/p>\n

\n\"One
Same request, four redirects – and two of them hand on something different from what arrived.<\/figcaption><\/figure>\n

What a redirect actually is<\/h2>\n

The server answers with a status code in the 300s and a Location<\/code> header naming another address. The client then makes a second request to that address. Nothing of the first response is displayed; it exists only to point somewhere else.<\/p>\n

Every hop is a full round trip: a name lookup if the host changes, a connection, a request, an answer. On a fast connection that is tens of milliseconds. On a phone with a weak signal it is noticeably more, and it happens before anything at all appears on screen.<\/p>\n

Which is why the number of hops matters as much as the codes. A chain of three is not three times slower than one, but it is three times as many chances for something to go wrong.<\/p>\n

Permanent or temporary<\/h2>\n

301<\/code> says the address has moved for good. Search engines transfer the ranking to the new address and eventually drop the old one. Browsers remember it – sometimes very persistently, which is worth knowing before using it during a rebuild.<\/p>\n

302<\/code> says the detour is temporary. The old address keeps its ranking, and nothing is remembered for next time.<\/p>\n

Using 302<\/code> for a permanent move keeps a dead address alive in search results. Using 301<\/code> for a temporary detour is worse: browsers cache it, and the visitor who saw the temporary version may keep landing there long after it has been switched off, with no way to notice why.<\/p>\n

That distinction is well known. The second one is not.<\/p>\n

The part that changes the method<\/h2>\n

A request has a method. Reading a page is a GET<\/code>. Submitting a form is usually a POST<\/code>, and the entered data travels with it.<\/p>\n

When a POST<\/code> meets a 301<\/code> or a 302<\/code>, browsers turn it into a GET<\/code>. The second request has a different method than the first, and the submitted data is gone – not rejected, not reported, simply not carried along.<\/p>\n

This was never the intention. The written rules said the method should be preserved; early browsers changed it anyway, enough of the web came to depend on that behaviour, and the rules eventually recorded what was actually happening.<\/p>\n

307<\/code> and 308<\/code> exist for exactly this reason. They are the same two meanings once more – temporary and permanent – with one addition: the method and the body stay as they were. 307<\/code> is the temporary one, 308<\/code> the permanent one.<\/p>\n

For an address that is only ever read, the difference is irrelevant, which is why it goes unnoticed for years. For an endpoint that receives form data, it decides whether the data arrives at all – and the failure looks like an empty form rather than an error.<\/p>\n

\n\"One
\n<\/figure>\n

What twelve real sites do<\/h2>\n

Twelve large sites were called on 1 September 2026 from an unencrypted address, following every hop to the end.<\/p>\n

Four arrive after a single hop. Seven need two. One needs three. Every first hop, in every case, was a 301<\/code> – the move from unencrypted to encrypted is the one thing everyone treats as permanent, and rightly so.<\/p>\n

The second hop is usually the switch between the bare domain and the one with www<\/code>. The third, where it appears, is a language or region redirect: one site sent the request onward to a country-specific subdomain, another to a language path. Those are worth noticing, because they are the hops that get added later, by a different team, to a chain that was already finished.<\/p>\n

Two of the twelve answered the final request with a refusal rather than a page – bot defence reacting to an unusual client. That says nothing about their redirects and everything about how such measurements should be read.<\/p>\n

Why every hop is worth removing<\/h2>\n

A chain that works is still worth shortening, for three reasons.<\/p>\n

The first is time, and it is the smallest. The second is that ranking signals weaken slightly along a chain, and search engines stop following after a handful of hops entirely.<\/p>\n

The third is the one that actually causes outages: things get lost on the way. A redirect to a different host drops the referrer under most policies. Cookies set for a bare domain do not travel to a subdomain. And the method change above applies at every single hop, so a chain that starts as a 307<\/code> and continues as a 301<\/code> still ends as a GET<\/code>.<\/p>\n

Chains are almost never built on purpose. They accumulate: one rule for encryption, one for www<\/code>, one for the trailing slash, one for the language. Each was correct when it was added.<\/p>\n

What can be measured in one call<\/h2>\n

Four questions settle any address. How many hops lie between the entered address and the final page. Which code does each hop use. Does any hop point at a different host, and does anything need to survive that. And does a permanent code appear where the move is not permanent.<\/p>\n

The indexing inspector<\/a> follows the chain and lists every hop with its code, which also shows whether the final address is the one that was meant.<\/p>\n

The answer worth having is short: how many hops, and whether any of them changes something that should not change.<\/p>\n

\n

Questions and answers<\/h2>\n

How can a 301 that was set by mistake be undone?<\/h3>\n

For search engines this is easy, because they fetch the old address again and see the new state. For browsers it works only to a limited extent: a 301 may be cached even without an explicit instruction, and a browser that has cached it no longer asks the server at all. Three points help:<\/p>\n

    \n
  1. Prevention: using 302 or 307 during a rebuild and switching to 301 or 308 only once the move is settled.<\/li>\n
  2. Limitation: a 301 can carry its own Cache-Control header, for example max-age=3600<\/code>. A browser then remembers the redirect only that long.<\/li>\n
  3. No redirect back: the target must not redirect to the old address. Otherwise a browser that has cached the old redirect bounces between the two addresses until it gives up.<\/li>\n<\/ol>\n

    Once a 301 has gone out without such a limit, it may stay in the affected browsers for a long time, in the worst case until their cache is cleared.<\/p>\n

    Which redirect fits an API endpoint that moves permanently?<\/h3>\n

    308, because it preserves the method and the body. With a 301, not only browsers but also many HTTP libraries turn a POST into a GET. Even so, the redirect only works as a transition: not every client follows it for a POST at all, so the new address belongs in the clients themselves as soon as possible.<\/p>\n<\/div>\n

    \n

    Sources<\/h2>\n