Cookie-Banner Probleme beheben

Ein funktionierendes Cookie-Banner ist mehr als nur ein Popup. Es muss technisch einwandfrei arbeiten und gleichzeitig die rechtlichen Anforderungen der DSGVO und des TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, ehemals TTDSG) erfüllen. Das klingt kompliziert, lässt sich aber auf einige Kernfunktionen herunterbrechen.

Technisch muss Ihr Cookie-Banner folgendes leisten: Es blockiert alle nicht-notwendigen Cookies und Tracking-Skripte, bis der Nutzer aktiv einwilligt. Es speichert die Entscheidung des Nutzers zuverlässig, damit das Banner nicht bei jedem Seitenaufruf erneut erscheint. Und es ermöglicht das nachträgliche Ändern der Einwilligung, ohne dass der Nutzer dafür alle Browser-Cookies löschen muss.

Rechtlich muss Ihr Cookie-Banner diese Anforderungen erfüllen: Gleichwertige "Akzeptieren"- und "Ablehnen"-Buttons, keine vorangekreuzten Checkboxen, transparente Information über verwendete Cookies und deren Zwecke, sowie die Möglichkeit zum jederzeitigen Widerruf der Einwilligung. Der Bundesgerichtshof hat 2020 im Planet49-Urteil (Az. I ZR 7/16) eindeutig festgestellt: Cookies für Werbung, Analyse oder Profiling dürfen nur nach einer aktiven und informierten Einwilligung gesetzt werden.

Bevor Sie mit der Fehlersuche beginnen, sollten Sie das Problem genau identifizieren. "Mein Cookie-Banner funktioniert nicht" kann vieles bedeuten, und die richtige Diagnose spart Zeit bei der Behebung. Hier sind die häufigsten Symptome und was sie bedeuten:

• Banner blockiert die ganze Seite: Das Banner legt sich als unsichtbare Schicht über die Website. Nichts ist mehr klickbar, auch wenn das Banner selbst nicht sichtbar ist. Ursache: Z-Index-Probleme oder JavaScript-Fehler.
• Banner lässt sich nicht schließen: Der "Akzeptieren"- oder "Ablehnen"-Button reagiert nicht. Der Nutzer steckt fest. Ursache: JavaScript-Konflikte mit anderen Plugins oder Theme-Problemen.
• Banner erscheint nicht: Das Banner sollte angezeigt werden, bleibt aber unsichtbar. Tracking läuft möglicherweise ohne Einwilligung. Ursache: Cache-Probleme, Plugin-Konflikte oder fehlerhafte Konfiguration.
• Cookies werden trotz Ablehnung gesetzt: Der Nutzer lehnt ab, aber Analytics und Marketing-Cookies werden dennoch geladen. Ursache: Fehlerhaftes Script-Blocking oder falsche Cookie-Kategorisierung.
• Banner erscheint bei jedem Besuch: Trotz Einwilligung zeigt sich das Banner bei jedem Seitenaufruf erneut. Ursache: Die Consent-Entscheidung wird nicht gespeichert, meist durch Cache-Konflikte oder REST-API-Probleme.

Eines der frustrierendsten Cookie-Banner Probleme: Die Website lädt, aber nichts ist mehr klickbar. Links, Buttons, Formulare, alles reagiert nicht. Der Grund ist meist ein unsichtbares Overlay, das sich über die gesamte Seite legt. Das Cookie-Banner zeigt zwar seine Buttons an, aber eine fehlerhafte CSS-Schicht blockiert alles darunter.

Ursache 1: Z-Index-Konflikt. Der Z-Index bestimmt, welche Elemente im Vordergrund liegen. Wenn das Cookie-Banner einen sehr hohen Z-Index hat, aber sein Hintergrund-Overlay falsch konfiguriert ist, kann es die gesamte Seite blockieren. Bei WordPress tritt das besonders häufig nach Theme-Updates auf, wenn CSS-Werte überschrieben werden. Bei statischen Websites passiert es oft, wenn neue Komponenten (Modals, Dropdowns, Sticky-Header) mit hohem Z-Index hinzugefügt werden und das Banner-Overlay überlagern. Ein technisches SEO-Audit kann solche Konflikte frühzeitig aufdecken.

