OneTrust vs Usercentrics vs Cookiebot 2026, was passt für wen (und wann alle drei falsch sind)

Warum die CMP-Wahl wichtiger ist als die meisten denken

Wer kennt das nicht? Marketing will ein Cookie-Banner, IT sagt „machen wir", drei Wochen später ist es live, aber niemand kann auf Anhieb sagen, ob die Einwilligungen rechtlich halten würden. Dann kommt die erste Anfrage einer Datenschutz-Aufsicht, und plötzlich erklärt sich keiner, warum das CMP genau dieses Tool und nicht ein anderes ist.

Ein CMP ist die Schaltzentrale am Eingang einer Website. Es entscheidet bei jedem Besucher: was darf gemessen werden, was geht an Werbeplattformen weiter, was bleibt aus. Wenn diese Schaltzentrale falsch dimensioniert ist, zu klein für die Compliance-Anforderungen, zu groß für die IT-Ressourcen, leidet alles dahinter. Falsche Conversion-Daten in Google Ads. Datenschutz-Risiken in der Datenschutz-Folgeabschätzung. Und das Marketing-Team trifft Budget-Entscheidungen auf einer Datenbasis, die rechtlich nicht hält.

Was sich 2026 geändert hat: mit voller DMA-Durchsetzung erzwingt Google Consent Mode v2 für alle EU-Nutzer, ad_user_data und ad_personalization müssen explizit gesetzt sein, sonst füllen sich Google-Ads-Audiences in der EU nicht mehr. Das macht die Wahl eines CMP, das diese Signale sauber liefert, zu einer harten Marketing-Anforderung, nicht nur zu einer Compliance-Frage.

OneTrust, Usercentrics und Cookiebot lösen dasselbe Problem. Aber auf so unterschiedlichen Niveaus, dass sie für unterschiedliche Unternehmen die richtige Wahl sind. Und 2026 ist die Antwort manchmal: keines der drei, sondern ein Headless-CMP-Setup. Hier die ehrliche Einschätzung.

Wann OneTrust passt

OneTrust ist eine Privacy-Management-Plattform. CMP ist nur ein Modul davon. Daneben gibt es Module für Datenschutz-Folgeabschätzungen, Vendor-Management, Datenpannen-Workflows, Cookie-Scanning, Rechte-der-Betroffenen-Workflows.

Das macht OneTrust mächtig, und teuer. Die Lizenz beginnt im niedrigen fünfstelligen Bereich pro Jahr und steigt mit dem Modul-Umfang schnell deutlich höher. Was Marketing-Material und Sales-Pitches systematisch unterschlagen: der Konfigurations-Aufwand. OneTrust hat ein riesiges Admin-Dashboard mit hunderten Settings, Geo-Rules, Vendor-Listen, Banner-Templates, Audience-Conditions, die alle aktiv konfiguriert werden müssen, sonst greift wenig davon. In unseren Audits sind 6–10 Wochen Dev-Zeit für das Initial-Setup realistisch, plus laufender Maintenance-Aufwand für jede neue Region oder jedes neue Tag-Vendor-Pairing.

Implementierung selten unter vier Wochen, weil die Konfiguration tief in die IT-Landschaft greift. Und ohne dedizierten Compliance-Owner verstaubt das Dashboard innerhalb von 12 Monaten, die Lizenzkosten laufen weiter, der Mehrwert sinkt.

Wann es passt:

• Großes Unternehmen mit eigener Compliance-Abteilung. Wenn jemand im Haus den Umfang OneTrusts ausnutzen kann (DSFA, Vendor-Audits, mehrere Marken), zahlt sich die Lizenz aus.
• Dediziertes Dev-Team mit Zeitbudget für die Initial-Konfiguration. Das Dashboard verlangt es, nicht es einmal anschmeißen und vergessen.
• Komplexer Tech-Stack. Wenn ihr 30+ Marketing- und Analyse-Tools nutzt und ein striktes Vendor-Management braucht. OneTrust hat hier die Tiefe.
• Mehrere Märkte mit unterschiedlichen Datenschutz-Regimen. EU + UK + Kalifornien + APAC. Geo-Logik, je nach Region eigene Default-States. OneTrust lässt das aus dem CMP heraus konfigurieren.

