Traffic loss during a hosting move almost never comes from the move itself. It comes from what people do carelessly around it: changing URLs at the same time, leaving a noindex tag on from staging, letting DNS flip before the new server is actually ready, or discovering three days in that the database went over with the wrong character encoding and half the post titles are now question marks. Keep the URLs, content, and site structure identical, sequence the DNS change correctly, and Google's crawlers treat a server swap as close to a non-event. Google's own documentation on hosting changes puts it plainly: if everything else stays the same, only the IP address is different, and that's a low-risk change for search.
The risk isn't the destination host. It's the 48 hours around the switch, and the dozen small things that are easy to forget because none of them show up until they're broken.
Why Sites Actually Lose Traffic During a Migration
Three failure modes account for almost every migration horror story, and none of them are "Google punished us for moving servers."
DNS was rushed. The domain started pointing to the new server before the new server was fully tested, or the old TTL (time-to-live how long resolvers are allowed to cache a DNS record before rechecking it) was still set high, so some visitors and some Googlebot crawls hit a half-configured new site for a day while others still hit the old one.
URLs changed along with the host. Someone used the migration as an excuse to also "clean up" the URL structure, drop a trailing slash convention, or switch from www to non-www. Now every inbound link and every indexed page is pointing at a URL that 404s, and that's a separate, much bigger project than moving hosts.
A staging safeguard got left on. The new host was built at a temporary URL with a noindex meta tag or a robots.txt block so Google wouldn't index the half-finished copy completely correct move and then it went live without anyone removing that block. The site is now telling Google not to index it, and Google is obeying.
None of these are hosting problems. They're sequencing problems, which is good news, because sequencing is something you fully control.
Two Weeks Out: Know Exactly What You're Moving
Before touching the new host, inventory what actually lives on the old one. This is the step people skip because it feels like busywork, and it's the step that prevents the "wait, where's the contact form data" panic on day three.
- Files and database. For a CMS like WordPress, that's the
wp-contentdirectory (themes, plugins, uploads) plus a full SQL export of the database, not just the files. A shocking number of DIY migrations move the files and forget the database is a separate thing. - DNS records beyond the A record. The A record (or AAAA for IPv6) points your domain to a server's IP address, but your zone almost certainly also has MX records (mail routing), TXT records (SPF/DKIM for email deliverability, domain verification for Search Console or Google Workspace), and possibly CNAME records for subdomains. Screenshot or export the full zone file before you touch anything; this is the record people forget, and it's the one that breaks email, not the website, so it doesn't get noticed until someone complains they stopped getting form submissions.
- The SSL certificate. If the old host issued a free certificate (Let's Encrypt or similar), it won't transfer; the new host needs to issue its own. Plan for this explicitly; a site that suddenly serves without HTTPS, even for a few hours, will show visitors a browser security warning and can affect how browsers and crawlers treat the page.
Lower the DNS TTL Before You Do Anything Else
This is the single most underused technique in a self-managed migration, and it costs nothing.
Your DNS TTL controls how long resolvers around the internet are allowed to cache your current record before checking again. If it's set to the common default of 3,600 or 86,400 seconds (one hour to a full day), then when you flip the A record on cutover day, a meaningful slice of visitors and crawlers will keep hitting the old server for up to a day, because their resolver hasn't rechecked yet.
The fix is to lower it in advance so the change itself propagates fast when you need it to.
| Timing | TTL setting | What's happening |
|---|---|---|
| 7 days before cutover | Lower to 3,600s (1 hour) if currently higher | Gets long-cached values out of circulation |
| 24–48 hours before cutover | Lower to 300s (5 minutes) | Short TTL is now the value being cached everywhere |
| Cutover day | Flip the A record to the new server's IP | Most resolvers pick up the change within 30–60 minutes |
| 48–72 hours after cutover | Raise TTL back to 3,600s+ | Reduces DNS query load once the switch is confirmed stable |
The reason for the two-step lower (not just dropping it to 300 seconds the day before) is that the old TTL is still in effect until it expires once a resolver that cached your record for 24 hours won't see your new, shorter TTL until that 24-hour window is up. Lower it a full cycle ahead of your actual cutover, not the night before.
Build and Test on the New Host Before DNS Ever Changes
Upload everything to the new host and get it fully working before the domain points there. Every competent host lets you do this without buying a second domain.
The cleanest way to preview the new server using your real domain name, without any visitor or crawler seeing it, is editing your local hosts file (a plain-text file on your own computer C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Mac/Linux) to point your domain at the new server's IP address just for your machine. Everyone else in the world still hits the old host; you see the new one. It's the closest thing to a dress rehearsal on the exact production URL.
If you'd rather not touch a system file, a temporary subdomain like preview.yoursite.com works too; just add a noindex meta tag or a robots.txt disallow rule on it so it doesn't get crawled and indexed as a duplicate site, and remember to remove that block before go-live. This is exactly the step people forget to undo, which is why "site suddenly not appearing in search" is one of the most common post-migration support tickets.
The WordPress-Specific Trap: Serialized Data and Charset
If you're moving a WordPress database with a plain find-and-replace tool (updating oldsite.com to newsite.com inside a raw SQL file), you can silently corrupt the site. WordPress stores some settings, widget configurations, theme options, and some plugin data as serialized PHP arrays, which encode the exact character length of each string as a number right next to it. A blind text replacement changes the string but not the stored length, and the data becomes unreadable to WordPress. The practical fix: use a proper serialization-aware search-replace tool (WP-CLI's wp search-replace, or a plugin built for migrations) instead of opening the .sql file in a text editor and doing Find & Replace.
Separately, check the database charset and collation on both hosts match (commonly utf8mb4 on modern hosts, but older accounts sometimes still run plain utf8 or latin1). A mismatch during import is the usual cause of post-migration content that looks fine in the editor but shows garbled apostrophes or missing accented characters on the live page.
Cutover Day: Order of Operations
Once the new host has been tested and matches the old site exactly, the sequence for going live is:
- Remove any
noindextags or robots.txt blocks you added for staging. Do this first, or you can flip DNS perfectly and still tell Google not to index the result. - Update the DNS A record to the new server's IP.
- Leave the old host running. Don't cancel it, delete files, or let the account lapse yet. DNS propagation isn't instant, and some visitors will still be routed to the old server for a window after you've made the change. If it goes offline before propagation finishes, those visitors get an error instead of your site.
- Watch server logs on both the old and new host. Traffic on the old server should trail off over the following hours to a couple of days as caches expire; traffic on the new one should climb to match. This is your real-time confirmation the switch is working, not just "assumed."
- Re-verify Search Console if your verification method (an HTML file, a meta tag) was tied to the old server. Update it during the migration window, not before. Google's guidance specifically notes it's better to make Search Console changes once there's already content live on the new host for it to process, rather than pointing Search Console at a destination with nothing there yet.
If a URL Absolutely Has to Change, Redirect It - and Leave the Redirect
A hosting move should not be a URL-restructuring project; bundling the two multiplies your risk for no reason. But if something genuinely can't stay the same (you're also switching from http to https, or consolidating www and non-www versions), every changed URL needs a 301 redirect (permanent redirect - this passes accumulated search authority to the new URL) to its new address, not a 302 (temporary redirect signals to search engines that the old URL might come back, so authority isn't fully transferred).
John Mueller, who works on Google's search relations team, has advised keeping those redirects live for at least a year after the change not the week or month people often assume is enough, because re-crawling and re-processing every affected URL takes time, and removing the redirect early can strand any crawl or link signals that hadn't finished transferring. ()
What to Watch in the First Two Weeks
Expect a brief dip in how often Googlebot crawls the site right after cutover - this is documented, normal behavior, not a warning sign. Google's crawling systems deliberately throttle back when they detect a new server, to avoid hammering it while it's still warming up, then ramp crawl frequency back up over the following days once the new host proves stable. ()
What's worth actually monitoring:
- Search Console → Index Coverage, watching for a spike in errors (especially 404s or "blocked by robots.txt") that wasn't there before the move.
- Uptime monitoring through the cutover window specifically - a free tool checking every few minutes will catch a misconfigured new server faster than waiting for a user complaint.
- Server response codes in your logs. A wave of 500-series errors from the new host in the first hours is a configuration problem (often PHP version mismatch or missing extensions between old and new hosts), not a DNS issue, and it's fixable immediately if you're watching for it.
If rankings or organic traffic do dip, full recovery on a clean migration with no technical errors typically plays out over four to eight weeks, according to Mueller's public comments on migration timelines - not overnight, but also not the months some site owners brace for.
The Record Everyone Forgets: Email
If your email runs through the same domain (Google Workspace, Microsoft 365, or a mailbox hosted by the old provider), your MX records control where mail gets delivered, and they are entirely separate from the A record that controls the website. Moving hosts and blindly copying "the DNS settings" without checking MX records specifically is how businesses go a day without incoming email and don't notice until a client says they never heard back. Confirm your MX records before cutover, and if your new host isn't also handling your email, make sure you're only changing the A record and leaving MX exactly as it was.
When It's Actually Safe to Cancel the Old Host
Not on cutover day, and not the next morning. Wait until:
- The old server's access logs show traffic has dropped to near zero (confirms DNS has fully propagated for essentially all visitors).
- You've done a full pass of the new site - forms submitting, checkout working if it's a store, images loading, SSL certificate valid, not just the homepage.
- At least one full backup of the new host's files and database exists somewhere other than the new host itself.
A week is a reasonable minimum buffer. It costs a few extra dollars to keep the old hosting account alive that long; it costs a lot more to need a file that only existed there after you've already cancelled it.
Related Guides
- for when DNS delays, missing verification records, or email setup errors linger after the cutover.
- slow performance, downtime, or server errors on the new host that don't resolve on their own.
- if the new host's certificate isn't issuing cleanly and visitors are hitting a security warning.
- worth a read once MX and TXT records are rebuilt on the new host, since a sloppy re-entry of these is a common way deliverability quietly breaks.
- a troubleshooting order of operations if the site doesn't come back cleanly after cutover.