Ursache 2: JavaScript-Fehler. Das Banner-Script bricht ab, bevor es vollständig geladen ist. Das Overlay bleibt aktiv, aber die Buttons funktionieren nicht. Öffnen Sie die Browser-Konsole mit F12 und prüfen Sie auf rote Fehlermeldungen. Häufig sehen Sie Meldungen wie "Uncaught TypeError" oder "Uncaught SyntaxError".

Lösung für WordPress: Deaktivieren Sie temporär alle anderen Plugins und wechseln Sie zu einem Standard-Theme wie Twenty Twenty-Four. Wenn das Banner dann funktioniert, liegt ein Plugin- oder Theme-Konflikt vor. Aktivieren Sie die Plugins einzeln wieder, bis Sie den Übeltäter finden. Bei Z-Index-Problemen können Sie in den Cookie-Plugin-Einstellungen oft den Z-Index manuell erhöhen.

Lösung für statische Websites (HTML/CSS/JS): Öffnen Sie die Browser-Entwicklertools (F12), wechseln Sie zum Elements-Tab und suchen Sie das Overlay-Element (oft mit Klassen wie "cookie-overlay" oder "consent-backdrop"). Prüfen Sie dessen CSS: Hat es position: fixed, width: 100%, height: 100% und einen hohen z-index? Setzen Sie testweise pointer-events: none auf das Overlay oder reduzieren Sie den Z-Index. Wenn das Problem nach Schließen des Banners bestehen bleibt, fehlt vermutlich JavaScript-Code, der das Overlay entfernt. Prüfen Sie, ob Ihr Close-Button-Handler das Overlay-Element korrekt per display: none oder remove() ausblendet.

Sie klicken auf "Alle akzeptieren" oder "Ablehnen", aber nichts passiert. Das Banner bleibt hartnäckig stehen und blockiert die Nutzung Ihrer Website. Dieses Problem ist fast immer auf JavaScript-Konflikte zurückzuführen.

Häufigste Ursache: Konflikte mit anderen JavaScript-Bibliotheken. Wenn mehrere Scripte dieselben Variablennamen verwenden oder in einer falschen Reihenfolge geladen werden, kann das Cookie-Banner-Script nicht mehr richtig funktionieren. Bei WordPress laden Themes und Plugins eigene JavaScript-Dateien, besonders häufig sind Konflikte mit jQuery-Versionen oder mit Caching-Plugins, die JavaScript zusammenfassen. Bei statischen Websites entstehen ähnliche Probleme durch Build-Tools, die Scripts bündeln, oder durch manuell eingebundene Bibliotheken, die sich gegenseitig überschreiben.

Diagnose: Öffnen Sie die Browser-Entwicklertools mit F12 und wechseln Sie zur Konsole. Laden Sie die Seite neu und achten Sie auf rote Fehlermeldungen. Typische Hinweise sind "$ is not defined" (jQuery-Konflikt), "Uncaught ReferenceError" oder Fehler, die den Namen Ihres Cookie-Plugins enthalten.

Lösungsansätze für WordPress: Leeren Sie zunächst alle Caches, sowohl den Browser-Cache als auch Plugin-Caches wie WP Rocket oder LiteSpeed Cache. Deaktivieren Sie JavaScript-Optimierungen in Ihrem Caching-Plugin (Optionen wie "JavaScript zusammenfassen" oder "Verzögert laden"). Wenn das nicht hilft, schließen Sie das Cookie-Plugin von der Optimierung aus, meist finden Sie diese Option in den erweiterten Einstellungen des Caching-Plugins.

Lösungsansätze für statische Websites: Leeren Sie den Browser-Cache und testen Sie im Inkognito-Modus. Falls Sie einen Build-Prozess nutzen (Webpack, Vite, Gulp), prüfen Sie, ob JavaScript-Dateien korrekt gebündelt werden und keine Abhängigkeiten fehlen. Bei CDN-Nutzung (Cloudflare, Bunny) leeren Sie auch dort den Cache. Prüfen Sie in der Browser-Konsole, ob alle Script-Dateien geladen werden (Network-Tab, Filter auf JS). Häufig liegt das Problem an der Ladereihenfolge: Das Cookie-Banner-Script muss nach seinen Abhängigkeiten (z.B. jQuery) geladen werden. Nutzen Sie defer statt async bei Script-Tags, um die Ausführungsreihenfolge zu garantieren.

