Quick answer
Test the new host using the website’s real hostname through a local override or approved preview. Check HTTPS, page content and important user tasks before moving public traffic. A working temporary URL alone does not prove the live hostname will work.
Test the destination while visitors still use the old site
Before changing public DNS, test the destination with the intended hostname. Check the virtual host, HTTPS and application journeys separately. Use the DNS and migration guides for the later switch, data synchronisation and rollback.
Know the exact hostname, current live destination, new assigned IP or preview route, and who can deploy to each side. Keep a verified backup and a way to reach both hosts without public DNS. If the site accepts orders or writes content, define when writes will stop or be synchronised; a preview can pass while the destination database is already becoming stale.
Choose a preview that preserves the hostname
If the host offers an authenticated preview facility, follow its instructions and confirm whether it presents the real hostname, a temporary hostname or a proxy. A temporary URL may cause absolute links, cookies, redirects or certificate names to behave differently, so record those limits. A local hosts-file override can send your own computer to the new IP while the browser requests the real domain; it changes only that computer. Keep a copy of the original hosts entry and remove it after testing.
For a diagnostic HTTP request, curl documents --resolve, which pins one hostname and port to one address for that command. For example curl --resolve www.example.com:443:192.0.2.10 -I https://www.example.com/ uses a documentation-only address; substitute the provider-assigned IP. This preserves the hostname for HTTP and TLS checks. A certificate error can be expected before the host has a valid certificate, but do not use -k as a pass criterion or ignore an unexpected certificate in a live handover.
Protect temporary copies and search visibility
A public temporary hostname may expose unfinished content or personal data. Prefer authentication or network-restricted access where the provider supports it. If the temporary copy must be crawlable for a technical test, Google documents a noindex meta tag or response header to prevent supported search engines from indexing it. A robots.txt disallow can stop a crawler seeing that noindex directive. Neither control is access protection, and other crawlers may behave differently. Verify the preview’s effective response and remove the temporary indexing rule from the production hostname at cutover.
A local hosts-file test does not publish a new URL, but it affects only the tester’s device. Another colleague may still see the old site. Label screenshots and test results with the target server and date.
Run a task-based acceptance check
Test the homepage and several deep URLs, styles and images, redirects, forms, login, search and any API or checkout journey that applies. Compare expected content with the current live site while avoiding real customer transactions in an unapproved test environment. Confirm database connections, scheduled tasks, email submission route, file uploads and permissions with the application owner. Check response codes and application logs for hidden failures. Test both apex and www if both will be served; a working one does not establish the other.
Record each issue with the preview method used. If the temporary hostname changes cookies or redirects, repeat that check using the real hostname through an approved override. For HTTPS, verify the certificate names and intended host route; certificate issuance may need a separate DNS validation step before cutover.
A header check is a starting point
For an illustrative destination, curl --resolve www.example.com:443:192.0.2.10 -I https://www.example.com/ checks the TLS connection and HEAD response. Replace the documentation-only IP with the assigned address. To retrieve the page, omit -I and inspect the returned content privately. Neither result tests a browser login or checkout.
If the request redirects to another hostname or port, the single resolve entry does not pin that destination. Inspect the Location header and configure a separate authorised override before testing it. Stop if the final content comes from the old host.
Prepare the cutover or recover the preview
Only move to public DNS after the responsible owner accepts the test results, data synchronisation plan, maintenance window and rollback conditions. Record the old and new targets, current TTL and who can change the authoritative zone. Keep the old host available through the cache overlap and verify visitors reach the new destination from more than one network after the change.
If a preview fails, correct the new host while the public DNS remains unchanged. Revert a local hosts-file override or close the preview session to return your own machine to normal resolution. After the migration, retire or restrict the temporary hostname and keep its noindex protection while it remains public. Remove any temporary noindex directive from the canonical live destination so the real site can be indexed. Share redacted failing URLs, logs and test context with the hosting or application owner rather than credentials.
Common questions
Does a hosts-file test change the public website? No. It affects only the machine on which you change it.
Can I test by browsing the new IP? It may reach the wrong virtual host or fail TLS; use the real hostname in the request.
Does a successful homepage prove readiness? No. Test the journeys and data writes that matter for the site.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.