revDSG & DSGVO bei Headless WordPress: der Datenschutz-Plan

Sobald jemand Ihr Kontaktformular ausfüllt, eine Seite aufruft oder Sie eine Statistik öffnen, bearbeiten Sie personenbezogene Daten. Das gilt für jede Website — und bei einer Headless-Architektur verteilen sich diese Daten auf mehr Dienste als beim klassischen WordPress: ein Backend, ein separates Frontend-Hosting, ein CDN, ein Formular-Versand, ein Analytics-Werkzeug. Das klingt nach mehr Komplexität, ist aber in der Praxis übersichtlicher, weil jeder Datenfluss eine bewusste Entscheidung ist. Wer verstehen will, wie diese Trennung technisch zustande kommt, findet die Grundlagen unter Was Headless WordPress im Kern ausmacht.

Dieser Beitrag zeigt, wo bei einer Headless-WordPress-Architektur personenbezogene Daten tatsächlich fliessen, was revDSG und DSGVO für ein Schweizer KMU konkret verlangen, und wie eine cookielose Analytics-Wahl den Aufwand senkt. Am Ende steht eine praktische Checkliste mit Tabelle. Wichtig vorab: Dieser Text ordnet die technische Architektur ein, er ist kein Ersatz für juristische Beratung. Für die rechtsverbindliche Beurteilung Ihres Einzelfalls braucht es eine Datenschutz-Fachperson oder Anwält:in.

Wo fliessen bei Headless WordPress personenbezogene Daten?

Die kurze Antwort: an vier Stellen. Eine Headless-Architektur trennt das, was beim klassischen WordPress in einem einzigen Server-Prozess verschmilzt — und genau diese Trennung macht den Datenfluss sichtbar.

Erstens das WordPress-Backend-Hosting. Hier liegt WordPress als reines Redaktionssystem. Personenbezogene Daten entstehen durch Redaktions-Logins (Namen, E-Mail-Adressen der Autor:innen), durch gespeicherte Formulareingänge, falls Sie diese im Backend ablegen, und durch Server-Logs. Der Standort dieses Hostings ist der wichtigste einzelne Hebel für die Datenresidenz: Ein Backend bei einem Schweizer Anbieter wie Cyon, Hostpoint oder Infomaniak hält diese Daten in der Schweiz.

Zweitens das Frontend-Hosting und CDN. Das ausgelieferte Frontend — etwa eine Next.js-Anwendung auf Vercel oder hinter Cloudflare — sieht jede Besucher:in. In den Server- und CDN-Logs landen IP-Adressen, und IP-Adressen gelten unter revDSG wie DSGVO in aller Regel als personenbezogene Daten. Das ist unvermeidbar und legitim, solange es transparent dokumentiert und durch einen Vertrag abgedeckt ist. Entscheidend ist der Standort: Ein US-basiertes CDN bedeutet eine Datenübermittlung in die USA, die eine vertragliche Grundlage braucht.

Drittens die Formular-Zustellung. Sobald ein Kontaktformular abgeschickt wird, wandern Name, E-Mail und Nachricht durch einen Zustelldienst — bei vielen Setups ein E-Mail-Dienst wie Resend oder ein Webhook in ein CRM. Das sind die sensibelsten Daten der ganzen Kette, weil sie direkt identifizierend sind und oft einen Geschäftskontext mittragen.

Viertens Analytics. Hier entscheidet sich, ob Sie überhaupt einen nennenswerten Datenschutz-Aufwand haben. Klassisches Tracking mit Cookies und User-Profilen erzeugt umfangreiche personenbezogene Datenflüsse; eine cookielose, aggregierte Messung erzeugt fast keine. Dazu weiter unten mehr.

Diese vier Stellen sind das Grundgerüst, nicht die garantierte Endliste. Reale Sites fügen oft Drittanbieter-Embeds hinzu — eingebundene Schriften, eine Karte, ein Video, ein Buchungs-Widget — und manche binden ein Fehler-Monitoring wie Sentry ein. Jedes davon ist ein weiterer Datenfluss, der ins Inventar gehört. Der eigentliche Headless-Vorteil ist nicht, dass diese Posten verschwinden, sondern dass sie zu bewussten Entscheidungen werden: Sie bauen jeden Dienst sichtbar ein, statt ihn von einem Plugin nachladen zu lassen.

Was verlangen revDSG und DSGVO von einem Schweizer KMU?

Für eine typische KMU-Marketing-Site reduzieren sich revDSG und DSGVO auf drei Pflichten: ein Verarbeitungsverzeichnis, einen Auftragsverarbeitungs-Vertrag mit jedem Dienst, der in Ihrem Auftrag Daten bearbeitet, und eine transparente Datenschutz-Erklärung. Der Knackpunkt bei Headless ist nicht die Menge der Pflichten, sondern die Standortwahl jedes Dienstes.

