Practical use and limits
Use it for: Run the review against the public hostname: inspect a fresh page, article, language variant, sitemap, robots file, and real image asset. Keep the commit and deployment URL in the release note.
Limits: A green build does not prove domain routing, browser rendering, analytics behavior, or search indexing. Pair it with a browser pass and URL Inspection.
Start with the visitor paths
I open the homepage, article archive, one article, privacy page, sitemap, and robots file. I check that navigation works from a fresh page load and that the browser title changes on article pages. These are simple checks, but they cover the path a new visitor, a reviewer, and a crawler are likely to take.
Check metadata against the public URL
The canonical URL, Open Graph URL, sitemap, and robots sitemap must agree about the production hostname. Preview URLs should never become canonical by accident. Article titles and summaries should describe the actual page rather than repeat a site-wide slogan. This is especially important when a project has recently moved from a Vercel subdomain to a custom domain.
Make the content readable without JavaScript tricks
Server-rendered HTML should contain the article title, summary, headings, and paragraphs. Links should look like links, buttons should have clear labels, and color should not be the only way to communicate meaning. A fast page is not useful if the reader cannot tell where to go next or cannot read it comfortably on a phone.
Check the deployment boundary
Keep secrets out of Git, define required environment variables in an example file, and make the build command deterministic. Confirm the production branch, domain aliases, and rollback path in the hosting dashboard. For a small site, knowing how to return to the previous working deployment is more valuable than adding a large release system.
Build a release evidence matrix
I use a small table with rows for routes, metadata, accessibility, performance, forms, analytics, and crawl files. Each row names the exact check, expected result, evidence, and owner. For example, the canonical check records one production article URL and the canonical found in its rendered HTML; the broken-link check records the command and number of failures. This prevents a vague “looks good” review and shows which checks were automated, sampled manually, or deliberately deferred.
Test one failure and the rollback
A release plan is incomplete until one important failure has a known response. I test a missing environment variable or unavailable API in preview, confirm the page fails safely, then verify that the previous production deployment can be restored without rebuilding. After launch I check the public hostname from a clean session, inspect one mobile page, and confirm that sitemap and robots responses still use the same domain. These checks cover the boundary where local success most often becomes a production surprise.
Write down what was tested
After the release, record the commit, build result, public URL, and any known limitations. This makes the next maintenance session faster and gives another person enough context to reproduce the check. Documentation is part of the production artifact, not paperwork added after the fact.
Frequently asked questions
Is a green build enough to launch?
No. A build proves the code compiles and routes can be generated. It does not prove that the public domain, redirects, metadata, links, or content are correct.
Which production check should happen first after deployment?
Open the canonical public URL in a clean session and follow the primary visitor path. That quickly catches domain, redirect, asset, navigation, and environment differences that a local build cannot prove.