- Extern geladene Google Fonts übermitteln die IP-Adresse jedes Besuchers an Google-Server in den USA. Ohne Einwilligung ist das nach Art. 6 DSGVO unzulässig.
- Das Landgericht München I hat am 20.01.2022 (Az. 3 O 17493/20) einem Websitebetreiber 100 Euro Schadensersatz für genau diese Praxis auferlegt.
- Die Lösung ist technisch einfach: Fonts einmal herunterladen, auf dem eigenen Server hosten und per @font-face einbinden. Ein externer Aufruf an Google entfällt vollständig.
- Wer Divi, Elementor oder ein beliebiges Theme nutzt, muss prüfen, ob der Page-Builder Fonts selbst nachlädt. Das Abschalten im Theme-Panel reicht oft nicht.
Schriftarten über Google Fonts einzubinden ist bequem. Google stellt tausende Schriften kostenlos bereit, der entsprechende Link-Tag ist in Sekunden gesetzt. Das Problem liegt nicht in den Fonts selbst, sondern darin, wie der Browser sie lädt. Ruft eine Website eine Schrift von Googles Server ab, schickt der Browser dabei automatisch die IP-Adresse des Besuchers mit. Google verarbeitet diese Adresse auf Servern in den USA. Für europäische Websites ist das eine Übermittlung personenbezogener Daten ohne Rechtsgrundlage, und deutsche Gerichte haben das bereits sanktioniert.
Warum externe Google Fonts ein Datenschutzproblem sind
Wenn eine Website die Schriftart Inter oder Roboto über den klassischen Link-Tag einbindet, sieht das im Quellcode so aus:
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap">Beim Aufruf der Seite schickt der Browser des Besuchers eine Anfrage an fonts.googleapis.com. Diese Anfrage enthält technisch notwendig die IP-Adresse des Anfragenden, außerdem den Referrer (also die URL der Ihrer Website), den Browser-User-Agent und weitere Header. Google verarbeitet diese Daten auf Servern außerhalb der EU, in der Regel in den USA.
Die entscheidende DSGVO-Frage lautet: Auf welcher Rechtsgrundlage nach Art. 6 DSGVO stützt sich diese Datenübermittlung? Einwilligung (Art. 6 Abs. 1 lit. a) liegt nicht vor, weil der Besucher vor dem ersten Seitenaufruf keine solche erteilt hat. Vertragserfüllung (lit. b) scheidet aus. Berechtigte Interessen (lit. f) hat das LG München im Google-Fonts-Urteil ausdrücklich abgelehnt: Google Fonts lassen sich auch lokal hosten, das berechtigte Interesse des Betreibers an Bequemlichkeit überwiegt das Persönlichkeitsrecht des Besuchers nicht.
Google selbst bietet seit Jahren die Möglichkeit, alle Fonts herunterzuladen. Der externe Aufruf ist also keine technische Notwendigkeit, sondern eine Entscheidung des Websitebetreibers für Komfort auf Kosten des Datenschutzes der Besucher.
Das LG-München-Urteil und seine Folgen
Im konkreten Fall besuchte der Kläger eine Website, die Google Fonts dynamisch eingebunden hatte. Dabei wurde seine IP-Adresse an Google übermittelt. Das Gericht stellte fest, dass diese Übermittlung das allgemeine Persönlichkeitsrecht in Form des Rechts auf informationelle Selbstbestimmung verletzte. Die Begründung: Der Kläger habe keine Einwilligung zur Übermittlung seiner Daten an Google gegeben, und ein berechtigtes Interesse des Betreibers scheide aus, weil Google Fonts ohne jede Einschränkung auch lokal gehostet werden könnten.
Das Gericht sprach dem Kläger 100 Euro Schadensersatz nach Art. 82 Abs. 1 DSGVO zu. Diese Summe klingt gering, aber das Urteil hat eine weit größere Bedeutung als die Zahl vermuten lässt. Es war einer der ersten deutschen Richtersprüche, der einen DSGVO-Schadensersatzanspruch für einen Kontrollverlust über personenbezogene Daten bejahte, auch ohne konkreten materiellen Schaden. Das Urteil ist seither in der datenschutzrechtlichen Literatur und von Aufsichtsbehörden vielfach zitiert.
Praktisch folgte auf das Urteil eine Abmahnwelle. Einige Rechtsanwälte verschickten in großer Zahl Abmahnungen an Websitebetreiber wegen dynamisch eingebundener Google Fonts. Diese Welle ebbte ab, aber die rechtliche Ausgangslage hat sich nicht geändert. Datenschutzbehörden mehrerer Bundesländer verweisen in ihren Hinweisen für Websitebetreiber auf das Problem externer Webfonts. Das Risiko bleibt.
| Merkmal | Extern (Google Server) | Lokal (eigener Server) |
|---|---|---|
| IP-Adresse des Besuchers übermittelt | Ja, bei jedem Seitenaufruf | Nein |
| Datenübertragung in die USA | Ja | Nein |
| Einwilligung erforderlich | Ja (nach LG München) | Nein |
| Rechtsgrundlage Art. 6 DSGVO vorhanden | Nicht ohne Weiteres | Nicht relevant |
| Abmahnrisiko | Vorhanden | Nicht vorhanden |
| Ladezeit (DNS-Lookup, TLS-Handshake) | Zusätzlich zu eigenem Server | Nur eigener Server |
| Kontrolle über Cache-Header | Nein (Google setzt sie) | Vollständig |
Fonts lokal hosten: So funktioniert es
Der Ablauf besteht aus drei Schritten.
Schritt 1: Schriftdateien herunterladen
Das praktischste Werkzeug dafür ist der Google Webfonts Helper. Dort wählt man die gewünschte Schrift und die benötigten Schnitte (Regular, Bold usw.), der Dienst stellt sofort den fertigen @font-face-CSS-Code und alle Fontdateien als ZIP zum Download bereit. Für moderne Websites reicht das Format WOFF2: Es wird von allen aktuellen Browsern unterstützt und bietet den besten Kompressionsgrad.
Wer direkt bei Google Fonts bleibt, findet seit einiger Zeit auch dort einen Download-Button. Man wählt eine Schrift, klickt oben rechts auf das Herunterladen-Symbol und erhält eine ZIP-Datei mit den TTF-Dateien. Für den Web-Einsatz sollte man TTF zusätzlich in WOFF2 umwandeln, was Werkzeuge wie Font Squirrel Webfont Generator übernehmen.
Schritt 2: Dateien hochladen
Die WOFF2-Dateien kommen in ein eigenes Verzeichnis innerhalb des Child-Themes, zum Beispiel /wp-content/themes/mein-child-theme/fonts/. Nie in das Parent-Theme laden: Updates überschreiben die Dateien.
Schritt 3: Per @font-face einbinden
In der style.css des Child-Themes (oder in einer eigenen CSS-Datei, die über wp_enqueue_style geladen wird) kommt der @font-face-Block. Das Format WOFF2 zuerst, als einziges, wenn moderne Browser das Ziel sind.
Für Entwickler · überspringbar
Profi-Block: @font-face und wp_enqueue_style
Dieser Abschnitt richtet sich an Entwickler. Wer ein Plugin nutzt, kann ihn überspringen.
@font-face in der CSS-Datei des Child-Themes:
@font-face {
font-family: 'Inter';
src: url('fonts/inter-v13-latin-regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
}
@font-face {
font-family: 'Inter';
src: url('fonts/inter-v13-latin-700.woff2') format('woff2');
font-weight: 700;
font-style: normal;
font-display: swap;
}Das Attribut font-display: swap sorgt dafür, dass der Browser sofort die Systemschrift zeigt und die eigene Schrift einwechselt, sobald sie geladen ist. Das verhindert den unsichtbaren Text während des Ladens (FOIT) und wirkt sich positiv auf den Largest Contentful Paint aus. Die vollständige @font-face-Referenz liegt bei MDN.
Schrift per wp_enqueue_style einbinden:
Wenn die CSS-Datei nicht ohnehin über style.css des Child-Themes läuft, lässt sie sich über die functions.php des Child-Themes einreihen:
add_action( 'wp_enqueue_scripts', 'mein_theme_fonts' );
function mein_theme_fonts() {
wp_enqueue_style(
'mein-theme-fonts',
get_stylesheet_directory_uri() . '/css/fonts.css',
array(),
'1.0.0'
);
}Die offizielle Dokumentation zu wp_enqueue_style bei WordPress Developer findet man dort.
Preload für den kritischen Font (optional, aber empfohlen):
Wer den LCP-Wert weiter verbessern will, kann die Hauptschrift per link rel="preload" im <head> vorabrufen. In WordPress geht das über den wp_head-Hook:
add_action( 'wp_head', 'mein_theme_preload_font', 1 );
function mein_theme_preload_font() {
echo '<link rel="preload" href="' . get_stylesheet_directory_uri() . '/fonts/inter-v13-latin-regular.woff2" as="font" type="font/woff2" crossorigin>';
}Nur die Schrift vorab laden, die tatsächlich im ersten sichtbaren Viewport steht. Zu viele Preloads heben den Effekt auf.
Wenn ein Plugin sinnvoller ist:
Für Websites ohne eigene Entwickler ist das Plugin OMGF (Optimize My Google Fonts) eine bewährte Lösung. Es analysiert die geladenen Google Fonts automatisch, lädt die Dateien auf den eigenen Server und ersetzt die externen Aufrufe.
Divi, Elementor und Co. laden Fonts oft selbst nach
Hier liegt der häufigste Fehler in der Praxis: Ein Betreiber aktiviert in den Divi-Einstellungen unter „Leistung“ die Option „Google Fonts deaktivieren“ und glaubt, das Problem sei gelöst. Es ist es oft nicht. Divi lädt unter Umständen trotzdem bestimmte Icon-Fonts (etwa das Divi-Icon-Set) von externen Servern nach. Elementor hat ähnliche Fallstricke. Auch WooCommerce-Plugins bringen gelegentlich eigene Font-Aufrufe mit.
Nur der Blick in den Netzwerk-Tab des Browsers (oder ein externer Scanner) zeigt die Wahrheit. Wie das geht, erklärt der Abschnitt weiter unten.
Für Divi-Nutzer ohne Entwicklerkenntnisse kann der Eintrag in der functions.php des Child-Themes externe Aufrufe zuverlässig unterbinden:
// Google Fonts aus Divi entfernen
add_filter( 'et_builder_get_fonts', function( $fonts ) {
return array();
}, 100 );
// Fallback: alle Google Fonts aus dem Head entfernen
add_action( 'wp_print_styles', function() {
global $wp_styles;
foreach ( $wp_styles->queue as $handle ) {
if ( isset( $wp_styles->registered[$handle] ) ) {
$src = $wp_styles->registered[$handle]->src;
if ( strpos( $src, 'fonts.googleapis.com' ) !== false ) {
wp_dequeue_style( $handle );
}
}
}
}, 100 );
Nach dieser Maßnahme unbedingt mit dem Netzwerk-Tab nachprüfen, ob wirklich kein Request mehr an fonts.googleapis.com geht.
Prüfen, ob noch externe Aufrufe rausgehen
Wer sicherstellen will, dass keine externen Font-Requests mehr die Website verlassen, hat zwei zuverlässige Wege.
Variante 1: Entwicklertools im Browser
Im Chrome oder Firefox mit F12 die Entwicklertools öffnen, auf den Tab „Netzwerk“ (Network) wechseln und die Seite neu laden. Im Filter-Feld „google“ eingeben. Erscheinen dort Requests an fonts.googleapis.com oder fonts.gstatic.com, laufen noch externe Aufrufe. Beide Domains müssen komplett leer bleiben.
Variante 2: Externer Scanner
Externe Scanner wie Lighthouse zeigen im Audit „Eliminate render-blocking resources“ oft Google Fonts-Requests als Problem auf. Daneben gibt es auf Datenschutz spezialisierte Prüfdienste, die externe Ressourcen aufzeichnen. Der Vorteil: Sie simulieren einen Erstaufruf ohne Cache, was näher an der realen Nutzersituation ist.
Wichtig: Den Test im Inkognito-Modus oder mit geleertem Cache durchführen, weil ein bereits im Browser gecachter Font keinen neuen Request auslöst und ein falsches sauberes Bild erzeugt.
Adobe Fonts und andere CDN-Schriftdienste
Wer Adobe Fonts über den Typekit-Code einbindet, schickt bei jedem Seitenaufruf eine Anfrage an use.typekit.net. Adobe verarbeitet dabei nach eigenen Angaben unter anderem die IP-Adresse des Nutzers und den Hostnamen der aufrufenden Seite. Adobe ist zwar dem EU-US Data Privacy Framework beigetreten, was die Drittlandübermittlung etwas vereinfacht, aber nicht die Frage nach einer Einwilligung auflöst. Wer Adobe Fonts ohne Consent-Banner einsetzt, steht vor demselben rechtlichen Grundproblem wie bei Google Fonts.
Font Awesome wird häufig über das CDN unter cdnjs.cloudflare.com oder den eigenen Font-Awesome-Servern eingebunden. Auch dort gilt: Jeder externe Request übermittelt technisch bedingt die IP-Adresse. Die DSGVO-konforme Alternative ist jeweils die lokale Einbindung der Icon-Font-Dateien.
Die Regel ist damit allgemeingültig: Jeder Font oder jede Icon-Font, die von einem Drittserver geladen wird, ist ein potenzieller Datenschutz-Fallstrick. Die Frage vor jeder Einbindung lautet: Liegt eine Rechtsgrundlage vor, oder können wir diese Datei lokal bereitstellen?
Performance-Nebeneffekt: lokal kann schneller sein
Viele Websitebetreiber nehmen an, Google-Server seien schneller als ihr eigenes Hosting. In der Praxis stimmt das nicht mehr unbedingt. Der Vorteil, den Google früher durch gemeinsam gecachte Fonts hatte, ist seit Jahren entfallen: Browser implementieren aus Datenschutzgründen partitionierte Caches, was bedeutet, dass eine Schrift, die auf Website A von Google geladen wurde, für Website B nicht mehr aus dem Cache geliefert wird. Jede Website beginnt mit einem frischen Font-Download von Googles Server.
Lokal gehostete Fonts bringen dagegen mehrere messbare Vorteile. Erstens entfällt der DNS-Lookup für fonts.googleapis.com und fonts.gstatic.com. Zweitens gibt es keinen zusätzlichen TLS-Handshake zu einem dritten Server. Drittens kann der Betreiber selbst die Cache-Header setzen und die Fonts langfristig im Browser-Cache halten. In realen Messungen verbessert sich dadurch der Largest Contentful Paint spürbar, wenn der Font im kritischen Renderpfad liegt und per Preload früh geladen wird.
Mehr zu Performance-Stellschrauben speziell für WordPress-Seiten findet sich im Artikel WordPress Speed-Optimierung: Die 10 Maßnahmen mit dem besten Aufwand-Nutzen.
Ein Fall aus der Praxis
In einem Projekt für einen regionalen Dienstleister hatten wir Google Fonts zunächst über das Theme eingebunden. Der Betreiber hatte den zugehörigen Eintrag in den Theme-Einstellungen deaktiviert, aber den Netzwerk-Tab nie geöffnet. Als wir die Website im Rahmen eines Datenschutz-Checks aufgerufen haben, luden trotzdem noch zwei Requests an fonts.googleapis.com und fonts.gstatic.com: einmal die Icon-Schrift des Themes, einmal eine von einem installierten Kontaktformular-Plugin eigenständig angeforderte Schrift.
Beides war dem Betreiber nicht bewusst. Die Lösung war, die Fonts manuell herunterzuladen, lokal einzubinden und die externen Aufrufe im wp_print_styles-Hook abzufangen. Danach: kein einziger Request mehr an Google-Server. Die Ladezeit sank gleichzeitig um rund 200 Millisekunden, weil zwei DNS-Lookups und zwei TLS-Handshakes entfielen.
Das Beispiel zeigt: Das Problem liegt nicht darin, dass Betreiber leichtfertig handeln. Es liegt darin, dass Plugins und Themes in eigener Regie externe Ressourcen nachladen, ohne dass es im Dashboard sichtbar ist. Der einzige zuverlässige Weg ist die Prüfung im Netzwerk-Tab, nicht das Vertrauen in Plugin-Einstellungen.
Wer sichergehen will, dass seine gesamte Website DSGVO-konform aufgestellt ist, findet den Gesamtüberblick im Artikel DSGVO-konforme Website ohne Abmahnangst: Das Wichtigste kompakt. Speziell zum Cookie-Banner, der für externe Dienste mit Einwilligung gebraucht wird, gibt es Cookie-Banner rechtssicher umsetzen.
Sofort-Checkliste
- Enthält der Quellcode Ihrer Website einen Link-Tag mit
fonts.googleapis.com? - Zeigt der Netzwerk-Tab beim Seitenaufruf Requests an
fonts.googleapis.comoderfonts.gstatic.com? - Haben alle verwendeten Schriften WOFF2-Dateien auf dem eigenen Server?
- Sind die @font-face-Regeln mit
font-display: swapversehen? - Wurde geprüft, ob das eingesetzte Theme oder der Page-Builder Fonts eigenständig nachlädt?
- Lädt das OMGF-Plugin oder eine eigene functions.php-Lösung alle Google-Font-Requests ab?
- Gibt es im Projekt installierte Plugins (Formulare, Slider, Bewertungswidgets), die eigene externe Fonts einbinden?
- Wurden auch Adobe Fonts und Font-Awesome-CDN auf lokale Alternativen umgestellt oder per Einwilligung abgesichert?
- Ist der Test nach dem Umstellen einmal im Inkognito-Modus mit geleertem Cache wiederholt worden?
- Gibt es für die verbleibenden externen Dienste einen entsprechenden Eintrag in der Datenschutzerklärung?
- Extern geladene Google Fonts verstoßen ohne Einwilligung gegen die DSGVO. Das LG München hat das 2022 mit einem Schadensersatzurteil untermauert.
- Die technische Lösung ist einfach: Fonts herunterladen, lokal einbinden, externen Request eliminieren. Kein Consent-Banner nötig.
- Page-Builder und Plugins laden oft eigenständig Fonts nach. Der Netzwerk-Tab im Browser ist die einzige zuverlässige Prüfmethode.
- Lokales Hosting beseitigt das konkrete DSGVO-Risiko für den Font-Abruf und kann durch entfallende DNS-Lookups auch messbar schneller sein.
Häufige Fragen
Gilt das Urteil zum LG München wirklich für alle Websites?
Das Urteil des LG München I vom 20.01.2022 (Az. 3 O 17493/20) ist ein Urteil eines Instanzgerichts, kein Grundsatzurteil des BGH. Es bindet rechtlich nur die Parteien dieses Verfahrens. Aber es spiegelt die herrschende Auffassung wider, dass die IP-Adresse ein personenbezogenes Datum ist und ihre Übermittlung ohne Rechtsgrundlage gegen die DSGVO verstößt. Datenschutzbehörden mehrerer Bundesländer teilen diese Einschätzung. Wer auf eine günstigere Rechtsprechung hofft, wartet auf etwas, das bislang nicht in Sicht ist.
Reicht es, Google Fonts im Theme-Panel zu deaktivieren?
Nein. Viele Themes und Page-Builder laden Schriften eigenständig über eigene Code-Pfade, die mit der Panel-Option nichts zu tun haben. Daneben installierte Plugins können zusätzliche externe Aufrufe einbringen. Die einzige verlässliche Prüfung ist der Netzwerk-Tab im Browser beim Aufruf der Seite ohne Cache.
Muss ich für lokal gehostete Google Fonts einen Lizenzhinweis geben?
Google Fonts stehen überwiegend unter der Open Font License (OFL) oder der Apache License 2.0. Beide erlauben die lokale Einbindung auf der eigenen Website ohne gesonderten Lizenzhinweis auf der Seite selbst. Es schadet nicht, in der Datenschutzerklärung zu erwähnen, dass Schriftarten lokal gehostet werden und keine Daten an Dritte übermittelt werden. Das stärkt das Vertrauen und macht die DSGVO-Konformität transparent.
Was kostet ein geeignetes Plugin wie OMGF?
Das Plugin OMGF (Optimize My Google Fonts, Host webfonts locally) ist in der Basisversion kostenlos im WordPress-Plugin-Verzeichnis verfügbar. Es erkennt geladene Google Fonts automatisch und richtet die lokale Einbindung ein. Eine Pro-Version mit erweiterten Funktionen gibt es kostenpflichtig, für die meisten kleineren Websites reicht die kostenlose Version.
Ist Adobe Fonts als Alternative zu Google Fonts DSGVO-konform?
Nicht automatisch. Adobe Fonts lädt Schriften ebenfalls von einem externen Server (use.typekit.net), was technisch bedingt die IP-Adresse überträgt. Adobe ist dem EU-US Data Privacy Framework beigetreten, was Drittlandübermittlungen erleichtert, aber die Frage einer Rechtsgrundlage für die Datenverarbeitung nicht vollständig löst. Wer ohne Einwilligung auskommt, hostet auch Adobe Fonts lokal. Adobe stellt dafür entsprechende Exportmöglichkeiten bereit, allerdings sind diese abhängig von der jeweiligen Lizenz.
Verbessert lokales Font-Hosting wirklich die Ladegeschwindigkeit?
Ja, in der Regel schon. Der früher existierende Cache-Vorteil von Google-Servern, nämlich dass Besucher eine Schrift bereits von einer anderen Website gecacht haben könnten, ist durch die partitionierten Browser-Caches entfallen. Lokal gehostete Fonts sparen mindestens einen DNS-Lookup und einen TLS-Handshake. Kombiniert mit font-display: swap und einem Preload-Link für kritische Fonts verbessert sich der Largest Contentful Paint messbar.
Was tun, wenn das Parent-Theme Fonts nachlädt und kein Child-Theme vorhanden ist?
Ohne Child-Theme sollte man keinen direkten Eingriff in das Parent-Theme vornehmen, weil Theme-Updates alle Änderungen überschreiben. Stattdessen ein Child-Theme anlegen (der Aufwand ist gering) und dort die functions.php mit dem Abfang-Code für externe Font-Requests platzieren. Alternativ leistet das Plugin OMGF dieselbe Arbeit ohne Code-Eingriff. Den Hintergrund zu Child-Themes erklärt der Artikel WordPress Child-Theme: Warum es Pflicht ist, keine Option.
Schützt ein Consent-Banner vor dem Datenschutzproblem mit Google Fonts?
Theoretisch ja. Wenn Besucher vor dem ersten Seitenaufruf explizit einwilligen, dass ihre Daten für das Laden externer Schriften übermittelt werden, liegt eine Rechtsgrundlage nach Art. 6 Abs. 1 lit. a DSGVO vor. Praktisch ist das aber keine gute Lösung: Der Consent-Banner muss die Seite blockieren, bis die Einwilligung vorliegt, sonst werden Fonts ohne Rechtsgrundlage geladen. Das führt zu einer schlechteren Nutzererfahrung und schlechterem Page Speed. Die lokale Einbindung ist technisch einfacher und rechtlich sicherer.