Google Fonts und DSGVO: Warum Ihre Website abmahnbar sein kann

Die kurze Antwort zuerst: Das Problem sind nicht die Schriften selbst, sondern wie sie geladen werden. Wenn Ihre Website eine Schriftart beim Aufruf direkt von einem externen Server nachlädt, wird dabei die IP-Adresse jedes Besuchers an diesen Server übertragen — in aller Regel ohne Einwilligung. Genau das gilt als datenschutzrechtlich heikel und hat eine ganze Welle von Abmahnschreiben ausgelöst.

Die gute Nachricht: Sie müssen Ihre Schriften nicht ändern. Sie müssen sie nur von Ihrem eigenen Server ausliefern statt von einem fremden. Das ist in einer halben Stunde erledigt und in diesem Beitrag Schritt für Schritt erklärt.

Hinweis: Dieser Beitrag ist eine technische und allgemeine Orientierung, keine Rechtsberatung. Bei konkreten Zweifelsfällen — etwa wenn ein Schreiben bereits vorliegt — fragen Sie eine auf IT-Recht spezialisierte Kanzlei.

Der 2-Minuten-Selbsttest

Bevor Sie irgendetwas ändern, prüfen Sie, ob Sie überhaupt betroffen sind. Es gibt zwei schnelle Wege:

Weg 1 — Quelltext durchsuchen. Öffnen Sie Ihre Startseite im Browser und drücken Sie Strg + U (Windows) bzw. Cmd + Alt + U (Mac). Der Seitenquelltext erscheint. Suchen Sie mit Strg + F nach diesen beiden Adressen:

• fonts.googleapis.com
• fonts.gstatic.com

Findet der Browser einen Treffer, lädt Ihre Seite Schriften remote — Sie sind betroffen.

Weg 2 — Netzwerk-Tab der Entwicklertools. Drücken Sie F12, wechseln Sie in den Reiter „Netzwerk" (Network) und laden Sie die Seite neu. Filtern Sie nach „font" oder tippen Sie den Domainnamen ins Suchfeld. Sehen Sie Anfragen an fremde Server, die Schriftdateien (.woff2, .ttf) ausliefern, haben Sie Ihre Antwort.

Wichtig: Der Test muss auf der live im Netz stehenden Seite laufen, nicht nur in einer lokalen Vorschau. Und prüfen Sie mehrere Seitentypen — Startseite, eine Unterseite, den Blog. Manche Baukästen und Theme-Plugins laden Schriften nur an bestimmten Stellen nach.

Warum das rechtlich heikel ist

Auslöser der Debatte war ein oft zitiertes Urteil des Landgerichts München I aus dem Januar 2022. Das Gericht entschied, dass das dynamische Nachladen von Google Fonts von einem externen Server die IP-Adresse des Nutzers ohne dessen Einwilligung überträgt und damit gegen das Recht auf informationelle Selbstbestimmung verstößt. Der klagenden Person wurde ein Schadensersatz von 100 Euro zugesprochen.

Das ist der belegbare Fakt. Wie es weiterging, ist eher eine Einschätzung: Auf das Urteil folgten Massen-Abmahnschreiben, oft von einzelnen Personen oder Kanzleien in großer Stückzahl verschickt, die pauschal Schadensersatz und die Erstattung von Anwaltskosten forderten. Teile davon wurden später von anderen Gerichten als rechtsmissbräuchlich eingeordnet, weil sie erkennbar auf Masse und Einnahmen zielten. Das nimmt aber weder das Grundproblem weg noch die Unsicherheit für Website-Betreiber.

Praktisch bedeutet das: Die Rechtslage im Detail ist umstritten, das technische Risiko ist es nicht. Wer die IP-Übertragung abstellt, hat den Angriffspunkt schlicht entfernt — und muss sich über den Ausgang künftiger Verfahren keine Gedanken mehr machen.

Die Lösung: Schriften lokal hosten

Der Kern ist einfach: Sie laden die Schriftdateien einmal herunter, legen sie auf Ihren eigenen Server und binden sie per CSS ein. Danach fällt der externe Aufruf weg — es fließt keine Besucher-IP mehr an Dritte. Fast alle gängigen Web-Schriften sind unter freien Lizenzen (OFL, Apache) veröffentlicht, die genau dieses Selbst-Hosting ausdrücklich erlauben.

Schritt 1 — Schriftdateien besorgen. Laden Sie die benötigten Schnitte im modernen Format .woff2 herunter. Nehmen Sie nur die Stärken, die Sie wirklich nutzen (z. B. Regular 400 und Bold 700) — jede zusätzliche Datei kostet Ladezeit.

Schritt 2 — Dateien ablegen. Legen Sie die Dateien in einen Ordner Ihres Servers, etwa /fonts/.

Schritt 3 — Per @font-face einbinden. Ergänzen Sie Ihr Stylesheet um einen Block pro Schnitt:

