Pre launch checks before you point the domain

Run these while the only route to the site is one you control. At that point a failure costs you an afternoon; after the domain resolves, the same failure is visible to customers and gets cached by crawlers. Five things need to pass: the site serves at all, the certificate covers the names you will really use, no staging-era block survived, nothing internal still points at the temporary address, and errors return the status they claim.

First, reach the site the way a visitor will

There are two routes before cutover, and they test different things. The provider's temporary path or preview hostname proves the files are in place and the interpreter runs. It lies about everything hostname-dependent: canonical tags, cookie domains, absolute redirects, virtual host selection, certificate matching. So do a second pass with a hosts file entry on your own machine mapping the final hostname to the new server address. That is the only pre-DNS test that exercises the real request the way production will receive it.

A pass on this step means the real hostname loads over https with no port number, no directory prefix, no default provider landing page and no directory listing.

The five checks and what a pass looks like

The certificate detail people miss

The subject alternative name list has to include the bare domain and the www form, plus any subdomain you will serve such as a shop or client area. Redirecting www to the apex does not exempt you: the browser validates the certificate before it ever sees your redirect, so a missing www entry produces a full-page security warning on the version half your visitors will type.

openssl s_client -connect 203.0.113.10:443 -servername yourdomain.tld </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -ext subjectAltName

Check the not-after date and confirm the intermediate is being served, since a chain your desktop browser silently repairs will still fail for API clients and payment callbacks. If issuance depends on the domain resolving to the new host, plan that as a timed step rather than assuming it happens on its own; the ordering side of that sits with your certificate setup.

Staging blocks and stale internal targets

Blocks arrive from more places than people remember: an X-Robots-Tag response header, a meta tag in the theme header, a CMS discourage-search-engines toggle, a Disallow: / line, and a password prompt or address allowlist at the server. Check all five, because removing one leaves the others in force. Note also that only noindex removes a page from results, as Google Search Central documents; a disallow line is a crawl instruction, so the two are not interchangeable when you are cleaning up.

For internal targets, grep the generated output and the content database for the preview hostname, the raw server address, and bare http:// links. Form action attributes are the worst offenders because they look fine until someone submits and gets a certificate warning or a rejected cross-origin token.

Order of operations

1. Serve test on the temporary path, then again through the hosts override.
2. Certificate names and chain.
3. Remove blocks, verify from a clean session with no cached credentials.
4. Search for and rewrite temporary hostnames, then re-crawl locally for broken links.
5. Confirm 404, 403 and the http-to-https redirect each return a single correct status hop.
6. Cut over, then repeat items two through five within the hour. Cutover changes which server answers, so a pre-DNS pass is a prediction until you confirm it.

Full sequencing for the wider move lives in the launch playbooks.