Product · audits
Automated Website Evidence Audit
Nine evidence domains, one prioritized remediation ledger.
Inputs and outputs
You supply
- One public URL to start from
- Optional list of additional public URLs on the same origin
- Optional list of paths to exclude
You receive
- Desktop and mobile render evidence at fixed viewports
- Accessibility findings mapped to WCAG 2.1 success criteria
- Technical SEO and metadata inventory
- Third-party request and storage inventory
- Asset integrity results for every referenced local file
- Link resolution results with HTTP status per target
- Browser console and page error transcript
- Interaction probe results for keyboard and focus behaviour
- Prioritized remediation ledger with severity and evidence references
When checkout opens, the entire purchase is a URL, a payment, and a download link. There is no intake form, no scoping call, and no questionnaire, because the scope is fixed and published on this page.
What this is
A run against a public website that records what a real browser engine actually does with it — at a desktop viewport and a mobile viewport — and files the result as evidence. Nine domains are examined. Every finding names the artifact that produced it. The report ends in an ordered list of work rather than a score.
It is deliberately narrow. It reads a site and reports. It does not log in, it does not submit anything, it does not change anything, and it does not guess.
What you get back
Two files. A static HTML report that opens in a browser with no network access required, and a JSON document with the same content in machine-readable form so it can be diffed, filed, or fed into your own tooling. Both are self-contained. Both carry the runner version, the browser engine version, and the audit definition version that produced them, so a report from six months ago can be explained.
What it will not do
The boundaries below are the product. They are published here rather than buried in terms, because the reason to trust an unattended process is knowing exactly how far it is allowed to go.
Seeing one before checkout opens
Checkout is not open, so there is nothing to buy on this page yet. There is a private demo: a code-gated route that runs the real pipeline and hands back the real package. It is not a signup and there is nothing to fill in unless you already hold the admin code, which is given out one conversation at a time.
Why there is no score
A single number sums unrelated evidence into something that cannot be acted on and can always be argued with. Instead the report ends in a ranked ledger: grouped by cause, ordered by severity and by how many routes each item affects, with every entry pointing back at the artifact that justifies it. The point of the run is to end in a decision about what to do next.
9 evidence domains · definition v1
Every check, every artifact, every limit
Expand a domain to read exactly what is examined, what is kept as proof, and what the domain does not cover.
Desktop and mobile rendering 6 checks
Record what a real browser engine paints at fixed viewports, so layout claims are settled by an image and a measurement rather than by memory.
Checked
- Full-page capture at a desktop viewport of 1440x900
- Full-page capture at a mobile viewport of 390x844
- Horizontal overflow measured as scrollWidth against clientWidth
- Minimum rendered text size per element
- Elements clipped or overlapping at either viewport
- Layout shift caused by late-loading local assets
Evidence kept
- Screenshot per route per viewport
- Measured document and element geometry as JSON
Not covered
- One browser engine, stated by name and version in the report
- No visual judgement of taste, hierarchy, or brand fit
- No emulation of assistive hardware or real devices
Accessibility 8 checks
Check the machine-checkable part of WCAG 2.1 AA and say plainly that the rest still needs a person.
Checked
- Exactly one meaningful h1 per route and coherent heading order
- Landmark structure and skip-link target resolution
- Accessible names for links, buttons, and form controls
- Image alternative text presence and emptiness for decorative images
- Text contrast ratios computed against resolved background colours
- Visible focus indicator on every keyboard-reachable control
- Language attribute and document title presence
- Reduced-motion handling for animated elements
Evidence kept
- Per-finding CSS selector and DOM snippet
- Computed contrast ratio with both resolved colour values
- Mapping to the specific WCAG 2.1 success criterion
Not covered
- Automated checks cover a minority of WCAG 2.1 criteria
- No screen-reader output is simulated or scored
- Cognitive, language, and content-comprehension criteria are out of scope
- A clean automated result is not an accessibility conformance claim
Technical SEO and metadata 7 checks
Inventory the machine-readable claims a page makes about itself and flag the ones that contradict each other.
Checked
- Title and meta description presence, length, and uniqueness across routes
- Canonical URL presence and self-consistency
- OpenGraph and Twitter card completeness
- Structured data presence and JSON parse validity
- robots.txt reachability and directives affecting the audited routes
- Sitemap reachability and agreement with discovered routes
- Heading outline and internal link depth
Evidence kept
- Extracted metadata table per route
- Raw structured-data payloads as found
Not covered
- No rank, traffic, difficulty, or competitor estimates
- No keyword recommendations
- Search engines are not queried; only the site is read
Privacy and third-party surface 6 checks
Record what the page contacts and what it stores, so the privacy policy can be compared against observed behaviour.
Checked
- Every outbound request grouped by third-party origin
- Cookies set on load, with attributes and declared lifetime
- localStorage and sessionStorage keys written on load
- Known analytics, tag-manager, and advertising endpoints contacted
- Third-party scripts loaded before any consent interaction
- Transport security of every request
Evidence kept
- Request ledger with origin, resource type, and initiator
- Storage ledger with key names and attributes
Not covered
- Observed behaviour on the audited routes only, at run time
- No legal opinion on GDPR, CCPA, or any other regime
- Server-side data handling is invisible to this audit
Asset integrity 5 checks
Prove that every local asset the page references actually resolves, because a green build does not.
Checked
- Every local image, stylesheet, script, font, and icon reference resolved
- HTTP status recorded per referenced asset
- Favicon, manifest, and social-card image reachability
- Assets referenced but never served
- Assets served with an unexpected content type
Evidence kept
- Asset ledger with source reference, resolved URL, and status
Not covered
- Reachability and content type only; no image quality assessment
- Third-party asset availability is recorded, not guaranteed
Link resolution 5 checks
Follow every discovered link once and record what came back.
Checked
- Internal links resolved with final HTTP status after redirects
- Redirect chains recorded with each hop
- Fragment targets checked against the destination document
- Outbound links resolved and recorded, not followed further
- Links that resolve only with a trailing-slash variant
Evidence kept
- Link ledger with source route, target, hop chain, and final status
Not covered
- One crawl depth boundary, stated in the report
- Authenticated, rate-limited, or bot-blocked targets are reported as such
- Link presence is not judged for editorial relevance
Browser console and page errors 5 checks
Capture the errors a visitor's browser already reports and nobody reads.
Checked
- Uncaught JavaScript exceptions with stack frames
- Console error and warning entries
- Failed network requests with status and initiator
- Content Security Policy violation reports
- Mixed-content and blocked-resource events
Evidence kept
- Timestamped console transcript per route and viewport
Not covered
- Errors raised during the observed load and probe window only
- Errors behind authentication or user-specific state are not reached
Interaction probes 6 checks
Exercise the parts of a page that only misbehave once touched.
Checked
- Keyboard traversal order against visual order
- Focus visibility at every stop in the tab sequence
- Disclosure, menu, and dialog controls opened and closed by keyboard
- Focus return after a dialog or menu closes
- Hover-only affordances that have no keyboard equivalent
- Layout stability during and after transitions
Evidence kept
- Probe transcript with the action taken and the resulting DOM state
- Screenshot at each interaction checkpoint
Not covered
- No form submission, no account creation, no destructive actions
- No purchase, upload, or state-changing request is ever performed
- Flows requiring credentials are skipped and listed as skipped
Prioritized remediation ledger 5 checks
Turn findings into an ordered list of work, so the report ends in a decision rather than a feeling.
Checked
- Severity assigned from a published rubric, not from tone
- Findings grouped by cause where one fix resolves several symptoms
- Each item linked back to the evidence that produced it
- Ordering by severity, then by breadth of affected routes
- Explicit separation of machine-verified items from items needing review
Evidence kept
- Ordered remediation table with severity, affected routes, and evidence IDs
Not covered
- Effort and cost estimates are not produced
- No code changes are written, proposed as patches, or applied
- Business priority is yours; the ledger orders by evidence only
Sample report schema · v1 · published-and-implemented
The output format, published before the product
The machine-readable half of a report is a single JSON document. Its shape was published here before the code existed, so the shipped product could be compared against what was promised. The derivation engine is held to it by a test that derives a real report and checks every required field below. A change to this schema gets a version bump and an entry in the launch log.
| Field | Type | Required | Description |
|---|---|---|---|
| schema_version | integer | yes | Version of this document schema. Increments on any breaking change. |
| report_id | string | yes | Opaque identifier for the run, unique per audit. |
| generated_at | string (RFC 3339) | yes | UTC timestamp at which the run completed. |
| target | object | yes | The audited origin, the entry URL, and the resolved route list. |
| runner | object | yes | Browser engine name and version, runner version, and audit definition version. |
| scope | object | yes | Crawl budget, viewports used, routes visited, and routes deliberately excluded. |
| domains | array of object | yes | One entry per evidence domain, each carrying its own findings and limits. |
| findings | array of object | yes | Flat list of every finding, referenced by the remediation ledger. |
| remediation | array of object | yes | Ordered remediation ledger. |
| artifacts | array of object | yes | Every screenshot, transcript, and ledger produced, with a content hash. |
| not_covered | array of string | yes | Explicit list of what this run did not examine, and why. |
| summary | object | no | Finding and remediation counts, and counts per severity. Derived from the lists below; carried so a reader does not have to recount them. |
| Field | Type | Required | Description |
|---|---|---|---|
| id | string | yes | Stable within a report; referenced by remediation entries. |
| domain | string | yes | One of the nine evidence domain identifiers. |
| severity | string | yes | One of the severity levels below, assigned by rubric. |
| title | string | yes | One line stating what was observed, not what it implies. |
| observed | string | yes | The measurement or event exactly as recorded. |
| expected | string | yes | The rule that was applied, and where that rule comes from. |
| routes | array of string | yes | Routes on which the finding was reproduced. |
| selector | string | no | CSS selector for the element, where the finding is element-scoped. |
| artifact_ids | array of string | yes | Artifacts proving the finding. A finding with none is not emitted. |
| verified_by | string | yes | machine — every published finding is machine-verified. |
| check_id | string | no | Namespaced identifier of the rule that produced this finding, as domain.check. Stable across reports; use it to track one defect over time. |
| status | string | no | One of the status values below. Defaults to reproduced. |
| viewports | array of string | no | Viewports the finding was reproduced at, where it is viewport-specific. |
| action | string | no | What to change, stated as an outcome. Repeated on the remediation entry that groups this finding. |
| needs_human_review | boolean | no | True when the finding records something a machine cannot judge — a third-party origin that may be intended, a cookie that may be necessary. |
| Field | Type | Required | Description |
|---|---|---|---|
| rank | integer | yes | Position in the ledger, ascending. |
| finding_ids | array of string | yes | Findings resolved by this item; grouped by shared cause. |
| severity | string | yes | Highest severity among the grouped findings. |
| affected_routes | integer | yes | Count of routes on which the grouped findings appear. |
| action | string | yes | What to change, stated as an outcome rather than as a patch. |
| needs_human_review | boolean | yes | True when the item cannot be closed by a machine check alone. |
| group_key | string | no | The shared cause that grouped these findings. Two symptoms with one key are one fix. |
| artifact_ids | array of string | no | Every artifact cited by the findings this entry groups. |
Severity rubric
Severity is assigned from these definitions. No finding is escalated because it sounds serious, and none is softened because it is awkward.
- blocking
- Observed behaviour prevents a documented task from completing at all for some visitors — a keyboard trap, an unreachable control, a 5xx on a route linked from the entry page.
- serious
- Observed behaviour degrades a documented task or violates a stated contract — a WCAG 2.1 AA failure, a broken internal link, an asset that does not resolve, an uncaught exception on load.
- moderate
- Observed behaviour is incorrect but has a working path around it — a redirect chain, a duplicated title, a missing canonical URL.
- minor
- Observed behaviour is inconsistent with the site's own conventions and carries no known user-facing impact.
- informational
- Recorded for the ledger with no defect asserted — a third-party origin inventory entry, a redirect that behaves as intended.
Finding status values
- reproduced
- Observed on every attempt within the run.
- intermittent
- Observed on some attempts; attempt count is recorded.
- not_reached
- In scope but unreachable — authentication, rate limit, or timeout.
- excluded
- Deliberately outside the run's stated scope.
Hard automation boundaries
What the runner is never allowed to do
These limits are enforced in the runner, not promised in prose. Anything on this list occurring during a run is a defect, and would be reported as one.
The runner never authenticates.
No credentials are accepted, stored, or used. Anything behind a login is out of scope and is reported as not reached, never as passing.
The runner never performs a state-changing request.
No form submissions, no purchases, no uploads, no account creation, no requests outside safe HTTP methods against the audited origin.
The runner never writes to your infrastructure.
No files, no DNS records, no repository commits, no configuration changes. The audit reads and reports; you decide what to change.
A finding without an artifact is not published.
Every entry in the report references the screenshot, header, console line, or DOM assertion it came from. If the artifact is missing, the finding is dropped rather than described.
Severity comes from a published rubric.
Severity is assigned by rule, not by how alarming a finding sounds. The rubric is published in the standards page and versioned with the report.
No single overall score is produced.
Composite scores compress unrelated evidence into one number that cannot be acted on. The report ends in an ordered list of work instead.
Audit output is never sold, aggregated, or published.
Reports belong to the buyer. Nothing from a run is used as a case study, a benchmark, or training data without a separate written agreement.
The runner never load-tests, floods, or brute-forces.
Requests are rate-limited and bounded by a stated crawl budget. The audit is designed to be indistinguishable from a careful visitor.
The runner never probes for vulnerabilities.
No injection attempts, no path traversal, no credential testing. This is an evidence audit, not a penetration test, and it is not a substitute for one.
Where a person is still required
An unattended product that pretends to cover these would be lying by omission. Each is named in the report itself, next to the results.
Accessibility conformance statements.
Automated checks find a minority of WCAG 2.1 issues. A conformance claim requires manual testing with assistive technology; this product does not make one and neither should a report derived from it.
Legal and regulatory interpretation.
The privacy domain records observed behaviour. Whether that behaviour complies with any given regulation is a question for a lawyer.
Content quality and editorial judgement.
Whether a page says the right thing to the right reader is not a machine question and is not answered here.
What to fix first, commercially.
The ledger orders by evidence and breadth. Only you know which route earns the revenue.
The fixing itself.
No code is written, patched, or deployed on your behalf as part of an audit.
Not buyable yet
Checkout is not open, there is no waitlist form, and no price is published. The launch page lists the gates that have to close first, and the launch feed records each one as it does.