3

Let's say that foo.com is where I eventually want to host a website, when it's ready, and blog.foo.com is where I'm currently hosting a website. Until foo.com is ready, is it okay to do a permanent redirect (301) to blog.foo.com?

Once the original website is ready, can this have any negative impact on it? If so, why/how?

One of the reasons why I want to use a permanent redirect is that using a temporary redirect has been negatively impacting the search rankings of blog.foo.com. I'm using Blogger to serve it, so I don't think adding a canonical meta tag would be possible.

aviraldg
  • 135
  • 6

2 Answers2

2

Disclaimer: I am far from an SEO expert.

Using a 301 permanent redirect doesn't seem appropriate here. Not from a semantic HTTP code standpoint or from a SEO perspective. The 301 should be used for permanent redirects, which yours isn't. It's temporary. From an SEO standpoint, the content should then start being transferred from foo.com to blog.foo.com, which is the opposite of what you want long term.

I would recommend using either a 302 or 307.

Justin Helgerson
  • 978
  • 7
  • 12
  • `302` would be my suggestion (like Ek0nomik said, the way you describe things your redirect is a temporary one). `303` or `307` are also technically appropriate, but 302 is more conventional. See also [a list of the HTTP Redirect codes over at Wikipedia](http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection) – voretaq7 Mar 09 '12 at 19:00
  • Yes, that's exactly what I thought (and knew) - but, is there any way to avoid the search ranking hit that comes along with temporary redirects? – aviraldg Mar 09 '12 at 19:02
  • @aviraldg not really - my vague understanding of how search engines handle redirects is that `302` means "Remember the original URL you found this at in your index" and `301` means "Forget the original URL. You were never here. This is not the resource you're looking for." -- if that understanding is still correct the HTTP/302 is your best bet. – voretaq7 Mar 09 '12 at 19:06
1

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 blog.foo.com.

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 HTTP/1.1.

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.

Ladadadada
  • 25,847
  • 7
  • 57
  • 90