maxburst/cookie-privacy-compliance

Cookie-, Tracking- und Datenschutz-Compliance

Diese Fähigkeit bringt eine Website von „Wir glauben, wir haben ein Cookie-Banner“ zu „Hier sind Belege, dass sich die Website rechtmäßig verhält“. Die Arbeit besteht aus vier Phasen: Umfang, Audit, Implementierung, Verifizierung. Eine Anfrage kann nur einige davon erfordern (ein reines Audit endet nach dem Bericht), aber sie laufen immer in dieser Reihenfolge ab, weil jede von der vorherigen abhängt.

Drei Ideen bestimmen alles hier.

Das Verhalten zählt, und es muss gemessen werden. Aufsichtsbehörden und Kläger testen, was der Browser tatsächlich tut: welche Cookies existieren und welche Dritten vor einer Auswahl, nach einer Ablehnung, nach einem Widerruf kontaktiert werden. Ein Banner beweist nichts. Die meisten wirklichen Feststellungen sind ein Banner, das vorhanden ist und gut aussieht, während die Tags trotzdem feuern. Ziehen Sie daher niemals aus dem Vorhandensein eines Consent-Tools, einer Plugin-Einstellung oder einer Codezeile Schlussfolgerungen; schließen Sie aus einem Scan.

Die Regeln hängen davon ab, wer die Besucher sind. Europa ist Opt-in (nichts Nicht-Notwendiges vor Einwilligung). Die USA sind Opt-out mit Opt-in-Nischen und einem großen Prozessrisiko. Der Rest der Welt liegt dazwischen. Dieselbe Website kann für eine Zielgruppe in Ordnung und für eine andere rechtswidrig sein, deshalb kommt zuerst der Umfang und jede Feststellung wird unter einem bestimmten Regime benannt.

Ein Banner, das lügt, ist schlimmer als kein Banner. Ein „Ablehnen“-Button, der die Tags nicht stoppt, macht aus einer Compliance-Lücke einen Täuschungsanspruch (dies ist das Tatsachenmuster in fast jeder kalifornischen Vollstreckungsmaßnahme). Versenden oder hinterlassen Sie niemals ein dekoratives Banner. Wenn etwas noch nicht getrennt werden kann, sagen Sie es und entfernen Sie das Versprechen.

Sie sind nicht der Anwalt des Benutzers. Geben Sie klare, praktische Feststellungen mit der dahinterstehenden Regel, markieren Sie die Stellen, an denen die Rechtslage ungeklärt ist oder die Fakten eine rechtliche Beurteilung erfordern, und sagen Sie dies im Bericht. Verstecken Sie sich auch nicht hinter Haftungsausschlüssen: Der Benutzer möchte wissen, was zu beheben ist.

Referenzdateien

Lesen Sie, was der Auftrag benötigt, nicht alles.

Datei	Lesen, wenn
references/jurisdictions.md	Immer während des Scoping. Ordnet die Zielgruppe den Einwilligungsregimen zu und teilt mit, welche Gesetzesdatei zu öffnen ist.
references/law-europe.md	Bei Besuchern aus EU/EWR, Großbritannien oder der Schweiz. Länderspezifische Unterschiede, Banner-Design-Regeln, Analytics-Ausnahmen, Durchsetzung.
references/law-us.md	Bei Besuchern aus den USA. Staatliche Gesetzes-Schwellenwerte, GPC, Kalifornien-Spezifika, Wiretap-Rechtsprechung, Gesundheits-/Kinder-/Finanzdaten.
references/law-rest-of-world.md	Kanada, Lateinamerika, Asien-Pazifik, Naher Osten, Afrika.
references/audit-playbook.md	Durchführung des Audits: Scanner-Nutzung, Ergebnisauswertung, Code- und Konfigurationsinspektion, Diagnose eines vorhandenen Consent-Tools.
references/failure-patterns.md	Interpretation der Scan-Ergebnisse. 27 Muster, die die meisten Feststellungen erklären.
references/implementation.md	Planung und Durchführung der Behebung: Auswahl oder Reparatur eines Consent-Tools, Rollout-Reihenfolge, Richtlinien, GPC.
references/consent-signals.md	Anbindung eines bestimmten Anbieters: Google Consent Mode v2, Meta, Microsoft, TikTok, TCF/GPP, Shopify, WP Consent API.
references/consent-tools.md	Auswahl zwischen Consent-Tools oder Ermittlung des Cookie-Namens, des Markups und der JS-API eines Tools.
references/script-blocking.md	Trennung eines Tags, Embeds, Fonts oder serverseitigen Ereignisses; WordPress-, Shopify-, Next.js- und SPA-Spezifika.
references/testing-tools.md	Verifizierung: die vollständige Testmatrix, Barrierefreiheits- und Leistungsprüfungen, Geo-Simulation.
references/report-template.md	Erstellung des Auditberichts oder des Verifizierungsberichts.

