Web & SEO

301 vs 302 vs 307 vs 308 Redirects Explained

Permanent or temporary, and does the request method matter? Those two questions decide between 301, 302, 307 and 308. Here's what each code means and how Google treats it.

  • By Jacob
  • 6 min read
A solid blue path of tiles running straight from one white card to another, beside a pale looping path, illustrating permanent and temporary redirects

A redirect is just an HTTP response that says "what you asked for is over there." But the status code you send with it tells browsers, caches and search engines two more things: whether the move is permanent, and whether the request may change from POST to GET along the way. Pick the wrong code and you can end up with the old URL in Google for months, or a form submission that silently loses its data.

Here's what each of the four common redirect codes means, according to the HTTP standard and Google's own documentation, and which one to use.

The four codes at a glance

CodeNamePermanent?Keeps the request method?
301Moved PermanentlyYesNot guaranteed. POST may become GET.
302FoundNoNot guaranteed. POST may become GET.
307Temporary RedirectNoYes, always
308Permanent RedirectYesYes, always

So there are really two questions: is it permanent, and does the method matter? Each combination has exactly one code.

What the HTTP standard says

All four are defined in RFC 9110, the current HTTP semantics specification.

301 Moved Permanently

The resource "has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs." Browsers can cache a 301 by default, so once a visitor has seen it, their browser may skip the old URL entirely on later visits.

The catch is in a note in the spec: "For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." Browsers do exactly that, so a form posted to a URL that answers with 301 arrives at the new URL as a GET without its form data.

302 Found

The resource "resides temporarily under a different URI," and the client "ought to continue to use the target URI for future requests." It carries the same historical note about POST turning into GET.

307 Temporary Redirect

Created to remove that ambiguity. It means the same as 302, except that the user agent "MUST NOT change the request method." A POST stays a POST, with its body.

308 Permanent Redirect

The permanent counterpart of 307: the same meaning as 301, with the method preserved. Like 301, it can be cached by default.

There is also 303 See Other, which explicitly tells the client to fetch the new URL with GET. It's the standard way to send a user to a results page after a form submission, the "post/redirect/get" pattern, so refreshing the page doesn't resubmit the form.

How Google treats each redirect

Google's documentation on HTTP status codes sorts them into two groups:

  • 301 and 308 are a strong signal that the redirect target should be processed. Google calls 308 "equivalent to 301."
  • 302 and 303 are a weak signal, and 307 is "equivalent to 302."

Its redirects guide explains what that means for indexing. With a permanent redirect, Google uses the redirect as a signal that the target should be the canonical URL, the one shown in search results. With a temporary redirect, it doesn't, and the old URL can stay in results.

Two practical consequences follow. First, for SEO there's no difference between 301 and 308, or between 302 and 307. Choose between them based on how browsers should handle the request method. Second, the permanent-or-temporary choice really does matter. A page that moved for good but answers with 302 is telling Google to keep showing the old address.

Google also counts redirects that aren't HTTP status codes. An instant <meta http-equiv="refresh" content="0; url=…"> is treated as permanent, a delayed meta refresh as temporary. JavaScript redirects should be a last resort, since Google may not render the page and never see the redirect.

Which one should you use?

Moved a page or a whole site for good: 301 (or 308)

Changed a URL slug, merged two articles, moved from HTTP to HTTPS, switched domains: use a permanent redirect from each old URL to its specific new URL. When you build the old-to-new mapping, the URL Parser helps you compare addresses part by part, so a stray query string or trailing slash doesn't slip through. 301 is the universal choice for normal page requests. 308 works just as well for GET requests and is the safer choice for API endpoints that receive POST, PUT or DELETE.

For site moves, Google advises to keep the redirects "for as long as possible, generally at least 1 year" in its site move guide, and suggests considering keeping them indefinitely for users who have old bookmarks.

Temporarily sending visitors elsewhere: 302 (or 307)

Maintenance pages, a short promotion, A/B tests, sending users to a login page or a country-specific version: use a temporary redirect, because you want the original URL to stay the one people and search engines remember. Use 307 if the original request could be a POST that needs to arrive intact.

After a form submission: 303

When a POST succeeds and you want to show a confirmation page, answer with 303 pointing at that page.

Seeing redirects in action

Redirects happen before the page loads, so they're easy to miss. Here is what our HTTP Headers Viewer reports for http://mobiweb.info:

http://mobiweb.info/    301  Location: https://mobiweb.info/
https://mobiweb.info/   200

One hop, permanent, straight to the final URL. That's what you want for an HTTP-to-HTTPS redirect. The viewer follows up to five hops and shows the status code, HTTP version and response time for each, so it quickly exposes chains like this:

http://example.com/page        301 → https://example.com/page
https://example.com/page       301 → https://www.example.com/page
https://www.example.com/page   301 → https://www.example.com/page/

Each hop adds a round trip for every visitor. Google follows up to 10 hops, but long chains still waste time and are fragile. Point every old URL directly at its final destination.

You can also check from the command line with curl -I http://example.com, which prints the status code and the Location header without following the redirect.

Common redirect mistakes

  • 302 for a permanent move. Many frameworks and hosting panels default to 302. Check what yours sends.
  • Redirecting everything to the home page. When an old page has no equivalent, Google may treat a redirect to an unrelated page like a "not found." Redirect to the closest relevant page, or return 404 or 410.
  • Chains and loops. Old redirects pointing to URLs that now redirect again. Update the old rules to point at the final URL.
  • Mixed signals. Redirecting a URL but still listing it in your sitemap, linking to it internally, or naming it as the canonical. Update all of them to the new URL.
  • Redirecting when you mean to hide. If a page should simply disappear from search but stay available, a redirect is the wrong tool. Our guide to robots.txt vs noindex covers that case.
  • Caching a mistake. Browsers can cache 301 and 308 responses. If you send a permanent redirect by accident, some visitors keep following it even after you remove it, so test redirects before making them permanent.

FAQ

Do redirects lose SEO value?

Google's documentation treats permanent redirects as a strong signal to move indexing to the new URL, and it doesn't describe any penalty for using them. A temporary redirect simply doesn't transfer the canonical status.

Is 308 supported everywhere?

All current browsers support it, and Google treats it the same as 301. Very old clients may not recognize it, which is why 301 is still the common choice for ordinary web pages.

Why does my browser show "307 Internal Redirect"?

That's usually HSTS. When a site has told the browser to always use HTTPS, Chrome upgrades http:// links itself and shows that step as a 307 in DevTools. The request never reaches the server, so it doesn't appear in server-side tools.

Should I use a redirect or a canonical tag?

Use a redirect when visitors should end up at the new URL. Use a canonical tag when both URLs should keep working for visitors, but only one should appear in search results.