Migrating hosting without changing URLs: test the new environment before switching DNS

When URLs remain unchanged, the key to reducing the impact of a hosting migration is to copy and test the site in the new environment, confirm that both users and Googlebot can access it, and only then switch DNS—not to shut down the old host immediately after the move. Google’s hosting migration guide explicitly warns that infrastructure changes can still affect search performance; unchanged URLs do not mean there is no risk. Preparation should cover functional testing, restrictions on test-site indexing, DNS caching, and Search Console verification.

Confirm the scope, then test the entire site

This process applies when public-facing URLs remain unchanged, such as when switching hosting providers or moving to a content delivery network (CDN). If you also change the domain, protocol, or URL paths, the move goes beyond the hosting migration discussed here, and the same process cannot simply be applied as-is.

First, prepare a copy of the site in the new environment. Depending on the existing platform, this may involve copying HTML files or exporting and importing a database. Testing should go beyond checking that the homepage opens. It should also cover:

• Whether all pages and images display correctly.
• Whether forms and other user interactions work as expected.
• Whether downloadable content, such as PDFs, is accessible.
• Whether the site is accessible across different browsers.

Prevent accidental indexing of the test site and check crawl access

Before launch, you can set up a test environment with IP-based access restrictions. For public testing, you can also use a temporary hostname such as beta.example.com. According to Google’s guide, publicly accessible test sites should include noindex rules to prevent accidental indexing.

If you use a temporary hostname, verify that property in Search Console and use the URL Inspection tool to check whether Googlebot can access the new infrastructure. Also check firewalls and denial-of-service (DoS) protection measures to ensure they do not block Googlebot from accessing the servers of your DNS or hosting provider. Being able to open the site in a browser is not a substitute for checking Googlebot’s access.

Adjust DNS in advance and prepare a cutover checklist

Google’s guide recommends lowering the time to live (TTL) of DNS records at least a week in advance—for example, to a few hours—so internet service providers refresh their caches and retrieve the new settings sooner. This does not guarantee that the switch will happen everywhere at the same time.

• Retain the verification files, meta tags, or Google Analytics elements needed for Search Console, and confirm after the migration that verification remains valid.
• Before the cutover, remove any temporary robots.txt rules that block crawling, along with any noindex tags or HTTP headers added for testing.
• Once everything is ready, update DNS so the existing URLs point to the new hosting infrastructure. Follow your DNS provider’s instructions for the specific steps.

Completing the cutover is not a signal to cancel the old hosting service immediately. Continue comparing logs from the old and new servers, checking DNS updates, and confirming that users and Googlebot can access the content normally. Wait until traffic to the old infrastructure drops to zero before shutting down the old service.