Google Fonts und die DSGVO: Was Website-Betreiber wissen sollten

Vier Jahre nach dem Münchner Urteil binden noch immer mindestens 7,4 % von 352 untersuchten deutschen Websites Google Fonts direkt ein — gemessen im Quelltext, der tatsächliche Anteil liegt höher. Zur Studie 2026.

Google Fonts sind bequem: eine Zeile im Quelltext, und die Schrift sitzt. Genau diese Zeile ist aber der Grund, warum Tausende deutsche Websites seit 2022 Post von Anwaltskanzleien bekommen haben. Der technische Kern des Problems ist klein — und in einer Viertelstunde behoben. Dieser Text zeigt, wie das geht, welches Gesetz dabei überhaupt greift, und welche drei Fehler auch nach der Umstellung noch dazu führen, dass Daten weiterhin abfließen.

Was Google Fonts überhaupt sind

Google Fonts ist eine kostenlose Sammlung von rund 1.700 Schriftarten, die Google seit 2010 anbietet. Fast jede Schrift daraus darf frei verwendet werden — auf Websites, in Druckerzeugnissen, in Programmen. Bekannte Vertreter sind Roboto, Open Sans, Lato, Montserrat und Poppins.

Der Grund für die enorme Verbreitung ist die Bequemlichkeit: Eine einzige Zeile im Quelltext, und die Schrift erscheint auf jedem Gerät gleich — ohne dass jemand Dateien herunterladen, umwandeln oder Lizenzen prüfen muss. Nach Schätzungen nutzt ein erheblicher Teil aller Websites weltweit mindestens eine dieser Schriften.

Der Haken liegt nicht in der Schrift, sondern im Weg, auf dem sie geladen wird. Genau da beginnt die Datenschutzfrage — und die lässt sich in zwei Varianten aufteilen:

Dieselbe Schrift, dasselbe Aussehen, derselbe Name — nur ein anderer Ladeweg. Das ist der ganze Unterschied, und deshalb muss niemand auf seine Schrift verzichten.

Was technisch passiert

Bindet eine Website eine Schrift so ein:

<link href="https://fonts.googleapis.com/css2?family=Roboto" rel="stylesheet">

dann lädt der Browser des Besuchers die Datei direkt bei Google — nicht dein Server. Damit erfährt Google bei jedem Seitenaufruf:

• die IP-Adresse des Besuchers,
• welche Seite gerade aufgerufen wurde (über den Referrer),
• Browser- und Systemangaben aus dem User-Agent,
• über die Reihenfolge und den Zeitpunkt der Abrufe indirekt auch, wie sich jemand durch die Seite bewegt.

Der Ablauf ist zweistufig, und das erklärt eine häufige Verwirrung: Die erste Anfrage geht an fonts.googleapis.com und holt nur eine kleine CSS-Datei. Darin stehen dann Verweise auf fonts.gstatic.com, von wo die eigentlichen Schriftdateien kommen. Wer nur den einen Host blockiert, hat deshalb oft noch den anderen im Netzwerkprotokoll stehen.

Die IP-Adresse gilt nach der Rechtsprechung des Europäischen Gerichtshofs als personenbezogenes Datum. Ihre Übermittlung an einen Anbieter in den USA braucht deshalb eine Rechtsgrundlage — in der Praxis die Einwilligung der Besucherin oder des Besuchers, und die liegt beim Seitenaufruf noch nicht vor.

Welches Gesetz hier eigentlich greift

Das wird in vielen Ratgebern durcheinandergebracht, deshalb einmal sauber getrennt:

Praktisch bedeutet das: Das Thema lässt sich nicht dadurch erledigen, dass man die Schrift ins Cookie-Banner aufnimmt und abwartet. Es ist keine Cookie-Frage. Es ist eine Frage der Übermittlung — und die passiert, sobald die Seite gerendert wird.

Das TTDSG heißt übrigens seit Mai 2024 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz). Umbenannt wurde es im Zuge des Digitale-Dienste-Gesetzes; die Paragrafen und ihre Inhalte blieben gleich. Wer noch „TTDSG § 25“ liest, liest nichts Falsches, nur etwas Veraltetes.

Das Urteil, das die Diskussion ausgelöst hat

Das Landgericht München I sprach im Januar 2022 einem Websitebesucher 100 Euro Schadensersatz zu, weil dessen IP-Adresse durch eingebundene Google Fonts ohne Einwilligung an Google übermittelt worden war (Urteil vom 20.01.2022, Az. 3 O 17493/20). Ein zweites Verfahren am selben Gericht bestätigte 2023 die Bewertung der dynamischen Einbindung (Az. 4 O 13063/22).