Wann es nicht passt: kleinere Setups, einzelne Marke, kein dedizierter Compliance-Owner. Da ist OneTrust wie ein LKW für die Brötchenfahrt am Sonntag. Kraftstoff für Power, der nie abgerufen wird.

In OneTrust-Setups sehen wir wiederkehrende Anti-Patterns, die Consent-Mode-v2-Lücken in einem Healthcare-Setup haben wir im GA4-Audit-Artikel ausführlich beschrieben. OneTrust ist mächtig, aber selten „out of the box v2-ready".

Wann Usercentrics passt

Usercentrics sitzt funktional zwischen den beiden: keine volle Privacy-Suite wie OneTrust, deutlich mehr zentrale Steuerung als Cookiebot. Enterprise-Consent über viele Domains, Sprachen und Jurisdiktionen, aus einer Verwaltung heraus. Deutsche Firma, deutsches Hosting, deutsche AGB. Und seit der Fusion 2021 gehören Usercentrics und Cookiebot zum selben Unternehmen, das Tier-Modell ist offiziell: Cookiebot für SMB, Usercentrics für Enterprise.

Die Lizenz liegt im mittleren Tausender-Bereich pro Jahr, abhängig von Traffic und Funktionsumfang. Implementierung: ein bis zwei Wochen für ein Standard-Setup mit Consent Mode v2, zwei bis vier Wochen für Multi-Domain-Setups mit Geo-Regeln und Server-Side-Kette.

Wann es passt:

• DACH-Unternehmen mit deutscher Datenschutz-Aufsicht als Maßstab. Software aus klar EU-souveränen Quellen, ohne Diskussion über US-Transfers beim CMP selbst.
• Mehrere Domains oder Marken, zentral gesteuert. Eine Konfigurations-Verwaltung, Geo-Regeln pro Jurisdiktion, Cross-Domain-Consent.
• TCF-2.2-Pflicht durch programmatische Vermarktung. Usercentrics liefert das zertifiziert, ohne den OneTrust-Suite-Overhead mitzukaufen.
• App und Web im selben Consent-Regime. Das App-SDK deckt iOS und Android ab, mit derselben Service-Verwaltung wie Web.

Wann nicht: eine einzelne Domain mit Standard-Stack, dann reicht Cookiebot zum kleineren Preis vom selben Anbieter. Oder Consent soll nur ein Modul einer konzernweiten Privacy-Governance sein, dann OneTrust.

Eine technische Grenze teilt Usercentrics mit Cookiebot: der DPS-Scanner hat dieselbe strukturelle SPA-Schwäche, weniger blind, aber nicht vollständig. Bei Next.js-/React-Stacks gehört das Service-Inventar auch hier manuell gepflegt.

Wann Cookiebot reicht

Cookiebot ist auf Cookie-Compliance spezialisiert. Keine Privacy-Suite, kein Vendor-Management, fokussiert auf ein Problem: rechtskonformes Cookie-Banner mit automatischem Scanning aller Tags.

Lizenz startet im niedrigen dreistelligen Bereich pro Jahr für kleine Sites, bei typischen Mittelstands-Sites meist deutlich unter 5.000 €/Jahr. Implementierung in einem halben Tag möglich. Cookie-Liste wird automatisch durch monatliche Scans aktuell gehalten.

Die 2026-Falle ist technischer Natur. Cookiebots Auto-Scanner ist auf klassische, server-gerenderte HTML-Sites optimiert. Bei modernen SPA-Frameworks (Next.js, React, Vue, SvelteKit, Astro mit Client-Hydration) findet er nur einen Bruchteil der tatsächlich geladenen Cookies und Skripte, weil:

• Skripte werden nach dem initialen HTML lazy nachgeladen, der Scanner sieht sie nicht.
• Routing passiert client-seitig. Sub-Pages werden nicht gecrawlt.
• Dritt-Skripte werden konditional eingebunden (nur in bestimmten Routes oder bei bestimmten User-States).

