Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Borlabs Cookie blockiert Google Analytics nicht: Ursachen und Lösung

    · Weswegen-Redaktion
    DSGVO

    Sie haben Borlabs Cookie eingerichtet, der Consent-Dialog steht, und trotzdem feuert Google Analytics schon beim ersten Seitenaufruf, bevor jemand auf “Akzeptieren” geklickt hat. Das ist ein echtes DSGVO-Risiko, denn ohne vorherige Einwilligung dürfen keine Statistik-Cookies gesetzt und keine Tracking-Requests gesendet werden. In den meisten Fällen liegt es nicht an einem Bug im Plugin, sondern daran, dass Analytics an Borlabs vorbei geladen wird. Sie erfahren hier, wie Sie das in fünf Minuten mit den Browser-Entwicklertools beweisen, wo die Ursache typischerweise sitzt und wie Sie GA sauber hinter die Einwilligung bekommen.

    Zuerst: Feuert Google Analytics wirklich vor der Einwilligung?

    Bevor Sie irgendetwas umstellen, verschaffen Sie sich einen belastbaren Befund. Öffnen Sie Ihre Website in einem frischen Inkognito-Fenster (kein zuvor gesetzter Consent-Cookie) und drücken Sie F12, um die Entwicklertools zu öffnen. Wechseln Sie in den Reiter Network und filtern Sie nach collect.

    Laden Sie die Seite neu, ohne den Cookie-Banner zu bestätigen, und beobachten Sie:

    • GA4 sendet an www.google-analytics.com/g/collect bzw. region1.google-analytics.com/g/collect.
    • Zusätzlich lädt oft googletagmanager.com/gtag/js?id=G-XXXXXXX oder googletagmanager.com/gtm.js.

    Sehen Sie diese Requests vor dem Klick auf “Akzeptieren”, wird Analytics tatsächlich nicht blockiert. Erscheinen sie erst nach der Einwilligung, ist alles korrekt und das vermeintliche Problem war nur ein bereits gesetzter Consent-Cookie aus einem früheren Besuch.

    Häufigste Ursache: Analytics ist fest im Code verdrahtet

    Borlabs Cookie kann nur blockieren, was über Borlabs ausgeliefert wird. Wenn der Google-Tag direkt im Theme-Header, in der functions.php, über einen Header-Injection-Slot oder über ein separates Plugin geladen wird, hat Borlabs keinen Zugriff darauf und der Consent-Dialog wird zur reinen Dekoration.

    Prüfen Sie deshalb, ob eine dieser Quellen den Tag einbaut:

    • ein direkt eingefügtes gtag.js-Snippet im Theme (häufig in header.php oder über Theme-Optionen wie “Custom Code / Header Scripts”)
    • Google Site Kit, MonsterInsights, GA Google Analytics, Analytify oder ähnliche Analytics-Plugins
    • ein Header-/Footer-Scripts-Plugin (z. B. “Insert Headers and Footers”)
    • ein Page-Builder mit eigenem Custom-Code-Feld (Elementor, Divi)

    Den Tag aus der Fremdquelle entfernen

    Deaktivieren Sie die doppelte Quelle vollständig. Wenn Sie Google Site Kit nur für Analytics nutzen, schalten Sie dort das Analytics-Modul ab oder deinstallieren Sie das Plugin. Entfernen Sie hartcodierte gtag-Snippets aus dem Theme. Ziel ist, dass nur noch Borlabs über den Tag entscheidet.

    Analytics über Borlabs als Service einbinden

    Legen Sie in Borlabs einen Service für Google Analytics an (in den älteren 2.x-Versionen “Cookie” genannt, ab 3.x “Service”). Borlabs bringt dafür eine fertige Vorlage mit. Ordnen Sie den Service der Gruppe Statistik zu, nicht den essenziellen Cookies. Tragen Sie im Opt-in-Code den Standard-GA4-Tag ein:

    <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

    Ersetzen Sie G-XXXXXXXXXX durch Ihre Mess-ID. Dieser Code wird jetzt erst ausgeführt, wenn der Besucher der Gruppe Statistik zustimmt.

    Der Script Blocker: die Phrasen müssen wirklich passen

    Damit vorhandene Skripte automatisch geblockt werden, arbeitet Borlabs mit dem Script Blocker. Er sucht im ausgelieferten HTML nach Textbausteinen (“Blocked Phrases”) und neutralisiert passende <script>-Tags, bis eine Einwilligung vorliegt. Blockiert Borlabs Analytics nicht, fehlt oft schlicht eine passende Phrase.

    Für GA4 und den Google-Tag sollten mindestens diese Phrasen hinterlegt sein:

    • googletagmanager.com/gtag/js
    • www.googletagmanager.com
    • gtag(
    • google-analytics.com

    Prüfen Sie den Script Blocker und ergänzen Sie fehlende Einträge. Wichtig: Der Script Blocker greift nur bei Skripten, die serverseitig im HTML stehen. Skripte, die erst per JavaScript nachgeladen werden, erwischt er nicht zuverlässig, hier ist der saubere Weg immer die Auslieferung über den Borlabs-Service (siehe oben).

    In Borlabs Cookie 3.x finden Sie den Script Blocker als eigenen Menüpunkt unter Borlabs Cookie → Script Blocker (Stand: Juli 2026). In den älteren 2.x-Versionen war die Blockier-Logik teils direkt am jeweiligen Cookie hinterlegt.

    Wenn der Google Tag Manager im Spiel ist

    Läuft Analytics über den Google Tag Manager, dann laden Sie nicht GA, sondern gtm.js. GTM startet danach GA im Hintergrund. In diesem Fall müssen Sie den GTM-Container blockieren, nicht direkt den Analytics-Tag.

    Dafür gibt es zwei saubere Wege:

    1. GTM komplett über Borlabs auslösen: Das GTM-Snippet als Borlabs-Service in der Gruppe Statistik (oder Marketing) einbinden, sodass der Container erst nach Einwilligung lädt. Einfach, aber gröber, weil dann der gesamte Container an der Einwilligung hängt.
    2. Google Consent Mode im GTM: Der Container lädt, GA-Tags feuern aber erst, wenn der Consent-Status auf granted steht. Das erfordert eine Verdrahtung zwischen Borlabs und dem dataLayer. Borlabs unterstützt den Consent Mode; die genaue Einrichtung hängt von Ihrer Container-Konfiguration ab.

    In Borlabs Cookie 3.x aktivieren Sie den Consent Mode nicht global, sondern je Dienst: Installieren Sie das passende Fertig-Paket (Google Analytics, Google Ads oder Google Tag Manager) aus der Borlabs-Bibliothek und schalten Sie in dessen Einstellungen den Consent Mode ein. Der Basic-Modus ist bereits mit der Installation des Pakets aktiv, den Advanced-Modus aktivieren Sie bei Bedarf zusätzlich in den Dienst-Einstellungen. Consent Mode v2 unterstützt Borlabs seit Version 3.0 (Stand: Juli 2026).

    Ein häufiges Missverständnis: Mit aktivem Google Consent Mode v2 kann es sein, dass Sie im Network-Tab weiterhin kleine Requests an Google sehen, obwohl noch keine Einwilligung vorliegt. Das sind sogenannte Cookieless Pings, die im Status denied keine Analytics-Cookies setzen und keine identifizierenden Daten übertragen. Rechtlich ist das eine andere Situation als klassisches Tracking.

    Prüfen Sie deshalb nicht nur, ob ein Request rausgeht, sondern auch, ob im Application-Tab der Entwicklertools tatsächlich _ga-Cookies gesetzt werden (unter Storage → Cookies → Ihre Domain, Namen _ga und _ga_XXXXXXX). Werden vor der Einwilligung keine _ga-Cookies gesetzt, arbeitet der Consent Mode wie vorgesehen. Ob Cookieless Pings für Ihren Anwendungsfall zulässig sind, sollten Sie datenschutzrechtlich abklären, technisch sind sie kein Bug.

    Cache und JavaScript-Optimierung als Störfaktor

    Zwei technische Nebenwirkungen sabotieren regelmäßig eine korrekte Blockierung:

    • Seiten-Cache: Caching-Plugins (WP Rocket, LiteSpeed Cache, W3 Total Cache) oder ein serverseitiger Cache liefern eine ältere HTML-Version aus, in der Ihre neuen Borlabs-Einstellungen noch nicht enthalten sind. Leeren Sie nach jeder Änderung den kompletten Cache und testen Sie erneut im Inkognito-Fenster.
    • JavaScript-Optimierung: Funktionen wie “Delay JavaScript Execution”, “Combine JS” oder Autoptimize können den von Borlabs manipulierten Script-Tag verändern oder verschieben, sodass die Blockierung ins Leere läuft. Nehmen Sie die Analytics- und Borlabs-Skripte von der Optimierung aus oder deaktivieren Sie die JS-Optimierung testweise, um den Effekt zu isolieren.

    Ein sauberer Test verlangt nach jeder Änderung: Cache leeren, neues Inkognito-Fenster, Network-Tab kontrollieren.

    Checkliste in Kurzform

    1. Im Inkognito-Fenster mit DevTools prüfen, ob g/collect vor der Einwilligung feuert.
    2. Doppelte GA-Quellen (Site Kit, Header-Snippet, Analytics-Plugins) finden und abschalten.
    3. Analytics als Borlabs-Service in der Gruppe Statistik einbinden.
    4. Script-Blocker-Phrasen für gtag, googletagmanager.com, google-analytics.com ergänzen.
    5. Bei GTM den Container über Borlabs bzw. Consent Mode steuern.
    6. Cache leeren und JS-Optimierung als Störquelle ausschließen.
    7. Erneut im Inkognito-Fenster testen: keine _ga-Cookies, kein collect-Request vor der Einwilligung.

    Wer sauberes Consent-Handling aufbaut, sollte den Banner gleich vollständig DSGVO-fest gestalten und das Tracking von Anfang an einwilligungsbasiert aufsetzen.

    FAQ

    Warum lädt Google Analytics trotz Borlabs Cookie schon vor dem Klick auf “Akzeptieren”? In fast allen Fällen wird der Tag an Borlabs vorbei geladen, etwa über Google Site Kit, ein Header-Scripts-Plugin oder einen fest im Theme eingebauten Snippet. Borlabs kann nur steuern, was es selbst ausliefert. Deaktivieren Sie die Fremdquelle und binden Sie Analytics als Borlabs-Service ein.

    Ich sehe im Network-Tab weiterhin Requests an Google, obwohl ich nicht zugestimmt habe. Ist das ein Fehler? Nicht zwingend. Mit aktivem Consent Mode v2 sendet Google im Status “denied” cookielose Pings ohne identifizierende Daten. Entscheidend ist, ob vor der Einwilligung _ga-Cookies gesetzt werden. Kontrollieren Sie das im Application-Tab der Entwicklertools.

    Muss ich den Script Blocker nutzen oder reicht der Borlabs-Service? Der über den Service ausgelieferte Opt-in-Code ist der robusteste Weg, weil der Tag erst nach Einwilligung überhaupt existiert. Der Script Blocker ist die Ergänzung für Skripte, die Sie nicht selbst über Borlabs steuern, etwa aus Drittanbieter-Plugins.

    Brauchen Sie Unterstützung bei DSGVO & Cookie-Consent (Borlabs & Co.)? Ypsilon.dev ist Ihre Webagentur aus Regensburg – jetzt kostenlose Erstberatung anfragen.