DSGVO Fonts in WordPress sicher nutzen

Schriften sind Design – aber auch Datenschutz. Sobald WordPress Fonts von externen Diensten (z. B. Google Fonts) nachlädt, können personenbezogene Daten wie IP-Adressen an Dritte übermittelt werden. Genau hier liegt das DSGVO-Risiko. In diesem Guide lernst du, wie du DSGVO Fonts WordPress sauber umsetzt: von der Risikoanalyse über lokale Einbindung bis zur technischen Prüfung und Dokumentation.

Warum Fonts in WordPress ein DSGVO-Thema sind

Viele WordPress-Themes, Page Builder und Plugins binden Schriftarten standardmäßig über externe CDNs ein. Häufig geschieht das über Google Fonts, manchmal auch über Adobe Fonts oder andere Anbieter. Das Problem ist nicht „die Schrift“ an sich, sondern die Verbindung zu einem externen Server beim Seitenaufruf. Dabei werden in der Regel technische Daten übertragen, insbesondere die IP-Adresse, die in der DSGVO als personenbezogenes Datum gelten kann.

Rechtlich relevant wird es, wenn diese Übertragung ohne passende Rechtsgrundlage (z. B. Einwilligung) oder ohne angemessene Garantien erfolgt. Zusätzlich entsteht ein Compliance-Risiko: Du musst nachweisen können, dass du datenschutzkonform arbeitest – und bei externen Font-Requests wird das schnell schwierig.

Typische Quellen für externe Font-Requests

• Theme: lädt Google Fonts über fonts.googleapis.com nach
• Page Builder: bindet Schriftbibliotheken dynamisch ein (z. B. bei visuellen Editoren). Mehr Hintergrund: WordPress Page Builder
• Plugins: Cookie-Banner, Slider, Social-Feeds, Formular-Plugins mit externen Assets
• Custom Code: harte Einbindung im Header oder via CSS-Import

Technisch betrachtet sind externe Fonts auch ein Performance-Thema: zusätzliche DNS-Lookups und Requests können die Ladezeit verschlechtern. Wenn du parallel an Ladezeit und Nutzererlebnis arbeitest, lohnt sich ein Blick in Page Speed und Core Web Vitals.

Welche Risiken drohen bei Google Fonts & externen Schriftbibliotheken

Wenn deine Seite Fonts extern lädt, entstehen zwei zentrale Risikofelder: Datenschutzrecht (Übermittlung personenbezogener Daten) und Abmahnbarkeit (zivilrechtliche Ansprüche, Beschwerden, Reputationsschaden). Besonders kritisch ist, dass externe Requests oft unbemerkt passieren – selbst wenn du „nichts geändert“ hast, können Theme-Updates oder Plugin-Updates wieder externe Quellen aktivieren.

Die Praxis zeigt: Viele Seitenbetreiber glauben, ein Cookie-Banner reiche aus. Bei Fonts ist das jedoch häufig keine saubere Lösung, weil die Schrift-Dateien oft bereits beim ersten Laden der Seite angefordert werden – also bevor ein Nutzer überhaupt eine Auswahl treffen kann. Für eine Einwilligungs-Lösung müsste die Font-Einbindung technisch wirklich blockierbar sein.

Woran du externe Fonts erkennst

• Requests an fonts.googleapis.com oder fonts.gstatic.com
• CSS mit @import url("https://...")
• <link rel="preconnect" href="https://fonts.gstatic.com"> im Quelltext
• Externe Anbieter wie Typekit/Adobe Fonts

Zusätzlich kann es passieren, dass Fonts über ein CDN eingebunden sind, das nicht zu deinem Hosting gehört. DSGVO-konform wird es deutlich einfacher, wenn alle Font-Dateien von deiner eigenen Domain ausgeliefert werden.

Wenn du in der Vergangenheit an deiner Seite geschraubt hast (neues Theme, neuer Builder, Relaunch), prüfe nachträglich konsequent alle externen Requests. Das ist besonders wichtig bei einem Website-Relaunch, weil hier typischerweise viele neue Assets hinzukommen.

