Google Fonts lokal selbst hosten in WordPress: DSGVO, LG München Urteil und Zero-Leakage WOFF2-Architektur

Über viele Jahre galt das dynamische Einbinden von Schriftarten über fonts.googleapis.com und fonts.gstatic.com als Standard für WordPress-Themes. Ein einfaches <link>-Tag im Header genügte, um typografische Vielfalt zu gewährleisten. Aus Sicht des europäischen Datenschutzrechts sowie moderner Web-Performance birgt dieser Ansatz jedoch erhebliche Haftungsrisiken und Ladezeitverluste.

In diesem Leitfaden beleuchten wir die rechtlichen Grundlagen des viel beachteten Urteils des Landgerichts München I, erläutern den Personenbezug dynamischer IP-Adressen und zeigen praxiserprobte Wege zur lokalen WOFF2-Bereitstellung in WordPress und WooCommerce.

#1. Das Urteil des LG München I (Az. 3 O 17493/20): Sachverhalt und Rechtsfolgen

Am 20. Januar 2022 entschied das Landgericht München I (Az. 3 O 17493/20) über die Klage eines Website-Besuchers gegen einen Seitenbetreiber. Das Urteil löste in Deutschland eine breite Abmahnwelle aus. Der Entscheidungstext steht im bayerischen Justizportal gesetze-bayern.de, die Zitate unten stammen von dort.

#Der Sachverhalt

Die Beklagte betrieb eine Website, die Google Fonts von Google-Servern nachlud. Beim Seitenaufruf gelangte dadurch die dynamische IP-Adresse des Klägers an Google. Die Beklagte räumte im Verfahren ein, dass sie vor der Änderung ihrer Seite bei den Besuchen des Klägers dessen IP-Adresse an Google übermittelt hatte. Von User-Agent oder Referrer ist im Urteilstext keine Rede. Einen solchen Datensatz sollten Sie also nicht als Teil dieses Urteils zitieren.

#Die rechtliche Würdigung des Gerichts

Das Gericht stufte diesen Vorgang als rechtswidrige Datenverarbeitung im Sinne der Verordnung (EU) 2016/679 (DSGVO) ein:

• IP-Adresse als personenbezogenes Datum: Gemäß Art. 4 Nr. 1 DSGVO und der Rechtsprechung des Europäischen Gerichtshofs (EuGH, Urteil vom 19. Oktober 2016, Rs. C-582/14 Patrick Breyer gegen Bundesrepublik Deutschland) stellt auch eine dynamische IP-Adresse ein personenbezogenes Datum dar, da rechtliche und technische Mittel zur Bestimmung der Person bestehen.
• Fehlende Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO: Der Webseitenbesucher hatte vor dem Verbindungsaufbau keine informierte, freiwillige Einwilligung erteilt.
• Kein berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO: Die Beklagte argumentierte, dass die Nutzung des Google-Dienstes aus Gründen der einheitlichen Schriftdarstellung erforderlich sei. Das Gericht wies diese Begründung entschieden zurück. Google Fonts können problemlos heruntergeladen und auf dem eigenen Server gehostet werden. Das Gericht weist außerdem darauf hin, dass in den USA kein angemessenes Datenschutzniveau besteht. Art. 44 DSGVO nennt das Urteil dabei nicht ausdrücklich.
• Schadensersatzanspruch nach Art. 82 Abs. 1 DSGVO: Das Gericht sprach dem Kläger 100 EUR zu, nebst Zinsen. Es begründete den Schaden mit dem Kontrollverlust über ein personenbezogenes Datum und dem vom Kläger empfundenen individuellen Unwohlsein. Zusätzlich verurteilte es die Beklagte zur Unterlassung und drohte für jeden Fall der Zuwiderhandlung ein Ordnungsgeld von bis zu 250.000 EUR an. Außerdem musste sie Auskunft darüber geben, ob und welche Daten des Klägers sie verarbeitet.

#2. Was entscheidet das Urteil, und was entscheidet es nicht?