Das Cookie-Banner sollte bei neuen Besuchern erscheinen, zeigt sich aber nicht. Das ist aus zwei Gründen problematisch: Erstens könnten Tracking-Cookies ohne Einwilligung gesetzt werden (DSGVO-Verstoß), zweitens bemerken Sie das Problem oft erst spät, weil Sie selbst schon eingewilligt haben.

Ursache 1 (WordPress): Aggressives Caching. Ihr Caching-Plugin speichert die Seite inklusive der Information "Nutzer hat bereits eingewilligt". Neue Besucher bekommen dann die gecachte Version ohne Banner. Lösung: Schließen Sie Cookie-bezogene Seiten vom Cache aus oder aktivieren Sie die "Cache-per-Cookie"-Funktion Ihres Caching-Plugins.

Ursache 1 (Statische Websites): Aggressives CDN- oder Server-Caching. Wenn Sie Cloudflare, Bunny CDN oder Server-seitiges Caching (Varnish, nginx FastCGI Cache) nutzen, kann die gecachte Seite das Banner-Script oder dessen Zustand falsch ausliefern. Lösung: Stellen Sie sicher, dass das Cookie-Banner vollständig client-seitig arbeitet und der Consent-Status im localStorage oder einem Cookie gespeichert wird, nicht im HTML. Schließen Sie die Banner-Logik von der Cache-Optimierung aus.

Ursache 2 (WordPress): Plugin ist deaktiviert oder fehlerhaft konfiguriert. Nach WordPress-Updates oder Plugin-Updates kann das Cookie-Plugin deaktiviert worden sein. Prüfen Sie unter Plugins, ob das Cookie-Plugin aktiv ist. Kontrollieren Sie auch die Plugin-Einstellungen, ob das Banner für alle Seiten aktiviert ist.

Ursache 2 (Statische Websites): Script wird nicht geladen. Prüfen Sie im Network-Tab der Browser-Entwicklertools (F12), ob die JavaScript-Datei des Cookie-Banners überhaupt geladen wird. Häufige Fehler: falscher Pfad zur JS-Datei, Script wurde beim Build-Prozess nicht inkludiert, oder ein Adblocker/Privacy-Tool blockiert das Script. Prüfen Sie auch die Konsole auf Fehlermeldungen.

Ursache 3: Browser-Erweiterungen. Erweiterungen wie "I don't care about cookies", "Consent-O-Matic" oder Werbeblocker können Cookie-Banner ausblenden. Das Problem: Sie als Betreiber sehen kein Banner, Ihre Besucher aber schon, oder umgekehrt. Testen Sie immer im Inkognito-Modus ohne Erweiterungen.

Test-Strategie: Löschen Sie alle Cookies Ihrer Website im Browser, öffnen Sie ein neues Inkognito-Fenster, und rufen Sie Ihre Website auf. Das Banner muss erscheinen. Wenn nicht, liegt ein echtes Problem vor.

Der Nutzer klickt auf "Ablehnen", aber Google Analytics, Facebook Pixel und andere Tracking-Dienste werden dennoch geladen. Das ist einer der schwerwiegendsten Cookie-Banner Fehler, denn er stellt einen direkten DSGVO-Verstoß dar. Datenschutzbehörden können hierfür Bußgelder verhängen.

Ursache 1 (WordPress): Dienste sind nicht richtig konfiguriert. Viele Cookie-Plugins blockieren nur Cookies, die sie kennen. Wenn Sie ein neues Tracking-Tool hinzufügen, müssen Sie es manuell dem Cookie-Plugin hinzufügen und der richtigen Kategorie (Marketing, Statistik, etc.) zuordnen. Vergessen Sie das, wird das Tool ohne Einwilligung geladen.

