Treating a Site Audit as a CI Gate, Not a One-Time Checklist
The same audit that flags accessibility and SEO problems in the editor also runs as an API-key-authenticated endpoint — which means you can ask a real question: did this deploy make things worse?
Most site audits are something you run once, feel briefly good or bad about, and then forget until the next redesign. That's fine for a solo site owner doing an occasional check-in. It's the wrong model once more than one person can publish changes, because the question that actually matters at that point isn't "is my site healthy in general" — it's "did the thing that just shipped make it worse."
The audit is already an API, not just a panel
The live AuditPanel that runs inside the editor and checks a site's accessibility and SEO isn't a one-off UI feature — it has an API-key counterpart at /api/v1/public/sites/[siteId]/audit, running the exact same auditNodes()/auditHtml() checks over the site's stored markup that the in-editor panel uses. Anything you can see about a site in the editor's audit view, you can also pull with a script and an API key. It's also exposed directly as an MCP tool (audit_site), so an AI assistant with read access to your site can run the same check.
What that unlocks: a before/after comparison
Once the audit is callable from outside the editor, you can wire it into whatever process gates your deploys — a CI pipeline, a pre-publish script, a scheduled check that runs nightly and diffs against the last run. The useful question becomes concrete: run the audit before a change, run it after, and compare. Did the number of accessibility violations go up? Did a page that used to have proper heading structure lose it? That's a fundamentally different, more actionable signal than "here's today's score," because it points at the specific change that introduced the regression instead of asking you to guess.
Why this matters more as a team grows
A single person publishing occasional changes can reasonably eyeball each update. The moment a team is publishing regularly — several editors, an agency managing client sites, an AI assistant with publish access — nobody's eyeballing every change anymore, and that's exactly when a silent regression is most likely to slip through unnoticed. Treating the audit as a gate rather than a checklist means the check happens whether or not a human remembers to run it, which is the entire point of a CI gate in the first place: it catches what busy people forget to look for.
The tooling for this already exists — it's the same audit endpoint the editor uses, just called from wherever your deploy process runs instead of from a button in the UI.