Das Urteil ist die Entscheidung eines Landgerichts in einem Einzelfall. Es ist keine Entscheidung eines Bundesgerichts und bindet andere Gerichte nicht. Seine Argumentation ist trotzdem leicht auf jede WordPress-Seite übertragbar, die Schriften direkt von Google lädt, denn sie beruht auf drei Punkten:

• Die dynamische IP-Adresse ist für den Seitenbetreiber ein personenbezogenes Datum. Nach dem Urteilstext genügt die abstrakte Bestimmbarkeit, auf eine konkrete Verknüpfungsmöglichkeit kommt es nicht an.
• Eine Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO lag nicht vor.
• Ein berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO verneinte das Gericht, weil sich Google Fonts auch ohne Verbindung zu einem Google-Server nutzen lassen.

Der dritte Punkt ist für die Praxis der wichtigste. Wer die Schriften selbst ausliefert, braucht für den Abruf keine Rechtsgrundlage gegenüber Google, weil keine Verbindung zu Google entsteht. Das Argument, die Schrift sei für die Darstellung nötig, trägt dann nicht mehr als Rechtfertigung für einen Drittanbieter-Abruf.

Zu § 25 TDDDG (vormals TTDSG): Die Vorschrift verlangt eine Einwilligung für Speicherung und Zugriff auf Informationen im Endgerät des Nutzers. Die Entscheidung stützt sich auf sie nicht. Ob ein reiner Schriftabruf darunter fällt, ist eine eigene Frage, die ich hier nicht beantworte. Für Österreich (Datenschutzbehörde) und die Schweiz (revDSG) habe ich keine Primärquelle zu Google Fonts gefunden und lasse beides deshalb weg. Eine Rechtsberatung ersetzt dieser Beitrag nicht. Die technische Umstellung auf Eigenhosting nimmt Ihnen aber die Angriffsfläche, die das Urteil beschreibt.

#3. Warum Cookie-Banner das Problem nicht sauber lösen

Viele Webmaster versuchten, das Problem durch das Blockieren von Google Fonts innerhalb ihres Cookie-Banners (Consent Management Platform) zu lösen.

Dieser Behelfsweg bringt jedoch gravierende Nachteile mit sich:

1. Layout-Verschiebungen (FOIT / FOUT): Verweigert der Nutzer die Einwilligung, wird die Seite mit Standardschriften (wie Times New Roman) gerendert, was zu unschönen Sprüngen im Cumulative Layout Shift (CLS) führt.
2. Verzögertes Rendering: Schriftarten werden erst geladen, nachdem das Banner bestätigt wurde, was den Largest Contentful Paint (LCP) spürbar verschlechtert.
3. Konvertierungsverluste: Datenschutzbewusste Kunden sollten nicht mit einer unvollständigen Typografie bestraft werden.

Typografische Dateien sind strukturelle Gestaltungselemente und keine Werbe-Tracker. Sie gehören direkt auf den eigenen Host.

#4. Performance-Vorteile des lokalen Hostings (Core Web Vitals)

Das Argument, dass Googles CDN durch browserspezifisches Caching schneller sei, trifft seit der Einführung des Cache Partitioning in allen modernen Browsern nicht mehr zu. Aus Sicherheitsgründen (Schutz vor Fingerprinting) besitzt jede Domain einen isolierten Cache.

Lokales Hosting bietet handfeste Geschwindigkeitsvorteile:

#5. Lösungsansätze im WordPress-Ökosystem

Für WordPress- und WooCommerce-Betreiber stehen im Wesentlichen zwei Wege zur Verfügung.

#Weg A: Dedizierte Schriftarten-Plugins (z. B. OMGF / Host Webfonts Locally)

Das Plugin OMGF von Daan van den Bergh konzentriert sich gezielt auf das Abfangen von Google Fonts:

• Funktionsweise: Durchsucht eingebundene Stylesheets nach Google-URLs, lädt die WOFF2-Dateien in das Verzeichnis wp-content/uploads/omgf/ und bindet eine lokale CSS-Datei ein.
• Vorteile: Schlank für Webmaster, die ausschließlich Schriften verwalten wollen.
• Grenzen: Erfordert bei Theme-Aktualisierungen manuelle Cache-Prüfungen.

#Weg B: Integrierte E-Commerce-Compliance mit Shoplex

