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

    Borlabs Cookie: iFrames in WordPress DSGVO-konform freigeben

    · Weswegen-Redaktion
    DSGVO

    Ein YouTube-Video, eine Google-Map oder ein Buchungs-Widget einbetten – und schon lädt ein fremder Server Skripte und setzt Cookies, bevor der Besucher überhaupt zugestimmt hat. Genau das ist ohne Einwilligung nicht zulässig. Mit dem Content Blocker von Borlabs Cookie geben Sie iframes erst nach aktivem Klick frei und zeigen vorher einen Platzhalter. Diese Anleitung zeigt, wo Sie das einstellen, wie Sie nicht automatisch erkannte iframes per Shortcode blockieren und welche Fehler in der Praxis am häufigsten passieren.

    Content Blocker statt Cookie-Gruppe – der entscheidende Unterschied

    Der häufigste Denkfehler: Man versucht, ein iframe über eine Cookie-Gruppe (in Borlabs 3 „Services”) zu regeln. Das ist die falsche Stelle. Borlabs trennt zwei Dinge:

    • Services / Cookies: Skripte und Cookies, die Ihre eigene Seite lädt – Google Analytics, Meta-Pixel, Matomo. Sie werden über die Einwilligung im Cookie-Banner freigeschaltet.
    • Content Blocker (Inhaltsblocker): externe eingebettete Inhalte – iframes, oEmbeds von YouTube, Vimeo, Google Maps, Instagram oder eigenen Drittanbieter-Widgets. Statt einer Anfrage an den fremden Server wird ein Platzhalter angezeigt, bis der Besucher klickt.

    Für iframes ist also fast immer der Content Blocker zuständig. Die Cookie-/Service-Verwaltung brauchen Sie nur, wenn der eingebettete Dienst zusätzlich eigene Cookies über ein Skript auf Ihrer Seite setzt.

    So blockiert Borlabs iframes automatisch

    Sobald das Plugin aktiv ist, durchsucht Borlabs den ausgelieferten HTML-Quelltext nach <iframe>-Elementen. Zeigt ein iframe auf einen fremden Host (also nicht Ihre eigene Domain), wird es standardmäßig automatisch blockiert: Borlabs ersetzt das src-Attribut technisch durch ein data-src und lädt die Quelle erst nach der Zustimmung nach. Für bekannte Dienste (YouTube, Vimeo, Google Maps, OpenStreetMap, Instagram u. a.) bringt Borlabs bereits fertige Content Blocker mit.

    Welcher Content Blocker greift, entscheidet der Hostname. Jeder Content Blocker hat unter „Locations” (früher „Hosts”) einen oder mehrere Einträge im Format hostname plus optionalem path. Wird dieser Hostname in einem iframe gefunden, gelten die Einstellungen dieses Blockers – also Platzhalter, Vorschautext und Freigabe-Verhalten.

    Für eigene Einbettungen – etwa ein Terminbuchungstool von booking.ihr-anbieter.de oder eine externe Karte – gibt es standardmäßig keinen passenden Blocker mit Platzhalter. Dafür legen Sie einen eigenen an.

    Schritt für Schritt: einen eigenen iframe freigeben

    1. Content Blocker anlegen

    Öffnen Sie im WordPress-Backend Borlabs Cookie → Content Blocker und klicken Sie auf Neu hinzufügen. Vergeben Sie:

    • eine ID – nur Kleinbuchstaben, eindeutig, z. B. buchungstool
    • einen Namen – frei wählbar, z. B. „Online-Terminbuchung”
    • einen Service-/Anbieternamen und einen Link zu dessen Datenschutzerklärung

    2. Hostname als „Location” eintragen

    Das ist der wichtigste Schritt. Sehen Sie sich den echten iframe-Code Ihres Anbieters an und übernehmen Sie nur den Host aus der URL – ohne https:// und ohne den Pfad. Aus

    <iframe src="https://booking.ihr-anbieter.de/widget?id=123"></iframe>

    wird als Location der Hostname booking.ihr-anbieter.de. Tragen Sie ihn im Abschnitt Locations ein. Setzen Sie einen Pfad nur, wenn Sie gezielt einen Teilbereich blockieren wollen.

    3. Platzhalter und Einwilligungstext gestalten

    Im Bereich für die Vorschau (Preview) legen Sie fest, was der Besucher vor der Zustimmung sieht: ein Hinweistext, warum der Inhalt blockiert ist, und der Freigabe-Button. Formulieren Sie den Text transparent, z. B.: „Zum Laden der Terminbuchung wird eine Verbindung zu booking.ihr-anbieter.de hergestellt. Dabei können personenbezogene Daten übertragen werden.” Das erfüllt die Informationspflicht und macht dem Besucher transparent, worauf er sich einlässt – ein vager „Externer Inhalt blockiert”-Text tut das nicht.

    Optional können Sie unter den JavaScript-Einstellungen des Content Blockers Code hinterlegen, der nach der Freigabe ausgeführt wird – etwa um ein per JavaScript nachgeladenes Widget zu initialisieren. Borlabs 3 stellt dafür zwei Felder bereit: „Global” – dieser Code läuft einmal pro Seite, sobald der Besucher den Inhalt zum ersten Mal freigibt – und „Initialisierung” (in der englischen Oberfläche „Initialization”), dessen Code bei jeder Freigabe erneut ausgeführt wird und das freigeschaltete Element als Variable el erhält.

    4. Speichern, Cache leeren, testen

    Speichern Sie den Content Blocker. Leeren Sie danach jeden Cache – Plugin-Cache (WP Rocket, LiteSpeed, W3TC), Server-Cache und ggf. CDN. Prüfen Sie die Seite anschließend in einem privaten Fenster: Vor der Zustimmung darf im Netzwerk-Tab der Browser-DevTools keine Anfrage an den fremden Host erscheinen; erst nach dem Klick auf den Platzhalter wird das iframe geladen.

    Wenn die automatische Erkennung nicht greift: der Shortcode

    Borlabs erkennt nur iframes, die im HTML-Quelltext stehen. Wird ein iframe erst per JavaScript nachgeladen – häufig bei Slidern, Pop-ups oder Page-Builder-Widgets (Elementor, Divi, Avada) – findet Borlabs es nicht und blockiert es nicht. In diesem Fall umschließen Sie den Einbettungscode manuell mit dem Content-Blocker-Shortcode. Die id verweist auf den zuvor angelegten Blocker:

    [borlabs-cookie type="content-blocker" id="buchungstool"]
