Site Migration Without Losing SEO: The Host-Only Plan

Moving web hosts without changing your URLs is the easiest migration to get right, and somehow the one people panic about most. If your domain stays the same and your URL structure stays the same, you are not doing an SEO migration in the way Google's own documentation on site moves with URL changes describes. You're moving infrastructure. The content sits at the same address, it just answers from a different server. Handled properly, this shouldn't cost you a single ranking.

Does moving hosts hurt your SEO if the URLs don't change?

Not if you do it properly. Google indexes URLs, not servers. If example.com/blog/post-name resolves to the exact same content before and after the move, there's nothing for Google to re-evaluate on the URL or content side. What actually hurts you is everything around the edges of the switch: DNS misconfiguration, a slower new server, redirects that didn't need to exist in the first place, or a cutover that leaves half your pages timing out for a few hours. I've had clients convinced their host migration tanked their rankings when the real cause was a plugin conflict that only showed up on the new server's PHP version. Separate the migration from unrelated site issues before you decide Google punished you for switching hosts.

Do you need 301 redirects when the URLs are identical?

Mostly no, and this is where host migration guides get muddled up with domain migration guides. A 301 redirect tells Google "this URL has permanently moved to that URL." If nothing has moved, there's nothing to redirect. The redirect situations that genuinely apply to a same-URL host move are: forcing HTTPS if your old server didn't, fixing a www versus non-www inconsistency you're finally sorting out during the move, or redirecting a small number of URLs that changed for unrelated reasons while you happened to be migrating. Don't build a redirect map for a migration that doesn't need one. That's agency-checklist thinking bleeding into a scenario it was never written for.

How much should you lower DNS TTL before migration, and when?

Lower your DNS TTL (time to live) at least 24 to 48 hours before cutover, ideally down to 300 seconds or lower. TTL controls how long resolvers cache your DNS records. If your TTL is sitting at the default 24 hours when you switch your A record to the new server, some visitors and some Googlebot requests will keep hitting the old server for up to a day afterwards, simply because their resolver hasn't asked for a fresh answer yet. Drop it low in advance, let that lower value propagate first, then make your actual server switch. This is the single most skipped step I see, and it's why you get "it worked for me but not for my colleague" reports during cutover.

What does Googlebot see during the propagation window?

During the propagation window, different Googlebot crawl requests can land on different servers, because Google's crawlers, like everyone else, are subject to DNS caching at whatever resolver they're querying through. This is exactly why keeping both servers serving identical content matters so much during this period, which I'll come to next. If your old and new servers are in sync, it doesn't matter which one Googlebot hits, the response is the same. If they've drifted, even slightly, Google can end up seeing inconsistent versions of the same URL within a single crawl session, and that's far more likely to cause a temporary dip than the migration itself.

Why keep both servers live during cutover?

Because propagation isn't instant and isn't uniform. Some ISPs and resolvers respect TTL properly, some don't, and mobile networks in particular are slow to pick up DNS changes. Decommission the old host the moment you flip DNS and anyone still resolving to the old IP gets nothing, Googlebot included, on a bad day. Keep the old server running, fully functional, for at least 48 hours after the switch, longer if your previous TTL was high or you're not certain every resolver has caught up. This costs you a bit of overlap hosting expense. It's cheap insurance against a chunk of your traffic hitting a dead server during the exact window you're trying to protect.

How do you verify the migration actually worked?

Don't trust "it loads fine when I check it." Run an actual crawl of the site post-migration with a proper crawler, comparing status codes, response headers, and page content against a pre-migration crawl if you took one, which you should have. Look for unexpected 404s, 500s, redirect chains that weren't there before, missing headers, or content rendering differently because of a server-level config difference such as PHP version, gzip compression, or a caching layer that behaves differently. Check your server response times too. A slower time to first byte on the new host is a real SEO factor, not a cosmetic one, and Google's guidance on TTFB is worth reading properly if you never have. If your new host is measurably slower under real load, fix that before you call the migration finished, not after.

