HTTP 301 vs 302 — Moved Permanently vs Found Comparison

http 301 vs 302: 301 is permanent and transfers SEO link equity, 302 is temporary. Learn the right choice for redirects and how Google, browsers, and CDNs treat each.

3xx

301

Moved Permanently

View full 301 page →

Quick Cheat Sheet

Aspect 301 Moved Permanently 302 Found (Temporary)
Permanence Permanent Temporary
Cacheable by default Yes, aggressively No (unless headers say so)
SEO link equity transfer Yes — pass PageRank No (mostly)
Method preservation Historically buggy Historically buggy
Modern strict equivalent 308 307

The Core Difference

301 Moved Permanently (RFC 9110 § 15.4.2) tells the client and search engines that the resource has been permanently relocated. Future requests should go directly to the new URL — the old URL is essentially deprecated.

302 Found (RFC 9110 § 15.4.3) signals a temporary redirection. The original URL is still the canonical one; the client just needs to follow the redirect this time. Future requests should still go to the original URL.

SEO Implications (The Big One)

This is the reason developers care about 301 vs 302:

  • 301 transfers PageRank / SEO authority from the old URL to the new one (Google: "we treat 301s as permanent and consolidate signals").
  • 302 does not transfer SEO authority by default. The old URL retains its ranking value, and Google may eventually start indexing the new URL as a duplicate, hurting both.

If you're moving a domain, restructuring URLs, or merging duplicate pages — always 301. Using 302 for permanent moves is one of the most common SEO mistakes.

Caching Behavior

301 is heuristically cacheable forever by default. This bites people: if you accidentally 301 to the wrong URL and clients cache it, those users may never hit your origin again until their cache expires (which could be weeks or never).

302 is not cacheable unless you explicitly send Cache-Control: max-age=N. This makes it safer for short-lived redirects.

The Method-Preservation Wart

Both 301 and 302 historically have an ugly history: many user agents convert POST to GET when following the redirect, which is technically against the original RFCs but became standard practice. RFC 9110 codifies this as MAY behavior.

If you need strict method preservation for POST/PUT/DELETE redirects, use 308 (permanent) or 307 (temporary) instead. These were specifically created to fix this issue.

When to Use Which

  • 301: moving a domain, renaming a URL slug, merging duplicate pages, deprecating old paths
  • 302: A/B test routing, geo-based redirects, short-lived maintenance redirects, login redirects to original URL after auth

Real-World Examples

  • Migrating from example.com/blog/post-1 to example.com/articles/post-1301
  • Geo-redirecting EU users to /eu based on IP → 302
  • After login, sending users back to the page they wanted → 302 / 303

Real-World Use Case

When migrating a site to a new domain, configure 301 redirects in Nginx (return 301 https://newsite.com$request_uri;) so SEO equity transfers and Google deindexes the old URLs. For a login flow that returns users to the page they were on, use 302 with a query parameter — never 301, because tomorrow the same login URL might redirect somewhere else.

Look Up Any Status Code

Browse all status codes →