Im europäischen Online-Handel müssen Händler neben Schriften zahlreiche weitere Vorgaben erfüllen: die Omnibus-Richtlinie (30-Tage-Tiefstpreis), B2B-Kaufbeschränkungen, Widerrufsbelehrungen, Pfandsysteme und den European Accessibility Act (EAA).

Das Plugin Shoplex bündelt diese Anforderungen und stellt ein integriertes LocalFontsService-Modul bereit:

• Automatisches Zero-Leakage-Filtering: Fängt über den Hook style_loader_src externe Stylesheets ab und entfernt überflüssige <link rel="preconnect" href="https://fonts.gstatic.com">-Tags.
• WOFF2-Optimierung: Lädt komprimierte WOFF2-Dateien mit modernem Subset (Latin und Latin-Extended), sodass alle Sonderzeichen und Umlaute (ä, ö, ü, ß) sauber abgebildet werden.
• Lokale Dateien mit font-display: swap: Speichert die Schriftdateien unter wp-content/uploads/shoplex-fonts/, schreibt die @font-face-Regeln auf diese Dateien um und setzt font-display: swap. Die wichtigsten Latin-WOFF2-Dateien lädt es per Preload vor, das senkt Layoutverschiebungen. Cache-Header für diese Dateien setzt Ihr Server oder CDN, nicht das Plugin.

Aktualisierung, 4. November 2026: Das Modul für lokale Schriften ist mit Shoplex 1.6.4 auf WordPress.org erschienen (3. November 2026). Es deckt Google Fonts und Bunny Fonts ab und entfernt neben preconnect auch dns-prefetch-Hinweise.

#6. Woran erkenne ich, welches Theme oder Plugin Google Fonts nachlädt?

Vor der Umstellung brauchen Sie eine vollständige Liste der Quellen. Ich gehe in dieser Reihenfolge vor:

1. Quelltext durchsuchen: Seite im Browser öffnen, Strg+U bzw. Cmd+Option+U drücken und nach fonts.googleapis.com und fonts.gstatic.com suchen. Der Treffer zeigt das <link>-Tag samt id-Attribut. Bei WordPress-Styles endet die id auf -css, der Teil davor ist das Handle für wp_dequeue_style().
2. Netzwerk-Reiter prüfen: Dort erscheinen auch Anfragen, die erst per JavaScript ausgelöst werden und im Quelltext fehlen. Die Spalte Initiator nennt die Datei, die die Anfrage ausgelöst hat.
3. Mehrere Seitentypen testen: Startseite, Beitrag, Produktseite und Warenkorb laden oft unterschiedliche Stylesheets. Eine saubere Startseite beweist nichts über den Checkout.
4. Quellen in Ihrem Setup abklopfen: Das Theme (Typografie-Einstellungen), der Page Builder, Zusatz-Plugins mit eigenen Widgets und Einbettungen von Drittanbietern können jeweils Google Fonts mitbringen.

Bei Elementor bietet das Hilfecenter eigene Artikel zu “Disable Google Fonts” und “Choose a loading method for Google fonts”. Der genaue Menüpunkt hängt von Version und Lizenz ab, prüfen Sie ihn deshalb in Ihrer Installation. Ich nenne hier keine weiteren Builder, deren Einstellungen ich nicht gegen die Dokumentation geprüft habe.

Seit WordPress 6.5 gibt es außerdem die Schriftenbibliothek im Editor. Laut dem WordPress-Core-Team lädt eine dort installierte Google-Schrift die Datei auf den WordPress-Server, standardmäßig nach wp-content/fonts. Der Auslieferungspfad liegt damit auf Ihrer eigenen Domain. Wer Blockthemes nutzt, kann diesen Weg ohne Zusatz-Plugin gehen.

#7. Eigene Zero-Leakage-Umsetzung im Theme

Wer ein eigenes Theme entwickelt, kann die Bereitstellung direkt in PHP und CSS vornehmen.

#Schritt 1: Externe Schriften deregistrieren

add_action( 'wp_enqueue_scripts', function(): void {
    wp_dequeue_style( 'theme-google-fonts' );
    wp_deregister_style( 'theme-google-fonts' );
}, 999 );