What's a normal post-move dip versus a real problem?

Some fluctuation in the days after any infrastructure change is normal and usually has nothing to do with rankings specifically, it's Google re-confirming crawl and index signals against a URL it already trusts. A normal dip is small, temporary, and recovers within a week or two on its own. A real problem looks different: rankings keep sliding instead of recovering, Search Console starts flagging server errors or a spike in "crawled, not indexed" pages, or your server logs show Googlebot hitting timeouts or 5xx errors repeatedly. If you see the second pattern, go back to basics. Check your new host's resource limits, check for a firewall or security plugin blocking Googlebot's user agent, and check that robots.txt didn't change accidentally during the move. I've seen more "SEO migration disasters" caused by an overzealous security setting on the new server than by anything to do with search engines at all.

How long does site migration SEO take, honestly?

For a same-URL host migration, the technical cutover itself should take hours, not days, provided your DNS TTL was lowered properly in advance. Full propagation across all resolvers globally can take up to 48 hours in edge cases, though most traffic shifts within a few hours. Google re-crawling and confirming everything is unchanged typically happens within one to two weeks for a small to medium site, faster if you submit key URLs for re-crawling via Search Console and your site already has healthy crawl frequency. Factors that widen this window: a large site with hundreds of thousands of URLs, a migration that also changes CDN or caching configuration, a new host with meaningfully different performance characteristics, or complications that turn a "simple" host move into something closer to a platform migration. If any of that applies, treat it as a bigger project and plan accordingly with something like a proper migration planner rather than winging the timeline.

What should a site migration SEO plan actually include?

Before touching anything: lower DNS TTL, take a full crawl and screenshot key rankings and Search Console data as a baseline, and confirm your new host can genuinely handle your traffic and stack, not just tick boxes on a spec sheet. During cutover: keep both servers live, monitor server logs for Googlebot activity on both, and resist decommissioning the old host early out of impatience. After cutover: run a comparison crawl, check Search Console for crawl errors and coverage issues daily for the first week, and watch your actual analytics rather than assuming silence means success. If you're choosing a new host as part of this and haven't settled on one yet, our hosting rankings and comparison tool are built for exactly this decision, and our Host Reliability Index gives you a more honest read on real-world performance than most marketing pages will. If you're running WordPress specifically, our WordPress hosting guide covers the platform-specific gotchas that catch people out during a host switch, and if you want the broader non-SEO checklist for the move itself, read how to switch web hosts without breaking your site.

Frequently asked questions

Will changing web hosts affect my Google rankings?

Not meaningfully, if the URLs stay the same and you manage DNS, server overlap, and performance properly. Rankings are tied to URLs and content quality, not to which server happens to be answering the request. Most ranking damage blamed on host migrations actually comes from unrelated issues surfacing in the same window, like a slower server or a misconfigured plugin.

Do I need to tell Google I'm changing hosts?

No. There's no submission process for a same-URL host migration because nothing about the URL or content has changed from Google's perspective. You only need to notify Google, via a change of address in Search Console, when you're moving to a genuinely different domain, which is a different kind of migration entirely.

Should I migrate hosting during low traffic periods?

It's sensible practice, mainly because it minimises the number of real users affected if something goes wrong during the propagation window, not because Googlebot cares what time it is. Pick a low-traffic window for your own team's sake and to reduce the blast radius of mistakes, then follow the technical steps properly regardless of timing.

What's the difference between a host migration and a full site migration for SEO?

A host migration keeps the URL structure identical and just moves the underlying server. A full site migration typically involves domain changes, URL structure changes, or a CMS switch, all of which need proper 301 redirect mapping and much closer monitoring because Google is genuinely re-evaluating new URLs. If you're only changing where your site is hosted, don't apply a full migration checklist wholesale, it's overkill and can introduce risk that wasn't there to begin with. For more on how hosting decisions fit into the bigger picture, see the hosting trends actually changing where sites live, and browse our hosting directory if you're still working out where to move to.