Wie erkennt ein browserbasierter Compliance-Scanner tatsächlich Probleme auf einer Website?

Er rendert die Seite in einer echten Browser-Engine, extrahiert einen strukturierten Snapshot aus Skripten, Cookies, DOM-Struktur und einwilligungsabhängigem Verhalten und führt dann die Prüfungen jedes Compliance-Moduls gegen denselben Snapshot aus.

Warum nicht einfach das rohe HTML abrufen und durchsuchen?

Rohes HTML spiegelt oft nicht wider, was der Browser eines Besuchers tatsächlich anzeigt oder ausführt, da Tracking-Skripte und Einwilligungslogik häufig erst nach dem Laden der Seite per JavaScript hinzugefügt oder verändert werden. Ein roher HTML-Abruf führt dieses JavaScript nie aus.

Kann eine Plattform DSGVO-, AI-Act- und Barrierefreiheits-Compliance gleichzeitig prüfen?

Ja. Jedes Compliance-Modul liest aus demselben Snapshot der gerenderten Seite, statt einen separaten Scan zu erfordern, sodass ein Scan Ergebnisse für jedes live geschaltete Modul liefert.

Wie erkennt das Tool Formulare, die personenbezogene Daten erfassen?

Es prüft die Felder jedes Formulars — Eingabefelder, Textbereiche, Auswahllisten — und gleicht deren Attribute type, name, id, placeholder und autocomplete mit Stichwortlisten für E-Mail, Telefon und Name ab. Ein Formular wird dann je nach Anzahl dieser Signale als niedrig, mittel oder hoch sensibel eingestuft, zusätzlich wird geprüft, ob neben diesen Daten eine Einwilligungs-Checkbox vorhanden ist.

Wie stellt dieses Tool fest, welche Cookies vor der Einwilligung feuern?

Das wird nicht aus statischem Code abgeleitet. Eine echte Browser-Engine rendert die Seite und zeichnet die tatsächlich ausgehenden Netzwerkanfragen anhand einer Liste bekannter Tracking-Anbieter auf und vergleicht, was vor der Interaktion des Nutzers mit dem Einwilligungsbanner feuert, mit dem, was danach feuert. Ein Anbieter wird nur dann als vor der Einwilligung feuernd gemeldet, wenn diese Anfrage nachweislich vor der Einwilligungs-Interaktion stattfindet — nicht allein aufgrund des Vorhandenseins eines Skript-Tags angenommen.

Website-Compliance

Wie automatisiertes Website-Compliance-Scanning wirklich funktioniert

Was zwischen der Eingabe einer URL und dem Erhalt eines Compliance-Berichts tatsächlich passiert.

Kurzantwort

Ein automatisierter Website-Compliance-Scan funktioniert, indem er eine Seite in einer echten Browser-Engine rendert — statt nur ihr rohes HTML abzurufen —, sodass er die Seite so sieht, wie es ein echter Besucher tun würde, einschließlich Skripten, die erst nach dem Laden der Seite ausgeführt werden, und Inhalten, die hinter der Cookie-Einwilligung verborgen sind. Diese gerenderte Seite wird in einen strukturierten Snapshot umgewandelt: geladene Skripte, gesetzte Cookies, Einwilligungsverhalten, DOM-Struktur und Textinhalt. Jedes Compliance-Modul (DSGVO, AI Act, Barrierefreiheit) führt dann seine eigenen Prüfungen gegen denselben Snapshot aus, und die Ergebnisse werden zu einem Bericht zusammengeführt.

Von GetGDPRScan Editorial · Zuletzt aktualisiert 2026-07-24

Bei einem Compliance-Scan wird oft angenommen, dass "das Tool mein HTML heruntergeladen und nach Schlüsselwörtern durchsucht hat." Diesen Ansatz gibt es, er ist aber unzuverlässig — er übersieht alles, was erst nach der Ausführung von JavaScript erscheint, was heute die meisten Tracking- und Einwilligungsvorgänge betrifft.

Dieser Artikel beschreibt den tatsächlichen Mechanismus: Rendering, Snapshot-Erstellung und modulare Analyse. Der begleitende Artikel Was automatisierte Compliance-Scanner erkennen (und was nicht) behandelt die Grenzen dieses Mechanismus.

Warum ist das Rendern der Seite wichtig, statt einfach nur ihr HTML abzurufen?

