A search-engine guide to 301, 302, 307, & other redirects

It’s useful to understand the differences between the common kinds of redirects, so that you know where to use them (and can recognize when they’re used incorrectly). Luckily, when it comes to Google, we’re pretty tolerant of mistakes, so don’t worry too much :).

In general, a redirect is between two pages, here called R & S (it also works for pages called https://example.com/filename.asp , or pretty much any URL). Very simplified, when you call up page R, it tells you that the content is at S, and when it comes to browsers, they show the content of S right away. That sounds simple enough, why are there different types of redirects? Let’s take a look at the redirects, then it’ll be clearer.

Server-side redirects (the webserver returns the redirect as soon as you try to access a page, the user never sees any of the content of page R):

301 permanent redirect: The server tells us that nothing will change its mind about this redirect. Just use “S” in the future, you can cache it like that. Search engines tend to index the content under “S”, and forward any signals from R to S. Useful when you change your site’s URLs for good (site moves, restructures, switching to HTTPS), well, at least until you find a new permanent home for them.

302 temporary redirect: Like the name says, this might not be that permanent. It might change in the future, it might change depending on who accesses it, on the device used, or the user’s location. You can’t cache this. Search engines tend to index the content (and keep all signals) under “R”, since it’s unsure that it’ll always redirect to “S.” This is useful for redirecting from the root URL to a lower-level page (“/” -> “/fancycms/mainpage.php”), and for redirects that depend on the user’s country, device, or language settings.

Client-side redirects (the webserver returns content for both R & S, but the browser recognizes the redirect):

JavaScript redirects: If you can’t do a server-side redirect, using JavaScript is a good fall-back. If you’re using a JavaScript framework for your site, this might also be the only option. Caching depends on the server settings, and search engines have to guess at what you’re trying to do (index under R or S?).

Meta refresh-type redirects: They’re kinda like JavaScript redirects, but usually not recommended.

307 redirects: Wait, isn’t this a server-side redirect? No, this is actually your browser trolling you. If you set up HTTPS, 301 redirect from HTTP to HTTPS, and enable HSTS, when you try to access the HTTP version in your browser, it’ll automatically access the HTTPS version, but record it as a 307 redirect. The 307 is a lie :).

What about PageRank? It’s simple, either the search engine indexes the content with its signals under R or under S, it doesn’t matter which type of redirect you use.

What about 303? 304.5? If you have strong feelings about one of the other kinds of redirects, feel free to use them. We’ll have to figure out which URL to index the content under, so if you have strong feelings about that too, make sure to follow up with other canonicalization signals.

How many redirects can you do at the same time? We follow up to 5 in a chain (please keep any redirect chain as short as possible), but you can redirect as many URLs on your site as you want at the same time.

How does RankBrain fit into this? It doesn’t.

The web isn’t perfect, search engines have to deal with what they find. Sometimes sites use a temporary redirect where a permanent one would be correct, sometimes the other way around. That’s why this is just one of several signals we use for picking the right URL (“canonicalization”).

In short, for 301 or 302:
301: “S” tends to get indexed, the redirect is cached
302: “R” tends to get indexed, the redirect isn’t cached

I hope this helps understand the differences & pick the right type when you need to set up redirects! Let me know if anything’s confusing :).

More about canonicalization: https://support.google.com/webmasters/answer/139066?hl=en
Photo
Shared publiclyView activity