Technologie15 min Lesezeit

CMS-Vergleich 2026: Headless, klassisch oder Hybrid?

Sanity, Strapi, Contentful — und WordPress, das längst auch headless kann. Wie wir in der Praxis zwischen klassischem CMS, Headless und Hybrid wählen.

TR
Tobias Rösner
Geschäftsführer & Lead Developer

Die CMS-Frage hat sich verschoben. Vor fünf Jahren war "Headless oder klassisch?" noch ein scharfer Schnitt. Heute kann WordPress headless, Sanity hat ein vollwertiges Studio, und Hybrid-Ansätze sind die Regel. Wir vergleichen vier echte Wege — und sagen ehrlich, wann welcher Sinn macht.

Klassisch vs. Headless: Was der Unterschied wirklich bedeutet

Ein klassisches CMS (WordPress, Drupal, Typo3) liefert Frontend und Backend in einem System — Themes, Templates, Markup kommen aus dem CMS heraus. Ein Headless CMS liefert nur Daten via API; das Frontend baut man separat mit Next.js, Nuxt oder SvelteKit. Hybrid-Setups (z. B. WordPress als Headless) kombinieren das vertraute Backend mit einem modernen Frontend.

Wichtig: "Headless" ist keine Eigenschaft der Software, sondern der Architektur. WordPress kann headless betrieben werden, Sanity kann mit einem fertigen Studio fast wie klassisch wirken.

Option 1: WordPress klassisch — bewährte Standardlösung

WordPress ist das CMS, das die meisten Redaktionen kennen. Block-Editor, Plugins für nahezu jeden Use-Case, gut funktionierende Workflows für Redaktionsteams. Für viele Sites bleibt es die pragmatische Wahl — gerade dann, wenn Endkunden selbst Inhalte pflegen sollen.

Wofür WordPress klassisch ein guter Fit ist:

  • Corporate Websites, Magazine, Blogs mit klaren Redaktions-Workflows
  • Content-lastige Sites, wo Backend-UX für nicht-technische Redakteure zählt
  • Projekte mit klassischen Plugins (Membership, SEO, Analytics) ohne eigene Entwicklung
  • Budgets, bei denen Headless-Komplexität nicht zu rechtfertigen wäre

Grenzen klassischer WordPress-Sites:

  • Performance: ohne Caching-Strategie wird WordPress schnell träge
  • Frontend-Modernisierung schwerer — man arbeitet im Theme-/Block-System, nicht in einem reinen Frontend-Framework
  • Plugin-Hygiene wichtig: zu viele Plugins erzeugen Pflegeschulden

Option 2: Sanity — Flexibilität für Custom-Content

Sanity ist unser Standard-Headless-CMS, wenn das Datenmodell komplex ist und die Redaktions-UX hochwertig sein soll. Das Schema wird in Code (TypeScript) definiert — was sich für Entwickler nach Heimat anfühlt — und das Studio ist eine vollwertige Redaktionsoberfläche, die man sogar selbst hosten und anpassen kann.

Sanity-Stärken:

  • Schema-as-Code: Datenmodell ist versionierbar, reviewbar, testbar
  • GROQ als Query-Sprache ist mächtig (Portable Text, Filter, Joins)
  • Real-time Collaboration im Studio — mehrere Redakteure parallel ohne Konflikte
  • Großzügiges Free Tier, gut für kleinere Projekte
  • Erstklassige TypeScript-Integration

Was zu beachten ist:

  • Studio braucht Custom-Setup — kein "Drag & Drop einer Site"
  • Frontend muss komplett selbst gebaut werden (Next.js, Nuxt, SvelteKit)
  • Kosten skalieren mit Dokumenten-/Datasets-Anzahl

Option 3: Strapi — Self-Hosted Headless mit voller Kontrolle

Strapi ist die Open-Source-Alternative, die wir nehmen, wenn Datenhoheit ein hartes Anforderungs-Argument ist (EU-Hosting, eigene Server, kein US-SaaS). Admin-UI lässt sich konfigurieren, REST- und GraphQL-APIs sind Standard.