Ursache 1 (Statische Websites): Script-Blocking fehlt oder ist fehlerhaft. Bei selbst implementierten Cookie-Bannern müssen Sie das Blocking manuell umsetzen. Tracking-Scripts dürfen nicht im HTML stehen, sondern müssen per JavaScript erst nach Einwilligung eingefügt werden. Typischer Fehler: Das Script steht direkt im <head> und wird sofort ausgeführt. Lösung: Speichern Sie Scripts als type="text/plain" mit einem data-Attribut (z.B. data-category="analytics") und aktivieren Sie sie erst nach Consent per JavaScript.

Ursache 2 (WordPress): Hardcodierte Scripts im Theme. Manche Themes oder Page Builder haben Google Analytics oder andere Tracking-Codes direkt im Code eingebettet. Diese werden vom Cookie-Plugin nicht erkannt und umgehen die Einwilligung. Prüfen Sie Ihre Theme-Einstellungen und entfernen Sie dort eingebettete Tracking-Codes. Fügen Sie alle Tracking-Dienste stattdessen über das Cookie-Plugin hinzu.

Ursache 2 (Statische Websites): Scripts an mehreren Stellen eingebunden. Durchsuchen Sie Ihren gesamten Code nach Tracking-Snippets. Google Analytics kann im <head>, vor </body> oder in separaten JS-Dateien stecken. Nutzen Sie grep -r "gtag\|analytics\|fbq\|pixel" . um alle Vorkommen zu finden. Alle Tracking-Scripts müssen zentral über Ihre Consent-Logik gesteuert werden.

Ursache 3 (WordPress): Content-Blocker greift nicht. Eingebettete YouTube-Videos, Google Maps oder Social-Media-Buttons setzen eigene Cookies. Ihr Cookie-Plugin muss diese Inhalte blockieren und durch Platzhalter ersetzen, bis der Nutzer einwilligt. Diese "Content Blocker"-Funktion ist bei manchen Plugins nur in der Premium-Version verfügbar oder muss manuell konfiguriert werden.

Ursache 3 (Statische Websites): Iframes laden ohne Einwilligung. YouTube, Google Maps und Social-Media-Embeds laden über <iframe>-Tags und setzen sofort Cookies. Lösung: Ersetzen Sie die Iframes durch Platzhalter-Divs mit Vorschaubild und "Video laden"-Button. Erst nach Klick (und vorheriger Cookie-Einwilligung) wird das echte Iframe per JavaScript eingefügt. Bibliotheken wie "tarteaucitron.js" oder "klaro" bieten diese Funktionalität auch für statische Websites.

Sie haben eingewilligt, aber das Cookie-Banner erscheint bei jedem Seitenaufruf erneut. Das ist nicht nur nervig für Besucher, sondern auch ein technisches Problem: Die Consent-Entscheidung wird nicht korrekt gespeichert. Ohne Speicherung ist das Banner nutzlos, denn Tracking-Cookies werden vermutlich ebenfalls nicht korrekt blockiert.

Ursache 1 (WordPress): REST API nicht erreichbar. Viele moderne Cookie-Plugins nutzen die WordPress REST API, um die Einwilligung zu speichern. Wenn diese API blockiert ist, durch Security-Plugins, Firewall-Regeln oder Server-Konfiguration, kann die Entscheidung nicht gespeichert werden. Testen Sie die REST API, indem Sie /wp-json/ an Ihre Domain anhängen. Sie sollten eine JSON-Antwort sehen, keine Fehlermeldung.

Ursache 1 (Statische Websites): localStorage oder Cookie wird nicht gespeichert. Die meisten Cookie-Banner für statische Websites speichern den Consent im localStorage oder als Cookie. Prüfen Sie in den DevTools (F12 → Application → Local Storage bzw. Cookies), ob nach dem Akzeptieren ein Eintrag erstellt wird. Häufige Fehler: JavaScript-Fehler verhindern das Speichern, oder der Code zum Setzen des Cookies/localStorage-Eintrags wird nie ausgeführt. Prüfen Sie die Konsole auf Fehlermeldungen.

