Google's John Mueller promised a couple weeks ago that he would dig deeper and document how Google handles the various types of redirects. Last night he posted those details on Google+. If you forget, there was a lot of debate in the SEO community over how Google handles 302 redirects.
In any event, he documented so you can trust him or not. In short, the 302 topic might be a bit confusing but technically, the page will rank just as well because of how Google handles a 302.
I am just going to quote what John wrote just in case it gets lost when Google+ gets the full axe. ;-)
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.
The 307 redirect topic is fun for me.
Here is one more tidbit from the topic:
@rajeshkumarsem I'd use a hostname, leave the IP address to DNS.
— John Mueller (@JohnMu) April 8, 2016
Forum discussion at Google+.
