301 vs 302 vs 307 vs 308 redirects

Separate permanence from method handling

301 and 308 describe permanent moves; 302 and 307 describe temporary ones. With 301 and 302, a client may change a POST into a GET when following the redirect. 307 and 308 preserve the request method and body.

For an ordinary page requested with GET, the permanence decision is often the main distinction. For a form or API endpoint, method handling can change the operation performed at the destination. Test that behavior with a controlled request before changing the endpoint.

301 — permanent; POST may become GET
302 — temporary; POST may become GET
307 — temporary; method and body preserved
308 — permanent; method and body preserved

Reference: MDN: Redirections in HTTP

Use permanence to describe the real move

Google treats permanent server redirects as a strong signal that the destination should be canonical. Temporary redirects signal that the source is expected to remain relevant. Neither is a promise of rankings or immediate replacement in search results.

If a product guide has moved permanently, map the old address to the equivalent new guide. If you are running a short-lived routing experiment, make that temporary intent explicit. Avoid choosing the status simply because it is the default in a hosting panel.

Reference: Google Search Central: Redirects and Google Search

Inspect the destination as well as the code

A correctly chosen status can still point to the wrong page. Check the Location value, the next hop and the final response. A redirect from an old article to an unrelated homepage may complete successfully while giving the reader a poor result.

RedirectPath uses GET requests. It can show which status a public URL sends and where the chain ends, but it does not test a POST submission. Use an integration test for forms or API calls that need to preserve their method and body.

Check a redirect before calling it complete

Keep a small mapping of old URLs to their intended destinations. Start with a deep link as well as the root URL so a catch-all rule does not hide a lost path.

1. Choose permanent or temporary behavior based on the actual move.
2. Decide whether non-GET requests must retain their method and body.
3. Trace the public source URL and confirm the final page is the intended replacement.
4. Update links you control to the destination, then retest representative old links.