Wer Google Fonts direkt über die Google-Server einbindet, sendet bei jedem Seitenaufruf die IP-Adresse jedes Besuchers an Google, ohne dessen Einwilligung. Genau das hat ein deutsches Gericht als Datenschutzverstoß mit Schadensersatzpflicht eingestuft. Die Empfehlung ist eindeutig: Fonts lokal hosten, externe Verbindung kappen, fertig. Der technische Aufwand dafür liegt bei wenigen Minuten pro Website.
Werbehinweis: Der Check ist für dich kostenlos. Die Seite finanziert sich über Prüf- und Umsetzungsaufträge sowie die Vermittlung von Anfragen an geprüfte Web-Agenturen. Details in der Methodik.
Was das LG München I tatsächlich entschieden hat
Am 20.01.2022 hat das Landgericht München I (Az. 3 O 17493/20) einem Websitebetreiber Schadensersatz auferlegt, weil eine Unterseite Google Fonts dynamisch von Google-Servern nachgeladen hatte. Dabei wurde die IP-Adresse des Klägers ohne Rechtsgrundlage an Google übermittelt. Das Gericht sah darin einen Verstoß gegen Art. 6 DSGVO und sprach 100 Euro Schadensersatz zu, dazu Unterlassung und Erstattung der Abmahnkosten.
Dieses Urteil ist bis heute der einzige tragfähige gerichtliche Anker für die Abmahnwelle, die im Sommer und Herbst 2022 folgte. Zehntausende Websitebetreiber erhielten Schreiben, viele davon von Privatpersonen und teils über auffällig ähnlich formulierte Massenverfahren. Mehrere Gerichte und Staatsanwaltschaften haben Teile dieser Abmahnwellen später als rechtsmissbräuchlich eingestuft, weil erkennbar nicht der Datenschutz im Vordergrund stand, sondern die Kostenerstattung. Das ändert nichts an der zugrunde liegenden technischen Tatsache: Externes Nachladen von Google Fonts ohne Einwilligung ist ein Datenschutzproblem, unabhängig davon, wer im Einzelfall abmahnt.
Für Unternehmen ist dabei vor allem eines wichtig zu trennen: das gerichtlich festgestellte Risiko und das Verhalten einzelner Abmahnender. Auch wenn ein Teil der Schreiben aus 2022 später als missbräuchlich eingeordnet wurde, bleibt die zugrunde liegende Rechtsfrage bestehen. Eine Website, die IP-Adressen ohne Einwilligung an Google überträgt, verstößt gegen die DSGVO, unabhängig davon, ob der konkrete Absender eines Schreibens seriös handelt oder nicht. Wer als B2B-Anbieter auf eine ernsthafte Prüfung durch Kunden, Auftraggeber oder Investoren angewiesen ist, sollte den Punkt daher unabhängig vom Abmahnrisiko beheben, schon aus Gründen der eigenen Datenschutz-Dokumentation.
Zahl: 100 Euro Schadensersatz für die Klägerseite, zugesprochen vom LG München I am 20.01.2022 (Az. 3 O 17493/20), wegen ungefragt an Google übermittelter IP-Adresse.
Warum die Standard-Einbindung überhaupt ein Problem ist
Die typische Einbindung sieht so aus, dass der Browser bei jedem Seitenaufruf einen Link- oder Import-Aufruf an fonts.googleapis.com beziehungsweise fonts.gstatic.com absetzt. Google erhält dabei IP-Adresse, User-Agent und Zeitpunkt des Zugriffs, ganz ohne Cookie-Banner oder Einwilligung davor. Das ist technisch identisch mit dem Nachladen jeder anderen externen Ressource, nur dass Fonts auf beinahe jeder Website vorkommen und deshalb besonders breit betroffen sind.
Der Live-Scanner prüft genau diesen Punkt automatisiert. Domain eingeben, und innerhalb weniger Sekunden liegt ein Befund vor, ob externe Font-Verbindungen aktiv sind. Das Ergebnis kommt als Score mit Grenzwert-Linie, nicht als Fließtext-Gutachten, damit sofort klar ist, ob gehandelt werden muss, und der Report geht per Mail direkt an die angegebene Adresse.
Das ist bewusst anders aufgebaut als eine anwaltliche Ersteinschätzung. Statt einer Bewertung in Fließtext liefert der Scanner ein messbares Ergebnis: welche Domains angefragt werden, wie viele externe Font-Requests pro Seitenaufruf entstehen und ob der Grenzwert für “unkritisch” eingehalten wird. Das passt zum eigentlichen Charakter des Problems, es ist ein technischer Konfigurationsfehler, kein Vertragsstreit. Wer den Befund einmal hat, kann die vier folgenden Schritte selbst umsetzen oder an die eigene Entwicklung beziehungsweise Agentur weiterreichen.
Der Fix in vier Schritten
- Die verwendeten woff2-Dateien der eingesetzten Schriftschnitte herunterladen, entweder über das offizielle Google-Fonts-Repository oder einen gängigen Download-Helfer.
- Die Dateien im eigenen Projekt ablegen, üblicherweise unter einem Pfad wie public/fonts.
- Die CSS-Regeln für font-face so umschreiben, dass sie auf den lokalen Pfad zeigen statt auf fonts.googleapis.com.
- Alle verbliebenen Verbindungen zu fonts.googleapis.com und fonts.gstatic.com aus HTML, CSS und eingebundenen Preconnect-Tags entfernen, danach die Seite neu laden und im Netzwerk-Tab prüfen, dass keine externe Font-Anfrage mehr auftaucht.
Zahl: Der Fix besteht aus vier Arbeitsschritten und lässt sich in der Praxis in unter 5 Minuten je Website umsetzen, ohne Serverumzug und ohne neue Verträge.
Wann die Empfehlung nicht reicht
Bei sehr großen Seiten mit vielen unterschiedlichen Schriftschnitten und Sprachvarianten kann das lokale Hosting den Wartungsaufwand erhöhen, weil Updates der Schriftdateien manuell nachgezogen werden müssen. Wer ein Content-Management-System mit Page-Builder-Plugins einsetzt, sollte zusätzlich prüfen, ob einzelne Plugins eigene Font-Verbindungen mitbringen, die vom Haupttheme unabhängig sind. Der Scanner-Befund zeigt in diesem Fall häufig mehrere getrennte Fundstellen statt einer einzigen, was die Reihenfolge der Bearbeitung vorgibt.
Ähnliches gilt für eingebundene Drittanbieter-Widgets, etwa Buchungstools, Chat-Systeme oder Kartenintegrationen, die häufig eigene Google-Fonts-Verweise mitbringen, ohne dass das im eigenen Theme sichtbar wird. Auch Preview- oder Staging-Umgebungen sollten in die Prüfung einbezogen werden, denn ein Fix, der nur auf der Live-Domain greift, hilft nicht, wenn intern verlinkte Subdomains dieselbe Font-Einbindung noch unverändert ausliefern.
Diese Einordnung ist eine technische Einschätzung, keine Rechtsberatung. Wer bereits ein Abmahnschreiben erhalten hat, sollte den konkreten Einzelfall zusätzlich unabhängig prüfen lassen (mehr dazu im Artikel zu pillar).
Fazit
Die Google-Fonts-Abmahnung ist ein reales, gerichtlich bestätigtes Risiko, technisch aber trivial zu beheben. Vier Schritte, lokale Hosting-Lösung, keine externe Verbindung mehr, und der Angriffspunkt ist dauerhaft geschlossen.