Bestandsaufnahme: So findest du alle Font-Requests auf deiner Website

Bevor du irgendetwas umstellst, brauchst du Klarheit: Welche Fonts werden geladen, von wo kommen sie und wer verursacht den Request? Eine saubere Bestandsaufnahme spart Zeit, weil du danach gezielt am Theme, am Builder oder am verursachenden Plugin ansetzen kannst.

Prüfung im Browser (schnell und zuverlässig)

1. Seite öffnen (Inkognito-Modus empfohlen).
2. Entwicklertools öffnen (Chrome: F12) → Tab Network.
3. Filter auf Font setzen oder nach fonts suchen.
4. Seite neu laden und die Domains prüfen.

Achte nicht nur auf Font-Dateien (.woff2, .woff), sondern auch auf vorgelagerte CSS-Dateien von externen Domains. Häufig wird zuerst eine CSS von fonts.googleapis.com geladen, die dann auf Font-Files bei fonts.gstatic.com verweist.

Prüfung mit Pagespeed-/Audit-Tools

• PageSpeed Insights oder Lighthouse: zeigt externe Ressourcen und Blocker.
• SEO-/Crawl-Tools: finden wiederkehrende externe Requests siteweit.

Wenn du tiefer in technische Grundlagen einsteigen willst, helfen dir Artikel wie Crawling oder Crawler, um zu verstehen, warum manche Ressourcen nur unter bestimmten Bedingungen sichtbar werden (z. B. erst nach Interaktionen).

Dokumentiere die Ergebnisse kurz: betroffene URLs, externe Domains, auslösendes Theme/Plugin. Diese Mini-Doku brauchst du später für interne Freigaben oder deinen Datenschutz-Nachweis.

Google Fonts lokal einbinden: der saubere Standard für WordPress

Die robusteste Lösung für DSGVO Fonts WordPress ist: Fonts lokal hosten und ausschließlich von deiner Domain ausliefern. Damit vermeidest du externe Datenübermittlungen beim Seitenaufruf und reduzierst gleichzeitig Abhängigkeiten von Drittanbietern. In vielen Fällen ist das die pragmatischste und wartungsärmste Lösung.

Der Grundablauf sieht so aus: Du besorgst dir die benötigten Schriftdateien (idealerweise WOFF2), legst sie in deinem WordPress-Verzeichnis ab und bindest sie per @font-face in dein CSS ein. Wichtig ist, dass du alle alten externen Einbindungen entfernst, sonst lädst du versehentlich doppelt.

So gehst du strukturiert vor

• Fonts identifizieren: Welche Familie, welche Schnitte (Regular, 600, 700, Italic)?
• Dateien bereitstellen: WOFF2 bevorzugen, WOFF optional als Fallback.
• Einbindung per CSS: @font-face mit lokalen Pfaden.
• Theme/Builder umstellen: externe Font-Optionen deaktivieren.
• Testen: Network-Tab + Quelltext auf externe Links prüfen.

Eine detaillierte Schritt-für-Schritt-Anleitung findest du auch hier: Google Fonts lokal laden in WordPress. Diese Anleitung ist besonders hilfreich, wenn du mit Child Themes, eigenen CSS-Dateien oder Caching arbeitest.

Performance-Hinweis: Wenn du lokal hostest, kannst du Fonts gezielt optimieren (Subset, nur benötigte Schnitte) und Render-Blocker reduzieren. Das zahlt direkt auf Nutzererlebnis und Conversion ein – passend dazu: Conversion Rate.

Einbindung ohne Plugin: @font-face, Child Theme und saubere Pfade

Wenn du maximale Kontrolle willst (und Updates keine Überraschungen verursachen sollen), ist die manuelle Einbindung über CSS oft die beste Wahl. Du definierst die Schrift über @font-face und weist sie dann in deinem Stylesheet zu. Wichtig ist dabei ein update-sicherer Ort: idealerweise ein Child Theme oder eine Custom-CSS-Datei, die nicht überschrieben wird.