Zur Einordnung gehört aber auch: Ein Landgerichtsurteil ist keine höchstrichterliche Klärung, und andere Gerichte haben ähnliche Fälle teils anders bewertet — unter anderem mit dem Argument, dass ein bloßer Kontrollverlust ohne spürbare Folge noch keinen ersatzfähigen Schaden begründet. Praktisch relevant wurde die Entscheidung trotzdem: In der Folge verschickten mehrere Absender massenhaft Zahlungsaufforderungen an Website-Betreiber, teils automatisiert erzeugt. Gerichte haben genau diese Massenschreiben in mehreren Fällen als rechtsmissbräuchlich eingeordnet.

Die Lösung: Schriften lokal ausliefern

Man muss nicht auf die Schrift verzichten. Die meisten Google-Fonts stehen unter der SIL Open Font License und dürfen selbst gehostet werden. Der Ablauf:

1. Schriftdateien herunterladen. Benötigt werden die .woff2-Dateien in den Schnitten, die die Website wirklich verwendet — meist Normal (400) und Fett (700). Jeder zusätzliche Schnitt kostet Ladezeit. Ein häufiger Fehler ist, alle neun Schnitte mitzunehmen, weil sie im Baukasten angeboten wurden.
2. Nur die benötigten Zeichensätze. Google liefert Schriften in Untermengen aus (latin, latin-ext, cyrillic, greek). Für deutsche Texte reicht in aller Regel latin plus latin-ext. Wer alles mitnimmt, verdreifacht die Dateigröße ohne Nutzen.
3. Auf den eigenen Server legen, zum Beispiel nach /fonts/.
4. Im Stylesheet einbinden statt per <link> zu Google:

