301 vs 302 vs 307 vs 308 Redirects: Complete Guide
Compare HTTP 301, 302, 307 and 308 redirects, including permanence, method handling, caching, SEO use cases, migration examples, and common mistakes.
HTTP redirects tell a client to request a different URL. The familiar choices—301, 302, 307 and 308—differ along two important dimensions:
- Is the move permanent or temporary?
- Must the client preserve the original HTTP method and request body?
For a normal browser GET, several codes can appear to do the same thing. The distinction becomes more important for search engines, caches, forms, APIs and any request that is not a simple GET.
Quick comparison
| Code | Standard meaning | Intended duration | Method handling |
|---|---|---|---|
| 301 | Moved Permanently | Permanent | Historical clients may change POST to GET |
| 302 | Found | Temporary | Historical clients may change POST to GET |
| 307 | Temporary Redirect | Temporary | Method and body must be preserved |
| 308 | Permanent Redirect | Permanent | Method and body must be preserved |
The first decision is intent. Use a permanent status when the old URL has been replaced for the foreseeable future. Use a temporary status when the original URL should remain the durable address and is expected to serve content again.
The second decision is request semantics. If replaying the original method and body at the destination is required, choose 307 or 308. This is critical for API calls and form submissions.
What is a 301 redirect?
301 Moved Permanently says that a resource has a new durable URL. Typical uses include:
- migrating from HTTP to HTTPS;
- moving to a new domain;
- replacing an old page slug;
- consolidating duplicate pages;
- merging equivalent content;
- enforcing one preferred hostname.
For page migrations, a 301 is widely supported and usually the expected choice. Update internal links, canonical tags and sitemaps to point directly to the destination instead of relying on the redirect indefinitely for your own navigation.
Historically, some clients changed a POST request to a GET while following a 301. That behavior is why 308 exists when strict method preservation is required.
What is a 302 redirect?
302 Found is commonly treated as a temporary redirect. Use it when the source URL remains the long-term address but another destination should handle requests for a limited period.
Examples include:
- a short maintenance window;
- a temporary campaign landing page;
- routing during an incident;
- a short-lived availability or regional flow;
- an experiment where the original URL remains canonical.
Do not use 302 forever merely because it feels easier to reverse. Long-lived temporary redirects create ambiguous intent for maintainers, caches and crawlers. If the move becomes permanent, update the rule and your internal references.
Like 301, historical 302 behavior may transform a non-GET request into a GET. Use 307 when the original method must be replayed exactly.
What is a 307 redirect?
307 Temporary Redirect communicates a temporary move while requiring the client to preserve the request method and body.
If a client sends:
POST /checkout HTTP/1.1
and receives a 307 to /checkout-v2, it should send a POST—with the original body—to the new location. That predictability makes 307 useful for APIs and application routes. It also means the destination must be prepared to receive the same potentially state-changing request.
HTTP Strict Transport Security can also cause browsers to show an “internal 307” when upgrading HTTP to HTTPS. That browser-internal behavior is not necessarily a 307 returned by your origin server, so distinguish the network source when debugging.
What is a 308 redirect?
308 Permanent Redirect combines permanent intent with strict method and body preservation. It is useful when an endpoint has moved permanently and non-GET requests must retain their semantics.
For ordinary web-page GET requests, 301 remains more familiar and widely used. For an API endpoint receiving PUT, POST or PATCH requests, 308 removes the ambiguity created by historical 301 handling.
Before redirecting state-changing requests, confirm that clients can safely retry them and that the destination supports the same authentication, payload and idempotency expectations.
Redirects and SEO
Search engines consider more than the number printed in the status line. They evaluate the destination, content equivalence, canonical signals, internal links and how long a redirect remains in place.
Good migration practice includes:
- map each valuable old URL to its closest relevant replacement;
- avoid sending every retired page to the homepage;
- use direct one-hop redirects where practical;
- keep the destination indexable and healthy;
- update internal links and XML sitemaps;
- align canonical tags with the final URL;
- retain important redirects long enough for users and crawlers to update references;
- monitor old URLs through logs, analytics and search tools.
A relevant permanent redirect normally helps search engines consolidate signals at the destination. A temporary redirect communicates that the source may remain the primary URL. Search engines can interpret long-lived redirects based on observed behavior, so status codes should reflect reality rather than attempt to manipulate an outcome.
Caching behavior
Permanent redirects are more likely to be cached, but the status code alone does not fully determine caching. Response headers, browser behavior, intermediary caches and previous visits all matter.
This has an operational consequence: a mistaken permanent redirect can continue affecting some visitors after the server rule is fixed. Test risky mappings with a temporary code, use an isolated browser profile, and inspect a fresh server-side request before switching to the permanent status.
Server configuration examples
An HTTP redirect response contains the selected status and a Location header:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page
In an application, prefer framework-native redirect APIs so headers and status codes are serialized correctly. Resolve relative destinations carefully and reject untrusted external targets in login or callback flows to prevent open-redirect vulnerabilities.
Common redirect mistakes
Redirect chains
Avoid routes such as:
/old → /newer → /newest
Point /old directly to /newest and update internal references. Use the URL Redirect Checker to see every hop.
Redirect loops
Conflicting host, HTTPS, trailing-slash or locale rules can send requests in circles. Follow the redirect loop troubleshooting workflow before editing multiple layers at once.
Redirecting to an error
A valid 301 that ends at a 404 or 500 is still a broken user journey. Always verify the final status and page purpose.
Using a client-side redirect by default
Meta refresh and JavaScript redirects depend on loading HTML or executing code. For a straightforward URL move, a direct HTTP 3xx response is clearer and more robust.
Replaying unsafe requests
A 307 or 308 preserves the original method. Redirecting a POST can repeat a state-changing operation if the client retries unexpectedly. Design APIs with explicit retry and idempotency behavior.
How to choose the correct code
Use this decision process:
- Will the original URL return as the primary address soon? If yes, choose a temporary status; otherwise choose a permanent one.
- Must the original HTTP method and body be preserved? If yes, use 307 for temporary or 308 for permanent.
- Is this a normal page GET with broad legacy-client requirements? 301 for permanent and 302 for temporary remain conventional.
- Does the destination represent the same user intent? If not, reconsider whether a redirect is appropriate.
- Does the complete route terminate successfully? Run a live chain check after deployment.
Redirect deployment checklist
- The code matches the intended duration.
- Method-preserving behavior is deliberate.
- The
Locationtarget is valid and properly encoded. - The destination is relevant and publicly reachable.
- The final response is healthy.
- No rule redirects to itself or creates a cycle.
- Internal links and canonical tags use the final URL.
- CDN and browser caching have been considered.
- Query strings are preserved or removed intentionally.
- Browser and Googlebot-style requests receive equivalent destinations.
For a repeatable audit, read How to Check a URL Redirect Chain and test the deployed rule—not just the configuration—with the free redirect checker.
Frequently asked questions
Does a 301 preserve SEO value?
A relevant, correctly implemented permanent redirect usually allows search engines to consolidate signals at the destination. Results still depend on destination quality, crawlability and consistent supporting signals.
Is 308 better than 301?
Not universally. 308 is more precise when method preservation matters. For a conventional web-page GET migration, 301 is well understood and often sufficient.
Should I use 302 for A/B testing?
It can be appropriate for temporary routing, but experiments also need stable canonicalization, consistent user experiences and careful bot handling. Avoid creating persistent crawler-only variants.
Can a redirect preserve query parameters?
Yes, but the exact behavior depends on the rule or application. Test campaign and functional parameters explicitly; never assume a rewrite engine will merge or retain them as intended.