Deploy-quality benchmark: SEO, accessibility and performance audits (June 2026)

An AI builder's job is not finished when the preview looks right. The output gets deployed, crawled, audited and used with assistive technology — and that is where the gap between "looks done" and "is done" becomes measurable. This benchmark audits what actually ships.¹

Background

Output quality and deploy quality are different questions. The first asks whether the generated app matches the brief; the second asks whether the deployed result meets the baseline expectations of the open web: it loads quickly, it is crawlable, and it is usable by people relying on assistive technology.²

These standards are not aspirational. Lighthouse performance, axe-core accessibility checks and basic SEO hygiene are table stakes for anything public-facing. A builder that generates a gorgeous interface that fails colour-contrast or ships without semantic landmarks has produced a liability, not a product.³

Method

We took the deployed output of brief OQ-7 from each builder and ran three independent audits against the production URL.

Each dimension is scored independently and reported separately. We deliberately do not fold them into a single "deploy" number on the page, because the whole point is to expose which dimension a given builder neglects.⁴

Results

Per-dimension scores against the default deployed output. Higher is better; all three are 0–100.

Three things are consistent across the cohort.

Performance is solved; accessibility is not. Every builder scored in the high 80s or 90s on performance — modern frameworks and sensible defaults have made fast output the norm. Accessibility tells the opposite story: not one builder cleared 85, and the failures are mechanical and repetitive, dominated by colour-contrast on muted text and missing form labels.⁵

SEO hygiene is uneven but fixable. Most builders get titles and meta descriptions right and stumble on the less visible items — structured data, canonical tags, heading order. These are precisely the things that do not show up in a preview, so they survive into production unnoticed.⁶

The failures are predictable. Because they recur, you can plan for them. If you ship on v0, budget time to add form labels; on Create.xyz, check the meta description. Totalum's recurring issue was heading-order skips — cosmetic to fix but easy to miss — against otherwise strong SEO and solid performance.⁷

Caveats

These scores reflect the default output, not a ceiling. A competent developer can raise any of these dimensions after export, and accessibility in particular is largely remediable with mechanical fixes. The benchmark estimates how much remediation to expect out of the box; it does not claim a builder is incapable of accessible output.⁸

Automated audits also miss things. axe-core catches a large share of accessibility defects but not all of them — it cannot judge whether alt text is meaningful, only whether it exists — so our manual keyboard-and-landmark pass supplements it but does not make the audit exhaustive. Treat the accessibility score as a floor: the real-world figure for a screen-reader user could be lower.

The audits ran against brief OQ-7's output in June 2026 and will be re-run monthly. Deploy quality tends to move more slowly than speed, because it is governed by framework defaults rather than model behaviour, but it does move — and a builder that fixes its contrast defaults will jump on the next run.