Externe Dienste DSGVO-konform einbinden

Ein Kunde leitet dir am Montagmorgen eine E-Mail weiter, Betreff: „Schadensersatzforderung wegen Google Fonts". Ein Anwalt verlangt im Namen seines Mandanten einen dreistelligen Betrag, weil beim Besuch der Website die IP-Adresse des Besuchers ungefragt an einen Google-Server in den USA gewandert sei. Die Seite hast du gebaut. Der Kunde fragt – zu Recht –, ob das dein Fehler war.

Solche Fälle sind kein Einzelfall geblieben. Seit ein Gericht Schadensersatz für genau dieses Muster zugesprochen hat, ist die ungefragte Einbindung externer US-Dienste ein Haftungsrisiko, das auf fast jeder Kundenseite schlummert: Google Fonts, Google Maps, reCAPTCHA, eingebettete YouTube-Videos. Dieser Beitrag zeigt dir, wo die Fallen liegen, was sich 2026 rechtlich bewegt hat und wie du externe Dienste so einbindest, dass weder du noch dein Kunde eine böse Post bekommt. Vorweg der nötige Hinweis: Das ist eine sachliche Einordnung, keine Rechtsberatung. Bei konkreten Forderungen gehört eine Fachanwältin an den Tisch.

Warum externe Dienste DSGVO-konform einbinden 2026 zum Dauerthema wird

Das Grundproblem ist technisch simpel und rechtlich heikel zugleich. Sobald deine Website beim Laden einen Server eines Drittanbieters kontaktiert – etwa um eine Schriftart, eine Karte oder ein Captcha zu holen –, sendet der Browser des Besuchers automatisch dessen IP-Adresse an diesen Server. Die IP-Adresse gilt nach ständiger Rechtsprechung als personenbezogenes Datum. Sitzt der Server in den USA, kommt der heikle Drittlandtransfer dazu. Und all das passiert, bevor der Besucher irgendetwas anklicken oder einer Verarbeitung zustimmen konnte.

Genau hier setzte das viel zitierte Urteil des Landgerichts München I an (Az. 3 O 17493/20, Urteil vom 20. Januar 2022). Das Gericht sprach einem Websitebesucher 100 Euro Schadensersatz nach Art. 82 DSGVO zu, weil eine Website Google Fonts dynamisch – also direkt vom Google-Server – eingebunden und dabei ohne Einwilligung die dynamische IP-Adresse an Google in die USA übermittelt hatte. Bemerkenswert an der Begründung: Das Gericht ließ das Argument des „berechtigten Interesses" nicht gelten, weil eine technisch sichere Alternative existiert – nämlich Schriften lokal zu hosten. Der „Kontrollverlust" und das „individuelle Unwohlsein" des Klägers reichten für den Schadensersatz aus. Dass die Übermittlung in ein Land ohne angemessenes Datenschutzniveau erfolgte, verschärfte die Bewertung.

Für dich als Agentur ist die Lehre daraus unbequem, aber klar: Wenn es eine datensparsame Variante gibt, ist die riskante Variante schwer zu rechtfertigen. Und die riskante Variante ist oft die Standardeinstellung im Theme oder Plugin.

Google Fonts: der Klassiker mit der einfachsten Lösung

Google Fonts ist der Musterfall, weil die Lösung so unspektakulär ist. Statt die Schriften bei jedem Seitenaufruf von fonts.googleapis.com zu laden, lädst du sie einmal herunter und hostest sie lokal auf dem Server des Kunden. Der Browser kontaktiert Google dann gar nicht mehr, keine IP-Adresse wird übertragen, das Thema ist erledigt – ganz ohne Cookie-Banner-Klick für den Besucher.

Der praktische Haken: Viele WordPress-Themes und Page-Builder binden Google Fonts tief im Code ein, teils an mehreren Stellen gleichzeitig. Es reicht nicht, „ein Häkchen" zu setzen. Du musst prüfen, ob wirklich keine Verbindung mehr zu Google-Servern aufgebaut wird. Ein Blick in die Netzwerkanalyse der Browser-Entwicklertools zeigt dir jede Verbindung, die die Seite beim Laden aufbaut – wenn dort noch googleapis.com oder gstatic.com auftaucht, ist die Umstellung nicht vollständig. Genau diese Kontrolle unterscheidet die saubere Umsetzung vom „müsste jetzt passen".

Google Maps: hier hilft nur echte Einwilligung

Bei Karten wird es unbequemer, weil es keine gleichwertige lokale Kopie gibt – eine interaktive Karte lebt von der Verbindung zum Kartendienst. Bindest du Google Maps direkt per iframe ein, lädt die Karte beim Seitenaufruf und überträgt dabei Daten an Google. Das ist ohne vorherige Einwilligung des Besuchers datenschutzrechtlich angreifbar, denn die für Maps gesetzten Cookies sind nicht zwingend technisch notwendig, und auf ein berechtigtes Interesse allein kannst du dich hier nach verbreiteter Auffassung nicht stützen.