Das revidierte Datenschutzgesetz (revDSG) gilt für Datenbearbeitungen in der Schweiz seit dem 1. September 2023. Es wurde bewusst an die europäische DSGVO angenähert, ist aber für KMU in der Praxis etwas schlanker. Die meisten DACH-orientierten Schweizer KMU erfüllen ohnehin beide Regelwerke parallel: das revDSG, weil sie in der Schweiz bearbeiten, und die DSGVO, sobald sie Personen in der EU gezielt ansprechen — etwa über mehrsprachige Marketing-Seiten oder EU-Kund:innen.

Für eine typische KMU-Marketing-Site reduzieren sich beide Regelwerke auf drei praktische Pflichten:

1. Ein Verarbeitungsverzeichnis — eine interne Übersicht, welche personenbezogenen Daten Sie zu welchem Zweck bearbeiten und an welche Dienste sie fliessen. Genau hier zahlt sich das Datenfluss-Inventar aus: Es ist der technische Kern dieses Verzeichnisses.
2. Auftragsverarbeitungs-Verträge (AVV) mit jedem Dienst, der in Ihrem Auftrag Daten bearbeitet. Hosting, CDN, E-Mail-Versand, Analytics — jeder dieser Auftragsbearbeiter braucht eine vertragliche Grundlage. Seriöse Anbieter stellen einen Standard-AVV bereit, den Sie nur ablegen müssen: Vercel, Cloudflare und Resend etwa veröffentlichen je einen Standard-DPA zum Download.
3. Eine transparente Datenschutz-Erklärung, die für Besucher:innen nachvollziehbar macht, welche Daten Sie erheben und an wen sie gehen. Diese Erklärung lebt im Frontend; ein Muster-Grundgerüst liefert Ihre eigene Datenschutz-Seite.

Der Knackpunkt für Headless-Setups ist die Frage des Datenstandorts. revDSG und DSGVO verbieten keine Datenübermittlung ins Ausland — sie verlangen eine angemessene Grundlage dafür. Liegt ein Dienst in den USA, lässt sich der Transfer derzeit auf das EU-US Data Privacy Framework stützen, sofern der Anbieter zertifiziert ist — für Daten aus der Schweiz greift das parallele Swiss-US Data Privacy Framework, das seit dem 15. September 2024 als angemessen anerkannt ist. Beide Rahmen stehen weiterhin unter rechtlicher Beobachtung, weshalb Standardvertragsklauseln als Rückfalloption sinnvoll bleiben. Liegt ein Dienst in der Schweiz oder der EU, ist die Lage deutlich einfacher. Deshalb ist die Standortwahl jedes Bausteins kein Detail, sondern die zentrale Compliance-Entscheidung — und sie hängt eng mit der Hosting-Architektur Ihrer Headless-Site zusammen.

Macht Headless den Datenschutz strukturell einfacher?

Ja — nicht weil Headless per se „datenschutzfreundlicher" wäre, sondern weil am Frontend keine PHP-Plugins laufen. Bei klassischem WordPress lädt fast jedes Plugin eigene Skripte, Schriften oder Tracker nach; im Headless-Setup ist jeder externe Datenfluss eine bewusste Einbau-Entscheidung. Das verkürzt das Verarbeitungsverzeichnis und entspannt die Cookie-Lage.

Die Grössenordnung dieses Plugin-Effekts ist messbar. Über alle erfassten Seiten hinweg bindet die mittlere Website laut Web Almanac 2024 bereits 27 Drittparteien ein — jede ein potenzieller Datenfluss in ein fremdes System. Bei einem klassischen WordPress lädt fast jedes Plugin potenziell eigene Skripte, Schriften oder Tracker am Frontend nach: Ein Marketing-Plugin bindet ein externes Pixel ein, ein Schriften-Plugin lädt von einem Drittserver, ein Chat-Widget öffnet eine weitere Verbindung — oft ohne dass die Betreiber:in es bewusst entschieden hat. Genau diese unkontrollierten Drittverbindungen sind die häufigste Quelle ungewollter Datenflüsse und damit von Datenschutz-Verstössen.

Im Headless-Setup ist das Frontend ein eigenständig gebautes JavaScript-Frontend. Es lädt nur, was bewusst hineingebaut wurde. Jeder externe Datenfluss ist eine explizite Entscheidung über eine definierte Schnittstelle — nicht ein Nebeneffekt eines Plugins. Das macht zwei Dinge einfacher: Das Verarbeitungsverzeichnis wird kürzer und vollständiger, und die Cookie-Lage wird überschaubar, weil keine Plugin-Kaskade im Hintergrund Cookies setzt.

Im Headless-Setup ist jeder Datenfluss eine bewusste Entscheidung über eine definierte Schnittstelle — kein Nebeneffekt eines Plugins, das niemand mehr überblickt.

Das WordPress-Backend bleibt natürlich ein vollwertiges WordPress mit allen seinen Datenbeständen. Aber es ist vom öffentlichen Frontend entkoppelt: Besucher:innen sprechen nie direkt mit WordPress, sondern nur mit dem Frontend, das vordefinierte Inhalte über eine Schnittstelle bezieht. Wie diese Schnittstelle aussieht — und welche Daten sie überhaupt freigibt — beschreibt der Beitrag zu WPGraphQL und REST API als Schnittstellen-Optionen. Diese Entkopplung verkleinert die öffentlich exponierte Angriffsfläche einer Headless-Site und damit auch das Risiko ungewollter Datenabflüsse.

