301 vs 302 Redirect: Which to Use and How to Keep Your SEO

Short answer: a 301 tells Google a page has moved permanently; a 302 says the move is temporary and the old URL will come back. If the old URL is gone for good — a domain change, a platform migration, a new URL structure — use a 301 (or 308). Use a 302 (or 307) only when the original page really is coming back.

Before changing anything, check what your site does today. The free redirect checker traces every hop with its status code and response time in milliseconds, and confirms that the http/https and www/non-www variants all end up at the same address.

Redirect status codes: 301, 302, 303, 307 and 308

There are five 3xx codes you will run into. They differ on two questions: is the move permanent, and is the request method (for example, a form POST) preserved?

For ordinary pages, which Googlebot fetches with GET, 301 and 308 behave the same, and so do 302 and 307. One common source of confusion: the 307 you see in the browser after a site enables HSTS does not come from the server. It is an internal browser redirect. Googlebot never sees it — it sees whatever your server actually returns.

How Google treats 301 and 302

To Google, a redirect is first of all a canonicalization signal: a hint about which URL should be shown in search results.

• 301 and 308 are a strong signal that the target is the new canonical URL. Over time the old URL drops out of the index and the target picks up its signals (links, history).
• 302 and 307 are a weak signal. Google tends to keep the old URL indexed, because you said it would return.

Google has stated publicly that 3xx redirects do not lose PageRank, so the old "a 301 leaks 15% of link equity" rule no longer applies. That does not make 301 and 302 interchangeable, though: the difference is which URL Google chooses to show.

It is also true that a 302 left in place for a long time may eventually be treated as permanent — Google representatives have said so. But you do not control when that happens. If the move is permanent, do not rely on Google to work it out; set a 301 from day one.

Meta refresh and JavaScript redirects are followed too, but they are less reliable. Whenever you have server access, use an HTTP redirect.

Redirect chains and loops

A redirect chain is A → B → C → D. It is typical on sites that have been through several changes: first http moved to https, then www was dropped, then the URL structure changed — and each layer was stacked on top of the previous one instead of replacing it.

Why chains hurt:

• Latency. Every hop is another request. On a slow mobile connection, three or four hops add hundreds of milliseconds before the page even starts loading.
• Crawl budget. Googlebot spends one request per hop. On large sites this slows down discovery of new and updated pages.
• Hop limit. Google's documentation says Googlebot follows up to 10 redirect hops; beyond that, Search Console reports a redirect error. In practice, aim for a single hop.

A redirect loop is when A leads to B and B leads back to A. The browser shows "too many redirects" and the page effectively disappears for users and for Google. A classic cause is an https rule on the origin server fighting an opposite rule in the CDN or hosting panel.

The fix for a chain is always the same: point the original URL directly at the final destination, and update internal links to the final URL.

Consolidating http/https and www

Every domain has four variants:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

Only one should return 200. The other three should reach it with one 301. The most common mistake is http://example.com → https://example.com → https://www.example.com: two hops where one would do.

nginx

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # SSL certificates here
    if ($host != "www.example.com") { return 301 https://www.example.com$request_uri; }
    if ($scheme = http) { return 301 https://www.example.com$request_uri; }

    # Redirect a single old URL
    location = /old-page { return 301 /new-section/new-page; }
    # ... rest of the config
}

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

# Redirect a single old URL
Redirect 301 /old-page /new-section/new-page

WordPress and hosted platforms

On WordPress, the free Redirection plugin or the redirect managers in Rank Math and Yoast Premium handle this without touching server config. Plugins run after PHP loads, so they are slightly slower than an nginx or Apache rule, but for most sites that is fine. Shopify and most other hosted platforms have a URL redirect manager in the admin; check whether yours supports bulk CSV import before a large migration.

Redirects in a site migration: checklist

Migrations are one of the riskiest moments for organic traffic — moving platforms, changing domains, restructuring categories. The cause is almost always the same: poorly planned redirects.

1. Build a 1:1 redirect map. Export every old URL (sitemaps, Search Console, a crawler, analytics landing pages) and map each one to its closest equivalent on the new site: product to product, category to category.
2. Do not send everything to the homepage. Mass-redirecting hundreds of URLs to the homepage looks convenient, but Google usually treats it as a soft 404 — the old URL drops out and passes nothing on. If there is no equivalent, a closely related category is better; if even that does not exist, an honest 404 or 410 is acceptable.
3. Handle parameters. Indexed URLs with query parameters need their own rules, not just the path.
4. Update internal links. Menus, footers, breadcrumbs and body copy should point straight to the new URLs. Redirects are for visitors and external links, not for your own navigation.
5. Update canonicals, hreflang and sitemaps. The new sitemap should list only final URLs that return 200. Submit it in Search Console.
6. Use the Change of Address tool in Search Console when you move to a new domain.
7. Keep redirects for at least a year. That is Google's own recommendation. If the old domain has backlinks, keep them indefinitely — it costs almost nothing.
8. Test before and after launch. Run the list of old URLs through a checker and confirm every one ends in a 200 after a single hop.

How to test your redirects

Browser DevTools (Network tab with "Preserve log" on) and curl -I -L https://example.com both show the full chain, but checking every variant by hand is tedious.

The Nord SEO redirect checker does it in one go: it traces every hop with status code and timing in ms, tests all four http/https × www combinations to see whether they merge into one version, and shows the final response headers — where problems like a leftover X-Robots-Tag: noindex after a migration become visible. For a broader look at the site, the free 60-second audit checks the technical basics alongside.

FAQ

Does a 301 redirect hurt SEO?

According to Google, 3xx redirects do not cause a loss of PageRank. What does hurt is bad mapping: pointing pages at unrelated targets, sending everything to the homepage, or building long chains. Some ranking movement in the first weeks after a migration is normal while Google reprocesses the URLs.

When should I use a 302 instead of a 301?

When the original URL will come back: a seasonal campaign page, scheduled maintenance, an A/B test, or a product that is temporarily unavailable. If you have no date for undoing the redirect, it is probably permanent.

How long should I keep a 301 redirect?

Google recommends at least one year. If the old URL has links from other sites or still gets direct traffic, the safest choice is never to remove it.

Should I use a 301 redirect or a canonical tag?

Use a 301 when users no longer need to reach the old page. Use rel="canonical" when both versions must stay accessible — for example, the same product listed in two categories, or URLs with tracking parameters. A canonical is a hint; a 301 actually moves the user off the old page.