WordPress selbst ist unkritisch — die Datenschutz-Themen kommen fast immer über Themes, Plugins und eingebettete Inhalte.
In der Praxis stecken die meisten WordPress-Datenschutzprobleme in drei Quellen: dem Theme, das oft Google Fonts oder Icon-Kits von externen CDNs lädt; Marketing- und Analyse-Plugins, die ihren Tracking-Code direkt in den <head> schreiben, ohne einen Consent-Status abzufragen; und dem Block-Editor, der YouTube-, Maps- und Twitter-Einbettungen beim Seitenaufruf sofort auflöst. Jede dieser Quellen lässt sich einzeln entschärfen.
Ein Consent-Plugin allein genügt nicht, wenn es die Skripte nicht tatsächlich blockiert. Viele Banner-Plugins zeigen nur den Hinweis an, während die Tracking-Plugins parallel laden. Wirksam sind Lösungen, die entweder die bekannten Tracker per Skript-Blocker zurückhalten oder tief in die jeweiligen Plugins eingreifen (z. B. über deren Consent-APIs).
WordPress-Kernfunktionen sind selbst unkritisch, mit einer Ausnahme: die Emoji-Skripte laden standardmäßig s.w.org und können — je nach Setup — eine externe Verbindung auslösen. Gravatare im Kommentarbereich übertragen außerdem einen Hash der E-Mail-Adresse an automattic.com. Beides lässt sich mit wenigen Zeilen in der functions.php oder einem kleinen Plugin abschalten.
Häufige Fundstellen: Themes, die Google Fonts von Google laden; Analytics- oder Marketing-Plugins ohne Einwilligungslogik; eingebettete YouTube-/Maps-Blöcke; Emojis und Gravatare von externen Servern. Für alle nicht notwendigen Zugriffe gilt § 25 Abs. 1 TDDDG.
Der kostenlose Scan prüft das ausgelieferte HTML und zeigt, welche Dienste eingebunden sind, ob ein Cookie-Banner erkannt wird und ob Datenschutz- und Impressum-Link vorhanden sind — mit Einordnung je Fund. Er ersetzt keine Rechtsberatung.
Dieser Text ist eine allgemeine Information nach bestem Wissen, kein Rechtsrat. Für den Einzelfall eine auf IT-Recht spezialisierte Kanzlei hinzuziehen.