Release Quality Gate
“The build passed” is only the first check.
A production compiler can tell us that the application is syntactically valid. It cannot tell us that a page has the right canonical, that a mobile viewport overflows, that a social image points to localhost, or that a form page now contains two H1 elements.
Our release standard layers structural audits and representative browser QA on top of the production build so failures are easier to catch before the site reaches a visitor or crawler.
Representative thresholds
Lighthouse is one signal inside the gate
These thresholds are used on representative release checks. They are not a claim that every page always produces the same synthetic score under every run.
100SEO minimum on representative Lighthouse runs
95+Accessibility minimum
95+Best Practices minimum
90+Performance minimum
Build-level checks
The generated site is inspected as an artifact
Source review matters, but the final HTML is what search engines and browsers receive. Our postbuild checks operate against the prerendered output whenever the project can provide it.
Documentation slugs, titles, descriptions, taxonomy, links, structure, and editorial rules are validated.
Every prerendered public page is inspected from generated HTML rather than only from source code.
Titles, descriptions, canonicals, robots state, Open Graph, Twitter metadata, headings, and main landmarks are checked.
Structured data is parsed and required page-type schema is verified.
Internal links are checked against the actual prerendered route inventory.
Referenced local images are checked for missing files, and CSS-served assets have a size budget.
Robots and sitemap modification-date sources are validated.
Browser QA
The site also has to behave like a website
Representative browser checks catch problems that static HTML inspection cannot, including overflow, runtime errors, lazy asset failures, and viewport-specific regressions.