Ist Bricks Builder DSGVO-konform? Der eine Punkt, auf den es ankommt

Ist Bricks Builder DSGVO-konform?

Kurze Antwort: Ja – der Bricks Builder selbst setzt keine Tracking-Cookies, sammelt keine Besucherdaten und lädt seine Icons und Skripte lokal aus dem Theme. Es gibt genau eine kritische Stelle, an der eine mit Bricks gebaute Website Besucherdaten ungefragt an einen US-Server schickt: Google Fonts. Warum das eine reale Abmahn-Gefahr ist, klärt der erste Abschnitt; danach schließen Sie die Lücke in wenigen Minuten – über den Font Manager von Bricks 2.0, den manuellen Weg für ältere Versionen oder die passende Performance-Einstellung.

Warum Google Fonts der wunde Punkt ist

Bricks lädt Google Fonts nur, wenn Sie in den Typografie-Einstellungen tatsächlich eine Google-Schrift auswählen. Tun Sie das, holt Bricks die Schrift standardmäßig direkt von fonts.googleapis.com bzw. fonts.gstatic.com. Bei jedem Seitenaufruf übermittelt der Browser des Besuchers dabei dessen IP-Adresse an Google in die USA – ohne Einwilligung, oft ohne dass die Betreiberin davon weiß.

Genau das hat das LG München I am 20.01.2022 (Az. 3 O 17493/20) als Verstoß gegen die DSGVO gewertet: Die IP-Adresse ist ein personenbezogenes Datum (Art. 4 Nr. 1 DSGVO), ein „berechtigtes Interesse” scheidet aus, weil sich die Schriften ebenso gut lokal einbinden lassen. Der Kläger bekam 100 Euro Schadensersatz zugesprochen. Das Urteil löste eine Welle von Abmahnungen und Schadensersatz-Forderungen aus – teils automatisiert per Crawler verschickt.

Wichtig zur Einordnung: Das Problem ist nicht Bricks, sondern die dynamische Einbindung von Schriften vom Google-Server. Die Lösung ist immer dieselbe: Schriften selbst hosten.

Google Fonts in Bricks lokal einbinden

Weg 1: Font Manager (Bricks 2.0)

Seit Bricks 2.0 gibt es den Font Manager, der das Selbst-Hosten mit einem Klick erledigt. So gehen Sie vor:

Öffnen Sie den Builder und rufen Sie in der Builder-Toolbar Einstellungen → Font Manager auf (alternativ das Zahnrad-Symbol direkt neben einem beliebigen „Schriftfamilie”-Regler). Beide Wege führen laut offizieller Bricks-Doku zum selben Font Manager (Stand: Juli 2026).
Wechseln Sie auf den Reiter Google.
Suchen Sie Ihre Schrift und klicken Sie auf das Download-Symbol.
Warten Sie die Erfolgsmeldung ab.

Bricks lädt daraufhin das Google-Fonts-CSS, holt die Schriftdateien herunter, legt einen Custom-Font-Eintrag an, speichert die Dateien in WordPress und fügt die Schrift der Quelle „Custom” hinzu. Verwenden Sie ab jetzt konsequent die Custom-Font-Version dieser Schrift (nicht die Google-Version) – dann entfällt der externe Request im Frontend.

Zwei häufige Stolpersteine:

Vorschau im Builder lädt weiter von Google. Das Bearbeiten im Builder betrifft nur eingeloggte Redakteure, nicht Ihre Besucher – datenschutzrechtlich unkritisch. Prüfen Sie zur Kontrolle immer das ausgeloggte Frontend, nicht die Builder-Ansicht.
Alte Auswahl bleibt stehen. Nach dem Download müssen Sie die Schrift an den betroffenen Elementen (und in den globalen Typografie-Einstellungen) neu zuweisen. Sonst zeigt die Seite zwar die richtige Schrift, lädt sie aber weiter extern.

Weg 2: Ältere Bricks-Versionen und der manuelle Weg

Nutzen Sie noch Bricks 1.x oder wollen Sie volle Kontrolle, funktioniert der klassische Weg zuverlässig:

Laden Sie alle benötigten Schnitte (z. B. 400, 500, 700) über den google-webfonts-helper (gwfh.mranftl.com) als .woff2/.woff herunter.
Legen Sie die Schrift in WordPress unter Bricks → Custom Fonts an und laden Sie die Dateien hoch.
Wählen Sie in Ihren Elementen die neue Custom Font statt der Google-Variante.

Weg 3: „Google Fonts deaktivieren” als Sicherheitsnetz

Unter Bricks → Einstellungen → Performance gibt es die Option „Disable Google Fonts” (Google Fonts deaktivieren). Aktivieren Sie sie, wenn Sie keine Google-Schriften nutzen oder alle Google-Schriften bereits selbst hosten. Damit stellen Sie sicher, dass Bricks im Frontend keine Verbindung zu Google aufbaut – auch nicht versehentlich über eine vergessene Einstellung.

