A successful build is not a verified deployment
The build can pass while the wrong commit is live, a custom domain points to an older deployment, or a critical route returns an unexpected response.
Verification starts after deployment. It should query the canonical production URL and treat the result as a release artifact.
Prove deployment provenance
Expose a small static deployment document containing the commit SHA used during the build. The verification job can compare that value with the commit that triggered the workflow.
This prevents a healthy but stale deployment from being reported as successful.
- Expected commit SHA
- Deployed commit SHA
- Canonical production URL
- Deployment readiness state when provider access is available
Check the critical public surface
The audit should cover the homepage, legal pages, robots.txt, sitemap.xml, canonical redirects, and any route used directly in sales or support.
Link scanning should remain bounded and respectful. The purpose is to catch broken internal navigation and unexpected redirects, not to crawl unrelated third-party systems.
Treat performance as a release threshold
Response timing alone is not enough. Run Lighthouse for desktop and mobile, preserve the reports, and fail intentionally when scores fall below the project policy.
Accessibility, SEO, and best-practice regressions are often easier to prevent at deployment time than to discover later through manual review.
Write two report formats
JSON supports CI, trend analysis, and future automation. Markdown gives a reviewer a concise record of health, SEO, links, legal routes, TLS, performance, and final verdict.
Both reports should identify the URL, timestamp, commit, thresholds, and any check that was skipped because required credentials were unavailable.