Skip to content

This translation has not been editorially reviewed yet. The German version is authoritative. Deutsche Fassung →

What we check

The audit areas, each with its own seal

A website can pass accessibility and fail on loading performance. Reporting that as one combined figure would hide exactly the information you need, so we never produce one. Each area is measured on its own, judged on its own and, once it reaches 90 out of 100 points and control over the domain has been proven, sealed on its own.

You choose what is audited

An order covers the areas you choose. If you need an accessibility statement, audit accessibility; before a relaunch, audit everything. Only what could be measured is charged: if a page returns nothing, it is not billed.

The audit areas

Accessibility (WCAG 2.2 AA)

55 success criteria · WCAG 2.2 A/AA

Measured in a real browser across three device profiles. A substantial share of these criteria cannot be decided by a machine; those stay visibly open until a human auditor has ruled on them.

ServiceAll check points

Data protection & cookies

10 weighted rules · dsgvo-v1

What loads before any consent, whether pressing “reject” actually stops it, cookies set before a choice was made, remotely loaded web fonts, and the presence of a privacy notice.

ServiceAll check points

CO₂ & sustainability

Page weight · transfer · SWDM · green web hosting

Page weight, transfer and requests per visit, the estimated CO₂ emission, and whether the hosting runs on renewable energy.

ServiceAll check points

Visibility in AI answers

12 rules · geo-v2

Whether an answering system can find, extract and attribute a passage of your page: answer-first openings, question headings, self-contained sections, machine-readable facts.

ServiceAll check points

Search engine optimisation

22 rules · seo-v2

Titles and descriptions, heading structure, internal linking, structured data.

ServiceAll check points

Indexing & technical setup

9 weighted rules · fetch, redirects, robots.txt, sitemap

Whether search engines may fetch the page, can find it and assign it unambiguously.

ServiceAll check points

Responsive behaviour

9 measured signals · 4 device profiles

Three device profiles rendered in a real browser: horizontal overflow, target sizes, text overflow.

ServiceAll check points

Loading performance

10 measured signals · Core Web Vitals

Loading behaviour, responsiveness, layout stability, measured rather than estimated.

ServiceAll check points

Software currency

4 weighted rules · read-only

Detected CMS, extensions and libraries past their maintenance end, determined passively, without credentials.

ServiceAll check points

Rules and signals

The difference helps when reading a result. It is the reason some areas report a score per check point and others the measured signals.

Rule-based

A fixed, countable set of rules with point weights. Each rule has an identifier, a weight, and appears by name in the report, so a finding can be traced back to the rule that produced it.

Signal-based

Judged from signals measured in a real browser, such as loading metrics or the behaviour of a consent banner. Instead of a rule list, the report states which signals are measured. Both are measurements; the report says which is which.

For weighted rules, the weights add up to exactly 100 points, so the result reads as a percentage. The weighting follows actual risk rather than ease of measurement: in software currency, one rule carries 40 points and the others 20 each, because only the first describes a real defect.

Where a machine stops

In almost every area the essential question can be decided by a machine: an image has an alternative text or not, a page responds or not, a tracker loads before consent or not.

Accessibility is the exception. Whether an alternative text actually describes the image, whether an error message is understandable, whether the reading order makes sense, a human decides that. Tools that still certify “100 % accessible” after a clean automated run are hiding that gap. Here such criteria stay visibly open until an auditor has ruled on them. That is why accessibility can only be sealed with human judgement.

The opposite pole is indexing: every criterion there is unambiguously machine-decidable. A status code is a status code.

When a seal is issued

An area receives its seal once it reaches 90 out of 100 points and control over the domain has been proven, by a DNS record or a file under /.well-known/. Without that proof no seal is issued, even with a perfect score. The seal states the domain, the audit area, the audit date, the ruleset version and the validity period, and stays verifiable on a public verification page.

An area that misses its target gets no seal, even if others pass. You still receive the full findings: what is missing, how serious it is, on which pages.

How the procedure works in detail is described under How it works; the binding rules are published in German in the Prüfordnung. How it works · Prüfordnung · Deutsche Fassung dieser Seite