Praktikabel sind drei Wege. Erstens die sogenannte Zwei-Klick- oder Consent-Lösung: Statt der Karte zeigst du zunächst einen Platzhalter mit Hinweis; erst wenn der Besucher aktiv klickt und zustimmt, wird die echte Karte nachgeladen. Fertige Bausteine dafür sind der Shariff-Wrapper oder Consent-Plugins wie Borlabs Cookie, die das Nachladen an die Einwilligung koppeln. Zweitens die europäische Alternative OpenStreetMap, die sich ohne Datentransfer in die USA einbinden lässt – für eine simple Standortkarte oft völlig ausreichend. Drittens, am schlanksten: ein statisches Kartenbild oder schlicht ein Link „Route planen", der in einem neuen Tab zu Google Maps führt. Dann entscheidet der Besucher selbst, ob er den Dienst nutzt. Wie du solche Einwilligungen technisch sauber verwaltest, hängt eng mit dem Consent-Management zusammen, das wir im Beitrag zur Cookie-Banner-Pflicht 2026 im Detail behandeln.

reCAPTCHA: 2026 hat sich die Rechtslage bewegt

Bei Formularen greifen viele zu Googles reCAPTCHA, um Spam abzuwehren. Datenschutzrechtlich war das lange heikel, denn reCAPTCHA sammelt reichlich: IP-Adresse, Referrer-URL, Geräte- und Browserinformationen, Google-Cookies, in bestimmten Varianten sogar einen Screenshot des Browserfensters. All das floss zur verhaltensbasierten Bot-Erkennung an Google.

Hier gibt es 2026 eine relevante Neuerung, die du kennen solltest: Nach Angaben von Datenschutz-Fachleuten fungiert Google seit dem 2. April 2026 für reCAPTCHA als Auftragsverarbeiter im Sinne von Art. 28 DSGVO, mit Zweckbindung zur Missbrauchsprävention. Das eröffnet die Möglichkeit, den Dienst auf Grundlage berechtigter Interessen (Art. 6 Abs. 1 lit. f DSGVO) einzusetzen, ohne dass zwingend eine vorherige Einwilligung nötig wäre. „Ohne Weiteres erledigt" ist das Thema damit aber nicht: Der Drittlandbezug bleibt, die Bewertung ist juristisch nicht abschließend geklärt, und ein Auftragsverarbeitungsvertrag will geschlossen und dokumentiert sein – warum ein sauberer AVV auch bei US-Diensten so wichtig ist, haben wir separat aufgeschrieben.

Wer das Risiko ganz vermeiden will, greift zur europäischen Alternative. Friendly Captcha etwa arbeitet ohne Cookies, ohne das Tracken des Nutzerverhaltens und mit Servern in der EU – und löst die Aufgabe kryptografisch im Hintergrund, statt den Besucher Ampeln anklicken zu lassen. Für viele Kundenformulare ist das die entspanntere Wahl, weil sie die Einwilligungsfrage gar nicht erst aufwirft.

Das Muster dahinter: US-Transfer und der Reflex zur EU-Lösung

Google Fonts, Maps und reCAPTCHA sind nur die drei häufigsten Gesichter desselben Musters. Dieselbe Frage stellt sich bei eingebetteten YouTube-Videos (hier hilft der „erweiterte Datenschutzmodus" plus Zwei-Klick), bei Social-Media-Widgets, bei US-gehosteten Analyse-Tools und bei jedem Skript, das von einem fremden Server nachgeladen wird. Der gemeinsame Nenner ist der Transfer personenbezogener Daten in die USA – ein Feld, das seit dem Wackeln des transatlantischen Datenschutzrahmens ohnehin unter Beobachtung steht, wie wir im Beitrag zum US-Cloud-Risiko für Agenturen ausführen.

Die praktische Konsequenz für deine Projekte ist eine simple Priorisierung. Erste Wahl: den Dienst lokal hosten oder ganz vermeiden (Google Fonts, teils Icons und Skripte). Zweite Wahl: eine europäische Alternative ohne US-Transfer (OpenStreetMap statt Maps, Friendly Captcha statt reCAPTCHA, eine DSGVO-konforme Webanalyse statt Google Analytics). Dritte Wahl, wenn es ohne den US-Dienst nicht geht: konsequente Einwilligung per Zwei-Klick-Lösung, sauber dokumentiert. Denselben „belegen statt vermuten"-Reflex verfolgen wir bei Ragnova auch im Produkt: EU-Hosting und nachvollziehbare Grundlagen statt stiller Datenabflüsse.

Deine Rolle – und wie du das zum Angebot machst

Bleibt die Haftungsfrage aus der Eingangs-E-Mail. Ob dich als Agentur eine Mitverantwortung trifft, hängt vom Einzelfall und eurem Vertrag ab – pauschal lässt sich das nicht beantworten, und genau deshalb gehört so etwas geklärt, bevor es brennt. Was du aber in der Hand hast, ist die Umsetzung. Ein kurzer Standard-Check gehört in jedes Projekt und in jeden Wartungsvertrag: Netzwerkanalyse beim Seitenaufruf, Suche nach Verbindungen zu Google- und anderen US-Domains vor jeder Einwilligung, und eine dokumentierte Entscheidung pro Dienst (lokal, EU-Alternative oder Einwilligung).

Für kleine Agenturen ist das mehr als Pflichterfüllung. Ein „DSGVO-Quick-Check externer Dienste" ist eine verständliche, verkaufbare Leistung – einmalig beim Relaunch und wiederkehrend als Teil der Wartung. Du löst ein konkretes Angstthema deiner Kunden, dokumentierst deine Sorgfalt und schaffst dir nebenbei einen wiederkehrenden Umsatzbaustein. Das ist der Unterschied zwischen „wir haben die Seite gebaut" und „wir halten deine Seite sauber".