Considering Google App Engine but no support for domain without www

[claudiathu]

This is my situation, I have a website which has been online for a few years. It has PR7 and millions of visits monthly.
Since the beginning, I've always use the domain without www, users are used to it, most backlinks are to that domain without www... It is performing very well in SERP, standing #1 for most of its main keywords. Search engine traffic accounts for almost 50% of total traffic.

In short, it is performing very well with it current setup in terms of SERP, user loyalty and brand name.

There is one problem. Users to my site are from all over the world, from the US to Asia to Australia. My server is currently in the US, and its latency and network performance from other locations like Asia is very poor (300ms something, plus dropped packets and congestion sometime). I really want to improve the user experience and for the last month I've tried and benchmarked various networks, webhosting providers and services to find the best location for my server.

I ended up with Google App Engine, which is stable, affordable with excellent geo-distribution technology that make my site fast anywhere in the world (or at least at 3 locations with 95%+ of my users: US, Asia and Australia). The only problem with GAE is that they don't support naked domain (without www or subdomain). Sound stupid isn't it? But that's the way it is. If I was to migrate my site to GAE, I cannot keep the naked domain.

I've read alot of articles regarding this and most of them said it is OK to add/remove the www as long as proper redirection is used. There is even an option in Google Webmaster Center to select the domain with/without www. But I would like to have comments from experts and those who actually did this before putting thousands of dollars migrating the site and end up losing traffic. Yes I could try adding the www on the current server before the migration, but it is still a scary thing to do.

Please give me some advise

[tedster]

most of them said it is OK to add/remove the www as long as proper redirection is used

Sorry, not from what I've seen. If a site is currently indexed without the "www" hostname, then switching over almost always causes a traffic drop of many months duration - even with the appropriate 301 redirects in place. I know it "shouldn't" be this way, but there is a lot of experience out there that says it has been.

Maybe someone has a positive experience in this kind of switch. I'd love to hear about it, and a recent one would be especially good.

[peterdaly]

Are you saying that you would/could implement a 301 redirect for all previous URLs?

[tedster]

Sure, you can redirect every page to its "www" version with one rule. Use .htaccess if you're on Apache or Internet Services Manager if you're on IIS. Then fix any absolute URLs you have in your internal linking, and ask the key backlinking sites to make the change, too.

But doing all that still doesn't mean your traffic won't hit a bump in the road, or a major sinkhole.

[claudiathu]

Should I try adding "www" for about a couple of month? If it doesn't work out I'll change it back. Does it hurt doing so?

[encyclo]

I recently encountered the same issue with a different hosting provider which uses reverse proxies and load-balancing. Luckily I was already using www, but it made me more aware of the advantage of not using example.com without a subdomain (www is a subdomain like any other). It adds an important element in the "www versus no-www" debate which is likely to become more important as more content moves away from one-server IP-address based hosting.

When you're dealing with the newer "cloud" hosting services such as this, it is difficult to use a "bare domain" or "naked domain" as load-balancing is much harder. In short, you can't use a CNAME in the DNS for a naked domain, you have to specify an IP address as an A record (or several A records with different IP addresses). With www, you add a CNAME to ghs.google.com and Google manages the DNS requests, balancing load using smart clusters in different locations. Specifying an IP address, or even several, does not have the same effect.

Note: Google's explanation can be found here: [groups.google.com...]

Google doesn't offer the option of handling the canonical redirect if you decide to go down that route (with the caveats that tedster has mentioned above), so you would need to have a server from a different provider handling uniquely the 301 redirect to www. Many domain registrars offer this, but if you have significant traffic you will need something more robust.

<added: most big sites use www, an exception is twitter.com - if you check their DNS record, their solution is to have 20 A records specifying 20 different IP addresses - see if Google or a different provider could handle a similar solution.>

[claudiathu]

Thank you encyclo,
It looks like I will need to try adding the www first and see how it goes. I wish I could experiment on another less important site first, unfortunately all my other sites are already using www. Does the reverse make any different?

[encyclo]

I would hesitate before going ahead with such a change, and weigh up all the options first. Firstly, is it just ping times slowing your site? For example, if you have lots of graphics or other static elements slowing things down, you could create a "static.example.com" subdomain and point that to Google App Engine. Can you switch parts of your site to subdomains (eg. forums.example.com instead of example.com/forums/)? Does your content divide up by region, allowing for using locally-hosted ccTLDs?

Switching from example.com to www.example.com is a big change, I would say don't rush it, as the potential pitfalls of a change on ranking are well-known.

[claudiathu]

That's exactly what I am doing: move all static contents and ajax services to Google App Engine, but that's pretty much all I can do. All other things are on the main website. I've profiled HTTP request from many locations and the difference between a client in the US and one in Asia is significant. From the US it never take longer than 100ms to load the main HTML, but in Thailand for example it can take a few seconds.

My content is identical for all users, and I am afraid that but dividing the websites for different regions, I will be losing the strength my site currently has.

[lammert]

Moving only the static content and ajax services to a CDN like service like Google App Engine should already give a significant performance improvement for remote visitors, without the problems associated with changing your preferred domain name from example.com to www.example.com. You might lose visitors through Google image search though in the transition period.