How to Move Your Website

On Google, any people ask about moving to another web host or IP address without having any sort of glitches. If you have a static website or can spare one day when the site can move between two IP addresses, this would be helpful. However, if you have a dynamic site, the concept will remain the same, but will be slightly more difficult for you. The steps involved in the process are these:

Step 1: Sign up with a good web host provider
It’s always wise to make an intensive research or follow some references in order to have a good web host. As far as I am concerned, I selected csoft.net after the research that did exhibit a brilliant readership, whereas, pair.com was the selection of my non-SEO friend. To clarify the fact, we can assume shifting from csoft.net to pair.com and the IP is going to change then from 63.x.x.x to 65.x.x.x. A machine makes use of DNS system (like 61.115.6.132 ) in order to map websites to the IP address.

Step 2: Create a backup of your website on the new web host
You are just in need of copying the whole file to the new web host with a static website. On the contrary, a blog engages MySQL for the purpose of storage of posts and it makes the process a bit difficult. It is quite possible to find some e-commerce sites where the database is always synced and if it happens, you are probably in need of setting up a copy of the database between the old and new location at the time of 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.
You have to remember that you not only have a username and password for both the web hosts, but different usernames and passwords for the database at every location. You might have the MySQL database stored on a unique location, the reason you should know the host option while database restoration. If the new host has a unique option for the database, you will need to edit the wp-config.php file, otherwise WordPress will not be able to access the database on your new host.

You have similar copies of your website at two different locations. If your blog is just updated with a few comments daily, it is not a big deal if a comment is posted or if someone changes your database during a time when the transition is taking place. However, if your site is huge and based on e-commerce, you will need to work hard to keep both databases synchronized.

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.
 
Sites like Google, Yahoo!, MSN, etc. possess a bit short DNS TTL setting (300-900 seconds) because you intend to have one of them in order to make the data center mechanics perfect for endowing the machines with good data provided you have several data centers. TTL is immensely important as a short TTL lets you drag the IP address of a data center out of the rotary motion very quickly.

The ‘Google Dance’ phenomenon lasted for about a week and would show the old as well as the new results depending on the data center which the user hit. This is because every data center was taken down and brought back up after loading with new data. T needed many days to switch the data to all the centers. Webmasters checked out www2.google.com or www3.google.com as they led them to the latest data centers. Today, the production system is better equipped to switch these things in much less time.

Step 4: The need to 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!

Posted in: