How to Move Your Website to a New Server Without Losing Google or AI Search Visibility | CrawlReady AI
A practical migration checklist: keep DNS, HTTPS, robots.txt, sitemaps, and AI crawlers working when you change hosts — so Google, ChatGPT, and Perplexity can still find you.
By Mubashir Hussain · CrawlReady AI · Human-reviewed technical guide
Some guides may be AI-assisted and are always human-reviewed for accuracy before publish. See our Google generative AI search guide and Google's AI content guidance.
Moving a site to a new VPS or cloud instance is a DNS and HTTPS job, not a redesign. Google, ChatGPT search, Claude, and Perplexity still look up your hostname. If the new server answers that hostname with the same public URLs, a valid certificate, and an open robots.txt, visibility should transfer. If anything in that chain breaks — even for a few hours — crawlers see downtime, certificate errors, or a blank host, and citations stall.
What actually changes when you change servers
The domain stays the same. The A record (and usually the www A record) change to a new public IP. Everything else must be rebuilt or copied onto the new machine: TLS certificates, nginx or Apache vhosts, application process, robots.txt, XML sitemap, and any firewall in front of ports 80 and 443.
Cloud providers add a second firewall you cannot see from SSH. On Oracle Cloud that is the VCN security list. On AWS it is a security group. Opening port 22 for deploy is not enough. If 80 and 443 stay closed, browsers and crawlers time out even though the app is healthy on localhost.
Step 1: Stand up the new host before you touch DNS
Deploy the application on the new IP first. Confirm from the server itself that the app returns 200 on the loopback port and that nginx proxies / when you send a Host: yourdomain.com header. Do not point DNS at a box that cannot serve the homepage yet.
- Copy the production
.env(secret key, mail, storage) so sessions and forms keep working - Use the same URL structure — do not rename paths as part of the move
- Install Python and process manager versions the app actually supports
Step 2: Open HTTP and HTTPS on the cloud firewall
Add ingress rules for TCP 80 and TCP 443 from 0.0.0.0/0. Leave the source port empty (all). Also allow those ports in the instance firewall (iptables or ufw) before the default reject rule. Then test from a network that is not the server:
curl -I http://NEW_PUBLIC_IP
curl -I -H "Host: yourdomain.com" http://NEW_PUBLIC_IPA timeout means the cloud security list is still closed. A 301 to the domain is fine once nginx is configured. A 200 with the real homepage HTML means the new origin is ready.
Step 3: Change DNS, then issue TLS on the new machine
Update the apex and www A records to the new IP. Wait until public resolvers return that IP — Namecheap and most registrars propagate in minutes, but some caches hold the old address longer. Only after the new host receives requests for your hostname should you run certbot (or install the existing certificate files).
HTTP should redirect to HTTPS. www should redirect to the canonical host you already use in Search Console. Mixed content or a certificate name mismatch will make Chrome and many crawlers treat the site as unavailable.
Step 4: Re-check crawl access, not just the homepage
After HTTPS is live, verify the files crawlers actually read:
https://yourdomain.com/robots.txt— still allows Googlebot and, if you want AI discovery, OAI-SearchBot, GPTBot, ClaudeBot, and PerplexityBothttps://yourdomain.com/sitemap.xml— 200, valid XML, URLs on the new HTTPS host- Homepage and key landing pages return 200, not a default nginx page
Run the AI Crawler Checker and the Indexability Checker against the live domain. A move often ships a fresh robots.txt from a template that blocks everything, or an empty sitemap from a new app install.
Step 5: Tell Google the site is still the same site
You do not create a new property in Search Console just because the IP changed. Use URL Inspection on the homepage after cutover. Request indexing only if the live HTML is correct. If you also changed protocol or www vs non-www, that is a site move — use a 301 and the Change of Address tool. An IP-only move is not a new site.
What usually breaks AI citations
- Security list still allows SSH only — ChatGPT and Perplexity never reach port 443
- New server has no certificate, so HTTPS fails while HTTP redirects in a loop
- Copied nginx config redirects the raw IP to the domain before DNS has switched, so testers think the new box is down
- Fresh
.envmissing production secrets, so the app 500s after the first request robots.txtregenerated withDisallow: /or a block on GPTBot / OAI-SearchBot
Migration checklist
- New host serves the homepage locally and via nginx with the real Host header
- Ports 80 and 443 open in both the cloud security list and instance iptables
- A records for
@andwwwpoint at the new IP - Valid TLS certificate for the apex and www; HTTP 301s to HTTPS
- robots.txt and sitemap.xml match the old public policy
- AI crawler and indexability scans pass on the live domain
- Old server stays up until those checks pass
If you want a single pass after cutover, start with the AI Crawler Checker, then confirm sitemaps with the Sitemap Checker. The move is done when those tools report the same access you had on the old host — not when the first deploy script exits.
Frequently Asked Questions
Will changing my server IP drop my Google rankings?
Not by itself. Search engines and AI crawlers follow your domain name, not the old IP. Rankings drop when the new host serves errors, mixed HTTPS, a different robots.txt, or a long DNS gap — not because the IP changed.
How long should I keep the old server online?
Keep it running until DNS has fully propagated and the new host returns 200 on HTTPS for the homepage, www, and key landing pages. A day or two of overlap is safer than cutting the old box the minute you change the A record.
Do I need a new SSL certificate after a server move?
Yes, unless you copied the existing certificate files. Let's Encrypt and most CAs bind the cert to the hostname, not the old machine. Issue or install a cert on the new server after DNS points there, and redirect HTTP to HTTPS.
Can AI crawlers fail even if Google still works?
Yes. A host firewall or cloud security list might allow Googlebot while blocking other user-agents, or the new robots.txt might disallow GPTBot or OAI-SearchBot. Always re-check AI crawlers after a move, not only Google Search Console.
Important disclaimer
This guide is for educational purposes only. No tool or technique guarantees search rankings, AI inclusion, or specific traffic results. Refer to official documentation from search engines and AI providers for current policies.
