301 vs. 302 redirect

The short answer

Use a 301 (Moved Permanently) when the old URL is gone for good and the new URL should take its place: a domain move, a switch to HTTPS, a new URL structure, merged pages. Use a 302 (Found) when the original URL will come back and should stay the one that is indexed: a short maintenance page, an A/B test, a geo or language redirect on a single entry URL, a temporarily sold-out product.

If you are unsure, ask yourself one question: should search engines and browsers forget the old URL? If yes, it is a 301. If no, it is a 302.

What the two status codes mean

Both codes are defined in RFC 9110, the current HTTP specification. The server answers with the status code and a Location header that points to the new target:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page/

HTTP/1.1 302 Found
Location: https://example.com/new-page/

• 301 Moved Permanently: the resource has a new permanent URL. Clients with link-editing capability (bookmarks, crawlers) should update their references to the new URL.
• 302 Found: the resource temporarily lives under a different URL. The client should keep using the original URL for future requests.

For the visitor, both look identical: the browser follows the Location header in a few milliseconds and shows the target page. The differences only show up in caching, in search engines and with non-GET requests.

SEO impact: what Google does with 301 and 302

An old myth says that a 302 "loses link juice". That is not true (any more). According to Google Search Central, all redirect types, 301, 302, 303, 307 and 308, pass PageRank. The real difference is canonicalization, meaning which URL ends up in the index:

• 301 (and 308) are a strong signal that the target URL should be canonical. Google will usually replace the old URL with the new one in search results.
• 302 (and 303, 307) are a weak signal. Google tends to keep the original URL in the index and show it in search results, because you said the move is temporary.

Canonicalization is a decision Google makes from many signals, so a redirect is not a guarantee. If a 302 stays in place for months and all other signals (internal links, sitemaps, rel="canonical") point to the target, Google may eventually treat it like a permanent redirect. Relying on that is sloppy, though: if you mean permanent, send a 301 and send consistent signals.

Typical SEO mistakes with the wrong code:

• 302 for a permanent move: after a relaunch the old URLs keep appearing in search results, and the new URLs take longer to take over.
• 301 for a temporary situation: a maintenance or "out of stock" redirect with 301 can cause Google to swap the canonical URL for the temporary target, and returning visitors land on the wrong page because of browser caching (see below).

Browser caching: why a 301 is hard to undo

This is the part that bites developers most often. RFC 9110 defines 301 (and 308) responses as cacheable by default. Browsers make heavy use of that: Chrome, Firefox and Safari remember a 301 and, on the next visit, jump straight to the target without asking the server again, often for a very long time.

So if you set up a 301 by mistake and remove it on the server, visitors who already saw it will keep being redirected until their cache expires or they clear it. You cannot "call back" a cached 301 from the server side.

A 302, by contrast, is only cached if the response carries explicit caching headers such as Cache-Control: max-age=... or Expires. Without them, the browser asks the server every time.

Practical consequences:

• While testing new redirect rules, start with a 302 and switch to 301 once everything works.
• If you want to limit how long a 301 is cached, add a header, for example Cache-Control: max-age=3600.
• Test with a tool that does not use your browser cache. Our redirect checker sends fresh requests from the server and shows every hop with its status code, so you see what the server really answers.

The POST problem: 301/302 vs. 307/308

For historical reasons, browsers change a POST request into a GET when they follow a 301 or 302. The form data is dropped. RFC 9110 explicitly allows this behaviour. For ordinary page redirects this does not matter, because links and bookmarks are GET requests anyway. It does matter for forms and APIs.

That is why 307 and 308 exist: they are the strict versions that must keep the method and body. There is also 303, which always switches to GET on purpose, for example after a form submission. The details are covered in our 307 vs. 308 guide.

Comparison table: 301, 302, 303, 307, 308

Code	Name	Permanent?	Method on redirect	Cached by default	Google canonical signal
301	Moved Permanently	Yes	POST may become GET	Yes	Strong
302	Found	No	POST may become GET	No	Weak
303	See Other	No	Always GET	No	Weak
307	Temporary Redirect	No	Preserved	No	Weak
308	Permanent Redirect	Yes	Preserved	Yes	Strong

All five pass PageRank. For normal web pages, 301 and 302 are the safe default choices because every client understands them. 307 and 308 are the better choice when non-GET requests must survive the redirect.

When to use which: common scenarios

Scenario	Recommended code
Moving to a new domain	301 (see the domain migration checklist)
HTTP to HTTPS	301 or 308 (see HTTP to HTTPS)
www to non-www or vice versa	301
New URL structure after a relaunch	301, one rule per old URL
Deleted page with a clear successor	301 to the successor
Deleted page without a successor	No redirect, answer 404 or 410
Short maintenance or campaign page	302 (or 503 for real downtime)
A/B test on a separate URL	302
Language or country redirect from the home page	302
After a form submission (Post/Redirect/Get)	303
API endpoint moved, clients send POST/PUT	308 (permanent) or 307 (temporary)

One note on deleted pages: redirecting everything to the home page is not a good substitute for a 404. Google tends to treat such redirects as "soft 404s", so you gain nothing and confuse visitors.

How to set up a 301 or 302

The code is usually one parameter. In Apache (.htaccess):

Redirect 301 /old-page/ https://example.com/new-page/
Redirect 302 /sale/ https://example.com/summer-sale/

In nginx:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

In PHP:

header('Location: https://example.com/new-page/', true, 301);
exit;

Watch out: many tools default to 302. PHP's header('Location: ...') without a status code sends a 302, and so does Apache's Redirect directive and a RewriteRule with a bare [R] flag. More complete examples are in the 301 redirect guide and the platform guides for .htaccess and nginx.

How to check which code your server sends

The browser address bar only shows you the final URL, not how you got there. To see the actual status codes:

• Enter the old URL in the redirect checker. It lists every hop with status code, target and timing, so you immediately see whether it is a 301 or a 302 and whether there are unnecessary intermediate steps.
• On the command line: curl -I https://example.com/old-page/ shows the status line and the Location header of the first response.
• In the browser developer tools (Network tab), enable "Preserve log" and "Disable cache", otherwise a cached 301 will hide what the server does now.

While you are at it, check for chains like HTTP to HTTPS to www to the final URL. Every extra hop costs time, and Google stops following after 10 hops. Our guide on redirect chains shows how to flatten them.