301 redirects are cacheable. This means that once a user hits that 301, the next time they request the original URL the browser will automatically go to the redirect target without making a request to the server.
Even if the browser cache is cleared, any transparent proxies along the way can also cache the 301 response.
302 responses are not cached.
There are other 3xx responses the indicate that the resource should be retrieved from a different URL however I'm not familiar enough with actually using them to know how browsers and proxies treat them. If you choose to use one of these, test before deploying.
Actually reading the RFC can be so instructive.
From the section on 301s:
Clients with link editing capabilities ought to automatically re-link
references to the Request-URI to one or more of the new references
returned by the server, where possible. This response is cacheable
unless indicated otherwise.
This means that bookmarks and RSS feed URLs might be changed in browsers and RSS feed readers. Some clients do this and some don't. You could send a cache header with the 301 that explicitly told clients not to cache it however this would not affect the above behaviour.
303 and 307 responses were created specifically in response to clients implementing the 302 redirect incorrectly. The request method is supposed to stay the same on the subsequent request, however very few clients actually do this and instead always change to a GET request.
The 303 response tells the client that they should use a GET request on the next hop. A 303 request cannot be cached.
The 307 response tells the client that they should continue using the same request method for the next hop. A 307 response is only cacheable only if explicitly told it is with one of the caching headers.
Both the 303 and 307 are not normally understood by pre-HTTP/1.1 clients. This could also be true of newer clients where the developer didn't implement the entire spec. This is probably only a concern if you know you have a lot of very old clients.
As for your concerns about SEO, the reason that
blog.foo.com is not getting the higher ranking is that you are indicating that
foo.com is the correct URL and that it is only temporarily on
blog.foo.com. Therefore, any links pointing to
foo.com should increase the ranking of
foo.com and not
blog.foo.com. The search traffic will then be sent to
foo.com and redirected to
blog.foo.com instead of the traffic being sent directly to
When you remove the redirect,
foo.com will already have a high ranking and no traffic will be sent to
blog.foo.com. I expect this is what you want to happen.
What should you do?
I would go with the 303 redirect unless I had forms on the site that accepted POST requests. For those I would use 307s which would cause the POST to be made again on the temporary site.
I would also change the 303 response to a 302 redirect for any request indicating that it was
HTTP/1.0 and not
If you do decide to go with 301s, you will most likely still see traffic hitting
blog.foo.com for some time after you remove the redirect. The ranking of
blog.foo.com may linger for some time as well.