301 vs 302 redirects: which should you use?

The decision starts with the source URL

Ask whether you want people and search engines to keep treating the original address as an address in its own right. A retired article with a direct successor has moved permanently. A campaign link that points to this week's offer still has a job to do next week, even though its target may change.

A redirect response contains a status and usually a Location header. The client requests the URL in Location next. A visible final page alone cannot reveal which status was used, how many hops occurred, or whether the first URL was cacheable.

What the server actually says

HTTP defines 301 as Moved Permanently and 302 as Found. Both normally include Location. A 301 is heuristically cacheable unless cache controls or method rules say otherwise; a 302 is not heuristically cacheable by default. Explicit cache headers and client behavior still matter. If you expect to edit a link's target, test it in a fresh client and avoid a long-lived cached permanent response.

For historical compatibility, a user agent may turn a POST into a GET after 301 or 302. A 307 is temporary and a 308 is permanent while explicitly preserving method and body. Do not swap 302 for 307 on a form or API without checking whether the destination accepts the original request.

GET /old-guide HTTP/1.1
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-guide

GET /spring HTTP/1.1
HTTP/1.1 302 Found
Location: https://example.com/current-offer

Search interpretation is a separate layer

Google Search describes 301 and 308 as strong signals that the redirect target should be canonical, and 302 and 307 as weaker signals. Search systems still consider other signals and need time to crawl. A 302 does not by itself promise that the old page stays indexed, and a 301 does not instantly transfer all search visibility.

During a site migration, map each old URL to its closest replacement, avoid redirecting unrelated missing pages to the homepage, update internal links and sitemaps, and keep redirects in place while old URLs are still used. For a temporary campaign destination, the published link can remain stable while the target changes. That is an operational reason for a temporary redirect, independent of an SEO slogan.

Inspect the whole path before choosing

Request the source URL and record every status, Location, final URL, and terminal response. Check HTTP and HTTPS, query parameters, and any www/apex normalization. A 301 to a 302 to a 404 is still a broken experience. Test from a fresh session or with a command-line client when browser caching may hide a change.

• Is the source being retired or kept as a managed public identity?
• Does the request use a method other than GET?
• Could a cached response make future destination edits appear ineffective?
• Does the target return the intended content without extra hops?

Two mistakes with different costs

Using a permanent status on an intentionally editable link can leave clients using a cached target after an operator makes a correction. Using a temporary status for a genuine site move sends a weaker canonical signal to search engines and makes migration intent less clear. Neither is fixed by changing the button label in an admin interface; verify the wire response.

A missing page does not automatically have a replacement. If there is no close successor, return an honest not-found response and help people navigate. Redirecting every retired path to the homepage can confuse visitors and search systems.

A compact release check

For a permanent move, list source and destination paths, verify every target exists, deploy the redirects, update navigation and sitemap, and trace representative old URLs. For an editable campaign, record the published URL and target separately, select an appropriate temporary response, change a test target, then confirm a fresh request follows the new Location.