Die Gesetzesdateien wurden am 11.11.2026 überprüft und versehen jede Behauptung mit einem Konfidenz-Tag. Datenschutzrecht ändert sich monatlich. Wenn eine Empfehlung von einem Detail abhängt, das als unsicher gekennzeichnet, unter „im Fluss“ aufgeführt oder älter als ein paar Monate ist, überprüfen Sie es vor der Verwendung anhand einer aktuellen Primärquelle und teilen Sie dem Benutzer mit, welche Punkte Sie nachgeprüft haben.

Phase 1: Umfang

Stellen Sie diese Punkte vor dem Scannen fest. Finden Sie selbst, was Sie können (die Website, ihren Footer, ihre Richtlinien, die Codebasis), und fragen Sie den Benutzer nur nach dem, was Sie nicht finden können. Beschränken Sie sich auf eine Runde Fragen.

1. Welche Websites und Hosts. Hauptdomain, Subdomains, eine separate Checkout- oder App-Domain, Staging.
2. Wo die Besucher sind. Fragen Sie nach der tatsächlichen Zielgruppe und überprüfen Sie sie anhand von Hinweisen: Sprachen, Währungen, Versandländer, Analytics-Geographie, wenn Sie Zugriff haben. „Nur USA“ von einem englischsprachigen Shop, der weltweit versendet, ist nicht nur USA. Eine Website unterliegt einem Gesetz, wenn sie Menschen dort anspricht oder bedient, unabhängig davon, wo das Unternehmen ansässig ist.
3. Was die Website mit Daten macht. Werbung und Retargeting, Analytics, E-Mail-Marketing, Konten, E-Commerce, eingebettete Medien, Chat, Session Replay. Und ob etwas einen sensiblen Bereich berührt: Gesundheit, Kinder oder Jugendliche, Finanzen, genauer Standort, alles, was ein geschütztes Merkmal offenbart. Sensible Bereiche ändern die Antwort in jeder Rechtsordnung.
4. Größe, für US-Recht. Ungefährer Jahresumsatz und Besuchervolumen nach Bundesstaat entscheiden, welche Staatsgesetze gelten. Einzelne Besucher mit einem Werbe-Cookie gelten als „Verbraucher“, sodass Schwellenwerte schneller erreicht werden, als Betreiber erwarten.
5. Welchen Zugriff Sie haben. Nur-Lese-öffentliche Website, Admin-Login, Code-Repository, Hosting oder SSH, Tag-Manager, Dashboard des Consent-Tools, Werbeplattform-Konten. Dies legt fest, wie tief das Audit gehen kann und ob Sie implementieren können.
6. Was der Benutzer davon erwartet. Nur Auditbericht oder auch Behebung und Verifizierung. Jede Messung, die sie sich nicht leisten können zu verlieren. Budget für kostenpflichtige Tools.

Wenn es noch keine zu scannende Website gibt (der Benutzer fragt nach einem Plan, einem Angebot oder einer Beratung und gibt keine URL an oder beschreibt die Website aus dem Gedächtnis): Überspringen Sie die Messung nicht, verschieben Sie sie. Behandeln Sie das, was Ihnen gesagt wurde, als Hypothese, schreiben Sie den Plan dagegen und machen Sie „Scan aus jeder Zielregion, um den Ausgangspunkt zu bestätigen“ zum ersten Schritt des Plans, wobei die Scanner-Befehle ausgefüllt werden. Geben Sie an, welche Teile des Plans von Fakten abhängen, die Sie nicht beobachtet haben.

Öffnen Sie dann references/jurisdictions.md und notieren Sie die Zielregime: für jede Zielgruppe das anwendbare Regime und die zwei oder drei Regeln, die die Feststellungen bestimmen werden. Geben Sie dies dem Benutzer in ein paar Zeilen vor dem Audit zurück. Wenn die Zielgruppe unbekannt ist oder weltweit, ist die Vorgabe striktes Opt-in für alle, gelockert nur für eine kurze Liste von Ländern, in denen die Rechtslage geklärt ist.

Phase 2: Audit

Befolgen Sie references/audit-playbook.md. Im Überblick:

