Servers

Moving a website to new hosting

A migration goes well or badly depending on the order of the steps. The most expensive mistake is switching DNS before checking that the site works on the new server at all.

4 min read

Moving a website to different hosting does not harm your Google rankings in itself - the addresses stay the same, only the server answering them changes. Trouble starts when the steps happen in the wrong order: switch the domain first, then find out whether anything works.

Before the move: a baseline

Record the starting state so that afterwards you can tell whether something got worse. Four things are enough: server response time, the number of indexed addresses from Search Console, a list of your most important pages, and a copy of the index coverage report.

Take a full backup too: files, database and - easy to forget - an export of the current DNS records. If you are moving the domain as well, without that list you will be reconstructing mail and domain-verification entries from memory.

Lower the TTL before you switch anything

TTL tells DNS servers how long they may keep the old answer in memory. With a default of several hours, some users would keep reaching the old server long after the switch. A day or two before the migration, lower the TTL on the A and AAAA records to 300 seconds. Once the move has gone well you can put the longer value back.

Test on the new server before switching the domain

This is the step whose omission costs the most. You can view the site on the new server without touching DNS - add the IP address manually to your local hosts file and your browser will go to the new server while everybody else still uses the old one.

While testing, go through:

  1. The PHP version and extensions - a newer server tends to be newer here too, and older code may not accept that.
  2. The database connection and character encoding, which is where accented characters usually break.
  3. The SSL certificate - it has to be issued and working on the new server before any traffic arrives.
  4. Forms and outgoing mail, together with the SPF and DKIM records.
  5. Cron jobs - they do not travel with the files.
  6. Directory permissions for every folder the site writes to.

Remember to keep the test copy out of the index. If the new server exposes the site on a temporary address, close it with a password or an X-Robots-Tag: noindex header. A second indexed copy of the same content is a real problem.

The switch and the first few hours

Pick your quietest period. Change the A and AAAA records to the new IP address and do not shut the old server down. For a few days some requests will still arrive there, and if the site takes orders or enquiries in the meantime, they need to work on both ends.

If you are changing page addresses at the same time - a hosting move does not require it, and it is better not to combine the two - every old address needs a 301 redirect to its new counterpart. A permanent redirect carries the link value across; a temporary one does not.

After the migration

Check the site as a visitor would: the home page, a few subpages, search, the cart or a form. Then look into the server logs and pick out the 404 and 500 responses - those show you what did not come across. In Search Console, check the indexing report and submit the sitemap again.

For the first fortnight, watch the response time and the number of indexed addresses. A brief wobble in visibility after a move is normal. A lasting drop means something was left behind: a missing redirect, a robots.txt that never travelled, or a certificate that does not cover the www version.

Not working out?

If the problem stays, or you would rather not experiment on a live site, write to us and we will look at it. The diagnosis costs nothing.

Maintenance and development