The Checks Worth Running Before a Launch
Launch disasters are rarely dramatic. They are a robots file that came from staging, a share card that renders as a bare link, a stylesheet that 404s on the production path, and a certificate on the apex that nobody checked because the www version worked. All of them are cheap to catch beforehand and expensive to discover afterwards.
The one that costs the most: robots.txt
A staging robots file with a blanket disallow, deployed to production, removes you from search entirely. The site works perfectly, every page loads, nothing errors, and traffic quietly fails to arrive. It is routinely discovered weeks later. Fetch the file from the production host and read it — not from your local build, from the thing that is actually serving.
The share card
Nobody sees the meta tags during development because they do not render on the page. Check what a share preview will produce: a missing image tag gives a bare text link, a relative image URL fails entirely because the platform fetching it has no base to resolve against, and a template-inherited description says the same thing on every page.
Everything the page loads, from the production host
Load the real URL in a real browser and look at every request. The failures that survive to launch are absolute-path assets that only exist locally, a font referenced from a domain that blocks hotlinking, and a stylesheet whose path changed in the production build. Each produces a page that is functional and looks wrong, which is a state that passes every check that only looks at status codes.
DNS, and knowing whether to wait
After pointing the domain, it will work for some people and not others. Check the record against many resolvers rather than your own browser, which is holding a cached answer and will happily mislead you for hours. If most resolvers have the new value you are waiting; if none do, the change did not apply and you should go and find out why rather than waiting longer.
Certificates, on every hostname
Check the apex and the www form, and any subdomain in the launch. The common failure is a certificate covering one and not the other, so half the traffic gets a security warning. If a redirect sends people from one to the other, the certificate has to be valid on the hostname they land on first, not just the destination.
Links, once, before anyone else finds them
Crawl the site for broken links before launch, because this is the one moment the list is short enough to fix completely. Internal ones are entirely your fault and usually the residue of a rename during the build. After launch this becomes a maintenance task nobody does, which is why it belongs on a schedule rather than on a checklist.
Then set up the ones worth repeating
Most of the above are worth running once. Four of them are worth running forever, because their failure is silent: robots, certificate expiry, page weight per deploy, and broken links. Those are the ones to hand over to something that will keep checking after everyone has moved on to the next project.