Candidate-bound release evidence
How does Go for Launch prove an Astro site is ready?
It does not rely on one score or a general claim. Go for Launch connects each required check to the same source revision, built artifact, staging deployment, and production release.
The verification layers
Every layer answers a different release question.
A passing build cannot stand in for browser behavior. A staging screenshot cannot prove what reached production. The records must converge on one candidate.
- 01
Build and discovery
Install from the lockfile, run diagnostics, build the complete route set, compare canonicals with the sitemap, and validate SEO and AEO output.
- 02
Browser and device
Test responsive layouts and interactions in Chromium and WebKit, then inspect the staged candidate in a pinned native iOS Safari Simulator.
- 03
Staging and scores
Deploy the exact artifact to staging, verify its identity, and require 100 in all four PageSpeed categories on mobile and desktop.
- 04
Promotion and production
Promote without rebuilding, verify the canonical host and redirects, then recheck public routes, metadata, social assets, forms, and release identity.
What the record covers
A chain, not a badge.
The toolkit checks the build, sitemap, metadata, headings, structured data, images, responsive layouts, Chromium, WebKit, native Safari, staging identity, PageSpeed, candidate identity, and canonical production response.
Inspect the contract
The rules and templates are public.
An important limit
Documentation describes the standard. It does not prove that a website passed.
A project-specific readiness claim requires evidence tied to the exact candidate that was built, staged, scored, promoted, and verified on its canonical production host.