noshost
Hosting6 min read· Updated

Test a new hosting server before changing DNS

A new server can answer HTTP 200 while serving the wrong website. Check the hostname, destination and a phrase unique to your public page before changing DNS.

Rehearse the hosting moveCompare the current endpoint and the new server with the same hostname.
Open Hosting Migration Rehearsal
On this page

    Prepare the comparison

    Install the website and its certificate on the new server. In Hosting Migration Rehearsal, enter the public URL and the new server IP. Verify control of the domain using the offered DNS or file proof. NosHost preserves the hostname when connecting to the supplied IP; it does not change your DNS.

    Select up to two additional public paths. For each tested path, state the expected status, final URL or a short public phrase. Pick a phrase that distinguishes your deployment from a hosting placeholder. Avoid account pages, passwords and personal data.

    Example: the wrong virtual host

    This is an illustrative test case using invented public content, not a customer incident. The expected homepage contains North Garden catalogue. The current site returns 200 with that phrase; the new server returns 200 with Welcome to your server. The new server passes the status check and fails the content check. Fix its virtual-host routing or document root, then rerun the same expectation.

    If both servers return 500, matching responses still fail. If a direct TLS connection cannot be verified, the origin result is unavailable. Neither case is a successful rehearsal. A different body hash alone may reflect a nonce or a timestamp.

    Read the coverage before moving

    The report covers the selected paths and public content. It does not copy your database, test every login or prove that scheduled jobs work. Optional nameserver comparisons cover displayed record types for the named host, not a complete DNS zone. Keep your own record inventory and verify third-party services separately.

    Before and after cutover

    1. Confirm expected content and redirects on each selected path.
    2. Check the new server's certificate and required background services.
    3. Keep a verified manual backup and record the prior DNS values.
    4. Plan how to handle writes during the move so orders or edits are not lost.
    5. Change DNS only after reviewing the report. Repeat the checks against the public address and test an actual user journey.

    Export a private baseline before the change. After repair, rerun with the same settings and compare compatible results. Review any exported target information before sharing it with support.

    Use the linked tools to confirm each change, then repeat the original test. Review server or DNS changes before applying them to a live site.

    Spotted something out of date? Email [email protected].

    More guides

    Technical SEO5 min read

    Crawling versus indexing

    Check response directives and discovery, then consult the search engine’s recorded indexing reason.

    Email5 min read

    Set up email DNS

    Separate receiving records from sending authentication and verify every legitimate sender.

    Network5 min read

    Why a port check says closed

    Trace the connection path without disabling the firewall or treating a TCP result as a UDP test.

    Redirects7 min read

    Fix ERR_TOO_MANY_REDIRECTS

    The usual causes are a CDN in Flexible SSL mode, a wrong site address in your CMS or two rules that disagree about www.

    Email9 min read

    Emails going to spam

    Read receiving-server headers, check authentication and alignment, then investigate reputation and recipient signals.

    DNS6 min read

    DNS change not showing up

    Compare authoritative records and resolver caches to investigate a DNS change that has not appeared.

    Server config6 min read

    Cron job not running

    Check paths, environment variables, permissions, logging and time zones in a cron job that is not running.

    ↑ ↓ moveEnter openEsc close

    Expanded view