#Schritt 2: Preconnect-Hinweise bereinigen

add_filter( 'wp_resource_hints', function( array $urls, string $relation_type ): array {
    if ( in_array( $relation_type, array( 'preconnect', 'dns-prefetch' ), true ) ) {
        $urls = array_filter( $urls, static function( string $url ): bool {
            return ! str_contains( $url, 'fonts.googleapis.com' )
                && ! str_contains( $url, 'fonts.gstatic.com' );
        } );
    }
    return $urls;
}, 10, 2 );

#Schritt 3: Lokale @font-face-Definitionen im CSS

@font-face {
    font-family: 'Inter';
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: url('/wp-content/themes/ihr-theme/assets/fonts/inter-v13-latin-regular.woff2') format('woff2');
    unicode-range: U+0000-00FF, U+0100-02AF;
}

@font-face {
    font-family: 'Inter';
    font-style: normal;
    font-weight: 700;
    font-display: swap;
    src: url('/wp-content/themes/ihr-theme/assets/fonts/inter-v13-latin-700.woff2') format('woff2');
    unicode-range: U+0000-00FF, U+0100-02AF;
}

#8. Wie binde ich lokale Schriften mit Preload ein?

Ein Preload lohnt sich für die ein bis zwei Schriftschnitte, die oberhalb des Falzes gerendert werden. Für Schriften verlangt MDN das Attribut crossorigin, auch wenn die Datei von derselben Domain kommt. Fehlt es, lädt der Browser die Datei doppelt, weil die Preload-Anfrage und die spätere Schriftanfrage nicht zusammenpassen.

<link rel="preload" href="/wp-content/themes/ihr-theme/assets/fonts/inter-v13-latin-regular.woff2" as="font" type="font/woff2" crossorigin>

font-display: swap zeigt den Text sofort in einer Ersatzschrift und tauscht die Schrift, sobald die Datei geladen ist. web.dev beschreibt diese Zeitspanne als Swap-Periode. Der Preload verkürzt die Zeit bis zum Tausch, er garantiert sie nicht. Binden Sie nur WOFF2 ein, die älteren Formate brauchen Sie für aktuelle Browser nicht mehr.

#9. Was tun, wenn nach der Umstellung weiter Anfragen an Google gehen?

Mein Vorschlag für die Fehlersuche: Immer erst den Initiator der Anfrage ermitteln, dann die Quelle abschalten. Ein Dequeue auf Verdacht trifft oft das falsche Handle.

Wer das Thema laufend im Griff haben will, findet die dauerhafte Pflege solcher Details in der WordPress-Wartung. Für eine Bestandsaufnahme aller externen Verbindungen einer Seite eignet sich zudem ein Sicherheitsaudit für WordPress.

#10. Prüfroutine in den DevTools

Prüfen Sie nach der Umstellung die Netzwerkanfragen:

1. Öffnen Sie ein neues privates Fenster im Browser (Inkognito).
2. Starten Sie die Entwicklertools (F12) und wählen Sie den Reiter Netzwerk (Network).
3. Filtern Sie nach: fonts.
4. Laden Sie die Seite neu (Strg+F5 bzw. Cmd+Shift+R).
5. Erfolgsprüfung:
   • Keine Anfragen an fonts.googleapis.com oder fonts.gstatic.com.
   • Alle .woff2-Dateien stammen von Ihrer eigenen Domain.
   • Der Antwort-Header weist content-type: font/woff2 auf.

#Fazit

Das Urteil des LG München I hat unmissverständlich verdeutlicht, dass Entwicklerkomfort nicht zulasten der informationellen Selbstbestimmung der Nutzer gehen darf.

Die lokale Bereitstellung von Google Fonts in WordPress verbindet lückenlose Rechtssicherheit gemäß Art. 6 Abs. 1 DSGVO mit handfesten Geschwindigkeitsgewinnen für die Core Web Vitals. Ob mit einem Spezial-Plugin wie OMGF, dem Compliance-Paket Shoplex oder per eigenem Theme-Code: Das Eliminieren externer Schriftenaufrufe gehört heute zum unverzichtbaren Handwerkszeug jedes professionellen Webmasters.