OneTrust vs Cookiebot 2026, was passt für wen (und wann beides falsch ist)

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 und Cookiebot lösen dasselbe Problem. Aber auf so unterschiedlichem Niveau, dass sie für unterschiedliche Unternehmen die richtige Wahl sind. Und 2026 ist die Antwort manchmal: keiner von beiden, 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 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 Enterprise-Verträgen meist deutlich unter 5.000 €/Jahr. Implementierung in einem halben Tag möglich. Cookie-Liste wird automatisch durch wöchentliche 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, bei großen AI-Content-Sites kommt Cookiebot dann oft teurer als 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 beider 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 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 beides falsch ist, der Headless-CMP-Trend 2026

Es gibt Setups, in denen weder OneTrust noch 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.

Wer eine deutsche Datenschutz-Aufsicht als Hauptlieferant von Compliance-Druck hat und die Software aus klar EU-souveränen Quellen kommen soll, ist Usercentrics weiterhin oft die saubere Antwort, deutsche Firma, deutsche Hosting-Standorte, deutsche AGB. Funktional zwischen Cookiebot und OneTrust angesiedelt, mit fokussiertem Privacy-Modul-Set, und mit guter API-First-Variante für Headless-Setups.

Disclosure

Wir sind weder Reseller noch Affiliate von OneTrust oder Cookiebot. Beide Plattformen haben wir bei verschiedenen Kunden produktiv implementiert, in beiden haben wir Setups übernommen die eine Vorgängeragentur falsch konfiguriert hat. Headless-CMP-Setups bauen wir seit 2024 selbst, bei mehreren Kunden produktiv. Diese Empfehlungen basieren auf direkter Erfahrung, nicht auf Marketing-Material der Hersteller.

Konkrete Schritte

Ohne aktuelles CMP, beginnen mit den If/Then-Regeln oben. Bei einem unpassenden CMP, ein Wechsel ist in 4–8 Wochen machbar, wir haben mehrere davon begleitet. Headless-CMP-Migration aus einem Standard-Tool: 4–6 Wochen typisch.

Bei aktuellem Bedarf an einer ehrlichen Außensicht: ein Discovery-Call dauert 30 Minuten und kostet nichts. Mehr zur Methodik gibt es auf der Measurement & Privacy Engineering Service-Seite.

CMP-Wechsel anstehend? Audit Sprint anfragen →, ab 1.500 € · 2 Wochen Turnaround.