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.
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:
- The PHP version and extensions - a newer server tends to be newer here too, and older code may not accept that.
- The database connection and character encoding, which is where accented characters usually break.
- The SSL certificate - it has to be issued and working on the new server before any traffic arrives.
- Forms and outgoing mail, together with the SPF and DKIM records.
- Cron jobs - they do not travel with the files.
- 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 developmentOther guides
Drupal 10 reaches end of life
Drupal 10 stops receiving security fixes on 9 December 2026. If your site runs on it, you have weeks left to decide - and the cost depends mostly on which version you are starting from.
Getting started with AI in your company
Most failed AI projects do not fall over on the technology, but on the choice of process. So we start with what is countable and repetitive, not with what looks most impressive.
A slow website
A slow site is never one fault, it is the sum of several. We start by measuring, because without that optimisation is guesswork - and usually speeds up what was already fast.
An expired SSL certificate
Instead of your site, visitors get a red warning and have to click through "proceed anyway". Most of these cases are an expired certificate or a renewal that never finished.
WordPress redirecting to spam sites
Visitors land on somebody else's site, and Google shows spam where your offer used to be. That is a break-in, not a fault - and cleaning the files alone will not hold.
The WordPress 500 error
HTTP 500 is the server saying something interrupted the code. On its own it tells you nothing - the whole job is getting to the log.
The WordPress white screen
Instead of your site you get blank white. It is one of the most common symptoms, and in most cases it can be defused in a quarter of an hour.