@font-face {
  font-family: 'Roboto';
  src: url('/fonts/roboto-v30-latin-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'Roboto';
  src: url('/fonts/roboto-v30-latin-700.woff2') format('woff2');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

5. Alle Verweise auf fonts.googleapis.com und fonts.gstatic.com entfernen — auch in Theme-Einstellungen, Page-Buildern und Plugins.
6. Die preconnect-Zeilen mit entfernen. Dazu unten mehr — das ist der am häufigsten übersehene Rest.
7. Nachprüfen. Der wichtigste Schritt, siehe unten.

font-display: swap sorgt nebenbei dafür, dass Text sofort sichtbar ist, statt bis zum Laden der Schrift unsichtbar zu bleiben. Das verbessert auch die Ladezeit-Bewertung.

Die passenden Dateien und den fertigen @font-face-Block muss man nicht von Hand zusammenstellen: Es gibt freie Werkzeuge, die aus einer Google-Fonts-Auswahl ein ZIP mit den .woff2-Dateien und dem passenden CSS erzeugen. Gesucht wird nach „google webfonts helper“.

Variable Schriften: eine Datei statt sechs

Viele Google-Fonts gibt es inzwischen als variable font — eine einzige Datei, die alle Strichstärken zwischen dünn und fett enthält. Statt sechs Dateien lädt der Browser eine, und die Einbindung sieht so aus:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-variable.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

Das ist meist kleiner als drei einzelne Schnitte und spart einen Teil der Anfragen. Lohnt sich vor allem, wenn eine Seite ohnehin mehrere Stärken verwendet.

Die Umstellung in den gängigen Systemen

WordPress

Der häufigste Fall — und der mit den meisten Verstecken. Zu prüfen sind vier Stellen:

• Das Theme. Viele moderne Themes (Astra, GeneratePress, Kadence, Blocksy) haben in den Einstellungen eine Option wie „Google Fonts lokal laden“ oder „Load fonts locally“. Ein Klick, fertig. Ältere oder selbst gebaute Themes laden die Schrift dagegen fest im functions.php oder im Stylesheet.
• Der Page-Builder. Elementor bringt eine eigene Schriftverwaltung mit und lädt standardmäßig von Google; in neueren Versionen lässt sich das unter den erweiterten Einstellungen abschalten. Divi und WPBakery haben ähnliche Schalter an anderer Stelle.
• Plugins. Formular-, Slider- und Bewertungs-Plugins bringen häufig ihre eigene Schrift mit — und laden sie unabhängig von allen Theme-Einstellungen.
• Der Block-Editor selbst. Seit WordPress 6.x können Block-Themes Schriften über theme.json einbinden. Steht dort eine Google-URL, hilft keine Theme-Option.

Es gibt Plugins, die die Umstellung automatisch übernehmen und die Dateien herunterladen. Sie funktionieren oft gut — verlass dich aber nicht darauf, sondern miss das Ergebnis. Ein Plugin, das nach einem Theme-Update nicht mehr greift, meldet sich nicht.

Shopify

Shopify liefert eine eigene Schriftbibliothek aus, die von Shopifys eigenen Servern kommt — damit entfällt das Problem für diese Schriften. Wer aber ein Theme aus dem Store gekauft oder anpassen lassen hat, findet nicht selten trotzdem einen Google-Fonts-Aufruf im theme.liquid. Dort suchen und ersetzen; die Schriftdateien lassen sich über die Asset-Verwaltung hochladen und mit {{ 'name.woff2' | asset_url }} einbinden.

TYPO3, Joomla, Drupal

Hier liegt die Einbindung fast immer im Template beziehungsweise Theme des jeweiligen Systems und lässt sich direkt bearbeiten. In TYPO3 lohnt zusätzlich ein Blick in die TypoScript-Konfiguration (page.includeCSS), in Joomla in die Template-Parameter.

Webflow, Squarespace, Wix, Jimdo

Hier wird es unangenehm ehrlich: Bei geschlossenen Baukastensystemen lässt sich das Laden externer Schriften nicht immer abstellen, weil man an den ausgelieferten Quelltext nicht herankommt. Webflow erlaubt das Hochladen eigener Schriftdateien und ist damit lösbar. Bei den anderen hängt es von Tarif und aktueller Plattformversion ab.

Wenn sich der Abruf nicht abstellen lässt, bleiben zwei realistische Wege: die Schrift auf eine plattformeigene umstellen, die vom Anbieter selbst ausgeliefert wird — oder die Übermittlung in der Datenschutzerklärung sauber benennen und die Einwilligung tatsächlich vorschalten. Was nicht funktioniert, ist die Sache zu verschweigen und zu hoffen, dass niemand ins Netzwerkprotokoll schaut.

Der am häufigsten übersehene Rest: preconnect

Fast jede Anleitung nennt den <link rel="stylesheet">. Kaum eine nennt die zwei Zeilen, die meist direkt darüber stehen:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Diese Zeilen laden keine Schrift. Sie weisen den Browser an, schon einmal eine Verbindung zu Google aufzubauen, damit es später schneller geht. Genau dabei wird aber bereits die IP-Adresse übertragen — auch dann, wenn die Schrift selbst inzwischen lokal liegt. Dasselbe gilt für rel="dns-prefetch".

Wer nach der Umstellung im Netzwerkprotokoll noch eine einzelne Verbindung zu fonts.gstatic.com ohne geladene Datei sieht, hat mit hoher Wahrscheinlichkeit genau das übersehen.

Was das Selbsthosten nicht löst

Die Schriftfrage ist nur ein Teilaspekt. Dieselbe Rechtslage gilt für jeden weiteren Dienst, der direkt im Browser des Besuchers geladen wird:

• Google Maps — die eingebettete Karte lädt sofort beim Seitenaufruf. Lösung: Vorschaubild mit Klick zum Laden, oder eine Kartenlösung aus der EU.
• YouTube-Videos — auch im „erweiterten Datenschutzmodus“ (youtube-nocookie.com) wird beim Laden eine Verbindung aufgebaut. Auch hier hilft eine Zwei-Klick-Lösung.
• reCAPTCHA — einer der hartnäckigsten Fälle, weil er oft im Kontaktformular steckt. Es gibt Alternativen, die ohne Drittanbieter auskommen.
• Font Awesome, wenn über deren CDN eingebunden — dasselbe Problem, andere Domain.
• jQuery und andere Bibliotheken über ein CDN — unauffällig, aber technisch identisch.
• Adobe Fonts (Typekit) — ebenfalls ein US-Dienst mit demselben Muster.

Ein Sonderfall sind Schrift-Dienste mit Sitz in der EU. Sie lösen die Drittlandfrage, nicht aber die Frage der Übermittlung an einen Dritten überhaupt. Wer ganz sicher gehen will, liefert selbst aus — das ist ohnehin die schnellste Variante, weil eine Verbindung weniger aufgebaut wird.

Selbst nachmessen — in zwei Minuten

Der häufigste Irrtum: Im Quelltext der Startseite steht nichts mehr von Google, also ist es erledigt. Tatsächlich werden Schriften oft aus einer CSS-Datei heraus nachgeladen, wo sie im Seitenquelltext gar nicht auftauchen. Sichtbar wird das nur, wenn man die tatsächlich geladenen Ressourcen betrachtet:

1. Seite im Browser öffnen, Entwicklerwerkzeuge starten (F12, am Mac ⌘⌥I).
2. Auf den Reiter Netzwerk wechseln.
3. Die Seite neu laden (wichtig — vorher aufgebaute Verbindungen erscheinen sonst nicht).
4. Im Filterfeld google eingeben.
5. Bleibt die Liste leer, ist die Startseite sauber.

Genau das prüft Apexly automatisch — und meldet zusätzlich weitere direkt eingebundene Dienste aus Drittländern, etwa Google Maps, YouTube, reCAPTCHA oder externe CDNs.

Wie häufig das Problem wirklich ist

Bei unseren eigenen Messungen über rund 4.000 Websites lag der Anteil mit extern geladenen Google Fonts bei etwa 10 Prozent — mit einem klaren Muster: Je kleiner die Website, desto häufiger. Bei sehr großen, bekannten Seiten waren es rund 6 Prozent, bei kleinen Unternehmensseiten 12 bis 13 Prozent.

Der wahrscheinlichste Grund ist banal: Große Seiten haben jemanden, der auf so etwas achtet. Kleine Seiten laufen oft jahrelang unverändert weiter, nachdem sie einmal gebaut wurden — und wurden in einer Zeit gebaut, in der die Google-Zeile Standard war.

Die fünf häufigsten Fehler auf einen Blick

Häufige Fragen

Was sind Google Fonts eigentlich?

Eine kostenlose Sammlung von rund 1.700 Schriftarten, die Google seit 2010 bereitstellt — darunter Roboto, Open Sans und Montserrat. Fast alle stehen unter einer freien Lizenz und dürfen ohne Gebühr verwendet werden. Das Datenschutzproblem betrifft nicht die Schriften selbst, sondern nur die Art, wie sie geladen werden.

Was ist fonts.gstatic.com?

Das ist der Server, von dem Google die eigentlichen Schriftdateien ausliefert. Der Ablauf ist zweistufig: fonts.googleapis.com liefert zuerst eine kleine CSS-Datei, darin stehen Verweise auf fonts.gstatic.com, von wo die Schrift selbst kommt. Wer nur den ersten Host entfernt, hat deshalb oft noch Verbindungen zum zweiten im Protokoll.

Sind Google Fonts generell verboten?

Nein. Verboten ist nichts — problematisch ist die Übertragung der IP-Adresse an Google ohne Einwilligung. Wer die Schriftdateien auf den eigenen Server legt, nutzt Google Fonts weiter, ohne dass Besucherdaten das Haus verlassen.

Reicht ein Cookie-Banner als Lösung?

Nur, wenn die Schrift tatsächlich erst nach der Einwilligung geladen wird. Ein Banner, das eingeblendet wird, während die Schrift im Hintergrund bereits geladen wurde, ändert an der Übertragung nichts. Das lokale Einbinden ist der einfachere und sicherere Weg — und der einzige, der auch ohne Zustimmung der Besucher funktioniert.

Wie erkenne ich, ob meine Website Google Fonts extern lädt?

Entwicklerwerkzeuge öffnen, Reiter Netzwerk, Seite neu laden, nach „google“ filtern. Der reine Blick in den HTML-Quelltext reicht nicht, weil viele Themes und Plugins Schriften aus CSS-Dateien heraus nachladen.

Darf ich die Schriftdateien überhaupt selbst hosten?

Bei den allermeisten Google-Fonts ja — sie stehen unter der SIL Open Font License, die das ausdrücklich erlaubt. Die Lizenz jeder einzelnen Schrift ist auf ihrer Seite bei Google Fonts angegeben.

Ich habe umgestellt, im Protokoll steht trotzdem noch fonts.gstatic.com. Woran liegt das?

Mit hoher Wahrscheinlichkeit an einer preconnect- oder dns-prefetch-Zeile, die stehen geblieben ist. Sie lädt keine Datei, baut aber trotzdem eine Verbindung auf — und überträgt dabei die IP-Adresse.

Was ist mit Baukastensystemen, bei denen ich das nicht abstellen kann?

Dann bleibt der Wechsel auf eine plattformeigene Schrift, oder — wenn auch das nicht geht — die Übermittlung in der Datenschutzerklärung zu benennen und die Einwilligung tatsächlich vorzuschalten. Verschweigen ist keine Option, weil sich der Abruf von außen in Sekunden nachweisen lässt.

Betrifft das nur Google Fonts?

Nein. Dieselbe Frage stellt sich bei jedem direkt eingebundenen Dienst aus einem Drittland — etwa Google Maps, YouTube-Videos, reCAPTCHA, Font Awesome, Adobe Fonts oder Skripte von CDN-Anbietern.

Heißt das Gesetz jetzt TTDSG oder TDDDG?

TDDDG. Das TTDSG wurde im Mai 2024 in Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz umbenannt, inhaltlich blieben die Vorschriften gleich. Für Schriften ist ohnehin eher die DSGVO einschlägig als § 25 TDDDG.

Stand: 6. August 2026. Dieser Text erklärt technische Zusammenhänge und ist keine Rechtsberatung.