Hilfe
Diese Seite erklärt, was die Prüfung tut, was du bekommst und wo die Grenzen liegen. Wenn eine Frage offenbleibt, schreib an info@websecureaudit.de.
In drei Sätzen
Du gibst eine Domain und eine dazugehörige E-Mail-Adresse ein. Wir rufen die Seite lesend ab, bewerten sie in 17 Prüfbereichen und erzeugen daraus einen Bericht mit Freigabeurteil, Einzelbefunden, Phasenplan und Kostenindikation. Den Bericht bekommst du als PDF per E-Mail.
Ablauf
- Formular absenden. Die Seite bestätigt sofort; die Prüfung läuft im Hintergrund.
- Prüfung. Wir rufen bis zu acht Seiten der Domain ab. Das dauert meist unter einer Minute.
- Bericht. Du bekommst eine E-Mail mit dem PDF im Anhang. In der Mail stehen bereits Note, Freigabeurteil und die dringendsten Punkte.
Voraussetzungen
- Die E-Mail-Adresse muss zur Domain gehören. Für
beispiel.dealso eine Adresse, die auf@beispiel.deendet. Andernfalls bricht das Formular mit einer Fehlermeldung ab. So geht ein Bericht über eine Domain nur an jemanden, der ein Postfach dieser Domain lesen kann. - Die Domain muss öffentlich erreichbar sein. Adressen im lokalen Netz,
localhostund interne IP-Bereiche werden abgewiesen. - Höchstens drei Prüfungen pro Stunde je Absender und je Empfängeradresse.
Was geprüft wird
- Sicherheit: Header, Cookies, Formulare, Mixed Content
- Authentifizierung, Session und Zugriff
- TLS und Zertifikat
- Öffentlich erreichbare Pfade und Dateien
- Aktualität von Core, Plugins und Bibliotheken
- SEO
- GEO – Sichtbarkeit in KI-Systemen
- GEO – Geo-Targeting und Mehrsprachigkeit
- Performance und Core Web Vitals – inklusive Google Lighthouse und den Felddaten echter Nutzer aus dem Chrome UX Report
- Barrierefreiheit / BFSG
- Backend und Betrieb
- Datenschutz / DSGVO
- Consent und § 25 TDDDG
- Pflichtangaben und Informationspflichten
- NIS2 / BSIG
- Digital Services Act
- KI-Governance nach AI Act und KI-Sicherheit
Wie das im Ergebnis aussieht, zeigt der Beispiel-Report.
Ladezeit: was die Zahlen bedeuten
Die Ladezeit schätzen wir nicht, wir holen sie bei Google – über dieselbe Schnittstelle, aus der auch PageSpeed Insights seine Werte bezieht. Im Bericht stehen deshalb zwei Messungen, die nicht dasselbe sind. Sie zu verwechseln ist der häufigste Fehler beim Lesen solcher Berichte.
| Laborwert (Lighthouse) | Eine einzelne Messung unter genormten Bedingungen: gedrosseltes Mobilfunknetz, Mittelklassegerät, leerer Cache. Sie sagt nicht, wie schnell deine Seite für einen bestimmten Besucher ist – sondern wie schnell sie unter immer gleichen Bedingungen ist. Genau deshalb lässt sich damit vergleichen, ob eine Änderung etwas gebracht hat. Enthalten: LCP, FCP, Speed Index, Total Blocking Time und CLS. |
|---|---|
| Felddaten (Core Web Vitals) | Was echte Besucher in den letzten 28 Tagen erlebt haben, erhoben im Chrome UX Report. Das ist der Wert, nach dem Google rankt – der Laborwert ist nur die Simulation dazu. Weichen beide auseinander, gilt das Feld. |
Die Felddaten erscheinen im Bericht als Tortendiagramm je Metrik: wie viele Besucher gut, verbesserungswürdig oder schlecht bedient wurden. Das ist die Information, die eine einzelne Zahl unterschlägt. Ein mittelmäßiger Durchschnitt kann bedeuten, dass alle mittelmäßig laden – oder dass die meisten sehr schnell laden und eine Minderheit sehr langsam. Nur der zweite Fall hat eine klare Ursache, und nur dann lohnt es, ihr nachzugehen.
Der ausgewiesene Wert ist immer das 75. Perzentil: drei von vier Aufrufen waren mindestens so schnell. Google nimmt bewusst nicht den Durchschnitt, weil der genau die langsamen Aufrufe verdeckt, um die es geht.
Hat deine Seite zu wenig Verkehr, gibt es keine Felddaten. Google veröffentlicht sie erst ab einer Mindestzahl von Aufrufen, damit sich daraus keine einzelnen Personen ableiten lassen. Der Bericht sagt das dann ausdrücklich. Es ist keine schlechte Note, sondern eine Auskunft über die Datenlage – bewertet wird dann allein nach dem Laborwert.
Dazu führt der Bericht die Einzelmaßnahmen auf, die Lighthouse gefunden hat, jeweils mit dem bezifferten Zeitgewinn in Sekunden und dem eingesparten Volumen. Sie sind danach sortiert. Die Summe ist eine Obergrenze, keine Addition: Die Posten überschneiden sich teilweise, weil dieselbe Datei in mehreren Zeilen auftauchen kann.
Welche Systeme lassen sich prüfen?
Jede Website, die über HTTP oder HTTPS erreichbar ist – die eingesetzte Technik spielt für den größten Teil der Prüfung keine Rolle. Header, Zertifikat, Consent, Pflichtangaben, SEO und Barrierefreiheit werden unabhängig davon bewertet, womit die Seite gebaut wurde.
Für Versions- und Aktualitätsprüfungen muss das System erkannt werden. Erkannt werden derzeit unter anderem WordPress und WooCommerce, Shopify, Shopware, TYPO3, Drupal, Joomla, Contao, PrestaShop und Laravel, dazu verbreitete Frontend-Bibliotheken wie React, Vue, Nuxt, Alpine, htmx und jQuery sowie vorgelagerte Dienste wie Cloudflare, Akamai oder Netlify. Wird nichts davon erkannt, läuft die Prüfung trotzdem – nur die systemspezifischen Befunde entfallen.
Was gelesen und ausgewertet wird
- HTML der abgerufenen Seiten
- HTTP-Header und Cookies
robots.txt,sitemap.xml,llms.txt- Strukturierte Daten (JSON-LD) und Metaangaben
- Eingebundene Skripte und deren Versionsangaben
- TLS-Zertifikat und Verbindungsparameter
Was von außen nicht geht
Nicht jede Syntax lässt sich analysieren – ausgewertet wird, was der Server ausliefert. Quelltext, der auf dem Server bleibt, ist unsichtbar: PHP, Python, Java, Datenbankinhalte, Konfigurationsdateien. Ebenso alles hinter einer Anmeldung: Benutzerkonten, Plugin-Stände, Systemdiagnose. Reine APIs ohne HTML-Oberfläche und native Apps sind ebenfalls kein Ziel dieser Prüfung.
Genau dafür gibt es das Backend-Audit: mit einem Lesezugang zum jeweiligen System – Shopsystem, CMS, CRM oder eigene Webanwendung, gleich welcher Technik. Je nach System ist das ein Konto mit Leserechten, ein API-Token, Basic-Auth oder ein Session-Cookie. Für WordPress, WooCommerce und Shopify läuft ein Teil der Prüfung automatisiert; bei allen anderen Systemen wird der Zugang für die manuelle Durchsicht genutzt. Das ist kostenpflichtig und läuft nur über eine Anfrage, nicht über das Formular auf der Startseite. Zugangsdaten schick bitte nie über das Formular; Umfang und Preis werden vorher vereinbart, der Zugang gilt nur für den vereinbarten Zeitraum und braucht lediglich Leserechte.
Das Freigabeurteil verstehen
| Freigabe erteilt | Kein Befund steht der Freigabe entgegen. |
|---|---|
| Freigabe nach Prüfung | Keine Blocker, aber Punkte, die vor der Freigabe jemand bewerten muss. |
| Freigabe blockiert | Mindestens ein Befund verhindert die Freigabe – etwa ein fehlendes Impressum oder eine fehlende Datenschutzerklärung. |
Aufwände und Kosten im Bericht
Jeder Befund bekommt eine Aufwandsspanne, die mit dem Stundensatz des passenden Gewerks multipliziert wird – Backend 110 €, Frontend 100 €, DevOps 125 €, SEO 95 €, Projektmanagement 115 €. Dazu kommen Projektmanagement und ein Risikozuschlag von 15 %. Das Ergebnis ist eine Indikation für die Budgetplanung, kein Angebot.
Grenzen
- Die Prüfung ist passiv: lesender Abruf, keine Anmeldung, kein Ausnutzen von Schwachstellen. Sie ersetzt keinen Penetrationstest.
- Rechtliche Einordnungen sind technische Indikatoren und ersetzen keine Rechtsberatung.
- Automatisierbar heißt: Für den Befund lässt sich ein Aufgabenpaket erzeugen, das ein Entwurf ist. Freigaben, fachliche und rechtliche Bewertungen bleiben beim Menschen.
- Geprüft wird der Zustand zum Zeitpunkt des Abrufs. Rechtsstand der hinterlegten Normen: 2026-08-16.
Wenn etwas nicht klappt
Die E-Mail kommt nicht an
Sieh zuerst im Spam-Ordner nach; der Absender ist info@websecureaudit.de. Kommt nach 15 Minuten nichts an, schreib uns mit der geprüften Domain.
„Die E-Mail-Adresse muss zur geprüften Domain gehören"
Das ist die Eigentumsprüfung. Nutz eine Adresse der Domain. Hast du keine, meld dich per Kontakt.
„Diese Domain ist im DNS nicht auflösbar"
Tippfehler oder die Domain ist nicht öffentlich erreichbar. Gib sie ohne https:// und ohne Pfad ein, also beispiel.de.
Die Prüfung meldet, die Seite sei nicht erreichbar
Häufig blockiert eine Firewall oder ein Bot-Schutz automatisierte Zugriffe. Unser Abruf weist sich als WebSecureAudit aus und kann in der Konfiguration zugelassen werden.