A production launch should be boring. The build is known, critical flows have been exercised, search engines receive the right signals, and somebody knows how to roll back.
This is the website checklist I use before a new launch or any release large enough to change routing, authentication, checkout, or infrastructure.
1. Reproduce the build from a clean checkout
Install exactly what the lockfile describes and create the production bundle:
pnpm install --frozen-lockfile
pnpm buildDo not use the development server as launch evidence. Development mode includes hot reload, source maps, error overlays, and different optimization behavior.
Confirm the runtime version, required environment variables, database migrations, and generated assets are documented. A successful build on one long-lived laptop is not the same as a reproducible release.
2. Run types, linting, and the complete test suite
Run the same commands CI will run. Treat warnings according to the project’s actual policy instead of casually accepting new ones.
pnpm typecheck
pnpm lint
pnpm testPre-commit checks are useful for fast feedback, but the release gate should cover the whole repository. The article on pre-commit hooks that catch bugs explains how I split fast local checks from full pre-push verification.
3. Exercise the revenue and account flows
Use the production build locally or in staging. Test the actions that would create a support ticket if they failed:
- Sign up, sign in, sign out, and password recovery
- Checkout, payment failure, receipt, and account activation
- Contact, newsletter, upload, or booking forms
- Account deletion, export, or cancellation
- The primary action on mobile and with a keyboard
Use realistic accounts and test data. A button rendering is not evidence that the email, webhook, database write, and confirmation screen all completed.
4. Verify forms and transactional email end to end
Submit every public form against staging or a safe production test route. Confirm:
- Validation works in both the browser and server
- Rate limits reject abuse without blocking normal use
- Success and error messages are visible and useful
- Email reaches the expected inbox and has working links
- Reply-to, unsubscribe, and support addresses are correct
Test the failure path too. Temporarily use an invalid value or a provider test mode so you know users do not receive a blank screen when an upstream service fails.
5. Crawl routes and search metadata
Check every indexable page for a successful status, unique title, useful description, one clear H1, canonical URL, and internal links.
Then inspect:
/robots.txtallows the pages you intend to publish/sitemap.xmlcontains canonical URLs only- Utility pages such as thank-you screens use
noindex - HTTP,
www, trailing-slash, and legacy URLs redirect permanently to one preferred URL - A nonsense URL returns a real 404 status
SiteCMD’s live-site scanner automates the repeatable parts, including canonical, robots, sitemap, heading, status, and structured-data checks.
If an important URL is still missing after launch, the indexing troubleshooting checklist follows the path from HTTP response through rendering and Search Console.
6. Test security headers, not just their presence
Start with the response headers:
curl -sI https://staging.example.comConfirm HTTPS redirection, HSTS, Content-Security-Policy, frame protection, content-type protection, and a sensible referrer policy. Then verify the policy works. A permissive CSP can be present and still protect nothing; How to actually test your Content Security Policy covers the enforcement workflow.
Review public JavaScript bundles and source maps for secrets. Confirm session cookies use Secure, HttpOnly, and an intentional SameSite value.
7. Complete a keyboard and screen-reader smoke test
Navigate the primary flow without a mouse. Focus must be visible, menu controls must open and close, dialogs must trap and restore focus appropriately, and every form field needs an accessible name.
At minimum, test:
- Heading order and landmark structure
- Link and button names
- Form labels and error associations
- Image alternatives
- Contrast and zoom at 200 percent
- Reduced-motion behavior where animation is used
Automated accessibility checks catch important failures, but they cannot decide whether the flow makes sense when read aloud.
The manual accessibility testing guide expands this smoke test into eight repeatable browser exercises for focus, zoom, forms, dialogs, motion, content, and screen readers.
8. Record a performance baseline
Run Lighthouse or another lab profile against the production build with consistent settings. Record the LCP element, render-blocking requests, total transfer size, and long tasks, not only the score.
Compare the result with real-user data when available. Lighthouse and Core Web Vitals answer different questions, so keep the lab baseline separate from CrUX or your own RUM.
Set a budget that can fail the release: maximum JavaScript, maximum image weight, or a permitted LCP regression. A budget without enforcement becomes a dashboard nobody checks.
9. Audit third-party requests
Open the Network panel and group requests by domain. Every analytics tag, embedded widget, font host, chat client, error tracker, and payment script adds performance, privacy, and availability risk.
Remove anything nobody can explain. Confirm the remaining domains appear in the CSP and privacy documentation. Verify optional tracking does not load before consent where consent is required.
10. Prove monitoring and alerts work
Do not settle for seeing a monitoring SDK in the bundle. Trigger a safe test error and confirm it reaches the dashboard with the correct release and environment.
Check uptime from outside the hosting provider, certificate-expiry alerts, failed background jobs, and notification recipients. An alert routed to a former employee is not an alert.
11. Rehearse rollback and recovery
Know the exact command or dashboard action that restores the previous release. Confirm database changes are backward compatible or have an explicit recovery plan.
For data-bearing launches, verify a recent backup exists and that restoration has been tested. A backup file nobody has restored is only a theory.
12. Run the post-deploy smoke test
After production deploys, repeat the shortest version of the critical-flow test against the real domain. Check the canonical host, one revenue action, one form, one authenticated page, monitoring, and the browser console.
Record the deployment identifier and the person responsible for watching the first hour. The release is complete when production behavior is verified, not when the deployment command exits.
Copy-paste launch gate
- Clean production build completed from the lockfile
- Typecheck, lint, and full tests passed
- Revenue and account flows completed
- Forms and transactional emails verified
- Canonicals, robots, sitemap, redirects, and 404 checked
- Security headers and CSP behavior tested
- Keyboard and screen-reader smoke test completed
- Performance baseline recorded and budget met
- Third-party requests reviewed
- Monitoring and alert delivery proven
- Rollback and backup recovery understood
- Production smoke test completed
The boring checks catch the boring failures. Those are exactly the failures that turn a launch into a late-night support incident.