Latest Tools

It is not something new that there are many people around us who raise the issue of switching to another web host or IP address being devoid of any sort of hiccups in Google. In this article, the experience of moving mattcutts.com from one IP to another IP just with the aid of altering the host is elucidated. It's easier to accomplish having a static website than a dynamic website. The idea doesn't vary but it is better if you can spend a day while your website can swing between 2 IP addresses. Some steps are there.

It is not something new that there are many people around us who raise the issue of switching to another web host or IP address being devoid of any sort of hiccups in Google. In this article, the experience of moving mattcutts.com from one IP to another IP just with the aid of altering the host is elucidated. It's easier to accomplish having a static website than a dynamic website. The idea doesn't vary but it is better if you can spend a day while your website can swing between 2 IP addresses. Some steps are there.

Step 1: You need to sign up with a good web host provider

You can do a bit of research or follow some references to find a good web host for yourself. The web host you could use is csoft.net, and you may find that the readership of your site is growing even beyond your own expectations. You could also use pair.com. if you move from csoft.com to pair.com, the IP would change from 63.x.x.x to 65.x.x.x. DNS is a system which is used to map websites to the IP address which a machine uses, such as, say 61.115.6.132.

Step 2: Create a backup of your website on the new web host

Having a static website is good as it would just mean copying the whole file to the new web host - that's it. But having a blog is a bit hard since it generally involves MySQL for storage of posts. Some e-Commerce sites are more difficult for this purpose as the database is always synced over there. In such a case, you might have to set up a replica of the database between the old and the new location during the transition.

Let's cite an instance of a WordPress blog using MySQL database which can afford to be down for a couple of hours with little problem. Firstly, assume that you have used the FTP or tar for copying the static files from one web host to the other. You then need to create a fresh MySQL database on the new host. Normally, you can give the same username and database name. If not, then make sure you tweak the WordPress wp-config.php on the new location for updating the username, database name, and other relevant things.

You now have a new SQL database so you can get away with the old one, copy it to the new one, and then load the database there.

Keep in mind that you not only have a username and a password for both the web hosts, but different usernames and passwords for the database at every single location. You may also have the MySQL database stored on a unique location, which is the reason I showed the host option while database restoration. Also, if the new host has a unique option for the database, you will be required to edit the wp-config.php file, else WordPress will be unable to access the database on your new host.

At two separate locations, you do have the same copies of your website. The issue of maintaining both the databases synchronized is only applicable to the vast and e-commerce based site. Whereas, someone altering your database at the transition period or a comment getting posted is nothing serious provided your blog is endowed with update of some comments regularly.

Step 3: Changing the DNS to point to the new web host

One needs to have an acquaintance with the term DNS because it's of paramount significance. Your IP address is indispensable for any agent striving to get to your site-be it Googlebot or anybody else. Rechecking the IP address after 500 fetches in order to determine the authenticity or making sure if some hours have gone are common factors. TTL (Time to Live), calculated in seconds, does have an impact if you have DNS-enabled browsers. It states that your fetched IP address is going to be safe for 'x' seconds and for this much time, the address can be stored. The browser is expected to proceed very slowly simply because the IP address is meant for everything on each webpage of your site.

For DNS, TTL assumes a significant role. A couple of websites like Google, Yahoo!, MSN, etc. have pretty short DNS TTL setting of about 300-900 seconds. This is because if you have many data centers, you would like to take one of them down to enable the data center mechanics to provide good data to the machines. If you have a short TTL, you would be able to pull the IP address of a data center out of the rotation in merely a couple of minutes.

This also explains the days of "Google Dance" that went by. It would last for a week or so, and based on the data center which the user hit, they would see the old as well as the new results. The main reason was that every data center was brought down and brought back, after loading it with new data. It required many days to switch the data to all the centers. During the period, webmasters checked out www2.google.com or www3.google.com since they led them to the latest data centers. Nowadays, the production system is properly equipped for switching these things around in lesser time.

Step 4: Wait while the DNS change is propagated through the internet

This is a TTL function and is based on whether you are switching to those name servers which are present in the DNS currently. DNS is hierarchical, and thus it will take some time for the DNS caches to be flushes as the TTL is exceeded. The switch, which takes place at the root of DNS, would be faster only if you use a smart registrar and a known set of the new name servers. The 'dig+trace domain' can be used in UNIX and Linux for confirming that the new name server is present on the root server.

Step 5: You are almost done with your task when you are sure that Googlebot is fetching from the new web host and the IP address. In such a case, the old website can be shut down.

You can check your IP address by pinging your domain. By doing this, you can see your progress. The old visitors, from their own DNS cache, may be using the old IP address, but be sure that the new visitors get the new one. It is considered good to allow a couple of days as a few people might have a long TTL set, even though most of them are for about a day or even less. So after a day has elapsed, it would actually be safe to de-activate hosting on the old location. You can check your logs for foolproof confirmation on this. If your log mentions no visitor visiting from the old location, then you are fully done with it!