301 vs 302 Redirects: Permanent and Temporary Explained

The difference between 301 and 302 comes down to one word: permanence. A 301 says "this page has moved for good", a 302 says "it is temporarily somewhere else and will come back".

That distinction is not a technical detail — it decides which URL Google treats as canonical. Leaving a 302 on a permanent move is one of the most common misconfigurations there is, and the outcome is predictable: the old URL keeps appearing in results while the new one never reaches full strength.

What a redirect is and when you need one

A redirect sends browsers and crawlers from the requested URL to a different one. An HTTP redirect specifically means a 3xx status code paired with a Location header.

The usual cases:

• The page's address changed (a slug edit, a category change).
• Two similar pages were merged.
• The site moved from HTTP to HTTPS, or from www to non-www.
• The domain changed.
• A product was removed but a close alternative exists.

There is also a case where a redirect is not appropriate: if the page genuinely no longer exists and has no matching alternative, returning 404 or 410 is more correct than redirecting to the home page.

Permanent and temporary codes

In practice the choice is simple: 301 for permanent, 302 for temporary. 308 and 307 are technically more precise (they never change the request method), but the SEO outcome is identical.

The difference in signal strength

Google's status code documentation states the difference directly:

• For 301 and 308, Google follows the redirect and uses it as a strong signal — the target URL should be selected as canonical.
• For 302, 303 and 307, Google still follows it, but this is a weak signal.

Note that "weak" does not mean "no effect". In practice Google may end up treating a long-lived 302 like a 301 — but relying on that is a bad idea. Google's redirect documentation gives a clear recommendation: use a permanent server-side redirect wherever possible for permanent moves.

The practical consequence of a temporary redirect is that the source page stays in the search results. Sometimes that is exactly what you want (see below) — just not when the move is permanent.

Redirect methods, ranked by reliability

Google's documentation ranks the methods by reliability:

1. Server-side redirects — the most reliable. Via .htaccess, mod_rewrite, nginx configuration or backend code (PHP, Node).

# nginx — a permanent redirect for a single page
location = /old-page {
    return 301 https://example.com/new-page;
}

# Apache (.htaccess)
Redirect 301 /old-page https://example.com/new-page

2. Meta refresh — the second choice. An important subtlety: an instant (0 second) meta refresh acts as permanent, while a delayed one (greater than 0) acts as temporary.

<meta http-equiv="refresh" content="0; url=https://example.com/new-page">

3. JavaScript redirects — only when nothing else is available. Google's documentation warns that rendering may fail for various reasons.

4. "Crypto" redirects — the weakest. That is, plain explanatory text with a link ("This page has moved here"). Google advises not to rely on these unless you have no other choice.

The simple rule: use the first method whenever you can. Server-side redirects are the fastest and introduce no dependency on rendering, JavaScript or the browser.

Chains, loops and the 10-hop limit

A redirect chain is A → B → C. Every hop is an extra request: the page gets slower, especially on mobile connections.

Per Google's documentation, its crawlers follow up to 10 redirect hops by default. Longer chains are abandoned — meaning the destination page is never seen at all.

A redirect loop is A → B → A. This makes the page completely unreachable and produces a "too many redirects" error in the browser.

The quickest way to inspect a chain:

curl -IL https://example.com/old-page | grep -E "^HTTP|^[Ll]ocation"

In practice: changing a domain or URL structure

The sequence:

1. Build a map. A table of old URL → new URL. Every old page should go to the closest match in content, not all of them to the home page.

2. Set up 301s one by one. Bulk-redirecting everything to the home page is the single most repeated mistake — Google frequently classifies such redirects as soft 404s.

3. Update internal links. Links inside the site should point at the new URL directly, not through a redirect.

4. Update the sitemap. New URLs belong in the sitemap; old ones do not.

5. Monitor in Search Console. Check the Pages report to see how the redirects are processed and how the old URLs leave the index. For a domain change, use the Change of Address tool.

6. Keep the redirects for at least a year. External links and user bookmarks keep pointing at old addresses for a long time.

When a 302 is the right choice

A 302 is not a wrong code — it simply has its place:

• A temporary campaign page. A product page redirects to a seasonal page for the duration of the campaign and then returns.
• An A/B test. Part of the traffic goes to a variant page for the duration of the test.
• A product temporarily out of stock. If the product will come back, deleting or permanently redirecting the page is wrong.
• Geo or language redirects. When sending a user to a regional version automatically, because the original URL must stay in place.

The test is simple: will the old URL show its own content again in future? If yes, use 302. If no, use 301.

Common mistakes

1. Leaving a 302 on a permanent move. The most frequent case; the canonical signal stays weak.

2. Redirecting every old URL to the home page. Irrelevant redirects get classified as soft 404s.

3. Building redirects in JavaScript. If rendering fails, the redirect is never seen.

4. Never cleaning up chains. Rules accumulated over years turn into four- and five-hop chains.

5. Leaving internal links on old URLs. Every click becomes an unnecessary extra request.

6. Not combining the HTTPS and www redirects. http://www → https://www → https:// is three hops where one would do.