Konsequenz: Cookiebot meldet eine „saubere" Cookie-Liste, in der die Hälfte der real existierenden Tracker fehlt. Compliance-Risiko, das in der Routine-Prüfung untergeht. Wer eine Next.js-/React-App betreibt, muss manuelles Fallback-Mapping anlegen, das die Cookies pflegt, die der Scanner nicht findet. Damit ist der größte Bequemlichkeits-Vorteil (Auto-Scan) faktisch weg.

Die zweite 2026-Falle ist die Preisstruktur. Cookiebot rechnet pro Seitenanzahl ab, was bei klassischen Sites mit 100–500 Unterseiten unproblematisch ist, aber bei AI-generierten Long-Tail-Sites, programmatischen SEO-Setups oder großen Content-Hubs schnell ins Unverhältnismäßige kippt:

Ab etwa 5.000 Unterseiten zieht die Pricing-Stufe stark an. Im niedrigen fünfstelligen Seitenbereich liegt Cookiebot dann über dem Usercentrics-Band, bei großen AI-Content-Sites oft sogar über OneTrusts Enterprise-Pauschale.

Wann es trotzdem passt:

• Kleinere bis mittlere Sites ohne eigene Compliance-Abteilung. Cookiebot tut, was es soll, ohne dass jemand intern lernen muss wie ein Privacy-Office tickt.
• Klassisches, server-gerendertes HTML ohne SPA-Anteile.
• Stabile Site mit < 5.000 Unterseiten und manueller Wartung der Tag-Listen.
• Klare, einzelne Compliance-Anforderung: rechtskonformer Cookie-Banner, mehr nicht.

Wann es nicht reicht: SPA-zentrische Stacks, Sites mit programmatischer Page-Generierung, Vendor-Management über das CMP, Marketing-Setup mit 50+ individuell zu kategorisierenden Tools, oder DSGVO-Auskunftsersuchen über das CMP. Cookiebot ist absichtlich kein Privacy-Suite-Tool.

Vergleichstabelle

Drei Entscheidungsfragen, als If/Then-Entscheidungsbaum

Die folgenden Wenn-dann-Regeln ersetzen 80 Prozent der Marketing-Pitches der Anbieter. Antwort jeweils ehrlich beantworten, danach steht eine klare Richtung.

• ✅ WENN ihr eine Next.js-/React-App mit 100.000+ Unterseiten habt DANN vermeidet Cookiebots Auto-Scanner und plant entweder Headless CMP oder OneTrust mit manueller Vendor-Liste ein.
• ✅ WENN ihr intern jemanden habt, der Privacy-Compliance als Vollzeitthema betrachtet (DSB + Privacy-Engineer) DANN kann OneTrust sein Geld wert sein, sonst wird es eine 25-k-€-Karteileiche.
• ✅ WENN ihr < 30 aktive Marketing- und Analyse-Tools nutzt UND eine klassische server-gerenderte Site habt DANN ist Cookiebot der schnellste Weg zur Compliance.
• ✅ WENN ihr mehrere Domains oder Marken in DACH betreibt und die deutsche Datenschutz-Aufsicht der Maßstab ist DANN Usercentrics: zentrale Steuerung, Geo-Regeln, deutsches Hosting, ohne OneTrust-Overhead.
• ✅ WENN ihr eine Brand mit hohem Design-Anspruch seid (Tech-Startup, Premium-Brand, Konsulting) DANN lohnt sich Headless CMP. Standard-Banner gewinnen 2026 keine Brand-Awards.
• ✅ WENN ihr > 200 DSGVO-Auskunftsanfragen pro Jahr beantwortet DANN automatisiert OneTrust diese Workflows, das allein rechtfertigt oft den Aufpreis.
• ✅ WENN Core Web Vitals geschäftskritisch sind (E-Commerce, hoher organischer Traffic) DANN Headless CMP. Standard-CMPs blockieren oft 50–80 KB JS auf der ersten Page.
• ✅ WENN keine der oberen Wenn-Bedingungen klar zutrifft DANN Cookiebot, der pragmatischste Default für 70 % aller Setups.

Wann alle drei falsch sind, der Headless-CMP-Trend 2026

