The audit engine
Every adapter, what it measures, what it depends on, and how a failing tool is handled.
Every check runs against a prospect's website and merge into one canonical payload. Every adapter is independent, every adapter can fail without taking the audit with it, and every result records which of those two things happened.
Fail-soft, by design
A missing binary, a timeout, a site that blocks a scanner: each is recorded against that adapter in a tool_status map and the remaining adapters carry on. This matters more than it sounds. A report that quietly downgrades an unmeasured check to "pass" is worse than no report, because the first thing a prospect's developer does is check one finding, and if it is wrong, the whole document dies.
Which is why every check records how it ended, not just whether it produced anything. A tool that ran and found nothing is a finding. A tool this scan tier deliberately did not buy was never in scope. A tool that was killed at its timeout is our problem. Those are three different facts, and a report that showed the same badge for all of them would be telling you the site is clean when what happened is that we did not look. Report sections say NOT INCLUDED when the checks behind them were not part of the scan, and UNAVAILABLE when they ran and could not produce a reading.
Cheap checks first
Within an audit, the fast checks always run. The expensive passes only run against domains that resolve and answer, so a parked domain or a dead site costs a fraction of a live one. That gating is also what the pricing reflects: a full deep scan costs more than a standard one because it genuinely costs more to produce.
The catalogue
The checks, grouped into the families they report under:
Family | Measures |
|---|---|
Reachability & delivery | Status chain, TTFB, redirect canonicalisation, CDN presence and cache-header quality |
Core Web Vitals | Lab measurement in a real headless browser via Lighthouse, plus field data from real Chrome users when a PageSpeed Insights key is configured |
Transport security | Certificate validity, issuer and expiry window, then full protocol, cipher and chain analysis |
Vulnerability & exposure | Known vulnerabilities and misconfigurations, publicly reachable admin paths, backups and config leftovers |
Dependency CVEs | Published vulnerabilities affecting the client-side JavaScript libraries detected on the page |
Accessibility | WCAG 2.1 Level AA failures on the rendered page, counted by severity, plus alt-text coverage |
Search & structured data | Titles, meta, canonical, robots, sitemap, OG tags, hreflang, schema.org validity and rich-result eligibility |
AI visibility | llms.txt, AI-crawler access, answerable content and citation signals |
Authority (E-E-A-T) | Entity definition, authorship, freshness and citation signals |
Conversion readiness | Calls to action, contact paths, forms, trust elements and mobile UX |
Email deliverability | SPF, DKIM, DMARC and BIMI records and their policy strength |
Domain & DNS | Record inventory, nameservers, mail routing, domain age, registrar and expiry date |
Privacy & compliance | Trackers set before consent, cookie flags, privacy policy, cookie notice, accessibility statement |
Link integrity | Broken internal and external links across the crawled pages |
Build quality | Rendered DOM, console errors, unused code, hydration mismatches, placeholder content |
Alongside those run port and WAF probing, subdomain takeover, blacklist and IP reputation, mail blacklists, login rate limiting, security.txt, crawl health and keyword rank. The standards each family is measured against are listed on the methodology page.
What the engine will not do
Scanners run in read-only configurations. Nothing attempts to exploit a finding, brute-force a login, or submit a form. Audits are rate-limited per host and identify themselves. The output is a diagnosis you could have produced by hand against the same public standards, just not for two hundred businesses before lunch.