Everything works locally. That is the least predictive signal available. The failures that appear after launch are the ones nobody can see from a development environment.
1. Does the build reproduce from a clean checkout
Delete the output directory and the caches, then build. If anything was generated once and committed by accident, this is where it shows.
2. Are the redirects real
Old URLs, trailing slashes, www versus bare domain. Test them against the deployed environment, not a local server: hosts differ in exactly this area.
3. Is the error page a page
A 404 that renders as a blank screen is a broken site with a status code. Check that it is served with 404, not 200 — a soft 404 confuses crawlers for months.
4. Do the crawler files agree with reality
`robots.txt` should not disallow the pages you want indexed, and the sitemap should list the canonical URLs only. A sitemap with redirects or 404s is worse than no sitemap.
5. Are titles and descriptions unique
Duplicate titles across a directory are the most common self-inflicted SEO wound, and they are invisible until search results look identical.
6. Does one page load without a warm connection
First visit on a phone. Not a Lighthouse score — the actual first paint. A page that is 300 KB of HTML has a problem that a fast laptop hides.
7. Is there a way to hear about breakage
An analytics tag, uptime check, or a contact link you read. Launching blind is a choice, not a default.
8. Can you roll back in ten minutes
If the answer is 'probably', test it. An untested rollback path is a hope, and the moment you need it is the worst moment to discover that.
What to ignore
Perfect scores. A site that launches with a 95 Lighthouse score and one broken form is worse than one that launches at 70 with everything working. Ship the checks above, not the dashboard.
Related: guardrails for what to leave automated, and evaluations for knowing whether the behaviour changed.