Zum Inhalt springen
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.

Passende Technologien

Tags

Headless CMSSanityStrapiContentfulWordPressJAMstackHybrid

Theorie in die Praxis umsetzen?

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