A hosting migration moves the same site to a different server without changing any URLs. Because nothing about the site’s structure changes, it is far lower risk than a URL migration and is often treated as having no SEO dimension at all.
That is nearly right. The risks are narrow, specific, and mostly concern availability during the cutover rather than anything structural.
What can actually go wrong
Downtime during propagation
DNS changes propagate at different speeds for different resolvers. If the old server is decommissioned before propagation completes, some visitors and crawlers hit nothing.
- Lower the TTL on your DNS records well before the move, so changes propagate quickly.
- Keep the old server running for at least 48 hours after the switch.
- Do not cancel the old hosting until logs show no traffic reaching it.
Configuration not carried across
The commonest real problem. Server-level settings live outside the site files and are easy to forget.
- Redirects configured at server level rather than in the application. Losing these breaks every old URL.
- robots.txt, particularly if it was served dynamically.
- HTTPS and certificates, where a lapse causes browser warnings and crawl errors.
- Compression and caching headers, whose absence shows up as a performance regression.
- Custom error pages and their status codes.
Staging protections carried across
If the site was staged on the new host before cutover, any noindex or robots block used during staging must be removed. This is a common way to deindex a site during an otherwise routine move. See staging site indexing.
Performance changes
A new host can be faster or slower. Slower response times reduce crawl rate and affect Core Web Vitals. Baseline before moving so the comparison is real.
IP-based issues
Rare, but a new IP with a poor history, or one that triggers geographic assumptions, can cause problems. Worth checking before committing to a host.
A practical sequence
- Baseline performance and capture a crawl before moving.
- Lower DNS TTL several days ahead.
- Replicate server configuration explicitly rather than assuming it transfers.
- Test thoroughly on the new host before switching DNS, with access restricted.
- Remove any staging protections before cutover.
- Switch DNS, keeping the old server live.
- Verify status codes, redirects, robots.txt and HTTPS immediately.
- Re-crawl and compare against the pre-move baseline.
- Decommission the old server only once traffic has stopped reaching it.
Frequently asked questions
Will changing hosts affect rankings?
Not inherently, since URLs do not change. Effects come from downtime, lost configuration or performance changes rather than from the move itself.
How long should I keep the old host?
At least 48 hours after switching DNS, and until logs confirm nothing is still reaching it. Cancelling early is the main cause of downtime during otherwise clean moves.
Do I need to tell Google?
No. There is no notification for a hosting change, and the Change of Address tool applies to domain moves rather than server moves.
What if the new host is slower?
That matters, since crawl rate adapts to response time and page speed affects users. Baseline before moving so you can tell, rather than discovering it later as an unexplained decline.
Consulting CTA
If you are moving hosts and want the configuration risks checked before cutover, book an SEO consultation.