How it works
From order to seal, step by step
An audit covers between 10 and 150 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.
1. 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 — not even if they appear in your sitemap. An exclusion is stated explicitly in the result rather than passed off as missing content, and if your home page itself is blocked, no audit takes place at all.
2. How the auditor behaves
Measurement is passive and 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 — but it is the one point at which the auditor does more than read.
We also never ask for credentials to your CMS or server, and would decline them if offered. The price of that boundary is that areas behind a login stay outside the scope — we say so instead of implying coverage we do not have.
3. 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 here, never as a clean bill of health.
4. The three levels
Bedarfsanalyse
Findings only, no seal · fully automated
Vorprüfung
Seal possible · fully automated
Gold-Standard
Seal possible · automated plus human judgement
5. 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.
6. What you pay for
Billing is consumption-based: a base price per audit plus an amount per page actually measured. 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 including the base price is refunded automatically.
The binding rules are published in German: Prüfordnung →