Ursache 2: Cookie wird nicht gesetzt oder sofort gelöscht. Das Consent-Cookie kann von Security-Tools, CDNs oder Server-Konfigurationen blockiert werden. Bei WordPress können Security-Plugins wie Wordfence die Ursache sein. Bei statischen Websites prüfen Sie, ob Ihre Content Security Policy (CSP) das Setzen von Cookies erlaubt. Auch eine falsche Cookie-Domain-Einstellung kann das Problem verursachen: Wenn Ihre Website unter www.domain.de erreichbar ist, das Cookie aber für domain.de gesetzt wird, funktioniert die Zuordnung nicht.

Ursache 3 (WordPress): Caching-Probleme. Wenn Ihre Seiten gecacht werden, aber das Consent-Cookie nicht berücksichtigt wird, sehen alle Besucher die gecachte Version ohne ihre persönliche Entscheidung. Die meisten modernen Caching-Plugins erkennen Consent-Cookies automatisch, aber bei älteren Versionen oder falscher Konfiguration kann es zu Problemen kommen.

Ursache 3 (Statische Websites): Banner prüft Consent-Status nicht. Ihr Banner-Script muss beim Laden prüfen, ob bereits ein Consent vorliegt. Typischer Code-Fehler: Das Banner wird immer angezeigt, ohne vorher localStorage.getItem('cookieConsent') oder document.cookie zu prüfen. Der Check muss ganz am Anfang der Banner-Logik stehen, bevor das Banner-Element sichtbar gemacht wird.

Lösung für WordPress: Leeren Sie zunächst alle Caches: Browser-Cache, WordPress-Page-Cache, Object-Cache (Redis/Memcached) und CDN-Cache (Cloudflare, Bunny). Prüfen Sie dann, ob Security-Plugins wie Wordfence oder Sucuri die REST API blockieren. In den Plugin-Einstellungen finden Sie oft Optionen zum Whitelisten bestimmter Endpunkte.

Lösung für statische Websites: Leeren Sie Browser-Cache und CDN-Cache. Prüfen Sie im JavaScript-Code, ob der Consent-Check korrekt implementiert ist. Testen Sie mit console.log(localStorage.getItem('cookieConsent')) in der Browser-Konsole, ob der Wert nach Einwilligung gespeichert wurde. Falls Sie Cookies statt localStorage nutzen, prüfen Sie das expires-Attribut: Ohne Ablaufdatum wird das Cookie beim Schließen des Browsers gelöscht.

Wenn Ihr Cookie-Banner nicht richtig funktioniert, hilft eine systematische Prüfung, die Ursache zu finden, bevor es Besuchern oder Datenschutzbehörden auffällt. Ich empfehle eine Kombination aus manuellen Tests und automatischen Scannern.

Schritt 1: Manueller Test im Inkognito-Modus. Öffnen Sie ein neues Inkognito-Fenster ohne Browser-Erweiterungen. Rufen Sie Ihre Website auf. Das Banner muss erscheinen. Klicken Sie auf "Ablehnen" und prüfen Sie in den Entwicklertools (F12 > Application > Cookies), ob wirklich nur technisch notwendige Cookies gesetzt wurden. Akzeptieren Sie danach und prüfen Sie erneut.

Schritt 2: Consent-Speicherung testen. Willigen Sie ein, schließen Sie den Browser komplett, öffnen Sie ihn wieder und besuchen Sie Ihre Website. Das Banner sollte nicht erneut erscheinen. Wenn es doch erscheint, wird die Consent-Entscheidung nicht gespeichert.

Schritt 3: Online-Scanner verwenden. Tools wie der Cookiebot Scanner oder der CCM19-Scanner analysieren Ihre Website automatisch und listen alle gefundenen Cookies auf. Sie zeigen auch, welche Cookies vor der Einwilligung gesetzt werden (was ein Fehler wäre). Die Basisversion dieser Scanner ist meist kostenlos.

Schritt 4: Verschiedene Browser testen. Cookie-Banner können sich in Chrome, Firefox, Safari und Edge unterschiedlich verhalten. Testen Sie zumindest in Chrome und Firefox. Achten Sie besonders auf Safari, das strengere Cookie-Richtlinien hat und manche Consent-Cookies blockieren kann.

Die Wahl des richtigen Cookie-Plugins kann verhindern, dass "Cookie-Banner funktioniert nicht" zur wiederkehrenden Sorge wird. Hier sind die drei führenden Optionen für WordPress im Jahr 2026, mit ihren Stärken und Schwächen.

