The ease with which an existing web site can be moved to a new web host depends largely on the technical type of website to be relocated, and on its reliance on additional components, such as scripts and databases.
There are 4 main categories:
- Static websites: No databases, minimal scripts, simple format.
- Dynamic Sites (such as blogging sites): Use of a database to store comment history and posts.
- Dynamic Commerce Sites (storefronts): Installed E-Commerce packages, complicated databases and scripts.
- Single-Source Solution websites: Reliant on one universal platform to develop and manage all website functions.
The easiest website to transfer to a new web host is a static website. The difficulty increases the further we move down the list. A blogging site, for example, may require the transfer of database content to a new web host. And websites using multiple, or complicated databases, and extensive scripts, increase the level of complexity involved even further.
In the case of websites utilizing a single-source solution, and wanting to continue using the same approach, there is the possibility that they will have to opt for an entirely new e-commerce solution, and then reconfigure.
Changing Web Host: The Steps Involved
There are 4 main procedures involved when changing a web host:
- Selecting a new web hosting provider
- Duplicate the Website
- Move the Domain Name
- Ensure the DNS change has propagated
Lets look at each of these steps in more detail...
Select a New Hosting Provider
This will largely depend on the type of website being run and any specific requirements needed. There are a lot of great hosting options available and the important thing here is to find a reputable host with proven reliability and excellent technical support.
If your web site is geo-targeted to a specific country the location of your hosting provider is important if your web site doesn't have a country-specific domain name extension. If the domain name extension already reflects the targeted country (e.g., .UK, .CA) then hosting location is less important: domain name extension trumps location.
Where hosting location is important, do verify with your new hosting provider if their IP addresses are indeed for the country you target. Some hosting providers are in fact resellers for other, real, hosting companies: an apparently UK based hosting company may be reselling US hosting
Duplicate the Website and Transfer Web Files
It is always a good idea to have a back-up of your website stored on a local computer. Hindsight is a wonderful thing and if anyone has ever lost a website due to hosting related issues, they are painfully aware of how important a back-up of your site can be.
Moving a static site from one host to another is a simple matter of transferring files. This can be done via FTP with applications like SmartFTP. Websites development software such as Dreamweaver, or FrontPage, both have functions for file transferal.
To move a simple MySQL database, such as that used by a blog, it is a matter of creating a new MySQL database with the new hosting provider. The matter is made a lot easier by using the same database name and password for the new version.
Most MySQL databases can be backed-up or exported via the phpMyAdmin entry in the control panel of your hosting. On the other side it can be easily imported this was.
A common problem that occurs at this stage is that your database is larger than 1 or 2 MegaByte while many hosting providers limit uploads to 1~2 MB. While there are workarounds and technical tricks, the best course of action is to contact your new hosting provider and explain them that you need to import a database larger than the permitted upload level. Good hosting companies will either (temporarily) increase the upload limit on your account or will offer the execute the import for you.
Transferring an e-commerce database that requires synchronization is a bit more tricky. The current hosting vendor may agree to assist, but if they refuse, it may be prudent to seek professional assistance if you're unfamiliar with the process involved.
Move the Domain Name
This is a very important step. A newly relocated website needs people to be able to find it. Unless a domain is pointed in the direction of the new hosts servers, anyone using that domain name will be sent to an place that no longer exists.
For the most part, this is a very easy task. Go to the company your domain name is registered with (often but not always different from your hosting company, new or old) and:
- If possible, lower the value of Time To Live (TTL) a couple of days before the site's final move. The value is expressed in seconds so that 1 hour is 3600. Set it to that value or lower to prompt browsers to ask for the specific IP address of your domain name sooner rather than later; this helps prevent people looking at your old site location for days to come
- Change the old hosts DNS information with the DNS information provided by the new web host.
Ensure the DNS Change Has Propagated
The switch from an old DNS to a new one will not happen instantaneously even if the Time to Live of the domain name is set very low. Many major ISP's cache DNS requests themselves, surfing their customers faster domain name resolution in exchange for slightly out of date information. This means that while you already see your site on your new web hosts, others may still access your site at its old location.
In general a full switch can take anywhere from 24-72 hours. So this is vitally important:
Don't take the original website down until search engine crawlers and all visitors access it from its new web host/IP address.
FAQ
Do I need to redirect my old domain?
No, you don't need to provide any 302 or 301 redirects unless besides moving to a new web host you also changed the domain name itself. This is a separate case and falls outside of this article's context.
Will my ranking be affected by moving to a new web host?
No, it shouldn't. If done right, as described above, there is no down-time at all and the switch is completely transparent.
Do I have to worry about spammy sites on the new hosting provider?
In general, no. Search engine engineers know that millions upon millions of web sites live on so-called shared hosting: punishing 10,000 sites on 1 server because of the presence of one spammer would make no sense and open up ways of counter-SEO that would make search useless.
Search engines remember what domains do and, yes, if you buy a domain name it is a very good idea to investigate its history. That however is besides the context of this article.
* with contributions by Ruud Hein
These steps are easy, but to prevent you from having to change..I tell people to do your research first so you don’t have to make that move..
“Black Seo Guy “Signing Off”
Good call, Antonio.
What are some quick research tips you’d give for people looking for a (new) host?
You’re right Antonio, choosing good host can save you from moving. But, good companies get acquired and turn bad, or your site becomes big and you need host with more resources… You can’t 100% sure you’ll never move.
Does this have any effect on the backlinks? Would moving to a new host have any effect on the ranking data?
Manish, if the transition is done the way Roko describes it here then there is no down time and never any reason for search engines to rank your site differently. It’s only when you experience downtime that search engines might start to reconsider, for that period of downtime and based on that period of downtime, if they shouldn’t rank you differently.
So without all the “no but’s..” the short version is: no, it doesn’t affect your backlinks and no, it doesn’t affect your ranking.
As Ruud said, changing hosts shouldn’t have any impact on rankings. Even changing domain name together with the hosting shouldn’t have any impact on rankings if redirect is properly set up so that every url from old domain points to corresponding url on the new domain.
I agree with you in general, Roko, on the domain name change but speaking on behalf of SEP now more than Ruud Hein, we’re hesitant with changing domain names. Massive redirects can cause a dip in ranking, often temporarily but still. In-house we tend to lean towards supporting such a move by providing additional trust signals to the search engines in order to help them “realize” that the domain is legitimately and not taken over by a spammer, unrelated business, etc.
My question is technically related – what about mail MX pointers? At what point do you change those to ensure no email is missed?
Good question, Nick.
I suggest setting up your MX records so they are ready to go when you switch the DNS. This way the whole thing moves over transparent.
I use Google Mail in Google Apps so this wouldn’t be an issue for me but if you host/do your own email, then do empty (download to your email program) all your email boxes, especially if it is IMAP email.
Thanks for bringing that up, Nick!
nice article.
what I do is plan a week before the switch.
I create a text file with tasks what needs to be moved and setup.
I keep adding stuff to the list until the last day and when I am ready to switch I do it when the traffic is low that’s early in the morning usually.
Also I’d keep the old hosting for at least a week should something go wrong with the new host.
Excellent idea and execution, Slavi.
Do you save the txt file for future domain moves or does it change every time?
Slavi, that’s smart – start taking notes a week before. There’s less chance you’ll forget to do something.
I myself am “addicted” to to-do tasks lists. Recently I have started using Quick Notes plugin for Firefox. One simple plugin made my work much more organized and effective – it is like having multiple tabbed notepad right inside your browser. Excellent for to-do lists and notes, plus it has some extra features.
We can shake hands there, Roko 🙂 My current task favorite is Remember The Milk. For simple notes and simple lists, SimpleNote.
Great post 🙂
You’ve even have added information about location specific domains and the location of the server.
Kudos, great job!
Angel
Very kind of you to take the time to pass those compliments on; thanks, Angel!