Beispiel: @font-face (vereinfacht)

Lege die Dateien z. B. unter /wp-content/uploads/fonts/ oder im Child Theme ab und nutze dann:

@font-face {
  font-family: "Inter";
  src: url("/wp-content/uploads/fonts/inter-regular.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

body { font-family: "Inter", system-ui, -apple-system, "Segoe UI", Arial, sans-serif; }

font-display: swap verbessert die Wahrnehmung beim Laden. Achte außerdem auf konsistente font-weight-Angaben. Häufige Fehlerquelle: Ein Theme nutzt 500/600/700, lokal sind aber nur 400/700 vorhanden – dann wirkt die Typografie „kaputt“ oder der Browser faked Gewichte.

Typische Stolperfallen

• Relative Pfade stimmen nicht (besonders bei CSS in Unterordnern).
• Cache liefert alte CSS-Versionen aus; nach Änderungen Cache leeren.
• Page Builder lädt trotzdem externe Fonts (Optionen separat deaktivieren).
• Preconnect/Link-Tags im Header bleiben bestehen.

Wenn du tiefer in saubere technische Umsetzung eintauchen willst, sind Grundlagen wie HTML-Tags hilfreich, um Header-Einbindungen im Quelltext schnell zu erkennen und zu entfernen.

Plugins & Page Builder: Einstellungen, die externe Fonts verhindern

In der Praxis kommen externe Fonts oft nicht (nur) aus dem Theme, sondern aus dem Zusammenspiel von Theme, Builder und Plugins. Deshalb solltest du in WordPress systematisch an den Stellen prüfen, an denen Fonts konfigurierbar sind. Das Ziel: Externe Font-Libraries deaktivieren und stattdessen lokale Fonts oder Systemfonts nutzen.

Typische Schalter in Themes/Buildern

• Disable Google Fonts / Load Google Fonts locally
• Typography-Einstellungen: „Google Fonts“ vs. „Custom/Local Fonts“
• Performance-Optionen: „Remove Google Fonts“, „Host fonts locally“

Gerade wenn du mit einem Builder arbeitest, lohnt es sich, die SEO- und Technikseite mitzudenken. Ein guter Überblick: WordPress Page Builder SEO optimieren. Denn externe Requests (Fonts, Icons, Skripte) wirken sich nicht nur auf Datenschutz, sondern auch auf Performance und Stabilität aus.

Wenn du Plugin-Lösungen nutzt

Plugin-Ansätze sind bequem, bergen aber ein Wartungsrisiko: Nach Updates können Einstellungen zurückspringen oder neue externe Quellen hinzukommen. Wenn du ein Plugin nutzt, achte auf:

• Transparente Ausgabe: zeigt es an, welche Fonts lokalisiert wurden?
• Kompatibilität: funktioniert es mit deinem Cache-/Minify-Setup?
• Fallback: werden externe Requests wirklich vollständig verhindert?

Nach jeder Änderung gilt: kontrollieren, ob wirklich keine Requests an Drittanbieter mehr rausgehen. Das ist bei DSGVO-Themen wichtiger als „es müsste funktionieren“.

Datenschutz & Dokumentation: was du intern sauber festhalten solltest

DSGVO-Konformität ist nicht nur Technik, sondern auch Nachweisfähigkeit. Wenn du Fonts lokal hostest und externe Requests entfernst, ist das ein großer Schritt. Zusätzlich solltest du intern dokumentieren, wie du zu dieser Lösung gekommen bist und was du umgesetzt hast. Das hilft bei Rückfragen, Beschwerden oder wenn später jemand (Agentur, Admin, Entwickler) am System arbeitet.

Checkliste für deine Dokumentation

• Ist-Zustand: Welche externen Font-Quellen gab es vorher?
• Maßnahme: Lokal eingebunden (Ort der Dateien, Methode, Datum).
• Prüfung: Nachweis-Screenshots aus Network-Tab (keine externen Font-Requests).
• Beteiligte Komponenten: Theme/Builder/Plugins, die angepasst wurden.
• Wartungsroutine: Prüfen nach Updates und Relaunches.

In der Datenschutzerklärung solltest du keine externen Font-Dienste nennen, wenn du sie nicht mehr nutzt. Umgekehrt gilt: Wenn externe Dienste noch aktiv sind, muss das sauber bewertet und beschrieben werden. Da sich Websites häufig weiterentwickeln, ist eine Wartungsroutine sinnvoll – ähnlich wie bei genereller WordPress Website Wartung.

Technischer Nebeneffekt: Wenn du Fonts lokal hostest, reduzierst du Third-Party-Abhängigkeiten. Das senkt die Wahrscheinlichkeit, dass sich durch externe Änderungen (CDN-Ausfälle, neue Policies) plötzlich Fehler einschleichen.

Häufige Fehler: Warum trotz lokaler Fonts noch externe Requests auftauchen

Du hast Fonts lokal eingebunden – und trotzdem zeigt der Network-Tab noch Requests zu Google? Das ist ein Klassiker. Häufig existieren mehrere Einbindungswege parallel. WordPress ist modular, und genau diese Modularität sorgt dafür, dass Fonts an verschiedenen Stellen „wieder reinkommen“.

Die häufigsten Ursachen

• Theme lädt weiterhin Google Fonts (z. B. über wp_enqueue_style).
• Builder lädt Fonts pro Seite, abhängig vom verwendeten Widget.
• Plugin bringt eigene Typografie mit (Formulare, Sliders, Cookie-Banner).
• Header enthält noch Preconnect/Stylesheet-Link zu Google Fonts.
• Cache/Minify kombiniert CSS und zieht wieder externe Imports rein.

So gehst du bei der Fehlersuche vor

1. Im Network-Tab den Request anklicken und den Initiator prüfen.
2. Im Quelltext nach fonts.googleapis.com suchen.
3. Theme-Einstellungen und Builder-Typografie prüfen.
4. Plugins testweise deaktivieren (Staging empfohlen).
5. Caches leeren (Plugin, Server, CDN).

Wenn du viele Optimierungen aktiv hast, kann auch Redirect-/Cache-Logik dazwischenfunken. Grundlagen dazu findest du bei Redirect und Redirect-Arten – nicht direkt Font-spezifisch, aber hilfreich, wenn Ressourcen über Umwege geladen werden.

Best Practices: Performance, Fallbacks und barrierearme Typografie

DSGVO-konform heißt nicht automatisch „gut umgesetzt“. Wenn du Fonts lokal einbindest, kannst du gleichzeitig Performance und Lesbarkeit verbessern. Gute Typografie wirkt direkt auf Vertrauen, Markenwahrnehmung und Conversion – und reduziert Support-Anfragen, weil Inhalte leichter erfassbar sind.

Performance-Basics für lokale Fonts

• WOFF2 verwenden (kleiner, schneller).
• Nur benötigte Schnitte laden (z. B. 400/600/700 statt 9 Varianten).
• Subsetting: nur benötigte Zeichen (z. B. Latin + Latin-Extended, wenn nötig).
• font-display: swap setzen, um Invisible Text zu vermeiden.

Saubere Fallback-Stacks

Plane immer einen Fallback ein, falls eine Font-Datei nicht geladen werden kann. Beispiel:

• Sans: system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif
• Serif: Georgia, "Times New Roman", Times, serif

Barrierearme Typografie bedeutet auch: ausreichende Schriftgröße, Kontrast und Zeilenlänge. Das ergänzt ein gutes responsive Webdesign und zahlt auf Nutzererlebnis ein – gerade auf mobilen Geräten.

Wenn du Schriften im Zuge eines Relaunches oder Markenupdates anfasst, denke an Konsistenz: Headlines, Buttons, Formulare, Cookie-Banner. Uneinheitliche Typografie wirkt schnell „zusammengebastelt“ und kann Conversion kosten. Dazu passt auch der Blick auf was eine gute Website auszeichnet.