Real Cookie Banner ist der aktuelle Testsieger vieler Vergleiche. Das Plugin bietet nach Herstellerangaben über 150 Service-Vorlagen, einen automatischen Cookie-Scanner und eine Live-Vorschau für Design-Änderungen. Das Plugin erfüllt die WCAG 2.2 Level AA Richtlinien für Barrierefreiheit, was seit dem BFSG wichtiger denn je ist. Die Einrichtung ist auch für Anfänger machbar. Preis: 59 Euro pro Jahr und Website (Stand Januar 2026). Eine kostenlose Version existiert nicht.

Borlabs Cookie richtet sich an professionelle Anwender, die maximale Kontrolle benötigen. Seit Version 3.0 bietet auch Borlabs einen automatischen Scanner, der die zuvor aufwendige manuelle Einrichtung deutlich vereinfacht. Die Dokumentation ist exzellent, der Support reaktionsschnell. Preis: 49 Euro pro Jahr und Website (Stand Januar 2026).

Complianz bietet als einziges dieser Plugins eine kostenlose Basisversion. Diese reicht für einfache Websites ohne komplexe Tracking-Setups aus. Stärke von Complianz ist die Abdeckung verschiedener Datenschutzgesetze weltweit (DSGVO, CCPA, LGPD und weitere). Allerdings ist die deutsche Übersetzung nicht immer perfekt. Premium-Version: ab 59 Euro pro Jahr (Stand Januar 2026).

Meine Empfehlung: Für professionelle Unternehmenswebsites empfehle ich Real Cookie Banner oder Borlabs Cookie. Die jährlichen Kosten sind gering im Vergleich zum Risiko eines DSGVO-Verstoßes. Für private Blogs oder sehr einfache Websites kann die kostenlose Version von Complianz ausreichen.

Alternativen für statische Websites (ohne WordPress): Für HTML/CSS/JS-Websites ohne CMS gibt es ebenfalls bewährte Lösungen. Klaro ist eine Open-Source-Bibliothek mit klarem Design und guter Dokumentation. Tarteaucitron.js bietet vorkonfigurierte Dienste für Google Analytics, YouTube und viele weitere. Cookieconsent von Osano ist leichtgewichtig und einfach anzupassen. Alle drei sind kostenlos, erfordern aber technisches Verständnis für die Einrichtung. Alternativ bieten kommerzielle Dienste wie Usercentrics, Cookiebot oder Consentmanager gehostete Lösungen, die auch ohne WordPress funktionieren.

Ein technisch funktionierendes Cookie-Banner ist nur die halbe Miete. Es muss auch die rechtlichen Anforderungen erfüllen. Die Datenschutzkonferenz (DSK) hat in ihrer Orientierungshilfe von 2021 kritisiert, dass viele Cookie-Banner intransparent gestaltet sind und Nutzer durch "Dark Patterns" zur Einwilligung drängen. Hier ist eine Checkliste für ein rechtssicheres Banner:

• Gleichwertige Buttons: "Akzeptieren" und "Ablehnen" müssen gleichwertig gestaltet sein. Gleiche Größe, ähnliche Farbgebung, gleichwertige Position. Ein kleiner "Ablehnen"-Link unter einem großen grünen "Akzeptieren"-Button ist nicht konform.
• Keine Vorauswahl: Checkboxen für nicht-notwendige Cookies dürfen nicht vorangekreuzt sein. Der Nutzer muss aktiv auswählen, welche Cookies er erlaubt.
• Transparente Information: Der Nutzer muss erfahren, welche Cookies und Tools eingesetzt werden, zu welchen Zwecken, von welchen Anbietern, und wie lange die Daten gespeichert werden.
• Widerrufsmöglichkeit: Die Einwilligung muss jederzeit widerrufbar sein, und zwar so einfach wie die Erteilung. Ein Link im Footer oder ein kleines Icon in der Ecke reichen aus.
• Echtes Blocking: Cookies und Tracking-Scripts dürfen erst nach der Einwilligung geladen werden, nicht davor. Das technische Blocking muss tatsächlich funktionieren.