Rohes HTML, das mit einer einfachen HTTP-Anfrage abgerufen wird, sieht oft ganz anders aus als das, was der Browser eines Besuchers tatsächlich darstellt. Cookie-Banner, Tracking-Skripte und Einwilligungslogik werden häufig erst nach dem ersten Seitenaufbau per JavaScript eingefügt oder verändert — ein reiner HTML-Abruf führt dieses JavaScript nie aus und kann daher genau das Verhalten übersehen, auf das es bei einer Compliance-Prüfung ankommt.

Das Rendern der Seite in einer echten Browser-Engine führt dieses JavaScript so aus, wie es der Browser eines Besuchers täte — dadurch lässt sich beispielsweise beobachten, ob ein Tracking-Skript tatsächlich feuert, bevor der Nutzer mit einem Einwilligungsbanner interagiert, oder erst danach.

Was wird aus einer gerenderten Seite extrahiert?

Sobald eine Seite gerendert ist, wird sie in einen strukturierten Snapshot umgewandelt, statt als rohes Markup analysiert zu werden. Dieser Snapshot umfasst typischerweise, welche Skripte von wo geladen wurden, welche Cookies wann gesetzt wurden, die DOM-Struktur und den Textinhalt der Seite sowie — entscheidend — den Zustand der Seite vor und nach einer simulierten Einwilligungs-Interaktion, damit ein Scanner ein Skript, das sofort feuert, von einem unterscheiden kann, das erst nach erteilter Einwilligung feuert.

Wie nutzen die verschiedenen Compliance-Module denselben Snapshot?

Jedes Modul — DSGVO, AI Act, Barrierefreiheit — ist ein eigenständiges Regelwerk, das denselben zugrunde liegenden Snapshot liest, statt einen eigenen separaten Seitenaufruf auszulösen. Das DSGVO-Modul sucht nach Tracking-Skripten und Cookies relativ zum Einwilligungsstatus; das Barrierefreiheits-Modul bewertet die DOM-Struktur anhand der WCAG-Erfolgskriterien; das AI-Act-Modul sucht nach Signalen für den Einsatz von KI-Systemen und zugehörigen Offenlegungen.

Deshalb erfordert ein neuer Compliance-Bereich keinen Umbau des Scan-Mechanismus — es reicht, ein neues Modul zu schreiben, das die bereits erfassten Signale liest, oder den Snapshot um neue Signale zu erweitern, die ein Modul benötigt.

Was jedes aktive Modul aus dem Snapshot liest

Modul	Primäre gelesene Signale
DSGVO	Skripte/Cookies vor vs. nach Einwilligung, Vorhandensein eines Cookie-Banners, Inhalt der Datenschutzerklärung
AI Act	Signale für den Einsatz von KI-Systemen und zugehöriger Offenlegungstext
Barrierefreiheit (WCAG)	DOM-Struktur — Überschriften, Alt-Texte, ARIA-Rollen, Formularbeschriftungen, Farbkontrast

Interagiert der Scanner mit der Seite, oder beobachtet er sie nur?

Manche Prüfungen erfordern begrenzte Interaktion — etwa um Skripte, die erst nach dem Schließen eines Einwilligungsbanners feuern, von solchen zu unterscheiden, die unabhängig davon feuern. Der Scanner erstellt keine Konten, sendet keine Formulare mit echten Daten ab und führt keine Aktionen aus, die über das hinausgehen, was zur Beobachtung von einwilligungsabhängigem Verhalten nötig ist.

So prüft GetGDPRScan das: Das DSGVO-Modul von GetGDPRScan vergleicht Skript- und Cookie-Aktivität gezielt vor und nach Berücksichtigung einwilligungsabhängiger Inline-Skripte, sodass ein Tracker, der scheinbar erst nach der Einwilligung lädt, nicht fälschlich als vorher ladend gemeldet wird.

Das Wichtigste in Kürze

•Der Scanner rendert Seiten in einer echten Browser-Engine statt rohes HTML abzurufen, sodass er Skripte und Einwilligungsverhalten so sieht wie der Browser eines Besuchers.
•Eine gerenderte Seite wird zu einem strukturierten Snapshot — Skripte, Cookies, DOM, Einwilligungsstatus vor/nach —, den jedes Compliance-Modul liest.
•Ein neues Compliance-Modul hinzuzufügen bedeutet, neue Prüfungen gegen bestehende (oder erweiterte) Snapshot-Daten zu schreiben, nicht den Scan-Mechanismus neu zu bauen.
•Der Scanner beobachtet einwilligungsabhängiges Verhalten; er erstellt keine Konten und trägt keine echten Daten in Formulare ein.