301 vs 302 Redirects: When to Use Each and Mistakes to Avoid

A 301 redirect is an HTTP response that tells browsers and crawlers a page has moved permanently to another address. A 302 redirect says the move is temporary. For SEO the difference matters: Google treats a 301 as a strong signal that the destination should be the canonical address, and a 302 as a weak one. The costly mistakes are choosing the wrong type and building redirect chains.

Any URL change, domain migration, switch to HTTPS or page removal calls for a redirect map. Done well, visitors and crawlers land on the right page and signals move with them. Done badly, you get 404s, “soft 404” pages and traffic losses that are hard to explain. This guide covers the differences between the codes, how to write the rules on your server and how to verify the result. Clean redirects are part of technical SEO, alongside canonical tags and sitemaps.

What separates a 301 redirect from a 302?

A redirect is a server response with a 3xx status code and a Location header pointing to where the client should go. These are the four codes you meet in SEO work:

Beyond these there are meta refresh and JavaScript redirects. Google processes them, but the hierarchy is clear: server-side redirects are the most reliable, meta refresh comes next and JavaScript redirects are a last resort because they depend on rendering. An instant meta refresh is treated as permanent, a delayed one as temporary.

One detail that confuses debugging: if your site sends the HSTS header, the browser may handle the HTTP-to-HTTPS step itself, and in developer tools you will see “307 Internal Redirect.” That is not a configuration problem. It is browser behavior.

How does Google treat redirects?

According to Google’s documentation, the indexing system uses a permanent redirect as a signal that the target should become the canonical address, so the destination usually appears in results. A temporary redirect is not used as a canonical signal, so the source page generally stays in the index while the destination may still be crawled.

Other useful reference points:

• Google’s crawlers follow up to 10 consecutive redirects by default. Beyond that, the URL is not resolved and Search Console may report a redirect error.
• A permanent redirect moves signals to the new address, but it does not fix weak content. If the destination does not resemble the source, you moved a URL, not its value.
• After a move, Google may keep showing the old address in results for a while. That does not automatically mean the redirect is broken; give Google time to recrawl and check the redirect itself.
• A redirect does not replace fixing internal links. Links inside the site should point straight to the final address so visitors do not go through a redirect on every visit. See the internal linking guide.

When do you use a 301 and when a 302?

Pick by asking: “Will the old page come back?”

Use 301 or 308 when you:

1. change a page’s slug (for example, remove diacritics or filler words from the URL);
2. move the site to a new domain or from HTTP to HTTPS;
3. choose the www or non-www version, or a trailing-slash form;
4. merge two pages that covered the same topic;
5. restructure a store’s categories and the old URL will no longer be used.

Use 302 or 307 when:

1. a product is temporarily out of stock and you point to an alternative, planning to come back;
2. you run an A/B test on different URLs for a limited time;
3. you send users by language or country, in which case it is better to offer a manual choice as well;
4. a page is under maintenance for a short period.

If you set a 302 by mistake and the move is actually permanent, Google may keep the old address for a long time. A practical rule: if you do not expect to reverse the move, use a 301.

How do you write redirects on the server?

The method depends on the server. These are the most common.

Apache (.htaccess). The first line moves a single page; the block after it forces HTTPS and the www version in one step:

Redirect 301 /old-services/ https://www.example.com/services/

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

nginx. The first block sends HTTP and the non-www host to HTTPS with www in one step; the second moves one page:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

location = /old-page/ {
    return 301 /new-page/;
}

WordPress. If you do not have server access, SEO plugins or dedicated redirect plugins manage the rules from the dashboard. Stick to one method; duplicate rules in a plugin and in .htaccess create chains. For a large set of addresses, our 301 redirect generator prepares the rules in the right format.

How do redirects affect speed and crawl budget?

