# 301 vs 302 Redirects

> Understand the difference between 301 Moved Permanently and 302 Found redirects. Learn when to use each, how browsers cache them, and their SEO implications.

Source: https://howhttpworks.com/compare/301-vs-302
Last reviewed: 2026-10-04

> **TL;DR:** Use 301 for permanent URL changes: it is heuristically cacheable and tells search engines to index the new URL. Use 302 for temporary redirects: it is not cached unless you add Cache-Control, and the old URL stays indexed (though Google eventually treats a long-lived 302 as permanent).

## The Core Difference

Both status codes tell the client to fetch a resource from a different URL. The difference is permanence — and that single distinction has cascading effects on caching, SEO, and browser behavior.

**301 Moved Permanently** signals that the resource has moved to a new location indefinitely. The client should update its bookmarks, links, and caches to use the new URL going forward.

**302 Found** signals a temporary redirect. The client should follow the redirect this time, but continue using the original URL for future requests.

## Caching Behavior

| | 301 | 302 |
|---|---|---|
| Browser caches redirect | Yes (heuristic; may persist for a long time) | No unless `Cache-Control`/`Expires` allow it |
| Requires `Cache-Control` to override | Yes | No |
| CDN caches redirect | Usually yes | Usually no |

A 301 without an explicit `Cache-Control` header is heuristically cacheable (RFC 9111 section 4.2.2), and browsers commonly keep it for a long time, in practice until cache eviction. This means if you redirect `/old-page` → `/new-page` with a 301, users who visited before will never hit your server again for `/old-page` — their browser goes straight to `/new-page`.

This is powerful but dangerous: if you need to change the redirect destination later, cached users won't see the update until their cache expires or they clear it.

A 302 is cacheable only when explicit freshness headers such as `Cache-Control: max-age` are present (RFC 9110 section 15.4.3). Every request to the original URL will hit your server and receive the redirect response fresh.

## SEO Implications

Google treats both as redirects that pass ranking signals, but they differ in which URL ends up in the index:

- **301**: The destination becomes the canonical URL and replaces the original in search results.
- **302**: The original URL normally stays indexed, since the move is declared temporary. A 302 left in place for a long time may eventually be treated as permanent.

If you're migrating a site or permanently changing URL structure, use 301. Using 302 for permanent moves delays or confuses the switch of the indexed URL, and gives you no browser caching.

## Method Preservation

Both 301 and 302 have a historical quirk: browsers change POST requests to GET when following these redirects, and RFC 9110 sections 15.4.2 and 15.4.3 still allow that. It is expected behavior, not a legacy bug, which is why 307 and 308 were created.

If you need to preserve the HTTP method across a redirect:
- Use **307 Temporary Redirect** instead of 302
- Use **308 Permanent Redirect** instead of 301

## When to Use Each

**Use 301 when:**
- You've permanently moved a page to a new URL
- You're migrating a domain
- You're consolidating duplicate URLs (e.g., `http://` → `https://`, `www.` → non-www)
- You want search engines to index the new URL

**Use 302 when:**
- You're temporarily redirecting during maintenance
- You're A/B testing different landing pages
- You're redirecting based on user state (e.g., login required) and the original URL should remain canonical
- You're not sure yet if the move is permanent

## Common Mistakes

**Using 302 for permanent moves** — the most common mistake. Developers reach for 302 because it feels "safer" (it's reversible), but for permanent URL changes it means losing SEO value and not getting browser caching benefits.

**Forgetting 301s are cached forever** — if you set up a 301 and later need to change the destination, users with cached redirects won't see the change. Always set `Cache-Control: max-age=3600` on 301s during a migration period, then remove the header once you're confident.

**Using 301/302 when you need method preservation** — if your form POSTs to `/submit` and you redirect to `/thank-you`, use 303 See Other (which always converts to GET) rather than 302.

## FAQ

### Does a 301 redirect pass SEO link equity?

Yes. Google says all 3xx redirects pass ranking signals, but a 301 is the clear signal that the destination should become the indexed, canonical URL. With a 302 the old URL usually stays indexed; if the 302 persists for a long time Google may eventually treat it as permanent.

### Can I change a 301 redirect after it has been cached?

With difficulty. A 301 is heuristically cacheable, and browsers may keep it for a long time even without any Cache-Control header. Users who visited before will not see the change until their cache expires. Always set Cache-Control: max-age=3600 during migrations, then remove it once stable.

### What is the difference between 301 and 308?

308 Permanent Redirect is the method-preserving version of 301. A 301 historically converts POST to GET when followed; 308 guarantees the original method is preserved. Use 308 when redirecting form submissions or API endpoints.

### What is the difference between 302 and 307?

307 Temporary Redirect is the method-preserving version of 302. Use 307 instead of 302 when you need to redirect POST, PUT, or PATCH requests without converting them to GET.

### Which redirect should I use for HTTPS migration?

Use 301. Migrating from http:// to https:// is a permanent change. The 301 tells search engines to update their index and passes link equity to the HTTPS version.

## References

- [MDN Web Docs: 301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301)
- [MDN Web Docs: 302 Found](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302)
- [RFC 9110: HTTP Semantics — Redirection 3xx](https://www.rfc-editor.org/rfc/rfc9110#section-15.4)