Es gibt Setups, in denen weder OneTrust noch Usercentrics oder Cookiebot die richtige Antwort sind. 2026 sehen wir das deutlich öfter als noch vor zwei Jahren, und der Grund ist fast immer derselbe: ein Headless CMP.

Konzept: eine eigene React-/Vue-/Svelte-Komponente baut das Banner-UI, dahinter sitzt eine CMP-API (Cookiebot bietet eins, Usercentrics, Klaro!, oder ein API-only-Anbieter wie Datatrails). Die Compliance-Mechanik (Audit-Trail der Einwilligungen, Geo-Logik, Cookie-Definitions-Datenbank) bleibt beim API-Anbieter. Die UI gehört dem eigenen Team.

Warum das 2026 zum Default wird:

• Core Web Vitals. Standard-CMPs blockieren typisch 50–80 KB JS plus Render-Path beim First Paint. Eine eigene Komponente, die nur 4–6 KB lädt und nach dem ersten Paint aufmacht, gewinnt LCP, INP und CLS spürbar.
• Brand-Fit. Standard-Banner sehen aus wie Standard-Banner. Eigene Komponenten matchen Schrift, Farbe, Spacing und Microcopy pixelgenau zur Brand, wichtiger Signal bei Premium-Brands.
• A11y und Microcopy. Eigene Komponente erlaubt feines Tuning. Fokus-Management, ARIA-Labels, kontextuelle Hilfetexte. Die Standard-CMPs liefern „okay", nicht „großartig".
• DMA-Pflicht Consent Mode v2 sauber. Wer die UI selbst baut, baut auch die Signal-Logik selbst, ad_user_data/ad_personalization werden exakt dann gesetzt, wann sie sollen, ohne Mapping-Krücken.

Aufwand: 2–4 Wochen für eine erste Version, plus die API-Lizenz im niedrigen vierstelligen Bereich pro Jahr. Klingt mehr als Cookiebot, ist es im Anfangsjahr auch. Aber: bei Sites mit hohen Volumina (> 5.000 Unterseiten, > 200 k Sessions/Monat) ist Headless oft günstiger als Cookiebots Volumen-Stufen, und bei Brand-Fokus zahlt sich der Aufwand allein über die Bounce-Rate-Verbesserung beim Banner aus.

Disclosure

Alle drei Plattformen haben wir bei Kunden produktiv implementiert und betrieben, mehrfach inklusive Übernahme von Setups, die eine Vorgängeragentur falsch konfiguriert hatte. Headless-CMP-Setups bauen wir seit 2024 selbst.

Seit Juni 2026 sind wir zertifizierter Usercentrics-Partner (CMP Expert Tech Track), und Cookiebot gehört zum selben Unternehmen. Die Partnerschaft ist eine technische Zertifizierung, keine Reselling- oder Provisions-Vereinbarung; an keiner Lizenz in diesem Vergleich verdienen wir mit. Zu OneTrust besteht keine geschäftliche Beziehung. Die Einschätzungen hier, inklusive der SPA-Schwäche des Usercentrics-Scanners und der Cookiebot-Pricing-Kritik, stammen aus Projekterfahrung, nicht aus Hersteller-Material.

Konkrete Schritte

Noch kein CMP im Einsatz? Die If/Then-Regeln oben geben die Richtung vor, danach steht die Shortlist. Ein unpassendes CMP lässt sich wechseln: 1–2 Wochen zu Cookiebot oder Usercentrics, 4–8 Wochen zu OneTrust, 4–6 Wochen in ein Headless-Setup. Entscheidend ist die Migration der Consent-States, sonst verfallen alle bestehenden Einwilligungen. Wir haben mehrere dieser Wechsel begleitet.

Der saubere Einstieg ist der Audit Sprint: Bestandsaufnahme des aktuellen Consent-Setups, priorisierter Mängel-Report, Wechsel- oder Fix-Plan. Mehr zur Methodik auf der Measurement & Privacy Engineering Service-Seite.

CMP-Wechsel anstehend? Audit Sprint anfragen →, Festpreis 2.400 € netto · 10 Arbeitstage.