<iframe src="https://booking.ihr-anbieter.de/widget?id=123"></iframe>
[/borlabs-cookie]

    Fügen Sie das im Block Custom HTML ein (nicht im visuellen Editor, der würde die eckigen Klammern verändern). Für oEmbeds wie Facebook- oder Instagram-Beiträge gibt es zusätzlich spezialisierte Shortcodes; bei einem klassischen <iframe> ist der content-blocker-Shortcode oben der richtige Weg.

    Einzelne iframes bewusst nicht blockieren

    Manchmal soll ein iframe ohne Einwilligung laden – etwa eine Einbettung von Ihrer eigenen Domain oder ein Dienst ohne datenschutzrelevante Übertragung. Zwei Wege:

    • Einzelnes iframe ausnehmen: Ergänzen Sie am <iframe>-Tag das von Borlabs vorgesehene Ausnahme-Attribut (data-borlabs-cookie-iframe-spared). Dieses iframe überspringt die automatische Blockierung.
    • Ganzen Hostname global ausnehmen: Über den PHP-Filter-Hook borlabsCookie/contentBlocker/modifyExcludedHostnames (eingebunden in der functions.php des Child-Themes oder einem Code-Snippet-Plugin) nehmen Sie einen Host dauerhaft von der Blockierung aus. Für bedingte Logik – etwa das Überspringen der iframe-Blockierung nur in bestimmten Fällen – steht zusätzlich der Hook borlabsCookie/contentBlocker/skipIframeBlocking bereit (Stand: Juli 2026).

    Prüfen Sie vor dem Freistellen ehrlich, ob wirklich keine personenbezogenen Daten an einen Dritten fließen – im Zweifel bleibt der Content Blocker die rechtssichere Variante. Mehr zur grundsätzlichen Pflicht finden Sie unter Cookie-Banner: wann er Pflicht ist.

    Typische Fehler und ihre Lösung

    • Das iframe lädt trotzdem ohne Zustimmung. Meist wird es per JavaScript nachgeladen und steht nicht im HTML. Lösung: mit dem Shortcode umschließen oder die native Borlabs-Integration des Page-Builders nutzen.
    • Der Platzhalter erscheint, aber nach dem Klick passiert nichts. Fast immer ein Hostname-Mismatch: Im iframe steht z. B. www.anbieter.de, in der Location aber nur anbieter.de, oder der Dienst lädt über eine CDN-Subdomain. Prüfen Sie den echten src in den DevTools und tragen Sie alle vorkommenden Hosts als Locations ein.
    • Änderungen wirken nicht. Meist ein nicht geleerter Cache. Erst Plugin-, dann Server-, dann CDN-Cache leeren und im Inkognito-Fenster testen.
    • YouTube-/Maps-Widgets aus dem Page-Builder werden nicht blockiert. Diese rendern oft per JavaScript. Ersetzen Sie das Widget durch ein Custom-HTML-Element mit Shortcode – siehe auch YouTube-Videos in WordPress einbetten.
    • Nach der Aktivierung erscheint das Banner gar nicht. Häufig ein Konflikt mit einem zweiten Consent-Plugin. Betreiben Sie immer nur eine Consent-Lösung gleichzeitig.

    FAQ

    Muss ich für jedes iframe einen eigenen Content Blocker anlegen? Nein. Für gängige Dienste bringt Borlabs fertige Blocker mit. Einen eigenen legen Sie nur für Anbieter an, die Borlabs nicht kennt – etwa Buchungs-, Formular- oder Karten-Widgets von Nischenanbietern. Ein Blocker kann über mehrere Locations auch mehrere Hosts abdecken.

    Reicht der Content Blocker allein für DSGVO-Konformität? Für die Einbettung ja – er verhindert die Datenübertragung vor der Einwilligung. Sie brauchen zusätzlich eine korrekte Cookie-/Service-Verwaltung für Skripte, die Ihre eigene Seite lädt, sowie einen Eintrag des Dienstes in Ihrer Datenschutzerklärung.

    Funktioniert das mit Borlabs Cookie 2 genauso? Das Prinzip ist identisch: Content Blocker plus Shortcode. In Version 2 heißt der Bereich „Hosts” statt „Locations”, die Menüführung ist etwas anders. Borlabs Cookie 3 setzt mindestens WordPress 4.7, PHP 7.4 und MySQL 5.6 voraus (Stand: Juli 2026) – moderne Installationen erfüllen das ohnehin.

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