Moving WordPress to a new host without losing rankings

Google doesn’t care which server your site lives on. It cares whether the URLs it indexed still return the same content with a 200 status, quickly, over HTTPS. A host move done in the right order changes none of that, and rankings don’t move. The drops people blame on “the migration” come from a handful of skipped steps: a changed URL structure, a lost redirect file, a staging copy that got indexed, an SSL certificate that lapsed for a day. Here’s the order I use, with the checks.

Step 01 Inventory before you touch anything

Take a full backup (files and database) and keep it off both hosts. Then record what “working” looks like so you can compare later:

• Export the list of indexed URLs: Search Console → Pages, and your XML sitemap.
• Save your .htaccess (or nginx rules) and any redirect plugin’s list. Old redirects are rankings; losing them is the number-one cause of a post-move drop.
• Note the PHP version, the cron jobs, and any server-level things: mail routing, SSL, wp-config.php constants, cache settings.
• Run a crawl (Screaming Frog, or Ahrefs’ free tools) and keep the report. This is your “before”.

Step 02 Build the copy on the new host, on a temporary address

Copy the files and import the database onto the new host, reachable at a temporary URL (most hosts give you one) or via your computer’s hosts file, which lets you see the new server at the real domain without changing DNS for anyone else. Do not set the site to a temporary domain with search-and-replace; keep the real URLs in the database and use the hosts-file trick. That way nothing has to be replaced back.

Keep the staging copy out of Google If the temporary URL is public, set Settings → Reading → “Discourage search engines” on the copy, or password-protect it at the host. An indexed duplicate of your whole site is a real ranking problem.

Step 03 Test it like a visitor and like Google

On the new server (via the hosts file): click through the site, submit a form, log in, place a test order if it’s a store, check images and uploads load, run the crawl again and compare against step 01. Every URL that was 200 before must be 200 now. Confirm the redirect rules from step 01 are in place on the new server; nginx hosts need .htaccess rules translated, and that’s where old redirects quietly die.

Step 04 SSL before DNS

The new host must serve a valid certificate for your domain before traffic arrives, or every visitor (and Googlebot) gets a warning for however long issuance takes. Most hosts can issue via DNS validation ahead of the move, or you can copy the existing certificate. Test at the new IP with curl --resolve. An hour of certificate errors is the most common self-inflicted “migration drop”.

Step 05 Lower the TTL, then switch DNS

A day before the move, set the DNS record’s TTL to 300 seconds, so the change propagates in minutes instead of a day. Then, at a quiet hour:

1. Put the old site into read-only for stores (a maintenance notice on checkout only; browsing continues). For a blog, skip this.
2. Take a final database export from the old host and import it into the new one, so the last comments and orders come across.
3. Point the DNS A record (or Cloudflare proxy) at the new host.
4. Watch the new host’s access log. Traffic appears within minutes.

Leave the old host running, untouched, for at least a week. Some resolvers ignore TTLs; those visitors quietly land on the old server, which still works.

Zero downtime, honestly Browsing never stops in this sequence. For stores there is one pause: checkout is frozen for the fifteen to thirty minutes between the final export and the DNS switch, so no order is created on a server that’s about to be retired. That pause is the price of not losing an order, and it’s worth paying.

Step 06 The checks after the switch

• curl -I https://yourdomain.com should show the new server and a 200.
• Search Console → URL Inspection on three URLs: live test, confirm “URL is available to Google” from the new host.
• Resubmit the sitemap. Not required, but it prompts a recrawl.
• Check that email still sends (contact form, order emails). Mail is the thing most often left pointing at the old host.
• Watch Search Console’s Pages report for a week. A blip of “server error (5xx)” for one day is normal; a growing number is not.

Step 07 Only now cancel the old host

After a week of clean logs, no 5xx in Search Console, and email confirmed, take a last backup from the old host and cancel. If you cancel on day one and something was missed, the backup you need is gone.

That’s the whole method. It’s not hard, but there are eleven places to skip something, and each skip has a ranking attached. If you’d sooner have it done for you, the migration service is exactly this list with a receipt at the end, and the only thing you do is approve the cutover time.