Moving to a new web host: a step-by-step plan for a quiet switch

List everything that has to move, not just the website

Copying the files is the easy part. A hosting account is often several services that grew up together, and the host you are leaving may be running some you have forgotten about: a mailbox, a nightly script, a redirect someone added years ago.

Pay particular attention to email. If your mailboxes live with your current host, cancelling the account deletes them. And if the move involves pointing your domain's nameservers at the new host, any DNS record you do not recreate there simply stops working. That includes the MX records that tell other mail servers where to deliver your email, and the TXT records that services use to confirm you own the domain. Before you change anything, save a copy or screenshot of every DNS record you have.

If your site runs on WordPress and its address is staying the same, the WordPress documentation says you can usually move it by copying the files and database. If the address is changing too, it warns against a blind find-and-replace across the database: some themes and widgets store values with the length of your URL marked, and when that length changes, things break. Use one of the tools the documentation lists instead. Then work through this inventory.

A week before: lower your DNS TTL

Internet providers do not look up your domain afresh for every visitor. They keep a copy of the answer, and each DNS record carries a time to live, or TTL: the number of seconds a copy may be kept before it should be thrown away and checked again. Think of it as a use-by date written on a sticky note. With a TTL of 86400, a provider that looked up your site a minute before you switched may keep sending visitors to the old server for up to a day.

Google's guidance on changing hosts suggests lowering the TTL to a conservative low value, for example a few hours, at least a week before the move, so that caches refresh faster on the day. The early start matters because copies made under the old, longer TTL have to run out before the shorter one takes effect. Make the change wherever your domain's DNS is managed, and note the original value so you can restore it once the move has settled.

Test the new copy before anyone else sees it

Upload a copy of the site to the new host and check it while the public still goes to the old one. Google's guidance is to review every element of the site in a browser, including pages, images, forms and downloads such as PDFs, and to add a noindex rule to any temporary test address so search engines do not index it by accident.

Many hosts give you a temporary preview address. There is also a way to see the new copy at your real address: your computer's hosts file, which it checks before asking DNS. Add a line with the new server's IP address followed by your domain name and its www version, and your computer alone goes to the new host while everyone else still reaches the old one. On Windows the file is C:\Windows\System32\drivers\etc\hosts and on a Mac it is /etc/hosts; you need administrator rights to edit either. Your browser may show a certificate warning during the preview if the new host has not yet issued a certificate for your domain. Delete the line when you have finished.

Then test like a visitor, not like the owner.

On the day: freeze, copy, switch

The copy you tested started going out of date the moment you made it, because the live site kept changing. Close that gap with a short content freeze: ask anyone who edits the site to stop, pause comments, and if you take orders or bookings, put the site into maintenance mode for the final copy. Pick a quiet time. Google's site-move guidance suggests moving during your recurring traffic dips, so fewer people are affected if something goes wrong.

Take a final backup of the old site, copy the latest database and any new uploads to the new host, and only then update your DNS records or nameservers. Remove any noindex rule or robots.txt block you used during testing; Google's guidance specifically reminds site owners to remove temporary blocks when they start the move.

Check the padlock as soon as the switch takes effect. The free certificate authority Let's Encrypt says its most common validation method, the HTTP-01 challenge, works by fetching a small file from your domain. Until your domain points at the new server, that check reaches the old one, so a new host relying on it usually cannot issue your certificate until after the switch. Ask your new host how it handles this, so visitors do not meet a security warning.

Keep the old host running until traffic stops

Do not cancel the old account on switch day. While some providers still hold the old DNS answer, a few visitors will keep arriving there, along with anything you missed in your inventory. Google's guidance is to watch the server logs on both the old and new hosts, and to shut the old one down only once traffic to it reaches zero.

Keeping the old host also gives you a way back. If something serious goes wrong, you can point DNS at the old server again, but that does not carry back the orders, comments or messages that arrived on the new one in the meantime, so copy those across first. Before you finally cancel, download a last copy of everything on the old account, including any mailboxes.

If your web addresses are changing too, such as a new domain or a new page structure, Google treats it as a site move with URL changes. Map every old address to its new one and set up permanent server-side redirects, such as 301 or 308, pointing straight to the final page rather than through a chain. Keep them for as long as possible, generally at least a year, and expect search rankings to fluctuate: Google says a small to medium-sized site can take a few weeks for most pages to move. If the domain itself is changing, also submit a Change of Address for the old site in Google Search Console.