Wer auf seiner Firmenwebsite eine Google-Schriftart wie Roboto oder Open Sans einbindet und dabei den Code direkt von Googles Servern lädt, überträgt bei jedem Seitenaufruf die IP-Adresse des Besuchers in die USA, ohne dass dieser zugestimmt hat. Das Landgericht München I hat genau das 2022 als DSGVO-Verstoß gewertet. Die Lösung ist unaufwendig: Schriftdateien einmal herunterladen und vom eigenen Server ausliefern, dann entfällt das Problem vollständig.
Was das Landgericht München entschieden hat
Im Urteil vom 20. Januar 2022 (Az. 3 O 17493/20) ging es um eine Website, die Google Fonts dynamisch einband, also den Schriftcode bei jedem Seitenaufruf live von fonts.googleapis.com und fonts.gstatic.com nachlud. Dabei übermittelt der Browser des Besuchers automatisch dessen IP-Adresse an Google-Server in den USA, ganz unabhängig davon, ob die Schrift am Ende überhaupt sichtbar wird. Das Gericht stufte diese Übertragung als unzulässige Datenverarbeitung ein: Ein berechtigtes Interesse nach Artikel 6 Absatz 1 Buchstabe f DSGVO reicht dafür nicht aus, weil es für die reine Textdarstellung keinen Grund gibt, ausgerechnet über Google-Server zu laufen. Der Kläger bekam 100 Euro immateriellen Schadensersatz zugesprochen, dazu einen Unterlassungsanspruch.
Diese Einordnung ist bis heute die zentrale Referenz für das Thema und wurde seither mehrfach bestätigt. Für Betriebe bedeutet das: Die dynamische Einbindung ist das eigentliche Problem, nicht Google Fonts als Schriftart-Bibliothek an sich. Wer dieselben Schriftarten lokal von der eigenen Website ausliefert, verarbeitet keine personenbezogenen Daten über Google und braucht sich um diesen Punkt nicht mehr zu kümmern.
Warum die Massenabmahnwelle seit 2023 kleiner geworden ist
Nach dem Urteil entstand eine regelrechte Abmahnindustrie: Automatisierte Crawler besuchten reihenweise Websites, protokollierten die Google-Fonts-Einbindung und verschickten Abmahnschreiben mit Zahlungsaufforderung. Ein Folgeverfahren vor demselben Gericht hat dieser Praxis einen Dämpfer verpasst. Im Urteil vom 30. März 2023 (Az. 4 O 13063/22) wies das LG München I die Ansprüche eines Abmahners ab, weil der fragliche Website-Besuch nachweislich von einem automatisierten Crawler stammte und nicht von einem echten Menschen, der durch die Datenübertragung tatsächlich beeinträchtigt wurde. Ohne einen echten Besucher, dessen Interessen verletzt wurden, fehlt die Grundlage für Unterlassungs- und Schadensersatzansprüche.
Wichtig für die Einordnung: Die rechtliche Bewertung der dynamischen Einbindung selbst hat sich dadurch nicht geändert, sie bleibt ein DSGVO-Verstoß. Verändert hat sich nur, dass automatisierte Massenabmahnungen ohne echten Besucher schlechtere Erfolgsaussichten haben. Für einen Betrieb ist das kein Freibrief, sondern eher eine Beruhigung: Das Risiko einer teuren Serienabmahnung ist kleiner geworden, das Risiko einer Beanstandung durch echte Besucher, Wettbewerber oder Verbraucherschutzverbände bleibt bestehen, solange die externe Einbindung aktiv ist.
Warum die externe Einbindung überhaupt zum Standard wurde
Die dynamische Einbindung war kein Zufall, sondern lange Zeit ein echter Geschwindigkeitsvorteil. Bis etwa 2020 teilten sich Browser den Cache für Ressourcen wie Schriftdateien über verschiedene Websites hinweg: Hatte ein Besucher eine bestimmte Google-Schrift schon auf einer anderen Seite geladen, lag sie im Cache bereit und musste auf der eigenen Website gar nicht mehr neu heruntergeladen werden. Dieses Argument ist inzwischen hinfällig. Chrome hat mit Version 86 im Oktober 2020 den Cache pro aufgerufener Website partitioniert, Firefox zog mit Version 85 im Januar 2021 nach, Safari trennt Drittanbieter-Ressourcen bereits seit rund 2013. Seitdem lädt jeder Browser dieselbe Google-Schrift für jede Website einzeln neu, der frühere Geschwindigkeitsvorteil der externen Einbindung existiert technisch nicht mehr. Übrig bleibt nur noch das Datenschutzrisiko, ohne den Performance-Ausgleich, der es früher zumindest nachvollziehbar gemacht hat.
Dynamische und lokale Einbindung im Vergleich
| Dynamisch (fonts.googleapis.com) | Lokal (selbst gehostet) | |
|---|---|---|
| IP-Adresse an Google | Bei jedem Seitenaufruf | Nie |
| DSGVO-Status | Verstoß laut LG München ohne Einwilligung | Unproblematisch, keine Datenverarbeitung über Google |
| Cookie-Banner nötig | Rechtlich vertretbar über Einwilligung lösbar, aber Mehraufwand | Nicht nötig |
| Ladezeit-Vorteil durch Cache-Teilung | Seit Chrome 86 / Firefox 85 nicht mehr vorhanden | Entfällt, da kein externer Aufruf |
| Einrichtungsaufwand | Meist Standard, kein Zutun nötig | Einmalig wenige Minuten bis Stunden |
| Pflegeaufwand danach | Muss bei jeder neuen Schriftvariante neu geprüft werden | Keiner, solange die Datei liegen bleibt |
So prüfen Sie in fünf Minuten, ob Sie betroffen sind
Die Prüfung braucht keine Entwicklerkenntnisse.
- Öffnen Sie Ihre Website im Browser.
- Klicken Sie mit der rechten Maustaste auf eine freie Stelle der Seite und wählen Sie Seitenquelltext anzeigen.
- Suchen Sie mit Strg+F (Mac: Cmd+F) nach fonts.googleapis.com und fonts.gstatic.com.
- Finden Sie einen Treffer, lädt die Seite Google Fonts extern von Google-Servern nach.
- Alternativ öffnen Sie die Entwicklertools (F12), wechseln in den Reiter Netzwerk und laden die Seite neu. Jede Anfrage an eine der beiden Domains bestätigt die externe Einbindung.
Kein Treffer bedeutet entweder, dass gar keine Google Fonts genutzt werden, oder dass sie bereits lokal eingebunden sind, in beiden Fällen besteht an dieser Stelle kein Handlungsbedarf.
Betroffen sind in der Praxis vor allem Websites, die auf einem WordPress-Theme, einem Page-Builder oder einem Baukasten aufsetzen, ohne dass jemand die Schrifteinbindung je bewusst geändert hat. Viele dieser Systeme laden Google Fonts standardmäßig dynamisch, weil das früher der einfachste Weg war und niemand die Einstellung nachträglich angefasst hat. Wer seine Website selbst über Jahre gepflegt und dabei mehrfach das Theme oder den Page-Builder gewechselt hat, prüft am besten noch einmal frisch, statt sich auf eine frühere Einschätzung zu verlassen.
Google Fonts lokal einbinden: das Prinzip
Der Fix ändert nichts am Erscheinungsbild der Website, nur an der Quelle, von der die Schrift geladen wird.
- Schriftdateien herunterladen. Die gewünschte Schriftart als Dateien im Format WOFF2 herunterladen, entweder direkt über die Google-Fonts-Seite oder über ein Werkzeug, das das CSS samt Dateien zusammenstellt.
- Dateien auf dem eigenen Server ablegen. Üblich ist ein eigener Ordner wie /fonts/ innerhalb des Website-Projekts.
- Eigene @font-face-Regel schreiben. Statt eines Links auf googleapis.com verweist das CSS jetzt auf die lokal abgelegte Datei, der Rest der Formatierung bleibt unverändert.
- Alte Google-Links entfernen. Verweise auf fonts.googleapis.com im Head-Bereich, in Theme-Einstellungen oder in Page-Buildern müssen konsequent raus, sonst lädt die Seite die Schrift doppelt.
Die konkrete Umsetzung unterscheidet sich je nach System. Bei WordPress und ähnlichen Baukästen übernehmen spezialisierte Plugins das Herunterladen und Umschreiben der Links automatisch, eine manuelle Kontrolle im Anschluss lohnt sich trotzdem. Bei handgecodeten oder statisch generierten Websites, wie sie Mr.Site einsetzt, werden die Schriftdateien direkt ins Projekt aufgenommen und beim Build mit ausgeliefert, ganz ohne externen Aufruf zur Laufzeit.
Google Fonts ist nur ein Beispiel für ein größeres Muster
Google Fonts steht stellvertretend für eine ganze Gruppe von Diensten, die im Hintergrund automatisch Daten in die USA senden, sobald eine Seite geladen wird: eingebettete YouTube-Videos, Google-Maps-Karten, Chat-Widgets und ähnliche Zusatzdienste funktionieren technisch genauso. Der Artikel Muss die Website in Deutschland gehostet werden ordnet diese ganze Kategorie ein und zeigt, worauf es bei der gesamten Kette eingebundener Dienste ankommt, nicht nur beim Hauptserver. Wer Google Fonts umstellt, sollte bei der Gelegenheit gleich prüfen, welche weiteren Dienste auf derselben Seite still im Hintergrund laufen.
Von der grundsätzlichen Einwilligungspflicht für Cookies und ähnliche Technologien unterscheidet sich Google Fonts in einem Punkt deutlich: Bei lokal eingebundenen Schriften gibt es überhaupt nichts einzuwilligen, weil keine Daten mehr abfließen. Das ist einfacher als der Weg über ein Consent-Tool, den der Artikel Cookie-Banner: Wann eine Website ihn wirklich braucht für Dienste beschreibt, die sich nicht so leicht lokal ersetzen lassen.
Der nächste Schritt für Ihren Betrieb
Die Umstellung auf lokale Schriftarten gehört zu den Punkten, die sich in wenigen Minuten erledigen lassen und danach dauerhaft erledigt bleiben, ohne Banner, ohne Einwilligungslogik, ohne wiederkehrende Prüfung. Mr.Site betreut mehrere hundert Unternehmens-Websites und übernimmt solche technischen Datenschutzpunkte im Rahmen der laufenden Website-Betreuung, inklusive einer kurzen Prüfung, welche weiteren eingebundenen Dienste auf der eigenen Seite unbemerkt Daten nach außen senden.