Ist eine cookielose Analytics-Lösung die bessere Wahl?

Für die meisten KMU-Marketing-Sites: ja. Analytics ist der Posten, der über den gesamten Datenschutz-Aufwand einer Site entscheidet. Cookie-basiertes Tracking erzeugt umfangreiche personenbezogene Datenflüsse, verlangt einen Consent-Layer und kostet Reichweite. Eine cookielose, EU-gehostete Messung erzeugt fast keine personenbezogenen Daten, kommt ohne Banner aus und verliert keine Sitzungen.

Wie viel Reichweite ein Banner kostet, ist gut belegt: Sobald ein gleich prominenter „Alle ablehnen"-Knopf angeboten wird, lehnt rund die Hälfte bis zwei Drittel der Besucher:innen ab — Studien aus 2024/2025 nennen Ablehnungsquoten von 50 bis über 70 Prozent. Diese Sitzungen fehlen anschliessend vollständig in den Daten. Klassisches, Cookie-basiertes Tracking verlangt zudem einen Consent-Layer mit Cookie-Banner und produziert ein langes Verzeichnis von Drittparteien.

Die datensparsame Alternative ist eine cookielose, aggregierte Messung mit einem EU-gehosteten Werkzeug. Plausible Analytics etwa positioniert sich als cookielos, speichert nach eigener Darstellung keine Cookies, legt keine geräteübergreifenden Profile an und verarbeitet keine personenbezogenen Daten im engeren Sinn — und kommt damit ohne Cookie-Banner aus. Eine vergleichbare Alternative für Teams, die ihre Daten lieber auf eigener Infrastruktur halten, ist Matomo selbst gehostet im cookielosen Modus; eine schlanke, gehostete Variante ist Fathom. Für eine Marketing-Site, die wissen will, welche Seiten und Kampagnen funktionieren, reicht diese aggregierte Sicht in den allermeisten Fällen vollständig.

Der Verzicht hat eine reale Kehrseite: Eine cookielose Messung legt keine geräteübergreifenden Profile an und liefert deshalb keine User-Level-Funnels über mehrere Sitzungen oder Geräte hinweg. Wer eine einzelne Person über Wochen und Endgeräte hinweg verfolgen will, bekommt das hier bewusst nicht. Für die meisten KMU-Marketing-Sites ist genau das aber kein Verlust, sondern der Punkt.

Der Doppeleffekt ist der Grund, warum wir diese Wahl bei Headless-Projekten standardmässig empfehlen: weniger Dokumentationsaufwand und keine Banner-Reibung — bei voller Reichweiten-Messung, weil keine Sitzung durch eine Banner-Ablehnung verloren geht. In der Headless-Architektur fügt sich das sauber ein, weil das Analytics-Skript bewusst und einzeln eingebunden wird, statt von einem Plugin nachgeladen zu werden.

Praktische Checkliste: Datenkategorie, Verarbeitungsort, Massnahme

Die folgende Tabelle ist das Arbeitsblatt. Sie übersetzt die vier Datenflüsse in konkrete Massnahmen — und bildet zugleich den technischen Kern eines Verarbeitungsverzeichnisses für eine typische Headless-Marketing-Site.

Drei Punkte aus dieser Tabelle verdienen Betonung. Erstens: Der Backend-Standort ist die wirksamste einzelne Massnahme — ein Schweizer Backend löst die schwierigste Datenresidenz-Frage am Ursprung. Zweitens: Die Formular-Zustellung ist der sensibelste Fluss und gehört explizit in die Datenschutz-Erklärung. Drittens: Die cookielose Analytics-Wahl ist der grösste Aufwand-Sparer der ganzen Liste, weil sie einen kompletten Consent-Layer überflüssig macht.

Wenn Sie wissen wollen, welche Drittverbindungen Ihre aktuelle Site tatsächlich aufbaut — also wo heute Daten abfliessen, die Sie vielleicht gar nicht kennen — gibt der kostenlose Website-Check in unter einer Minute einen ersten Überblick, ohne dass Sie Daten preisgeben müssen.

Nächster Schritt

Datenschutz bei Headless WordPress ist keine Zusatzlast, sondern ein Nebeneffekt sauberer Architektur: Wer jeden Datenfluss mit Standort und AVV dokumentiert, hat das Verarbeitungsverzeichnis fast fertig. Die strukturelle Trennung von Backend und Frontend macht diese Arbeit kürzer als beim plugin-lastigen klassischen WordPress.

Wenn Sie Ihre konkrete Ausgangslage einordnen wollen — welche Dienste Sie nutzen, wo die Daten liegen, was fehlt —, vereinbaren wir gerne ein Erstgespräch, 15 Minuten und kostenlos. Eine Übersicht über unser Vorgehen von Audit bis Launch zeigt die Seite Leistungen.