Sometimes you may decide you want to move servers without changing your domain name or any of your URLs. A common cause of this is that the growth of your traffic requires you to move up in terms of hosting environment. If you are using third-party hosting, perhaps you are changing your hosting company. If you have your own data center, you may need to move or expand your facilities, resulting in a change in the IP addresses of your servers.
This is normally a straightforward process: simply go to the registrar where you registered the domain name and update the DNS records to point to the new server location. You can also temporarily decrease the site’s DNS Time to Live (TTL) to five minutes (or something similar) to make the move take place faster. For the most part, you should be done, though you should follow the monitoring recommendations we will outline shortly.
Even if you follow this process, certain types of problems can arise anyway. Here are the most common ones:
You may have content that can’t function on the new platform. A simple example of this might be that you use Perl in implementing your site, and Perl is not installed on the new server. This can happen for other reasons, and these can result in pages that return 404 or 500 errors, instead of the content you intended.
Unfortunately, publishers commonly forget to move key content or files over, such as robots.txt, analytics files, sitemaps.xml, the .htaccess file, and so forth. The first tip, of course, is not to forget to move these files, but people are human and they do make mistakes.
Server configuration differences can also lead to mishandling of certain types of requests. For example, even if both your old server and your new server are running IIS, it is still possible that the new server is configured in such a way that it will turn any 301 redirects you have in place to 302 redirects, which would be unfortunate indeed!
The best advice for dealing with these concerns is to make a list of special files and configuration requirements and verify that everything is in place prior to flipping the switch on the server move.
In addition, you should conduct testing of the new site in its new location before flipping the switch. You will need to access the content on the new site using its physical IP address. So, the page at http://www.yourdomain.com/pageA.html will be found at an address similar to http://206.130.117.215/pageA.html. To do this, you should add that IP address to your test machine’s hosts file (this assumes you are running Windows) with a corresponding hostname of http://www.yourdomain.com, which will allow you to surf the site at the new IP address seamlessly. This advance testing should allow you to check for any unexpected errors. Note that the location of the hosts file varies across different versions of Windows, so you may need to search online to get information on where to find it on your machine.
As with our other scenarios, post-launch monitoring is important. Here are the basic monitoring steps you should take:
Monitor your Webmaster Central account for 404 errors and to see how well Google is doing with your 301s. When you see some 404s pop up, make sure you have a properly implemented 301 redirect in place. If not, fix it.
Monitor the spidering activity on the new domain to make sure no unexpected drops occur.
Watch your search traffic referrals for unexpected changes.
You can also check your server logs for 404 and 500 errors. This will sometimes expose problems that your other checks have not revealed.
Sometimes organizations transition from a single-server environment to a multiserver environment because of increasing levels of traffic (a good problem to have!). How this affects them depends on how they make the transition. The wrong way to do it is to have one server at http://www.yourdomain.com, another at http://www2.yourdomain.com, yet another at http://www3.yourdomain.com, and so forth. This is because all these scenarios are creating duplicate content. Unfortunately, this type of mistake is common. If you search on inurl:www2 in Google, it returns 346 million results! (See Figure 10-1.)
Fortunately, when you are knowledgeable about that issue, it is usually not too difficult to implement a transparent solution in which the URL always starts with “www” regardless of the server providing it.