301 vs 302 Redirects: When to Use Each (and Why It Matters)

What they are and how they work

Both 301 and 302 are HTTP redirect status codes in the 3xx family. When a browser or crawler requests a URL and the server responds with one of these codes plus a Location header, the client is told to fetch a different URL instead. The visible result is identical: the user lands on the destination page. The difference is in the meaning the status code carries, and search engines read that meaning carefully.

A 301 Moved Permanently says the resource has a new home and the old address should no longer be used. Browsers may cache a 301, so repeat visitors are sent straight to the destination without asking the server again. A 302 Found (historically "Moved Temporarily") says the resource lives elsewhere for now, but the original URL is still the one to use going forward. Browsers do not cache a 302 by default, because the situation is expected to change.

There is also a 307 Temporary Redirect, which behaves like a 302 but guarantees the request method is preserved. For everyday SEO decisions, the 301 versus 302 choice matters most, because it controls how your indexed URLs and ranking signals move.

How each affects SEO

Link equity and signal consolidation

A 301 consolidates ranking signals, including the value of inbound links, onto the destination URL. In modern Google terms this is signal consolidation rather than a percentage of "link juice" flowing through. The destination becomes the address Google reports and ranks, and the old URL drops out of the index over time.

A 302 is different. Because it signals a temporary situation, Google keeps the original URL indexed and canonical, and signals stay with the source rather than transferring. That is exactly what you want for a short-term detour, and exactly what you do not want when you have permanently moved a page and need its authority to follow it.

Indexing behavior

With a 301, Google swaps the indexed URL: the destination replaces the source in search results. With a 302, the source URL stays in the index even though visitors are sent to the destination. This is the most common source of confusion. If you 302 a permanently moved page, the old URL keeps showing in results, the new URL struggles to be indexed in its place, and your consolidation never happens.

When to use each

Reach for a 301 when the change is permanent. Typical cases: moving from HTTP to HTTPS, consolidating www and non-www, retiring an old domain after a rebrand, merging two pages into one, changing a URL structure, or replacing an outdated article at a new address. The old URL is never coming back, so you want signals and indexing to follow the move.

Reach for a 302 when the original URL must remain the indexed, canonical address. Typical cases: a short A/B test that routes some traffic to a variant, a "back in stock soon" product page pointing at a temporary placeholder, geo or device routing where the entry URL should keep its identity, or maintenance windows where a page will return shortly. The test for whether a 302 is correct: would you be unhappy if Google indexed the destination instead of the original? If yes, a 302 is right. If you actively want the destination indexed, you need a 301.

Redirects interact with how crawlers reach your pages, so keep your robots.txt configuration consistent with your redirect plan. A page blocked from crawling cannot have its redirect seen.

Implementation

On Apache, redirects usually go in .htaccess or the virtual host config. The R=301 or R=302 flag sets the status code explicitly.

# Apache .htaccess

# Permanent single-page redirect (301)
Redirect 301 /old-page/ https://example.com/new-page/

# Permanent redirect with mod_rewrite
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]

# Temporary redirect (302) during maintenance
RewriteRule ^sale/?$ /maintenance/ [R=302,L]

On Nginx, redirects are defined in the server block. Use permanent for 301 and redirect for 302, or state the code directly with return.

# Nginx server block

# Permanent single-page redirect (301)
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# Permanent redirect using rewrite
rewrite ^/old-page/?$ /new-page/ permanent;

# Temporary redirect (302)
location = /sale/ {
    return 302 /maintenance/;
}

How to test

Never assume a redirect returned the code you intended. Check it. The fastest way is curl with the -I flag, which shows response headers only.

curl -I https://example.com/old-page/

# Look for the status line and Location header:
# HTTP/2 301
# location: https://example.com/new-page/

To follow the whole hop sequence, add -L and watch each response. Browser developer tools (Network tab) show the same status codes, and dedicated redirect-checker tools display the full chain at a glance. Verify the status code, the final destination, and the number of hops.

Common mistakes

Using a 302 for a permanent move. This is the most expensive error. Many servers and frameworks default to 302, so a redirect set up casually may not be the 301 you assumed. The old URL stays indexed, the new URL does not take its place, and signals never consolidate. Always confirm the code with curl -I.

Redirecting to an irrelevant page. Sending a retired product page to the homepage is a classic example. Google may treat a redirect to an unrelated destination as a soft 404, meaning the consolidation you wanted simply does not happen. Redirect to the closest relevant equivalent. If no equivalent exists, consider whether a clean 404 or 410 status is the more honest answer.

Building redirect chains. When A redirects to B, and B redirects to C, crawlers waste budget and a little signal can be lost at each hop. Point every redirect directly at the final destination and clean up old links. For a deeper look at this, see our guide on redirect chains and loops.

FAQ