Every redirect is an extra request. For a visitor it means time lost before the page starts loading; for Googlebot, a request spent without new content. On a small site the effect is barely noticeable. On a store with tens of thousands of URLs, chains and redirects inside internal links can consume a visible share of crawl budget and delay the discovery of new pages.

On mobile, where connections vary, each hop adds to the time before first paint and therefore shows up in metrics such as LCP, covered in our guide to Core Web Vitals. The fix is always the same: one step between the old address and the final one, with menu, content and sitemap links pointing straight at the destination.

Redirects in an online store

Stores have a specific problem: products come and go. For a discontinued product you have three options. If a near-identical replacement exists, use a 301 to it. If the stock-out is temporary, keep the page and signal availability. If the product is gone with no equivalent, a 404 or 410 page is more honest than a redirect to the category, and you can offer the category as a helpful link on the error page. General rules for categories and products are in our ecommerce SEO guide.

How do you build a redirect map, step by step?

In a migration or restructure, the map decides how much traffic you keep.

1. List all old URLs. Use a site crawl, the sitemap, Search Console data and pages with external links.
2. Choose the closest new page for each. The topical equivalent, not the homepage. If there is no equivalent, do not force an irrelevant redirect.
3. Put the rules in one table. Columns: old URL, new URL, type (301/302), notes.
4. Remove chains. If A goes to B and B to C, write A straight to C.
5. Implement on the server and fix internal links, the sitemap and canonical tags so they point to final addresses.
6. Test. Run a crawl and check key pages by hand.
7. Monitor Search Console over the following days and weeks: 404 errors, redirects and “soft 404” pages.

The full procedure for moving a site is in our migration plan that avoids SEO losses.

How do you check that a redirect works?

Do not rely on what you see in the browser; it hides intermediate steps and may use cache. Check the headers:

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

The output shows each hop: the status code and the destination. A healthy redirect usually has one hop followed by a 200. For many addresses, a crawler (for example Screaming Frog) lists all redirects, chains and loops in one pass. In Search Console, URL Inspection shows the canonical Google selected and whether the page is indexed.

Common redirect mistakes

• Redirect chains. HTTP to HTTPS, then to www, then to a trailing slash: three hops where one would do.
• Redirect loops. A sends to B and B sends back to A; the page never loads.
• Everything redirected to the homepage. You lose relevance and risk soft 404 treatment.
• 302 instead of 301 for permanent moves. The source can linger in results.
• A sitemap that lists redirecting URLs. The sitemap should contain final addresses; see our XML sitemap guide.
• Internal links to old addresses. The redirect works, but it slows every visit and crawl.
• Deleting rules too early. External links and bookmarks keep sending visitors for a long time.
• Redirecting an error page to the homepage. If the page truly no longer exists, a 404 or 410 is more accurate.
• Contradictory redirect, noindex and canonical signals. They must all say the same thing; see canonical tags and duplicate content.

When you should NOT use a redirect

A redirect is not the answer to everything:

• Pages with no equivalent. For a product withdrawn for good with no alternative, a 404 or 410 is honest and clean.
• Parameter duplicates. If the page must stay reachable (filters, sorting), the canonical tag is the right tool, not a redirect.
• Content that still exists. Do not redirect a page just to “collect” authority; first decide whether merging the pages makes sense for users.
• Pages unindexed for another reason. A redirect does not fix blocked indexing; likely causes are in our guide to pages not indexed.
• Language versions. Do not push users to a language based on browser settings alone; offer separate pages per language, with hreflang annotations and a language switcher.

Conclusion and next steps

Good redirects are few, direct and documented. Start here:

1. List the URL changes you are planning or have already made.
2. Choose 301 for permanent moves and 302 only for temporary situations.
3. Build the map with a topical equivalent for every URL and remove chains.
4. Verify with curl -I and a crawler, then watch Search Console.
5. Keep the rules as long as possible and update internal links.

If you are preparing a migration or have inherited a site with dozens of redirects, we can review it together as part of our technical SEO service or through the contact page.