Für Entwicklerinnen lässt sich das Laden serverseitig hart abschalten. Der Filter unterbindet das Nachladen der Webfonts im Frontend:

// functions.php des Child-Themes
add_filter( 'bricks/assets/load_webfonts', '__return_false' );

Den Filter bricks/assets/load_webfonts führt Bricks in der offiziellen Hook-Dokumentation als vorgesehenen Weg, das Nachladen der Webfonts im Frontend zu unterbinden (Stand: Juli 2026).

Danach unbedingt gegenprüfen: Netzwerk-Tab öffnen, Seite ausgeloggt neu laden, auf googleapis/gstatic filtern – es darf kein Treffer erscheinen. Kostenlose externe Scanner wie der Google-Fonts-Checker liefern eine schnelle Zweitmeinung.

Was Bricks von sich aus richtig macht

Damit klar ist, worüber Sie sich nicht sorgen müssen:

Icon-Fonts sind lokal. Font Awesome, Ionicons & Co. liegen im Theme unter bricks/assets/fonts und werden vom eigenen Server ausgeliefert – kein externer CDN-Request. Das hat das Bricks-Team ausdrücklich bestätigt.
Keine Tracking-Cookies. Der Builder setzt im Frontend keine Analyse- oder Marketing-Cookies. Was an Cookies anfällt, sind allenfalls die technisch notwendigen von WordPress selbst (z. B. Login-Session im Backend).
Kein Phone-Home. Bricks überträgt beim normalen Seitenbetrieb keine Besucherdaten an Bricks-Server. Lizenzprüfung und Update-Abfragen laufen im Adminbereich, nicht beim Website-Besucher.

Die eigentlichen Baustellen liegen bei Ihnen

„DSGVO-konform” ist keine Eigenschaft, die ein Page-Builder mitbringt – sie hängt davon ab, was Sie damit einbauen. Die typischen Datenschleudern kommen nicht von Bricks, sondern von Diensten, die Sie einbetten:

YouTube-/Vimeo-Videos, Google Maps, Google reCAPTCHA, Analytics, Ads/Pixel – all diese Einbindungen laden externe Skripte und übertragen IP-Adressen, meist in die USA.
Solche Dienste dürfen erst nach aktiver Einwilligung laden. Dafür brauchen Sie ein Consent-Management wie Borlabs Cookie oder Real Cookie Banner, das die Skripte blockt, bis der Besucher zustimmt.
Bricks bietet passende Elemente (Video, Map, Formular). Das Blockieren übernimmt aber Ihr Cookie-Tool, nicht Bricks. Prüfen Sie z. B. gezielt, dass reCAPTCHA sauber über Borlabs gesperrt wird, bevor der Besucher einwilligt.

Dazu kommen die klassischen Pflichten jeder Website: Impressum, Datenschutzerklärung, ein AV-Vertrag (AVV) mit Ihrem Hoster und Server möglichst in der EU. Eine Orientierung, welche Tools grundsätzlich unbedenklich sind, finden Sie unter DSGVO-konforme Apps und Dienste.

Praxis-Checkliste

Alle verwendeten Schriften als Custom Fonts selbst gehostet (Font Manager oder manuell)
„Disable Google Fonts” unter Performance aktiviert
Ausgeloggtes Frontend im Netzwerk-Tab geprüft: keine googleapis/gstatic-Requests
Externe Einbindungen (Video, Maps, reCAPTCHA, Analytics) per Consent-Tool geblockt
Impressum, Datenschutzerklärung, AVV mit dem Hoster vorhanden
Bricks und WordPress auf aktuellem Stand (Sicherheits-Updates)

FAQ

Setzt Bricks Builder selbst Cookies? Nein. Bricks setzt im Frontend keine Tracking- oder Marketing-Cookies. Cookies entstehen erst durch Dienste, die Sie einbetten (z. B. Analytics), oder durch WordPress-Grundfunktionen wie die Login-Session.

Reicht es, die Option „Google Fonts deaktivieren” zu aktivieren? Sie ist das richtige Sicherheitsnetz, ersetzt aber nicht das Selbst-Hosten. Wenn Sie eine Google-Schrift verwenden möchten, laden Sie sie zuerst lokal herunter (Font Manager) und aktivieren die Option zusätzlich. Danach immer im ausgeloggten Frontend gegenprüfen.

Sind die Icons in Bricks (Font Awesome) ein DSGVO-Problem? Nein. Bricks liefert seine Icon-Fonts aus dem Theme-Verzeichnis (bricks/assets/fonts) vom eigenen Server aus. Es gibt keinen externen CDN-Aufruf und damit keine IP-Übertragung an Dritte.

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