301 vs 302 vs 307 vs 308 Redirects: When to Use Each Status Code

If you are choosing between 301, 302, 307, and 308 redirects, the real decision is simpler than the numbering suggests: is the move permanent or temporary, and does the request method need to be preserved? That one question determines most of the right answer for SEO, browser behavior, APIs, and form submissions.

Quick decision guide: which redirect code to use

The deciding factor is usually permanence first, then method preservation. If you are moving content for good, reach for a permanent redirect. If you are only sending traffic elsewhere for a short period, use a temporary redirect. If the request is a form submission or API call and the method must not change, choose a method-preserving code.

What redirect status codes do, in plain English

• Redirect status codes are server responses that tell browsers and crawlers to request another URL.
• They affect users, search engines, caching, and indexing behavior.
• They are part of the 300-range HTTP status codes, which cover redirection responses.

In practice, redirects are not just about sending people somewhere else. They also shape how search engines interpret the move, how often browsers revisit the original URL, and whether the request body survives the trip to the destination.

301 vs 302: permanent and temporary redirects

For most site owners, the 301 vs 302 decision is the most important one. A 301 says the original URL has moved for good. A 302 says the detour is temporary. That distinction matters because search engines and browsers tend to treat them differently. In general, a 301 is the safer choice for permanent content moves, while a 302 is better when you expect to return traffic to the original address.

One practical rule helps keep mistakes down: if you are changing a URL because the old one is gone for good, use 301. If you are redirecting only while something is temporarily unavailable, use 302.

Where 307 and 308 fit: method preservation matters

307 and 308 were introduced to make method behavior explicit. That matters because not every redirect should silently convert a POST into a GET. If a form submission, API call, or other non-GET request is redirected, the destination may need the same method and payload to function correctly. In those cases, 307 or 308 is often the technically safer choice.

For example, if you are moving a form submission endpoint temporarily during maintenance, 307 is the better fit. If you are permanently changing an API route and need the request body to arrive intact, 308 is the clearer long-term choice.

SEO impact: what search engines are likely to treat as equivalent and where caution is needed

• 301 and 308 both signal permanent moves and are generally treated similarly for link equity transfer.
• 302 and 307 are temporary and are not the default choice when consolidating ranking signals.
• The correct redirect code should match the actual intent of the move, not the SEO outcome you hope to force.
• Using the wrong code can create ranking confusion, indexing issues, or unnecessary duplicate URL signals.

From an SEO perspective, the cleanest approach is consistency. Use a permanent redirect when the content or endpoint is truly replaced. Use a temporary redirect when the source URL still has a valid future. That keeps crawlers from guessing and reduces the chance of mixed signals during migrations.

Use cases by scenario

• Site migration or URL restructuring: 301
• Maintenance page or short-term campaign routing: 302
• A/B testing where the original URL may return: 302
• Form submission or API endpoint moved temporarily: 307
• Permanent endpoint change for an API or application route: 308
• Avoid using temporary codes for permanent content moves

These examples cover the most common operational decisions. A redesign, domain change, or content consolidation usually calls for 301. A maintenance window, controlled experiment, or reversible promotion usually points to 302. If the request is not a simple page view, check whether the method needs to survive the redirect before deciding.

Common mistakes to avoid

• Using 302 when the move is actually permanent
• Using 301 when the change is temporary
• Using 301 or 302 for POST requests without considering method changes
• Assuming 302 behaves identically in every client without testing the implementation
• Ignoring caching and indexing effects after redirect changes

The most expensive redirect mistakes are usually not syntax errors. They are logic errors. A redirect that looks harmless can still distort indexing, create cache surprises, or break form submissions. That is why the code choice should always be tied to how the destination really behaves.

Implementation notes for developers and site owners

• Redirects can be implemented server-side.
• The final choice should align with how the destination behaves, not just with a traffic goal.
• Test the redirect after deployment to confirm status code, destination, and request handling.
• Keep the implementation approach platform-neutral so it can adapt to Apache, Nginx, CDN, app, or framework rules later.

If you want a stronger governance layer around redirects, it can help to pair implementation with a verification process. For example, a verification-first approach is especially useful where mistakes carry operational or compliance risk. See A Verification-First Framework for Redirect Audits in Regulated and High-Trust Environments for a more disciplined audit mindset.

For teams handling frequent content changes, redirect decisions also benefit from clear rules rather than ad hoc fixes. That is one reason governance matters in fast-moving environments; see Redirect Governance for Fast-Changing Content: Lessons from High-Velocity Data Systems.

When to revisit this guide

• Recheck after a site migration or large URL change
• Revisit after browser or crawler behavior changes
• Revisit after SEO guidance changes on permanent redirect handling
• Revisit when building forms, APIs, or short-link systems
• Revisit if the site begins using redirects in a new hosting or CDN layer

Redirect guidance is stable enough to be useful, but not so static that it should never be reviewed. Browser support, crawler interpretation, and platform defaults can change over time. This page is meant to be a practical reference you can return to when your routing strategy, infrastructure, or SEO setup changes.