WordPress-Cookies vor der Einwilligung blockieren

Der größte Teil des Cookie-Compliance-Problems im Web lebt auf WordPress. Dort sind auch die meisten Consent-Banner installiert, und erstaunlich viele davon bewirken nicht viel.

Wir haben katla-app/wordpress veröffentlicht, ein Plugin, das eine WordPress- oder WooCommerce-Website mit Katla verbindet. Es lädt das Consent-Skript, blockiert Skripte und Einbettungen ohne Einwilligung auf dem Server und rendert die Cookie-Richtlinie und die Datenschutzerklärung, die Katla aus Ihren tatsächlich gescannten Cookies erstellt.

Das Problem mit dem Blockieren im Browser

Der Cookie-Guard von Katla verhindert, dass Cookies geschrieben werden. Das ist der richtige Grundbaustein, und auf einer handgebauten Website reicht er meistens, weil Sie kontrollieren, welche Skripte auf der Seite sind.

WordPress ist anders. Ein Theme reiht ein Skript ein. Drei Plugins reihen vier weitere ein. Ein Page Builder fügt ein Pixel ein. Bis ein Besucher die Seite lädt, stecken Tracker darin, die niemand bewusst hinzugefügt hat, und ein Tracker, der lädt, hat bereits eine Anfrage mit IP-Adresse und Referrer an einen Drittanbieter geschickt, ob er nun ein Cookie setzen konnte oder nicht.

Das im Browser zu blockieren, ist ein Wettlauf, den Sie nicht zuverlässig gewinnen. Das Consent-Skript muss ausgeführt werden, die richtigen Globals patchen und das Tag neutralisieren, bevor das Tag läuft. Manchmal klappt das. Dann sortiert ein Optimierungs-Plugin Ihre Skripte um, und es klappt nicht mehr.

Also blockieren, bevor die Seite ausgeliefert wird

Das Plugin blockiert serverseitig, während WordPress das HTML noch zusammensetzt. Ordnen Sie einem Skript-Handle eine Kategorie zu, im Tab Blocking oder im Code:

add_action( 'wp_enqueue_scripts', function () {
	katla_block_script( 'google-analytics', 'analytics' );
	katla_block_script( 'facebook-pixel', 'marketing' );
}, 20 );

Das Skript, das im Browser ankommt, ist wirkungslos:

<script type="text/plain" data-katla-src="…" data-katla-category="analytics"></script>

Es gibt keinen Wettlauf, weil die ausführbare Version in der Antwort nie existiert hat.

Das Detail, das uns am wichtigsten ist, betrifft Inline-Skripte. Analytics-Tags bestehen selten aus einer einzigen Datei: Es gibt einen Loader, dann ein Inline-gtag('config', …) oder einen dataLayer-Push, der über wp_add_inline_script am selben Handle hängt. Blocker, die nur das src behandeln, verlieren diese oft, und das Tag kommt nach der Einwilligung falsch konfiguriert oder gar nicht zurück. Dieses Plugin neutralisiert Inline-Skripte zusammen mit ihrem Handle und spielt sie in der Reihenfolge des Quelltexts wieder ab, sobald die Kategorie erlaubt ist, sodass das Tag genau so wiederhergestellt wird, wie WordPress es zusammengesetzt hat.

WooCommerce, wo Kaputtmachen teuer ist

Ein Consent-Plugin in einem Shop hat eine zweite Aufgabe, die genauso wichtig ist wie Compliance: den Shop nicht kaputtzumachen. Blockieren Sie das falsche Handle, und der Warenkorb aktualisiert sich nicht mehr oder der Checkout scheitert still, und Sie erfahren es von einem Kunden.

Deshalb ist die WooCommerce-Integration vor allem eine Liste von Dingen, die das Plugin verweigert. Warenkorb-, Session- und Checkout-Cookies umgehen den Guard vollständig: woocommerce_cart_hash, wp_woocommerce_session_*, wc_fragments_* und Co. Shop-kritische Handles wie wc-cart-fragments, wc-checkout und wc-blocks-checkout werden aus der Blockliste entfernt, sodass eine unbedachte Regel den Checkout nicht lahmlegen kann. Das Plugin deklariert Kompatibilität mit HPOS und den Warenkorb- und Checkout-Blöcken.

Eine bewusste Ausnahme: Cookies für die Bestellzuordnung (sbjs_*) stehen nicht auf der Allowlist. Es sind Marketing-Cookies, praktische zwar, aber eben Marketing. Wenn Sie sie vor der Einwilligung loswerden wollen, sperren Sie das Handle wc-order-attribution.

Drei Stufen der Kontrolle

Die Standardeinstellung braucht keinen Code: Katla rendert das Banner und den Einstellungsdialog, gestaltet über Ihr Dashboard.

Wenn Sie das Markup lieber selbst in der Hand haben, lädt der Headless-Modus den Guard und window.KatlaConsent ohne die gehostete UI, und das Plugin rendert sein eigenes Banner, übersetzt über WordPress und gestaltet mit CSS Custom Properties, sodass es Ihr Theme übernimmt:

add_filter( 'katla_banner_css_vars', function () {
	return array(
		'katla-primary' => '#111111',
		'katla-radius'  => '0px',
		'katla-font'    => 'var(--wp--preset--font-family--body)',
	);
} );

Oder Sie schalten die UI ganz ab und bauen Ihre eigene auf Basis von window.KatlaConsent und dem Event katla:consent. In allen drei Fällen arbeitet darunter derselbe Guard.

Richtlinien, die wirklich auf der Seite stehen

[katla_policy] rendert Ihre generierte Cookie-Richtlinie und Datenschutzerklärung serverseitig, als Teil des Seiten-HTML. Kein iframe, kein clientseitiger Fetch: echtes Markup, indexierbar, gestaltet von Ihrem Theme und neu erstellt, wenn sich Ihre Cookies ändern. Für jeden Shortcode gibt es einen Gutenberg-Block, dazu [katla_cookie_table], wenn Sie nur die Tabellen wollen, und [katla_cookie_settings] für den Link „Einstellungen verwalten“, den Ihre Richtlinienseite ohnehin braucht.

Erste Schritte

Sie brauchen eine verifizierte Katla-Website mit mindestens einem abgeschlossenen Scan, denn das Plugin braucht Cookie-Daten, um Richtlinien zu rendern. Dann:

wp plugin activate katla-consent
wp katla site-id 00000000-0000-0000-0000-000000000000
wp katla verify

Oder fügen Sie die Site-ID unter Settings → Katla Consent ein.

Die WordPress-Anleitung behandelt die Shortcodes, die Filter, die WP-CLI-Befehle und die Besonderheiten von WooCommerce, und die Seite zu WordPress und WooCommerce enthält die Einrichtungsschritte und die Fragen, die WordPress-Teams vor dem Wechsel stellen. Das Plugin liegt auf GitHub unter katla-app/wordpress. Issues und Pull Requests sind willkommen.