@font-face {
  font-family: 'Hausschrift';
  src: url('/fonts/hausschrift-regular.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'Hausschrift';
  src: url('/fonts/hausschrift-bold.woff2') format('woff2');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

Anschließend nutzen Sie die Schrift wie gewohnt, zum Beispiel:

body { font-family: 'Hausschrift', system-ui, sans-serif; }

Das font-display: swap; sorgt dafür, dass der Text sofort in einer Ersatzschrift sichtbar ist und nicht unsichtbar bleibt, bis die Datei geladen hat.

Schritt 4 — Den externen Aufruf entfernen. Suchen Sie im HTML nach der Zeile, die auf fonts.googleapis.com verweist — meist ein <link>-Tag im Kopfbereich — und löschen Sie sie. Gleiches gilt für @import-Zeilen mit dieser Adresse im CSS. Wird das nicht entfernt, lädt die Seite die Schrift doppelt: einmal lokal und einmal weiter von extern.

Schritt 5 — Nachprüfen. Wiederholen Sie den 2-Minuten-Selbsttest von oben. Kein Treffer mehr auf die beiden Domains? Dann ist der Font-Teil erledigt.

Wer mit WordPress, einem Baukasten oder einem Theme arbeitet, findet den externen Aufruf oft nicht im eigenen HTML, sondern tief im Theme oder in einem Plugin. Viele Themes bieten inzwischen eine Einstellung „Fonts lokal laden" oder „Google Fonts deaktivieren". Prüfen Sie das — und testen Sie danach erneut, denn nicht jede Einstellung hält, was sie verspricht.

Weiterdenken: nicht nur die Schriften

Schriften sind der bekannteste Fall, aber nicht der einzige. Jedes Element, das beim Seitenaufruf etwas von einem fremden Server nachlädt, überträgt dabei die IP des Besuchers. Prüfen Sie im Netzwerk-Tab, welche fremden Domains Ihre Seite sonst noch kontaktiert. Typische Kandidaten:

• Externe Skript-Bibliotheken (z. B. JavaScript-Frameworks oder Icon-Sammlungen, die von einem CDN geladen werden) — lassen sich fast immer ebenfalls lokal hosten.
• Eingebettete Karten. Ein Kartendienst, der direkt im Seitenlayout steckt, lädt beim Aufruf mit und funkt die IP weiter. Alternative: ein statisches Kartenbild mit Link, oder die Karte erst nach einem Klick laden.
• Video-Einbettungen. Ein Player-Fenster einer Videoplattform baut oft schon beim Seitenaufruf eine Verbindung auf. Besser: erst auf Klick nachladen (Vorschaubild statt Live-Player).
• Social-Media-Widgets und Like-Buttons, die als fertiger Code eingebunden sind.
• Externe Statistik- und Tracking-Dienste, die vor der Einwilligung feuern.

Die Faustregel: Alles, was für die Grunddarstellung nötig ist (wie Schriften und Skripte), gehört auf den eigenen Server. Alles, was Besucherdaten an Dritte gibt (Karten, Videos, Tracking), sollte erst nach aktiver Einwilligung laden — ein Cookie-Banner allein reicht nicht, wenn die Inhalte schon davor geladen werden.

Bei uns ist das der Normalfall

Wir bauen Websites grundsätzlich so, dass Schriften lokal ausgeliefert werden — kein einziger externer Font-Request beim Seitenaufruf, in keinem Projekt. Das ist bei uns kein Extra, das man dazubestellt, sondern der Ausgangszustand. Dieselbe Logik gilt für Skripte und Einbettungen: was Besucherdaten an Fremdserver geben würde, wird entweder selbst gehostet oder gar nicht erst blind eingebunden.

Wenn Sie sehen wollen, wie das in echten Projekten aussieht, können Sie im Showroom selbst den Test machen: Seite öffnen, F12, Netzwerk-Tab — und schauen, welche fremden Domains kontaktiert werden. Der Punkt eines Portfolios ist ja genau, dass man es nachprüfen kann.

Wer gerade ohnehin über eine neue oder überarbeitete Website nachdenkt: In den Beiträgen Was eine Website für kleine Unternehmen wirklich kostet und Warum Ihre Firma bei Google nicht auftaucht gehen wir auf Budget und Sichtbarkeit ein. Und wenn Sie unsicher sind, ob Ihre bestehende Seite sauber ist, schauen Sie einfach in den Showroom und melden sich — ein kurzer Blick in den Netzwerk-Tab sagt schon viel.

Häufige Fragen

Ist es jetzt verboten, Google Fonts zu benutzen?

Nein. Verboten ist nur das unangekündigte Remote-Laden vom fremden Server, weil dabei ungefragt die Besucher-IP übertragen wird. Genau dieselben Schriften dürfen Sie weiter verwenden, wenn Sie die Dateien selbst hosten. Die Lizenzen der meisten Web-Schriften erlauben das ausdrücklich.

Bekomme ich wirklich eine Abmahnung, wenn ich nichts ändere?

Sicher ist das nicht — viele der Massen-Schreiben wurden von Gerichten als rechtsmissbräuchlich eingestuft, und nicht jede Seite wird überhaupt geprüft. Sicher ist nur: Solange die IP-Übertragung läuft, existiert der Angriffspunkt. Ihn zu entfernen kostet wenig Zeit und nimmt das Thema dauerhaft vom Tisch.

Reicht ein Cookie-Banner, um das Problem zu lösen?

In den meisten Fällen nicht. Schriften und Skripte laden typischerweise sofort beim Seitenaufruf — also bevor der Besucher im Banner überhaupt etwas anklicken konnte. Die Übertragung hätte dann schon stattgefunden. Wirksam ist nur, den externen Aufruf technisch abzustellen (lokal hosten) oder ihn tatsächlich erst nach der Einwilligung auszulösen.

Ich habe eine Baukasten- oder WordPress-Seite — muss ich trotzdem etwas tun?

Ja, oft gerade dann. Viele Themes und Plugins laden Schriften standardmäßig remote, ohne dass man es im eigenen HTML sieht. Machen Sie den Selbsttest und suchen Sie in den Einstellungen nach einer Option wie „Fonts lokal laden". Danach unbedingt erneut prüfen, ob der externe Aufruf wirklich weg ist.

Woran erkenne ich nach der Umstellung, dass alles sauber ist?

Am selben 2-Minuten-Test: Quelltext oder Netzwerk-Tab dürfen keine Treffer mehr auf fonts.googleapis.com oder fonts.gstatic.com zeigen — und im Netzwerk-Tab sollten die Schriftdateien jetzt von Ihrer eigenen Domain kommen.