Key facts
- Google uses page speed and Core Web Vitals as part of how it evaluates a page, so a new host that is genuinely slower than the old one can drag rankings down even when every URL and piece of content stayed the same.
- A migration that changes any URL structure without adding a 301 redirect from the old URL to the new one tells Google that page is simply gone, and it can drop from the index rather than transfer its ranking history to a new address.
- A misconfigured SSL certificate after a host move can force visitors and Googlebot into browser security warnings or a mixed content state, both of which actively work against a page's ability to rank.
- DNS propagation during a host switch can take up to roughly 48 hours across networks, and if Googlebot hits the site during that window and gets server errors, it can log those pages as temporarily unreachable.
- A robots.txt file copied over from a staging or development environment during migration can accidentally block search engines from crawling the entire live site, which is one of the most damaging and most common migration mistakes.
Check Page Speed On The New Host First
The single most common reason rankings slip after a hosting move is that the new host is actually slower, whether from a smaller server plan, a data center farther from your visitors, or a caching layer the old host had configured that the new one does not. Run your key pages through a speed testing tool and compare the results to what you had before the move, not to a general benchmark.
Google factors page experience signals, including Core Web Vitals like loading speed and responsiveness, into how it evaluates pages. A meaningful drop in speed alone can lower rankings even when nothing else about the site changed, and it is often the first thing to check because it is the easiest to measure with a direct before and after comparison.
If speed did drop, check whether the new host has the same level of caching, a content delivery network, and server resources as the old one, since hosting plans that look similar on paper can perform very differently under real traffic.
Missing Redirects Are the Classic Migration Mistake
If the migration changed any URLs, even something as small as adding or removing a trailing slash or switching from http to https, every changed URL needs a 301 redirect pointing from the old address to the new one. Without that redirect, Google treats the old URL as gone and has to discover and evaluate the new one from scratch, losing whatever ranking history the old URL had built up.
Check Search Console's Page Indexing report for a spike in 404 errors right after the migration date; a sudden jump there is a strong sign that URLs changed without proper redirects in place, and it names the specific pages affected.
If you find missing redirects, add them promptly and submit the affected URLs for reindexing, but expect some recovery time even after the fix, since Google needs to recrawl and re-evaluate each corrected page rather than reinstating the old ranking instantly.
SSL Problems And Server Errors During Cutover
A host switch that does not carry the SSL certificate over correctly can leave the site showing a certificate error, an insecure warning, or a mix of secure and insecure content on the same page. Any of these damages both user trust and how search engines evaluate the page, and a browser security warning will scare away real visitors even if a search engine still ranks the page.
DNS changes during a host switch do not take effect everywhere instantly; propagation can take up to roughly 48 hours across different networks. If Googlebot happened to crawl the site during that window and hit a server error, an old cached page, or nothing at all, it can record a temporary problem that takes another crawl cycle to correct once everything is stable.
Check your server error logs from the days immediately around the migration date for a spike in 500-level errors, since a consistent pattern there during the cutover window explains a lot of what a search engine saw during that period.
A Robots.txt File Left Over From Staging
One of the most damaging and surprisingly common migration mistakes is a robots.txt file that still contains a blanket disallow rule from the staging or development version of the site, quietly blocking search engines from crawling the entire live site after the move. This can look identical to a normal ranking drop until you actually check the file.
Open yourdomain.com/robots.txt directly in a browser right after any hosting migration and read it line by line. A single Disallow: / left in from a staging environment is enough to block every crawler from the whole site, and it is an easy thing for a migration checklist to miss because the site otherwise looks and functions perfectly normally.
If you find this, remove the blocking rule immediately and use Search Console's URL Inspection tool to confirm Google can now fetch the page correctly, then request reindexing on the pages that matter most while the rest recovers naturally over the following crawl cycles.
Related questions
If the underlying technical problem is fixed quickly, most sites see rankings stabilize within two to six weeks as Google recrawls and re-evaluates the affected pages. A migration with a lingering issue, such as a robots.txt block that went unnoticed for a while, can take longer simply because the problem itself ran for longer before being caught.
A brief, small dip during the DNS propagation window is common and usually resolves on its own within a couple of days as every network catches up to the new server location. A larger or longer lasting drop points to an actual technical problem introduced during the move, such as a missing redirect or a blocked robots.txt file, rather than normal migration turbulence.
If every URL stayed exactly the same, including the protocol and any trailing slashes, redirects are not the issue. But it is worth checking a sample of URLs directly rather than assuming, since even one small unnoticed change, like a shift from http to https, requires a redirect on every affected URL to avoid losing that page's ranking history.
Yes. Page experience signals, including load speed and responsiveness, are part of how Google evaluates pages, so a meaningfully slower host can lower rankings on its own even with identical content and URLs. This is worth ruling in or out early with a direct speed comparison, since it is a common and often overlooked migration side effect.
Open your site's robots.txt file directly in a browser and read every line for a Disallow rule that blocks the whole site, then use Search Console's URL Inspection tool on a few key pages to confirm Google can actually fetch and render them. Both checks together will catch the most common accidental blocking mistakes from a migration.
Want a second opinion on your situation?
Get a free, no-obligation proposal. We’ll look at your site and your market and tell you honestly what we’d do — and what we wouldn’t.
Get your free proposal