How to switch hosts without losing rankings or going offline

Two fears keep people on hosts they have already decided to leave: I’ll lose my Google rankings, and I’ll break the site.

The first is mostly unfounded. The second is real but entirely manageable. Here is the honest version of both, and a method that addresses them.

There is no ranking factor for hosting company. Google evaluates your site — its content, its URLs, whether it responds when crawled. Move that same site to a different server and, from Google’s perspective, nothing has happened.

Practitioners who migrate sites routinely report the same thing: dozens of moves with no ranking effect, except where something else went wrong at the same time. One publisher ran the experiment deliberately, moving a site between hosting regions across several continents with a CDN in front, and observed no meaningful change in rankings or traffic.

What does damage rankings during a migration:

• Extended downtime, so Googlebot hits connection errors repeatedly
• A noindex tag left on from staging — the single most destructive mistake on this list
• Broken redirects or changed URLs, usually because a redesign got bundled into the move
• A materially slower server, which degrades the page experience signals you had

Every one of those is a process failure, not a consequence of changing host. Which means every one is avoidable.

The mistake that causes most migration pain is treating the move as a single event — copy everything across, flip DNS, hope.

Do it the other way round. Get the site fully working on the new host while the old one is still serving traffic, verify it there, and make the switch a five-minute change to one DNS record. If anything is wrong, you find out before any visitor does.

Take a backup you have actually tested. Files and database, downloaded locally, not just a snapshot sitting in the old host’s panel. A backup you have never restored is a hypothesis.

Inventory what you have. Not just the site: email accounts and MX records, cron jobs, SSL certificates, redirect rules in .htaccess, subdomains, DNS records for third-party services (mail verification, analytics). The forgettable items are the ones that break.

Note your current speed. Run the TTFB tests against your existing host and write the numbers down. Without a baseline you cannot tell whether the move helped, and you may need the comparison if the new host underperforms.

Freeze changes. No publishing, no plugin updates, no design work for 48 hours either side. If something breaks, you want a short list of suspects.

Change one thing. Move hosts, then redesign — never both at once. When rankings wobble after a combined host-and-theme change, nobody can tell you which caused it.

1. Set the site up on the new host, on a temporary URL. Most hosts give you a staging domain or you can use a subdomain you control. Copy files and database across. Do not touch DNS yet.

2. Block the staging copy from search. Password-protect it, or use noindex. Two copies of your site indexed simultaneously is a genuine duplicate-content problem.

3. Test properly on the new host. Not just the homepage. Check a blog post, a category page, a form submission, checkout if you have one, the admin area, images loading, and SSL. Run your TTFB test here too and compare it against the baseline.

4. Remove the crawl block. Do this before you switch DNS, while you can still see the result.

5. Lower your DNS TTL — 24 hours before the switch. Set the A record’s TTL to 300 seconds. The TTL tells resolvers how long to cache the old answer, so lowering it first means the eventual change propagates in minutes rather than hours. This one step is what makes a “zero downtime” migration possible.

6. Do a final sync, then switch. Copy across anything that changed since step 1 — new comments, orders, form entries — then update the A record to the new host’s IP. Pick a genuine low-traffic window for your audience, not just for you.

7. Keep the old host running for a week. Do not cancel. While DNS propagates, some visitors still reach the old server, and if anything is wrong you can revert by changing one record. A week of overlap costs a few dollars and buys you a complete rollback path.

Within the first hour:

• Load the site from a device that has never visited it — mobile data works well
• Confirm the padlock: SSL must be issued and valid on the new host
• Check yourdomain.com/robots.txt for anything blocking crawlers
• View source on a few pages and search for noindex
• Send yourself an email at your domain, and reply to it

Within the first week:

• Watch Google Search Console for a crawl-error spike
• Resubmit your sitemap
• Spot-check that your important pages are still indexed with site:yourdomain.com
• Re-run the TTFB tests and compare against your baseline

Small fluctuations in the first week or two are normal and usually resolve on their own.

If you see a real drop, work through the causes in order of likelihood: a noindex left in place, robots.txt blocking something it should not, broken redirects, missing pages returning 404s, or SSL errors. Almost every genuine post-migration drop traces to one of those five, and all five are fixable in an afternoon.

What it is almost certainly not is Google disapproving of your new host.

Only if you have a reason the migration can actually address.

If your problem is renewal pricing, moving is straightforwardly rational — what hosting actually costs covers running that calculation properly. If your problem is speed, first confirm the server is genuinely at fault, because most slow sites are slow for front-end reasons and moving will change nothing.

If you have confirmed the server is the bottleneck, our speed rankings compare eight managed cloud hosts on measured origin response time, and the head-to-head comparisons work through the specific trade-offs between them.

Migrating is a manageable afternoon’s work. Staying on a host that is costing you money or speed, because moving sounds risky, is the more expensive mistake.