A launch is where small oversights become public. Most of them are checkable in twenty minutes, and the ones people miss are consistently the same few.
This is the list, in the order that matters.
Before you point the domain
Everything here is easier while nobody is looking.
Test through your hosts file. Map the domain to the new server locally so you see the real site while everyone else still sees the old one. This is your only private rehearsal.
Load every kind of page. Homepage, an interior page, a form, search results, and a 404. Each can break independently.
Check the PHP version and extensions match what the site needs. A missing extension produces a fatal error on one page in place of a broken homepage. Choosing a PHP version picks it up from there.
Certificates before redirects
The order that prevents the most visible launch failure.
Get the certificate covering every hostname the site answers on: bare domain and www at minimum. Then add the redirect to HTTPS.
Doing it the other way round means every visitor is redirected to an address that shows a browser warning. It looks catastrophic and it is a five-minute fix, which is the worst combination on launch day. There is more on the sequence in forcing HTTPS.
Pick one address and be consistent
With or without www. Either is fine; both being reachable is not.
Redirect the other form, set the site's own address setting to match, and make sure internal links use the same one. A site whose links say one thing and whose canonical says another is publishing two versions of itself. Addon domains and duplicate content deals with the other addresses that quietly serve the same site.
Turn off the thing that hid the staging site
The single most common launch mistake, and it is invisible.
If the site was built on staging with search engines discouraged, that setting travels with it. In WordPress it is a checkbox under Reading, and it adds a noindex instruction to every page.
The site works perfectly and never appears in search results. Weeks pass before anyone connects the two.
curl -s https://example.com/ | grep -i noindex
That returns nothing on a correctly launched site. Run it after launch, not before.
Also remove password protection, any maintenance rule, and any IP restriction used during the build. Maintenance pages goes into taking those down properly.
Mail, which is not the website
Pointing a domain at a new server moves the website. It also moves mail, whether you meant it to or not.
Confirm the MX records are what you intend, and that mailboxes exist on whichever server is receiving. Then actually send a message in both directions and confirm it arrives. A launch that silently stops the contact form emailing is discovered by the customer who did not get a reply. Migrating email explains moving it deliberately.
Check SPF and DKIM name the new sending server. Mail that fails authentication does not bounce; it drifts into spam folders over the following weeks.
Lower the TTL days ahead
Not on launch day. The old value has to expire before the new one applies, so lowering it at the moment of the change accomplishes nothing.
Drop it to 300 seconds a day or two before, and raise it once things are settled. Understanding DNS propagation explains the timing.
Redirect the old site's addresses
If this replaces an existing site, every indexed URL is about to break.
Map the old addresses to their equivalents and redirect each one. Sending everything to the homepage is better than a 404 and considerably worse than a real match: search engines treat it as pages that vanished rather than moved. There is more on writing them in redirecting a domain or page.
The hour after
Load the site from outside your network. A phone on mobile data. Your own machine may be caching DNS or holding an old page.
Check a form actually delivers. Check the site over both address forms. Check the padlock on a page containing images, since mixed content breaks it while the certificate is fine.
Then read the error log instead of assuming silence means success. A fatal error on a page nobody has visited yet is waiting there. Understanding error logs sets out finding it.
The week after
Set up uptime monitoring from outside, alerting to an address that does not depend on this server.
Confirm backups are running and restore one, deliberately, to a test location. A backup that has never been restored is a hope. There is more in backing up and restoring.
And check the search console for crawl errors, which surfaces the redirects you missed while there is still time for it to matter.
The five that catch people
The noindex setting left on. The certificate added after the redirect. Mail moved without anyone testing it. The TTL lowered too late. Old URLs left un-redirected.
None of them break the site visibly on the day, and all five are checkable in ten minutes.
Check what the site is telling search engines
The commonest launch fault is invisible to visitors and total in effect, and it is set during development on purpose.
curl -s https://example.com/robots.txt curl -sI https://example.com/ | grep -i x-robots curl -s https://example.com/ | grep -i 'name="robots"'
A blocking directive left in place from staging means the site launches and is never indexed, and nobody notices for weeks because the site itself works perfectly.
Check all three, since the instruction can come from the file, from a header or from the page, and removing one leaves the others in force. Then check a deep page as well as the home page, because a template can carry it while the front page does not.
Confirm the forms reach a person
A launch checklist that covers pages and not messages misses the failure that costs money silently.
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://example.com/contact -d 'test=1'
tail -20 ~/logs/example.com.error.log
exim -bp 2>/dev/null | head
Submit every form yourself and confirm the message arrives, in the inbox rather than in the spam folder. Then confirm any automatic reply reaches the sender.
The frequent fault is mail that is accepted and never delivered because the sending address does not belong to the domain it claims. That produces a form that appears to work from the visitor's side and delivers nothing. The email deliverability tool deals with getting it right.
Record what the site looked like on day one
The first week after a launch produces questions that are impossible to answer without a baseline.
curl -s https://example.com/sitemap.xml | grep -c '<loc>'
for p in / /about /contact; do
printf '%-10s %s\n' "$p" "$(curl -s -o /dev/null -w '%{http_code} %{time_starttransfer}' "https://example.com$p")"
done
date
Save the page count, the response times and the date somewhere outside the site. Two weeks later, when somebody asks whether traffic dropped or the site got slower, you have something to compare against.
Without it, every question about the launch is answered with an impression. The measurement costs two minutes on the day and cannot be reconstructed afterwards.