301 vs 302: Moved Permanently vs Found
301 and 302 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 301 — Moved Permanently | HTTP 302 — Found |
|---|---|---|
| Definition | The resource at the requested URL has permanently moved to the URL in the Location header. Browsers and crawlers update their records. Search engines transfer ranking signals to the destination. | The resource is temporarily available at a different URL. Unlike 301, clients should continue using the original URL for future requests. Historically misused — prefer 307 (method-preserving) or 303 (POST/redirect/GET) for more explicit semantics. |
| Plain-language summary | The resource has permanently moved to the URL in the Location header. Browsers and search engine crawlers update their internal records to the new URL. SEO signals (PageRank, links) are transferred to the destination. Use this only when the move is truly permanent — reversing a cached 301 is difficult. | The resource is temporarily available at a different URL. The original URL remains valid and the client should continue using it for future requests. Unlike 301, browsers do not cache 302 redirects, and search engines do not transfer SEO signals. Historically, browsers changed POST to GET on 302, which is technically incorrect but widely implemented. |
| When to use | Use 301 for: permanent domain migrations (http→https, www→non-www, domain renames), permanent URL restructuring, consolidating duplicate URLs to a canonical. Do not use 301 for temporary campaigns, A/B tests, or login flows — use 302 or 307 for those. Use 308 if you need to preserve the HTTP method (POST stays POST) on a permanent redirect. | Use 302 for temporary redirects where the original URL should be preserved. Prefer 307 when you need to guarantee method preservation (POST stays POST). Use 303 for Post/Redirect/Get (PRG) patterns after form submission. Never use 302 for permanent URL changes — that is a 301. |
| Client behavior | Browsers cache the redirect aggressively and follow it automatically, typically changing POST to GET (historical behavior). Search engine crawlers follow and pass link equity to the destination. Most HTTP clients follow redirects by default; some have a max follow depth (commonly 5–10 hops). | Browsers follow the redirect automatically and typically change POST to GET (historical, widely-implemented non-spec behavior). The redirect is not cached; each visit to the original URL re-checks the server for a redirect. Crawlers visit the original URL again in future crawls rather than updating their index. |
| Caching behavior | Cached by browsers and CDNs indefinitely unless Cache-Control or Expires specifies otherwise. Once cached, clients will not hit the original URL again until cache expiry. This makes 301s easy to deploy but hard to roll back — test before shipping. | Not cached by default. Each request to the original URL hits the server and may receive a different destination. You can add Cache-Control headers to cache 302s, but this is rarely appropriate for truly temporary redirects. |
| SEO / crawler impact | Search crawlers interpret 301 (redirect-codes) for indexation and link equity accordingly. | Search crawlers interpret 302 (redirect-codes) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 301 expect Moved Permanently semantics. | API clients branching on 302 expect Found semantics. |
| Safe to retry? | Follow redirect, then retry original intent | Follow redirect, then retry original intent |
Common real-world scenarios
When you see HTTP 301
Common in access logs during site migrations, HTTPS enforcement, and URL canonicalization. Watch for: redirect chains (A→B→C — each hop adds latency and some crawlers have hop limits), redirect loops (A→B→A — will show as 301 thrashing in logs), and 301s that land on 404 (the redirect was set up but the destination does not exist).
When you see HTTP 302
Appears in login flows, feature flags, A/B testing, short-term promotional redirects, and geographic routing. Common in access logs during marketing campaigns or seasonal routing. Watch for 302s that have been "temporary" for months — if the destination is permanent, convert to 301 and recover the lost SEO signals.
Decision rule
Use 301 when the response should communicate moved permanently behavior; use 302 when found is the accurate protocol signal.
A frequent mistake is swapping 301 and 302 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 301 when the correct protocol signal is Moved Permanently. Use 302 when the correct signal is Found. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 301 and 302?
301 communicates Moved Permanently, while 302 communicates Found. Choosing the right one keeps clients and intermediaries predictable.
Do 301 and 302 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 301 instead of 302?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 301 Moved Permanently — full guide · HTTP 302 Found — full guide · All comparisons · HTTP 301 status reference · HTTP 302 status reference