Observations, not certification
Version 1.1 · Effective 2 October 2026
A SitesProof report lists what an automated crawler saw on one web page, or a small set of pages, on one date. It is a set of observations. It is not a certificate, an audit, an assessment against any standard, or legal advice.
Contents
- What this report is
- What it is not
- How the checks work
- Standards we refer to
- What to do with a finding
- Contact
1. What this report is
We render the page in a real browser and record what can be seen from the outside: the scripts the page loads and their hashes, the network requests and cookies that happen before anyone agrees to anything, the accessibility problems an automated test engine can detect, the plugin and theme versions the page reveals, the response headers, the certificate, and whether the usual legal pages exist and load.
Each finding says what was observed, where, and when. The date and the pages covered are printed on the report.
2. What it is not
- Not a certification. Nobody can certify compliance from an automated scan, and we do not. No wording in a report, on this site, or in an email from us means a site is compliant, certified, approved, safe or secure.
- Not an audit. A report is not a PCI DSS assessment, an accessibility audit, a penetration test or a legal opinion. Where a standard requires a qualified assessor, an auditor or a lawyer, this report is material they may look at, not a substitute for them.
- Not complete. We see a sample of pages from the public internet. We do not see your servers, your code, your consent records, your contracts or anything behind a login. A report with no findings does not mean there is nothing wrong.
- Not a fix. We never change a page, inject anything into it, or overlay it. Automated accessibility overlays in particular do not make a site accessible, and one vendor was fined $1M by the FTC for selling them as if they did. We only tell you what we saw.
- Not legal advice. Nothing in a report is advice about your obligations under any law or standard.
3. How the checks work
Checks are automated and run against a stored copy of the crawl, so they can be replayed. That makes them consistent and cheap to re-run, and it also means they inherit the limits of any automated test: they can miss a real problem, and they can report something that is not a problem in context. Automated accessibility testing in particular only covers part of the WCAG success criteria; the rest needs a person.
Findings are kept over time rather than recreated on every scan, so a report can say how long something has been open and what changed since the last one. A finding marked resolved means a later crawl no longer saw it, not that the underlying cause was addressed.
4. Standards we refer to
Where a finding mentions a standard — PCI DSS requirements for payment-page scripts, WCAG 2.2 AA and EN 301 549 for accessibility, published vulnerabilities for plugins and themes — the reference tells you which rule the observation is relevant to. It is not a determination that you meet, or fail, that rule. Those determinations are made by your assessor, your auditor, your lawyer or the regulator, never by us.
5. What to do with a finding
Treat a report as a list to review, not a verdict. Check each finding against what you know about the site, fix what is real, and keep the report as evidence of when you looked. If you think a finding is wrong, tell us: a false finding is a bug and we want to hear about it.
6. Contact
Questions about a report: support@sitesproof.com. Security reports: security@sitesproof.com. Data and privacy: privacy@sitesproof.com. SitesProof is operated by SitesProof, Milutenka 23, Kyiv, Ukraine.