Help
This page explains what the scan does, what you get and where the limits are. If a question stays open, write to info@websecureaudit.de.
In three sentences
You enter a domain and a matching email address. We fetch the site read-only, assess it across 17 areas and produce a report with a release verdict, individual findings, a phase plan and a cost indication. The report arrives as a PDF by email.
How it runs
- Submit the form. The page confirms immediately; the scan runs in the background.
- Scan. We fetch up to eight pages of the domain. That usually takes under a minute.
- Report. You get an email with the PDF attached. The mail already carries the score, the release verdict and the most urgent points.
Requirements
- The email address must belong to the domain. For
example.comthat means an address ending in@example.com. Otherwise the form stops with an error. That way a report about a domain only reaches someone who can read a mailbox of that domain. - The domain must be publicly reachable. Addresses on the local network,
localhostand internal IP ranges are rejected. - At most three scans per hour per sender and per recipient address.
What gets checked
- Security: headers, cookies, forms, mixed content
- Authentication, session and access
- TLS and certificate
- Publicly reachable paths and files
- Currency of core, plugins and libraries
- SEO
- GEO – visibility in AI systems
- GEO – geo-targeting and multilingual setup
- Performance and Core Web Vitals – including Google Lighthouse and field data from real users in the Chrome UX Report
- Accessibility / German Accessibility Act
- Backend and operations
- Data protection / GDPR
- Consent and § 25 TDDDG
- Mandatory disclosures and information duties
- NIS2 / BSIG
- Digital Services Act
- AI governance under the AI Act, and AI security
What that looks like in practice is shown by the example report.
Load time: what the numbers mean
We do not estimate load time, we fetch it from Google – through the same interface PageSpeed Insights draws its numbers from. The report therefore carries two measurements that are not the same thing. Confusing them is the most common mistake when reading such reports.
| Lab value (Lighthouse) | A single measurement under standardised conditions: throttled mobile network, mid-range device, empty cache. It does not say how fast your page is for any particular visitor – it says how fast it is under conditions that never change. That is exactly why it lets you compare whether a change achieved anything. Included: LCP, FCP, Speed Index, Total Blocking Time and CLS. |
|---|---|
| Field data (Core Web Vitals) | What real visitors experienced over the past 28 days, collected in the Chrome UX Report. This is the number Google ranks on – the lab value is only the simulation of it. Where the two disagree, the field wins. |
The field data appears in the report as a pie chart per metric: how many visitors were served well, adequately or badly. That is the information a single number hides. A mediocre average can mean everyone loads mediocrely – or that most load very fast and a minority very slowly. Only the second case has a clear cause, and only then is it worth chasing.
The figure shown is always the 75th percentile: three out of four visits were at least that fast. Google deliberately avoids the average, because it hides precisely the slow visits that matter.
If your site has too little traffic, there is no field data. Google only publishes it above a minimum number of visits, so that individual people cannot be derived from it. The report says so explicitly. It is not a bad mark but a statement about the data available – the assessment then rests on the lab value alone.
On top of that the report lists the individual actions Lighthouse found, each with the time saved in seconds and the bytes saved. They are sorted by that. The sum is an upper bound, not an addition: the items overlap in places, because the same file can appear in several rows.
Which systems can be scanned?
Any website reachable over HTTP or HTTPS – the technology behind it is irrelevant to most of the scan. Headers, certificate, consent, mandatory disclosures, SEO and accessibility are assessed regardless of what the site was built with.
Version and currency checks need the system to be recognised. Currently recognised are, among others, WordPress and WooCommerce, Shopify, Shopware, TYPO3, Drupal, Joomla, Contao, PrestaShop and Laravel, plus common front-end libraries such as React, Vue, Nuxt, Alpine, htmx and jQuery, and upstream services such as Cloudflare, Akamai or Netlify. If none of them is recognised the scan still runs – only the system-specific findings fall away.
What gets read and evaluated
- HTML of the pages fetched
- HTTP headers and cookies
robots.txt,sitemap.xml,llms.txt- Structured data (JSON-LD) and meta tags
- Embedded scripts and the versions they declare
- TLS certificate and connection parameters
What cannot be done from outside
Not every syntax can be analysed – what gets evaluated is what the server delivers. Source code that stays on the server is invisible: PHP, Python, Java, database contents, configuration files. Likewise everything behind a login: user accounts, plugin versions, system diagnostics. Pure APIs without an HTML surface and native apps are also not targets of this scan.
That is exactly what the backend audit is for: with read access to the system in question – shop platform, CMS, CRM or a custom web application, whatever it is built on. Depending on the system that is an account with read rights, an API token, basic auth or a session cookie. For WordPress, WooCommerce and Shopify part of the check runs automatically; for every other system the access is used for a manual review. This is paid and only happens on request, not through the form on the home page. Please never send credentials through the form; scope and price are agreed beforehand, the access applies only for the agreed period and needs read rights only.
Understanding the release verdict
| Release granted | No finding stands in the way of release. |
|---|---|
| Release after review | No blockers, but points someone has to assess before release. |
| Release blocked | At least one finding prevents release – a missing legal notice or a missing privacy policy, for instance. |
Effort and cost in the report
Every finding gets an effort range, multiplied by the hourly rate of the trade it belongs to – backend €110, frontend €100, DevOps €125, SEO €95, project management €115. On top come project management and a 15 % risk margin. The result is an indication for budgeting, not a quotation.
Limits
- The scan is passive: read-only fetching, no login, no exploitation of weaknesses. It is no substitute for a penetration test.
- Legal classifications are technical indicators and are no substitute for legal advice.
- Automatable means: a task package can be generated for the finding, and it is a draft. Sign-off and any technical or legal judgement stay with a human.
- What is assessed is the state at the moment of fetching. Legal status of the standards on file: 2026-08-16.
When something goes wrong
The email does not arrive
Check the spam folder first; the sender is info@websecureaudit.de. If nothing arrives within 15 minutes, write to us with the domain you scanned.
“The email address must belong to the domain being scanned”
That is the ownership check. Use an address of the domain. If you have none, get in touch via contact.
“This domain cannot be resolved in DNS”
A typo, or the domain is not publicly reachable. Enter it without https:// and without a path, so example.com.
The scan reports the site as unreachable
Often a firewall or bot protection blocks automated access. Our request identifies itself as WebSecureAudit and can be allowed in the configuration.