301 vs 302 vs 307 vs 308 Redirects

When a page moves to a new address, it is not enough to just drop in a link. You need to tell the search engine how to treat the old URL: forget it forever or keep it around for a while. That decides whether link equity is passed along, whether the old page stays in the index, and whether you lose rankings. The 301, 302, 307, and 308 codes are exactly those instructions. Let’s look at real examples and see which code belongs in which situation so you do not get it wrong.

A redirect is a sign on the door: “We moved.”

• The redirect code is the detail underneath it: “permanently,” “temporarily,” “keep the request method the same.”
• If you move and leave no sign, the visitor walks into an empty room.
• If you leave the wrong sign, they end up in the wrong place, or the search engine keeps showing the old address even though the new one is already live.

The job of these codes is to tell the browser and the crawler exactly what to do with the request.

Related reading:

• How to Set Up a Redirect the Right Way for SEO and Users

301 — permanent move

This code is used when a page has moved permanently and the old address is never coming back. Search engines treat 301 as a signal that says: “transfer all authority, link equity, and rankings to the new URL.” The old address gradually disappears from search results, and the new one takes its place.

Without a 301, you risk losing the rankings you built up over the years.

Example: you moved an article from poznayu.com/old-article/ to poznayu.com/new-article/. In your server settings, such as .htaccess, you would write:

Redirect 301 /old-article/ https://poznayu.com/new-article/

Or, if you are using Nginx:

location /old-article/ {
return 301 https://poznayu.com/new-article/;
}

After that, Google and Yandex will start replacing the old URL with the new one while keeping almost all of the value.

302 — temporary redirect

302 says: “the page is here for now, but it will be back.” With this code, search engines keep the old URL in the index, and the new one does not get the full value. Use it for sales, page tests, or maintenance work.

The key is not to confuse 302 with 301, or you may accidentally wipe out accumulated authority for months.

Example: you temporarily redirect the promotions page poznayu.com/sale/ to poznayu.com/black-friday/ during a sale.

Redirect 302 /sale/ https://poznayu.com/black-friday/

After the sale ends, you remove the redirect and the old address works again. The search engine will not penalize you for a temporary move.

307 — temporary, but strict

307 is the temporary equivalent of 302, but with one important difference. It guarantees that the request method, whether GET, POST, or something else, stays the same. If the old address received a POST request, the new one will get the same method. A 302 can sometimes turn POST into GET, while 307 does not.

For normal links, the difference is small. For payment forms or data submissions, 307 is the better choice.

Example: poznayu.com/order/ accepted POST data, and you temporarily redirect to poznayu.com/new-order. In Nginx, it would look like this:

location /order/ {
return 307 https://poznayu.com/new-order/;
}

The browser will resend the same data without losing information.

For  htaccess:

RewriteEngine On 
RewriteRule ^order/$ https://poznayu.com/new-order/ [R=307,L]

308 — permanent and strict

308 is the permanent equivalent of 301. It is used when you need to keep the request method intact, for example when permanently redirecting POST requests. For ordinary pages, 301 is usually enough. But if you are permanently moving a page that accepts POST data, 308 is the better option.

Example: the signup form on poznayu.com/subscribe/ moved to poznayu.com/newsletter/, and you want the POST method to stay intact.

location /subscribe/ {
return 308 https://poznayu.com/newsletter/;
}

In most projects, 308 is rare, but it is worth knowing about, especially if you work with APIs or web forms.

For htaccess:

Redirect 308 /subscribe/ https://poznayu.com/newsletter/

So what is the real choice? Both 301 and 308 are permanent redirects. But there is one key difference that most guides ignore.

1. 301 can change the request method. If a POST goes to the old address, the browser will almost certainly turn it into a GET during the redirect. For normal links, that is not a problem. But if you are redirecting a form submission or a payment request, the data can be lost.
2. 308 does not do that. It preserves the original method. If it was POST, it stays POST. That is why 308 is called a “strict permanent redirect.”

Comparison table of redirect codes

Below is a table that will help you choose the right code quickly:

Which redirect code should you choose?

In practice, for 95% of tasks on a standard informational site, 301 and 302 are enough.

1. For a permanent move of articles, sections, or an entire domain, use 301.
2. For temporary testing or seasonal discounts, use 302.
3. If you are working with payment forms or any POST requests, look at 307 and 308.

It is important to remember that chains of multiple redirects, such as 301 → 302 → 200, slow down loading and dilute link equity. Try to send the user and the crawler directly from one old URL to one final destination.

The takeaway: before you set up a redirect, ask yourself whether the move is permanent or temporary. Does the request method change? The answer to those two questions tells you which code to use. And do not forget to verify the result with webmaster tools to make sure the redirect works exactly the way you intended.

Ethan Carter

I’m Ethan Carter, an American developer and technical writer with more than 20 years of experience in systems and application programming. My core specialty is low-level development in Assembler: 22 years of hands-on work, including deep experience in code optimization, CPU architecture, and performance-critical solutions. I also hold a PhD in Assembler and have spent more than 18 years working with ASP.NET, building enterprise web systems, APIs, and scalable backend solutions.

In addition, I have 9 years of experience in C++ and C#, along with 7 years of hands-on microcontroller programming in Assembler. Thanks to this mix of academic background and practical engineering experience, I can write about software architecture, low-level optimization, and modern development in a way that makes complex technical topics clear for a professional audience.