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

How it works

From order to seal, step by step

An audit covers between 10 and 1000 publicly reachable pages of one domain, agreed in advance. The auditor discovers them, measures each area, leaves anything it cannot decide to a human, and issues a separate seal for every area that both reaches 90 of 100 points and belongs to a domain whose control has been proven. The procedure is documented, its limits are stated, and every result leads to a public verification page.

The procedure

Scope. The audit scope is fixed: up to 1000 pages of the domain, starting at the home page, discovered via sitemap and internal links.
Measurement. Every page runs through the automated checks of the ordered areas, in a real browser. Only what can be decided unambiguously is measured.
Human judgement. Criteria a machine cannot decide stay open until an auditor rules on them. These rulings count towards the score and are marked as human judgements.
Scoring. Each area gets a score against the agreed target. An area that misses its target gets no seal, even if other areas pass.
Seal and verification. Areas that pass receive a seal with their own audit ID. The verification page shows result, audit date, validity and status, permanently.

Which pages are looked at

Discovery starts at your home page, follows the sitemap and internal links on the same host, and stops at the agreed page count. Redirects are resolved first: if your domain redirects to a different host, that host is what gets audited, and the report says so.

Your robots.txt is respected. Addresses it blocks for our product token EuidPruefservice are not fetched, even if they appear in your sitemap. An exclusion is stated explicitly in the result. If your home page itself is blocked, no audit takes place at all.

How the auditor behaves

Measurement is read-only: pages are fetched and evaluated the way a browser would. No vulnerability scanning, no port probing, no login attempts, no load testing. Every request identifies itself with a dedicated user agent carrying a contact reference, and repeated audits of the same domain are spread out over time, regardless of how many customers request them.

There is exactly one exception, and it is written into the published audit rules: the data protection area clicks “reject” on the consent banner and reloads the page, to measure whether the rejection technically takes effect. That question cannot be answered by reading. It is ordinary use of a public page, and the one point at which the auditor does more than read.

We never ask for credentials to your CMS or server, and would decline them if offered. The price of that boundary: areas behind a login stay outside the scope, and the report says so.

Where a human takes over

Anything a machine can decide unambiguously is decided by the machine. Anything it cannot stays open until an auditor rules on it, and such rulings are marked as human judgements in the report. A criterion is never treated as met merely because the measurement found no violation. An empty result counts as an error, never as a clean bill of health.

What a seal requires

Two things, and both are mandatory. The area must reach 90 of 100 points, and control over the domain must be proven, either by a DNS record or by a file under /.well-known/ containing a value derived from a secret generated for that customer. Without that proof no seal is issued, however good the score.

Each seal states the domain, the audit area, the audit date, the ruleset version and the validity period, and links to a public verification page that stays reachable. Expired and revoked seals remain listed there as such. A verification page that quietly disappears would make every other seal worthless.

What you pay for

The price follows the page count according to the published scale. Only what could be measured is charged: if a page returns nothing, it is not billed; if an audit produces nothing at all, the full amount is refunded.

The binding rules are published in German: Prüfordnung · Deutsche Fassung dieser Seite

FAQ

Why is an automated test not enough?

Many criteria cannot be decided by a machine. Whether an alternative text really conveys the image cannot be judged by any tool. Such criteria stay explicitly undecided with us until an auditor has judged them. A criterion never counts as met merely because the measurement found nothing.

How does the audit service make sure its own measurement is correct?

The measuring core is checked against our own test page with known, deliberately built-in defects. If it misses a known defect, the measuring core counts as faulty. An empty audit counts as an error for us, never as a clean bill of health.

What does a seal state?

Domain, audit area, score, audit date and expiry. Every seal links to its public verification page, where status (active, expired or revoked) and scope are visible to anyone.

Can a seal be revoked?

Yes. Revoked seals are explicitly marked as revoked on the verification page; the page stays. That is exactly where the value of public verification lies.

Does the audit put load on my website?

The audit reads like an ordinary visitor, with spaced requests and an identifying user agent including a contact reference. The one exception to pure reading: the data protection area clicks “reject” on the cookie banner and reloads the page to measure whether the rejection technically takes effect.