1. Scannen Sie die Live-Website mit dem mitgelieferten Scanner. Er lädt die Website in einem sauberen Browser unter verschiedenen Szenarien (keine Interaktion, Ablehnen, Akzeptieren, Global Privacy Control, optional Widerruf) und zeichnet Cookies, Web Storage, Drittanbieter-Anfragen und Google-Consent-Signale in jeder Phase auf.

   # einmalige Einrichtung
   npm install --prefix <skill-dir>/scripts && npx --prefix <skill-dir>/scripts playwright install chromium
   
   node <skill-dir>/scripts/scan.mjs https://example.com --out ./scan-quick                    # Schnellcheck: Startseite + ein paar Links
   node <skill-dir>/scripts/scan.mjs https://example.com --coverage types --out ./scan-us       # Audit: jeder Seitentyp im Sitemap
   node <skill-dir>/scripts/scan.mjs https://example.com --coverage all --out ./scan-full       # jede Sitemap-URL (langsam)
   node <skill-dir>/scripts/scan.mjs https://example.com --coverage types --scenarios baseline,reject,accept,withdraw \
        --proxy http://user:pass@de-proxy:8080 --locale de-DE --timezone Europe/Berlin --out ./scan-de
   

   Verwenden Sie --coverage types für alles, was zu einem Bericht wird: Seitenvorlagen unterscheiden sich (Artikel betten Videos ein, Produktseiten laden Widgets, Kontaktseiten laden ein Captcha), und ein Scan der Startseite übersieht das meiste. Fügen Sie Warenkorb-, Checkout- und Dankesseiten manuell hinzu; sie sind nicht in Sitemaps.

   Lesen Sie zuerst die „Fakten“-Tabelle oben in summary.md, dann die Screenshots, dann die benötigten Details pro Szenario (auf werbelastigen Websites sind die Details lang; suchen Sie darin, anstatt sie ganz durchzulesen). Der Scanner meldet, von wo aus er ausgeführt wurde. Consent-Tools ändern das Verhalten je nach Besucherland, daher beschreibt ein Scan nur dieses Land. Scannen Sie aus jedem Zielregime (über einen Proxy oder VPN-Ausgang) oder geben Sie im Bericht klar an, welche Regime nicht beobachtet wurden. Präsentieren Sie niemals einen Scan von einer US-IP als Beleg für EU-Besucher.

2. Schauen Sie hinter den Browser, soweit Ihr Zugriff es erlaubt: wo jedes Tag injiziert wird (Theme, Plugin, Tag-Manager, fest codiert, Edge), wie das Consent-Tool konfiguriert ist, serverseitiges Tracking, das ein Browser-Scan nicht sehen kann, Caching und Skriptoptimierungs-Ebenen, die Dinge umordnen.

   Zwei Website-Typen benötigen mehr als den Standardlauf, und das Playbook deckt beide ab: Websites, deren Optimierer jedes Skript bis zur ersten Mausbewegung oder einem Leerlauf-Timer zurückhält (ein schneller Scan dieser sieht sauber aus, obwohl er es nicht ist), und US-amerikanische Opt-out-Seiten ohne Ablehnen-Button, bei denen die Frage ist, ob das Opt-out und GPC den gesamten Werbestapel erreichen. Wenn der Scanner eine Frage, von der der Auftrag abhängt, nicht beantworten kann, schreiben Sie eine kurze Sonde mit derselben Browser-Bibliothek und bewahren Sie sie bei den Beweisen auf.

3. Diagnostizieren Sie das bereits vorhandene Consent-Tool. Normalerweise ist eines installiert und halb eingerichtet. Finden Sie genau heraus, warum es versagt (das Playbook hat eine Entscheidungssequenz), denn die Behebung ist weitaus häufiger eine Reparatur als ein Austausch.

4. Überprüfen Sie die Papierseite: Datenschutzerklärung, Cookie-Richtlinie, erforderliche Links und Formulierungen, Formulare und deren Einwilligungssprache, Weg für Rechtsausübungsanfragen, Einwilligungsaufzeichnungen.

5. Schreiben Sie Feststellungen gegen die Zielregime. Jede Feststellung: was beobachtet wurde (mit Nachweis aus dem Scan), welche Regel für welche Zielgruppe verletzt wird, wie schwerwiegend, und die Behebung. Verwenden Sie references/report-template.md. Der Bericht hat zwei Ebenen: eine Zusammenfassung in einfacher Sprache, auf die ein Website-Betreiber reagieren kann, dann die technischen Details für den, der die Umsetzung vornimmt.

Halten Sie hier an, wenn der Auftrag nur das Audit umfasst. Ändern Sie während eines Audits nichts an einer Website.

Phase 3: Implementierung

Befolgen Sie references/implementation.md. Das Wesentliche:

