Types of HTTP Redirects: Complete Reference

Every type of HTTP redirect explained: 301, 302, 303, 307, 308, meta refresh, JavaScript, and canonical. Comparison table, use cases, and a decision guide for choosing the right one.

HTTP defines several redirect status codes, each with different behavior for browsers, search engines, and caching. On top of the server-side codes, there are client-side redirect methods that work through HTML and JavaScript. Choosing the wrong type can break user experience, waste crawl budget, or silently drain your search rankings.

This reference covers every redirect type you will encounter, explains when to use each one, and provides a decision guide for the most common scenarios. For implementation details, see the HTTP Redirect Guide.

Server-Side HTTP Redirects (3xx Status Codes)

Server-side redirects happen at the HTTP protocol level. The server sends a response with a 3xx status code and a Location header pointing to the new URL. The browser follows the redirect automatically before rendering anything to the user.

300 Multiple Choices

The 300 status code indicates that the requested resource has multiple representations, and the server is offering the user (or user agent) a choice. In practice, 300 is almost never used on the modern web. No major browser has a standardized way to present the choices to the user, and no major search engine treats it as a meaningful redirect signal.

When to use it: Essentially never. If you have multiple versions of a resource (different languages, formats), use content negotiation or explicit links instead.

301 Moved Permanently

The 301 is the most widely used redirect on the web. It tells browsers and search engines that the resource has permanently moved to a new URL. Browsers cache 301 redirects aggressively, and search engines transfer full link equity to the destination URL. [1]

When to use it: Domain migrations, permanent URL changes, HTTPS upgrades, consolidating duplicate content, removing old pages with relevant replacements.

SEO behavior: Google passes full PageRank through 301 redirects. The old URL is eventually removed from the index and replaced by the new one. For the full SEO analysis, see How Redirects Affect SEO Rankings.

Caching: Browsers may cache a 301 indefinitely. Once cached, users continue following the redirect from their local cache even if you remove it from the server. This is one reason why using a 301 for a temporary move is a bad idea.

For a deep dive, see 301 Moved Permanently Explained.

302 Found

Originally named "Moved Temporarily" in HTTP/1.0, the 302 status code was renamed to "Found" in HTTP/1.1. Despite the rename, its practical meaning remains the same: the resource is temporarily available at a different URL.

When to use it: A/B tests, maintenance pages, geo-based routing, seasonal promotions, any situation where you intend to bring the original URL back.

SEO behavior: Search engines generally keep the original URL in the index and do not transfer link equity to the destination. Google has said it may eventually treat long-standing 302s as permanent moves, but this is slow and unreliable.

Caching: Browsers typically do not cache 302 redirects, or cache them only briefly. This means the browser checks with the server on subsequent requests.

Method handling: The HTTP spec technically allows browsers to change the request method from POST to GET when following a 302. In practice, most browsers do change the method, which is why 307 exists as an alternative for method-preserving temporary redirects.

For a deep dive, see What Is a 302 Redirect.

303 See Other

The 303 status code tells the browser to retrieve the resource at the new URL using a GET request, regardless of what method the original request used. This is specifically designed for the pattern where a POST request (like a form submission) should redirect the user to a confirmation page via GET.

When to use it: After form submissions (the Post/Redirect/Get pattern), after API operations where you want to redirect to a result page.

SEO behavior: Not typically relevant for SEO because 303 is used for application flow, not content moves. Search engines do not transfer ranking signals through 303 redirects.

For more details, see 303 See Other Explained.

304 Not Modified

Strictly speaking, 304 is not a redirect. It is a conditional response. When a browser sends a request with cache validation headers (If-Modified-Since or If-None-Match), the server can respond with 304 to indicate that the cached version is still valid. No content is sent, and the browser renders from its cache.

When to use it: You do not set this up manually. Your web server handles 304 responses automatically as part of its caching logic. It is included here for completeness since it lives in the 3xx status code range.

307 Temporary Redirect

The 307 status code is the strict version of 302. It means the same thing (temporary redirect) but with one critical guarantee: the browser must not change the request method. If the original request was a POST, the redirected request must also be a POST. [1]

When to use it: API endpoints that temporarily point elsewhere, form submissions that need to be resubmitted to a different URL, any temporary redirect where preserving the HTTP method is important.

SEO behavior: Google treats 307 the same as 302 for ranking purposes. The original URL stays in the index.

Caching: Not cached by default, similar to 302.

For a deeper look, see 307 Temporary Redirect.

308 Permanent Redirect

The 308 status code is the strict version of 301. It signals a permanent move with the guarantee that the browser will not change the request method. [1]

When to use it: API endpoints that permanently move, form submission endpoints that permanently change URLs, any permanent redirect where preserving POST (or other non-GET methods) is required.

SEO behavior: Google treats 308 identically to 301. Full PageRank transfer, old URL removed from index over time.

