301 vs 302 Redirect: Choosing the Right One for SEO

“`html

301 vs 302 redirect? Short version: use a 301 when a page has moved for good, and a 302 when the move is temporary and the old URL should stay in search. Restructuring URLs or moving pages and worried about losing your listing? The status code you pick is what tells Google which address to keep. Below: how Google reads each code, when to use which, how to set them up in NGINX and Apache, and the mistakes that leave the wrong URL sitting in results.

What is the difference between a 301 and a 302 redirect?

A 301 says a page has moved permanently. A 302 says the move is temporary. Visitors won’t notice a thing, but search engines will. Quick definition first: a status code is the three-digit number a server sends back with every response to say what happened to the request. According to Google’s documentation on redirects, both 301 and 308 mean a page has permanently moved to a new location. So the 308 redirect is basically the 301’s permanent sibling, and Google lists the two side by side.

How Google treats a permanent redirect versus a temporary one

Google keeps track of both the old URL and the new one, and the redirect type (temporary or permanent) helps it decide which one becomes canonical. The canonical URL is the single version Google picks to index and show for a group of duplicate or closely related pages. Use a permanent server-side redirect and the indexing pipeline treats the target as the preferred canonical. The old address? It turns into an alternate name, and it can still show up in results when a query suggests the searcher trusts the old URL more. A temporary redirect is a weaker signal. So the source may well hold on to its spot.

When to use a 301 and when a 302

Go with a permanent redirect when the old address is never coming back. The usual suspects:

• You changed your URL structure, say moving posts from dated paths to flat slugs.
• You merged two thin pages into one stronger guide.
• You settled on one preferred host: www or non-www, http or https.
• You moved the whole site to a new domain.

A temporary redirect makes sense when the original page is expected to return:

• A short-lived campaign page is standing in for a product page.
• You’re A/B testing a destination.
• A page is offline for a while and will come back at the same address.

Google’s rule of thumb is refreshingly simple. It comes down to how long the redirect will stay and which URL you want people to see in search results. Domain buyers run into the same question (different context, same logic), and our guide to redirects on expired domains covers that case.

Setting up a 301 or 302 in NGINX and Apache

In NGINX, the cleanest way to send either code is a return directive inside a location block. For a single page, location = /service { return 301 https://example.com/about/service; } gives you a permanent move. Swap in return 302 and it’s temporary. That’s it. For pattern-based moves, a rewrite rule ending in the permanent flag returns a 301, while the redirect flag returns a 302. Same syntax whether NGINX serves your site directly or you run an NGINX proxy before your hosting and keep the redirect rules on your own origin server.

Apache gives you two routes. With mod_alias, Redirect permanent "/old" "https://example.com/new" sends a 301 and Redirect temp sends a 302. With mod_rewrite, the [R=301] flag is permanent and a bare [R] is temporary (easy to forget, and a common source of accidental 302s). Whatever server you’re on, Google recommends a permanent server-side redirect whenever possible when you change a URL that shows in search.

Redirect mistakes that keep the wrong URL in search

Most redirect trouble boils down to mixed signals about which URL is the final one. Watch out for these:

• A 302 left in place for a permanent move. You told Google the change was temporary, so it may keep treating the old address as canonical. Fair enough, really.
• A redirect chain. A few restructures later, A points to B, which points to C. Send every old URL straight to the final target instead.
• Everything redirected to the home page. Lazy, and it shows. Map each retired page to its closest match so visitors and crawlers land somewhere that makes sense.
• Stale internal links and sitemaps. If your navigation and XML sitemap still list old URLs, they contradict your own redirects. Update them to the new addresses.

One more thing. Changing servers is a separate job from changing URLs, and our notes on IP moves without ranking loss explain how to handle that step on its own.

How to check which redirect your server actually returns

Fastest check: request the old URL from the command line and read the response headers. Config files can say one thing while a plugin, a CDN rule or some forgotten old block says another. So test what’s actually live:

1. Run curl -I https://example.com/old-page and read the status line at the top of the output.
2. Check that the Location header points to exactly the target you meant.
3. Repeat for the http and https versions, with and without www.
4. Request the target too. If it redirects again, you’ve found a chain to collapse into one hop.

Want to know what Googlebot really got over time? Look at the status codes in access logs, not a single one-off test. The decision itself stays short, though: in any 301 vs 302 redirect question, a permanent move gets a 301 or 308, and a temporary one gets a 302. For more on this, browse technical SEO on the blog.

FAQ