• Vereinbaren Sie zuerst den Plan. Zeigen Sie dem Benutzer, was sich ändern wird, welche Messung sie verlieren oder behalten werden, welchen kostenpflichtigen Plan es benötigt, und holen Sie ein Ja ein. Das Entfernen oder Trennen eines Trackers ändert die Berichterstattung und Anzeigenleistung; das ist ihre Entscheidung, nicht Ihre.
• Arbeiten Sie an einem sicheren Ort. Staging, falls vorhanden. Auf Produktion: zuerst sichern, immer nur eine Sache ändern, wissen, wie man zurückrollt, und hinterlassen Sie niemals eine Website in einem Zustand, in dem das Banner etwas verspricht, was die Tags nicht tun.
• Beheben Sie in Abhängigkeitsreihenfolge: entfernen Sie Unbenutztes, etablieren Sie ein Consent-Tool als alleinigen Eigentümer für Einwilligungen, setzen Sie Consent-Standardwerte, bevor ein Tag geladen wird, trennen Sie jedes Tag und Embed über das Tool, schließen Sie Anbietersignale an (Consent Mode und den Rest), behandeln Sie GPC und US-Opt-out-Links, machen Sie den Widerruf funktionsfähig, aktualisieren Sie dann die Richtlinien, damit sie dem entsprechen, was die Website jetzt tut.
• Leeren Sie nach Änderungen jede Cache-Ebene (Seiten-Cache, CDN, Minify/Kombinieren von Bundles), sonst testen Sie die Website von gestern.

Phase 4: Verifizierung

Nichts ist behoben, bis ein frischer Scan es zeigt. Führen Sie den Scanner erneut mit denselben Szenarien und Standpunkten wie beim Audit aus und vergleichen Sie mit dem Audit-Lauf. references/testing-tools.md enthält die vollständige Matrix; das Minimum für die Freigabe ist:

• Opt-in-Zielgruppen: null nicht notwendige Cookies und null Tracker-Anfragen vor einer Auswahl und nach Ablehnung, auch nach echter Maus- und Scrolleingabe; Ablehnen auf der ersten Ebene mit gleichwertiger Hervorhebung; Akzeptieren lädt die Tags tatsächlich; Widerrufen stoppt sie und entfernt Erstanbieter-Tracker-Cookies; die Auswahl bleibt über Seiten hinweg bestehen und wird nicht erneut erfragt.
• Opt-out-Zielgruppen: der Opt-out-Link und GPC stoppen jeweils Verkaufs-/Weitergabe-/zielgerichtete Werbe-Tags ohne weitere Klicks; Besucher in Kalifornien sehen eine Bestätigung, dass das Signal respektiert wurde; nichts feuert vor Einwilligung auf Seiten, die sensible Daten berühren.
• Überall: Consent-Signale auf ausgehenden Google-Treffern stimmen mit dem vom Besucher gewählten Zustand überein; die Ergebnisse sind auf gecachten und ungecachten Ladevorgängen, auf Mobilgeräten und auf den relevanten Seitentypen (Produkt, Checkout, Dankesseite, Formulare) gleich; die Cookie-Richtlinie listet das auf, was der Scan findet.

Berichten Sie, was bestanden hat, was fehlgeschlagen ist und was nicht getestet werden konnte (z. B. eine Region, für die Sie keinen Standpunkt hatten, oder serverseitige Ereignisse, auf die Sie keinen Zugriff hatten). Ein nicht getesteter Check wird als nicht getestet gemeldet, niemals als bestanden.

Arbeitsnotizen

• Nachweis vor Behauptung. Nennen Sie den Cookie-Namen, den Anfrage-Host, den Consent-Parameter, den Screenshot. Eine Feststellung ohne Nachweis ist eine Meinung.
• Unbekannte Cookies und Hosts sind zu klärende Feststellungen, keine Durchwink-Fälle. Identifizieren Sie sie (wer setzt sie, wofür) oder listen Sie sie als ungeklärt auf.
• Schweregrad folgt der tatsächlichen Exposition: wer die Zielgruppe ist, welche Daten betroffen sind, wie sichtbar der Fehler ist, wie aktiv diese Regel durchgesetzt oder verklagt wird. Ein Werbe-Pixel, das vor Einwilligung für französische Besucher oder auf einer US-Gesundheitsseite feuert, ist kritisch. Ein fehlender Impressumslink nicht.
• Behalten Sie die Messung des Benutzers bei, wo das Gesetz es erlaubt. Compliance bedeutet nicht, Analytics zu löschen. Bevorzugen Sie die Option, die die Regel erfüllt und die nützlichsten Daten behält: mit Einwilligung getrennte Tags, Consent Mode, cookielose oder ausgenommene Analytics-Konfiguration, regionsspezifisches Verhalten. Erklären Sie den Kompromiss und lassen Sie den Benutzer wählen.
• Sagen Sie, was Sie nicht überprüft haben. Mobile Apps, E-Mail-Tracking-Pixel, Offline-Datenaustausch, Verträge mit Anbietern und Unterlagen zum internationalen Datentransfer sind Teil der Datenschutz-Compliance und größtenteils außerhalb eines Website-Scans. Nennen Sie die, die relevant erscheinen, damit nicht angenommen wird, sie seien erledigt.