Borlabs Cookie (WordPress): Reject-Pfad leakt Tracker
Borlabs Cookie ist im DACH-WordPress-Markt sehr verbreitet. Wenn der dsgvochecker.de-Reject-Pfad-Test trotz Banner Tracker meldet, liegt es fast immer an einer dieser vier Ursachen — alle WordPress-spezifisch, alle lösbar im Borlabs-Backend.
TL;DR: Die vier häufigsten Reject-Pfad-Lecks bei Borlabs Cookie: (1) Tracker-Skript nicht als Borlabs-Cookie-Eintrag registriert, (2) Cache liefert ungeblockte Version aus, (3) iFrame-Embeds umgehen den Content-Blocker, (4) Theme-Skripte außerhalb von wp_enqueue_script.
Ursache 1: Ist der Tracker als Borlabs-Cookie-Eintrag registriert?
Borlabs blockt nur, was im Backend unter Cookies konfiguriert ist. Plugin-Skripte ohne Eintrag laufen ungebremst.
Borlabs blockt nur Tracker, die im Backend unter Cookies als eigener Eintrag angelegt sind. Wenn ein Plugin (oder die functions.php des Themes) Tracker-Skripte direkt über wp_enqueue_script oder als Inline-<script> einfügt, sieht Borlabs sie nicht und kann sie nicht abhängig vom Consent steuern. Sie laufen vor und nach Reject.
Fix: Im Borlabs-Backend unter Cookies alle aktiven Tracker prüfen. Für jeden externen Service (Google Analytics, Meta Pixel, Hotjar, etc.) muss ein Cookie-Eintrag existieren mit Opt-in-Code (was beim Consent ausgeführt wird) und Fallback-Code (oft leer). Wenn ein Plugin Tracker enqueued, das Plugin-Skript-Handle zusätzlich unter Settings → JavaScript als zu blockendes Skript eintragen.
Quelle: Borlabs KB — Setting up Borlabs Cookie
Ursache 2: Liefert ein Cache-Plugin eine ungeblockte Version aus?
Cache-Plugins speichern Output bevor Borlabs filtert. Cache nach jeder Änderung komplett leeren.
Borlabs filtert WordPress-Output zur Laufzeit. Wenn ein Caching-Plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache) eine Seite gecacht hat bevor der Borlabs-Filter wirkte, liefert das Cache eine Version mit ungeblockten Tracker-Skripten aus — und das Banner wird später via JavaScript injected, aber die Skripte sind längst geladen.
Fix: Im Caching-Plugin den gesamten Cache löschen nach jeder Borlabs-Konfigurationsänderung. Borlabs hat dazu eine Hook-Integration für WP Rocket, LiteSpeed und Cache Enabler — im Borlabs-Backend unter Settings → General → Compatibility die passende Option aktivieren. Zusätzlich prüfen, dass der Caching-Plugin Browser-Cache Header nicht zu lange setzt.
Quelle: Borlabs KB — Common Issues
Ursache 3: Umgehen iFrame-Einbettungen den Content-Blocker?
YouTube/Vimeo/Maps brauchen den Borlabs-Wrapper. Direkt eingefügte iFrames laden ohne Consent.
Borlabs hat einen separaten Content-Blocker für iFrames (YouTube, Vimeo, Google Maps, Facebook-Embeds). Wenn ein Plugin oder ein Gutenberg-Block iFrames direkt einfügt, ohne den Borlabs-Content-Blocker-Wrapper, lädt das iFrame — und damit alle externen Cookies des eingebetteten Dienstes — ohne Consent.
Fix: Im Borlabs-Backend unter Content-Blocker für jeden eingebetteten Dienst einen Content-Blocker-Eintrag prüfen oder anlegen. Im Editor iFrame-Einbettungen entweder via Borlabs-Shortcode [borlabs-cookie type="content-blocker" id="youtube"]...[/borlabs-cookie] oder via Borlabs-Block einbinden. Direkt eingefügte <iframe>-Tags ohne Wrapper sind das Hauptproblem.
Quelle: Borlabs KB — Setting up Borlabs Cookie (Content Blocker)
Ursache 4: Lädt das Theme Tracker außerhalb von wp_enqueue_script?
Page-Builder injizieren oft Tracker direkt über Theme-Optionen. Borlabs sieht solche Skripte nicht.
Manche Themes (z.B. komplette Page-Builder wie Elementor Pro, Avada, Divi) bringen eigene Performance- oder Marketing-Skripte mit, die direkt über Theme-Optionen oder Custom-Code-Felder eingebunden werden — außerhalb des klassischen wp_enqueue_script-Pfads. Borlabs sieht diese nicht, weil sie nicht als WordPress-Skript registriert sind.
Fix: Im Theme/Page-Builder-Backend nach Custom JavaScript, Tracking Code, Header/Footer Scripts Optionen suchen. Tracker-Code aus diesen Theme-Feldern entfernen und stattdessen als Borlabs-Cookie-Eintrag mit Opt-in-Code anlegen. Wenn das Theme das nicht erlaubt: einen JavaScript-Blocker-Eintrag in Borlabs anlegen, der das spezifische Theme-Skript-Handle blockt.
Quelle: Borlabs KB — JavaScript Blocker
Wie verifiziere ich, dass der Fix wirkt?
Cache komplett leeren, dann erneut scannen. Wenn der Reject-Pfad sauber ist, sind Sie DSGVO-konform.
Nach jeder Änderung im Borlabs-Backend: Caching-Plugin-Cache komplett löschen (das ist bei WordPress + Borlabs der häufigste Schritt der vergessen wird), Browser-Cache leeren, und einen erneuten Reject-Pfad-Scan auf dsgvochecker.de starten.
Stand: 29.04.2026 · Quellen aus borlabs.io sind bei den jeweiligen Punkten verlinkt.