Caching: Cached aggressively, same as 301.

For a full breakdown, see 308 Permanent Redirect.

Client-Side Redirect Methods

Client-side redirects do not use HTTP status codes. Instead, they work through HTML or JavaScript after the page has already begun loading in the browser. They are slower than server-side redirects and generally worse for SEO.

Meta Refresh Redirect

A meta refresh redirect uses an HTML <meta> tag in the <head> of the page to instruct the browser to load a different URL after a specified delay.

<meta http-equiv="refresh" content="0;url=https://example.com/new-page">

The content attribute specifies the delay in seconds. A value of 0 means an immediate redirect.

When to use it: Only when you have no access to server configuration and cannot set up a proper HTTP redirect. Static HTML pages on hosting that does not support server-side redirects are the primary use case.

SEO behavior: Google can follow meta refresh redirects, but they are a weaker signal than a 301. Google's documentation recommends using server-side redirects whenever possible. A meta refresh with a delay of 0 is treated more favorably than one with a longer delay.

User experience: With a delay of 0, the redirect is nearly instant. With longer delays, the user sees the original page briefly before being redirected, which feels broken.

JavaScript Redirect

A JavaScript redirect uses window.location to send the user to a different URL.

window.location.href = "https://example.com/new-page";

When to use it: Client-side routing in single-page applications, conditional redirects based on browser features or user state, or as a last resort when neither server-side redirects nor meta refresh are available.

SEO behavior: Google can execute JavaScript and follow JS redirects, but it requires rendering the page first, which is slower and less reliable than a server-side redirect. Other search engines may not execute JavaScript at all, meaning the redirect might not work for them. JS redirects are the weakest redirect signal for SEO.

User experience: The original page loads (at least partially) before the redirect fires. Users may see a flash of the original content.

For a comparison of these methods, see Meta and JavaScript Redirects.

Canonical Tag (Not Technically a Redirect)

The rel=canonical tag is not a redirect. It does not move the user to a different page. Instead, it tells search engines which URL should be considered the primary version when multiple URLs serve the same or similar content.

<link rel="canonical" href="https://example.com/preferred-page">

When to use it: Duplicate content across multiple URLs (pagination, tracking parameters, print versions), when you want to consolidate ranking signals without redirecting users.

SEO behavior: Google uses the canonical tag as a strong hint (not a directive) for choosing the preferred URL. It can consolidate ranking signals similar to a 301, but it does not guarantee that Google will honor it.

Key difference from redirects: Users can still access both URLs. Only search engine indexing is affected.

Comparison Table

TypePermanent?Method Preserved?SEO Equity TransferBrowser Caching
301 Moved PermanentlyYesNo (may change POST to GET)Full transferAggressive
302 FoundNoNo (may change POST to GET)Minimal or noneBrief or none
303 See OtherNoAlways changes to GETNoneNone
307 Temporary RedirectNoYesMinimal or noneBrief or none
308 Permanent RedirectYesYesFull transferAggressive
Meta Refresh (0s)Depends on contextN/APartial (weaker signal)None
JavaScript RedirectDepends on contextN/AWeak (requires rendering)None
Canonical TagN/A (not a redirect)N/AConsolidation hintN/A

Decision Guide: Which Redirect Type Should You Use?

For most website owners, the decision tree is short.

Is the move permanent?

If yes, use 301. Unless you are redirecting an API endpoint or form submission that uses POST, in which case use 308.

Is the move temporary?

If yes, use 302. Unless you need to preserve the HTTP method (POST), in which case use 307.

Are you redirecting after a form submission?

Use 303. This is the Post/Redirect/Get pattern, and 303 is designed specifically for it.

Do you have no server access?

Use a meta refresh with a delay of 0. This is a last resort. If you can switch to hosting that supports server-side redirects, do so.

Do you need a conditional redirect based on client state?

Use a JavaScript redirect. But be aware that search engines may not follow it reliably.

Do you have duplicate content but do not want to redirect users?

Use a canonical tag. It consolidates ranking signals without affecting the user experience.

For the vast majority of use cases on the web, the answer is either 301 or 302. The other types exist for specific technical situations. If you are not sure which applies to you, 301 for permanent and 302 for temporary will cover nearly every scenario correctly.

For a detailed comparison of the two most common types, see 301 vs 302 Redirects. For a full list of all HTTP redirect status codes, see HTTP Redirect Status Codes.

References

  1. IETF, "RFC 9110 - HTTP Semantics, Section 15.4: Redirection 3xx," June 2022. https://httpwg.org/specs/rfc9110.html#status.3xx
  2. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects

Trace any redirect type instantly

See every hop, status code, and header in your redirect chain. Works with 301, 302, 307, 308, meta refresh, and JS redirects.

Try Redirect Tracer