What the six checks look at

One crawl produces one artifact, and the six checks read that artifact. None of them touches the network, so the same crawl can be re-checked after we improve a rule. Each check reports observations with a severity and, where one is relevant, the rule the observation relates to. None of them issues a verdict on that rule.

Payment-page scripts

Runs only on pages that actually take card details — a card field, a payment-provider iframe, or a payment provider's script. A URL that merely looks like a checkout is not enough. On those pages it inventories every script and reports:

• a script that is not on your approved list, graded higher when it is third-party;
• an inline script that is not on your list, matched by the hash of its source;
• an approved script whose body changed since you approved that hash — the one observation this check grades critical;
• an approved third-party script with no integrity attribute.

Relevant to PCI DSS 6.4.3 (know and authorise every script on the payment page) and 11.6.1 (notice when one changes). We report; only a qualified assessor says whether a merchant meets either requirement.

The approved list is yours, per site. On a fresh site nothing is approved yet, so the first report lists everything that is there — that first pass is the inventory, and approving the scripts you expect is what turns later runs into a change detector.

Cookies and trackers before consent

The crawler loads the site twice: once as a first-time visitor, then again after accepting a consent banner if it finds one. This check reads only what happened before consent:

• a cookie set before consent, deduplicated per cookie and domain across the site;
• a third-party request that looks like tracking (a script, an XHR, a pixel, a beacon) fired before consent;
• no consent banner at all, where the site nonetheless sets non-essential cookies or calls third parties.

Relevant to GDPR Art. 6 and ePrivacy Art. 5(3). A short list of genuinely necessary cookies — session, CSRF, cart, and the consent tools' own cookies — is never reported. A cookie we cannot classify from the public cookie database is reported as unclassified at low severity, with the reason, rather than guessed at: you know what your own cookie is for and we do not.

Accessibility

Against WCAG 2.2 AA, and EN 301 549 with it. axe-core runs in the real browser, on the site's entry page and on a payment page if the crawl found one, and we report the failures that carry a WCAG 2.2 A or AA tag. Each finding names the page, the rule axe reported and the element's selector, and lists the WCAG success criteria behind the rule. At most five elements per rule per page are listed; the finding carries the true count.

Automated testing covers only part of the WCAG success criteria. So a finding says what axe reported on a date, and never that a page is or is not accessible. There is no overlay and no auto-fix in this product, and there never will be: accessiBe was fined $1M by the FTC for claiming exactly that.

A page we did not run axe on produces nothing — it is not reported as clean.

Known plugin and theme vulnerabilities

Only for WordPress, and only from what the public pages reveal: plugin and theme slugs and version numbers read off the site's own asset URLs and its generator tag. Those are matched against the Wordfence Intelligence advisory feed, which we refresh daily.

A finding says "this version is named in this advisory", with the CVE id where the advisory has one. It is not a statement that the site has been, or can be, compromised — and the version came from a URL, so confirm it in the WordPress admin before acting. Where a plugin has advisories in the feed but no readable version, we say the version is unknown, at info severity: grading an unknown version by the worst advisory ever filed against that plugin would put a 9.8 on a report for a site that may well be patched.

Security headers and TLS

Per page, on pages that returned a normal 200 (a 404's headers are the error page's headers, so they are skipped), we report which of these are absent: content-security-policy, strict-transport-security, x-content-type-options, x-frame-options, referrer-policy, permissions-policy. A missing CSP on a payment page is graded higher and relates to PCI DSS 6.4.3; the rest are low to medium with no standard attached.

From one TLS handshake against the site's main host we also report: HTTPS not available at all, a certificate expiring within 30 days or already expired, an outdated protocol version, a hostname that does not match, and a chain that does not validate.

A missing header is reported as a missing header. Nothing here says a site is secure or insecure, and header values are never judged — so tightening a CSP does not churn the finding.

Legal pages

From the entry page's own links, and where no link names one, a single conventional address, we probe for five pages: privacy notice, terms, cookie policy, imprint, and accessibility statement. For each we report that it is missing, that a published link to it is broken, or that the page exists but is so short it reads as a placeholder.

We check whether the page exists and loads. We never read it and say anything about its contents — that is a lawyer's job. An imprint is a legal requirement in some countries and not others, so it is reported as something to check, not as a gap.

What none of them do

No check changes anything on the site. No check produces a score, a pass, a grade or a certificate. A report is a list of observations from one crawl on one date — the report disclaimer is the full version of that sentence, and it is printed on every page of every PDF.