Strapi-Stärken:

  • Self-Hosted: volle Daten- und Infrastruktur-Kontrolle
  • Open Source: kein Vendor Lock-in
  • Admin-UI ohne Code konfigurierbar — niedrigere Einstiegshürde als Sanity
  • Plugin-Ökosystem für Erweiterungen
  • Lizenzkostenfrei (Community-Edition) — laufende Kosten sind nur Hosting

Realistische Trade-Offs:

  • Eigenes Hosting bedeutet eigene Verantwortung für Updates und Backups
  • Major-Updates erfordern teils manuelle Migration
  • Performance-Tuning bei größeren Datenmengen Eigenleistung

Option 4: Contentful — Enterprise-Standard

Contentful ist der Enterprise-Klassiker — etabliert, stabil, mit Features für große Teams (SSO, Audit-Logs, Workflows). Pricing entsprechend: Free-Tier ist limitiert, ernsthafte Nutzung beginnt bei $300/Monat aufwärts.

Wann Contentful sinnvoll ist:

  • Enterprise-Kunden mit etablierten Compliance-Anforderungen
  • Sehr große Redaktions-Teams mit komplexen Workflows
  • Multi-Site / Multi-Brand-Setups mit zentralem Content-Repository

Hybrid: WordPress als Headless

Spannend wird es, wenn das Beste aus beiden Welten gefragt ist: WordPress als Backend (Redaktion kennt das System), aber Frontend mit Next.js oder Nuxt für moderne UX und Performance. Über die WP-REST-API oder WPGraphQL holen wir die Daten ab und rendern damit ein eigenes Frontend.

Wofür Hybrid-WordPress passt:

  • Redaktion hat WordPress-Erfahrung, will nicht umlernen
  • Frontend-Performance ist hart (Core Web Vitals als Conversion-Faktor)
  • Bestehende WP-Installation soll modernisiert werden, ohne Redaktionsprozesse anzufassen
  • Multi-Channel: dieselben Inhalte für Website + App + Newsletter

Was Hybrid-Setups verlangen:

  • API-Layer sauber dokumentieren (REST oder WPGraphQL)
  • Caching-Strategie auf Frontend-Seite (ISR mit Next.js, route-level caching in Nuxt)
  • Authentifizierung und Preview-Modus brauchen Setup

Pricing im Schnellüberblick

Grobe Orientierung (Stand 2026):

  • WordPress klassisch: ~5–30 €/Monat Hosting, ggf. Premium-Plugins einmalig
  • WordPress headless: Hosting + Frontend-Hosting (managed oder selbst-gehostet) — typisch zusammen 20–80 €/Monat
  • Sanity: Free für kleine Projekte, dann ab ~99 $/Monat
  • Strapi: kostenlos (Community) + eigenes Hosting (10–50 €/Monat), Cloud ab ~29 $/Monat
  • Contentful: Free-Tier sehr limitiert, ernsthafte Nutzung ab ~300 $/Monat

Wann wir was empfehlen

WordPress klassisch: wenn Redaktion das System kennt, kein hartes Performance-Argument vorliegt, Budget pragmatisch ist.

Sanity: wenn das Datenmodell komplex ist (Custom Content Types, strukturierte Inhalte) und das Frontend ohnehin eigenständig gebaut wird.

Strapi: wenn Self-Hosting harte Anforderung ist (EU-Datenhoheit, eigene Infrastruktur).

Contentful: wenn Enterprise-Workflows, SSO und große Teams den Pricing-Punkt rechtfertigen.

Hybrid-WordPress: wenn Redaktion bei WordPress bleiben soll, das Frontend aber maximale Performance liefern muss.

Fazit

Es gibt keinen Universal-Gewinner. Wir wählen nach Redaktions-Realität, Performance-Anspruch und Hosting-Anforderungen — nicht nach Tool-Vorliebe. Wer dem Kunden ehrlich erklärt, welche Konsequenzen eine CMS-Entscheidung über die nächsten Jahre hat, baut die nachhaltigere Site.

Tags

Headless CMSSanityStrapiContentfulWordPressJAMstackHybrid

Theorie in die Praxis umsetzen?

Sprechen Sie mit uns über Ihr nächstes Projekt.