Direct answer: This is a form that runs entirely in your browser. You fill in 12 acceptance verdicts and the location of each piece of evidence, and it generates a Markdown evidence pack carrying the URL, capture time, user agent and HTML SHA-256, plus a CSV for spreadsheets. All priority-1 items must pass and priority-2 items must meet the ratio threshold for a "pass"; any item marked pass without an evidence location disables export. It does not crawl, does not verify your verdicts and uploads nothing.
Acceptance clause 9 asks for "URL, time, UA, tool version and the raw HTML". Our own scans follow that: raw HTML kept outside the repository, capture time and UA recorded, anonymised CSV published. Projects are less disciplined. A few screenshots land in a chat, and two weeks later nobody can say which version they show. That is the gap this tool closes.
URL, time with a time zone, and a user agent are mandatory.
Every pass needs an evidence location.
A missing HTML hash only warns: you can export, but you cannot prove the version.
The tool: fill in → validate → export
12 verdicts
| ID | Check | Priority | Verdict | Evidence location |
|---|
Press "Fill sample verdicts" to get a record that passes and can be exported. Change any item to Pass, clear its evidence field, and the export buttons disable immediately with an error naming the item and what is missing. That behaviour is deliberate: scoring is cheap, reproducing the score is not.
The 12 checks and their priorities
| Priority | Check | Evidence |
|---|---|---|
| P1 | Scope and page list (redesign re-acceptance) | Page-list CSV + version |
| P1 | robots.txt by bot and path | Raw robots.txt + line verdicts |
| P1 | Body visible with JS disabled | HTML fragment + screenshot |
| P1 | Exactly one H1 per page | HTML line number |
| P1 | JSON-LD parses and matches visible content | Validation output + raw JSON-LD |
| P2 | hreflang only for real alternates, with x-default | hreflang list |
| P1 | Inquiry path within two clicks, form or mailto/tel | Screenshot + HTML |
| P2 | Performance proxy recorded | TTFB / weight record |
| P1 | Evidence carries URL, time, UA and HTML hash | Header of this pack |
| P1 | Pass criteria written down | Threshold and P1/P2 rule |
| P2 | Remediation window and recheck scope agreed | Contract clause or minutes |
| P1 | Boundaries: no ranking, citation or traffic promise | Sign-off page |
9 items are P1 and 3 are P2. Not-applicable items leave the denominator; untested items keep the result at incomplete.
How the hash is computed
The page ships a pure-JavaScript SHA-256 and hashes the UTF-8 bytes of the pasted text into 64 hex characters. It needs no network and no extension; the same text produces the same value on any device. The tests pin four known vectors (empty string, abc, Chinese text, 1000 as) against Python's hashlib.
Be clear about what the hash proves and what it does not: it proves that the text you saved matches the record, so two pieces of evidence can be compared as the same or a different version. It does not prove the HTML came from the live site. That still needs the fetch log, URL, time and user agent together.
Pass criteria and recheck
The default rule follows the acceptance clauses: all P1 pass, P2 at 80%. The threshold can be changed, and the chosen value is written into the pack header so a recheck can see which rule was used. Not-applicable items are removed from the denominator instead of distorting the ratio; untested items keep the result at incomplete, so it cannot be exported as a pass.
Recheck scope is fixed to "failed items and affected pages only", with "same URL, same user agent, same tool version". If any of the three changes it is a new measurement, not a recheck — a distinction that frequently goes missing in disputes.
Five common evidence problems
- Screenshots with no time or user agent. The version cannot be identified and the result cannot be reproduced; screenshots do not carry that metadata.
- Homepage only. Product and contact pages often differ in robots, H1 and structured data; the scope list must name every URL.
- Passes with no evidence location. "Already optimised" is not evidence; the tool blocks that record from being exported.
- Using the hash instead of a fetch log. The hash covers the pasted text, not its origin.
- Rechecking the whole site. Recheck failed items and affected pages only, or cost and comparability both collapse.
Boundaries
- No verification: the tool does not fetch or parse your site, and does not judge whether a verdict is correct; it only checks that the record is complete and consistent.
- Not legal advice: clause wording, liability, data protection and payment follow the contract and counsel.
- No uploads: everything runs in the browser and is discarded when the tab closes; download what you need to keep.
- No outcome promise: passing acceptance does not mean indexed, cited, visited or inquired.
Tests and recalculation
The logic lives in js/evidence-pack.js (no dependencies, no network); scripts/test_evidence_pack.js covers 62 assertions: four SHA-256 vectors, field normalisation, validation errors and warnings, P1/P2 counting, threshold comparison, not-applicable removal, untested blocking, Markdown escaping and CSV quoting, plus the English output. Run:
node scripts/test_evidence_pack.js
Related: the 12 acceptance clauses (the 12 checks map to them), the per-bot robots matcher and the contact-path pilot.
Sources and definitions
- RFC 9309, Robots Exclusion Protocol: rfc-editor.org.
- FIPS 180-4, Secure Hash Standard (SHS), SHA-256: csrc.nist.gov.
- Clauses mapped here: website AI readability acceptance clauses (12).