Headless CMS vs traditionelles CMS 2026: Was wählen
„Alle reden von Headless, Jamstack, Decoupled. Brauche ich das wirklich?" Die häufigste Frage von Kunden, die Twitter-Threads von Entwicklern gelesen haben. Die Realität: Für 80 % aller Geschäftsanforderungen reicht ein traditionelles CMS (Joomla, WordPress) völlig aus. Aber für die restlichen 20 % bietet Headless einen echten Vorteil. In diesem Artikel – was die beiden unterscheidet und für wen welche Lösung geeignet ist, ohne Hype.
Was ist ein Headless CMS
Ein traditionelles CMS (Joomla, WordPress, Drupal) besteht aus drei fest miteinander verbundenen Schichten: dem Admin-Bereich, in dem Redakteure Inhalte schreiben, der Datenbank, in der diese gespeichert werden, und dem Theme (Template), das die Seiten rendert. Sie ändern das Template – Sie ändern das Design. Sie ändern das CMS – Sie ändern alles.
Anteil von Headless an allen CMS-Websites in 2026
Migrationsdauer von traditionellem CMS zu Headless
typischer PageSpeed Mobile bei Jamstack-Sites
höhere Entwicklungskosten Headless vs traditionelles CMS
Bei einem Headless CMS bleiben nur der Admin-Bereich und die Datenbank. Das Frontend gehört Ihnen, in einer beliebigen Technologie. Das CMS liefert Inhalte über eine REST- oder GraphQL-API. Der Frontend-Entwickler nimmt die API und gestaltet die Seiten beliebig.
Einfache Analogie: Ein traditionelles CMS ist ein Auto mit fertiger Karosserie. Headless ist ein Chassis mit Motor, die Karosserie bauen Sie selbst nach Ihren Anforderungen. Mehr Flexibilität, aber auch mehr Arbeit.
Stack und Architektur – Vergleich
| Parameter | Traditionelles CMS (Joomla, WP) | Headless CMS |
|---|---|---|
| Was ist enthalten | Admin + DB + Frontend-Themes | Admin + DB + API. Frontend separat. |
| Wer rendert die Seiten | CMS-Theme (PHP-Templates) | Beliebiges Frontend: React, Vue, Astro, Next.js |
| Wer wird im Team benötigt | 1 Fullstack-Entwickler | Frontend-Entwickler + Backend (oder 1 Fullstack) |
| Ladegeschwindigkeit | 60–85 PageSpeed Mobile ab Werk | 95–100 (statisches Rendering) |
| SEO | Ab Werk, Plugins | Manuell, aber mehr Kontrolle |
| Multi-Channel | Nur Web | Web + Mobile + digitale Schaufenster + E-Mail |
| Entwicklungskosten | Basis (1×) | 2–3× Basis |
| Wartungskosten | Plugin-Updates | Frontend-Updates + CMS separat |
| Lernkurve für Redakteure | Einfach, gewohnt | Ähnlich, aber „losgelöst" vom Endergebnis |
Für wen welcher Ansatz geeignet ist
Wann ein traditionelles CMS wählen (Joomla, WordPress)
- Unternehmenswebsite mit 10–50 Seiten. Team von 1–3 Redakteuren, einmalige Entwicklung, minimale Anpassung. Joomla oder WordPress deckt 95 % der Anforderungen ab.
- Blog oder Medien. WordPress ist der De-facto-Standard für Content-Projekte. Riesiges Ökosystem, komfortabler Editor für Nicht-Techniker.
- Kleiner E-Commerce. WooCommerce (WP) oder VirtueMart/HikaShop (Joomla) funktionieren gut bis zu 5000 SKU.
- Kleines lokales Team. Wenn Sie keinen Frontend-Entwickler haben und auch keinen einstellen wollen – das traditionelle CMS gewinnt.
- Schneller Start mit festem Budget. Eine Landingpage aus fertigen Themes + Plugins in 1–2 Wochen zu starten – ist mit einem traditionellen CMS einfacher.
Wann Headless gerechtfertigt ist
- Mehrere Konsumkanäle. Content geht an Website + iOS-App + Android-App + digitale Anzeigetafeln in Filialen + E-Mail-Newsletter. Eine Quelle der Wahrheit über die API.
- Das Team arbeitet bereits mit React/Vue/Next. Warum ein neues CMS-Theme lernen, wenn der Frontend-Entwickler über Next.js oder Astro rendern kann?
- Performance-kritische Websites. Wenn jede 0,1 Sekunde Ladezeit Millionen Euro Umsatz bedeutet (großer E-Commerce, Werbung mit hohem CPC).
- Komplexe UI-Anpassung. Wenn Standard-Themes nicht reichen, interaktive Dashboards, individuelle Widgets, Echtzeitdaten benötigt werden.
- Team aus 5+ Redakteuren mit verschiedenen Rollen. Gute Headless CMS haben ein flexibles Rechtesystem, mehrstufige Workflows und Versionierung.
Strapi vs Sanity vs Contentful
Die drei beliebtesten Headless CMS auf dem Markt. Wie sie sich unterscheiden.
| Parameter | Strapi | Sanity | Contentful |
|---|---|---|---|
| Hosting | Self-hosted (Docker, VPS) | Managed (Cloud) | Managed (Cloud) |
| Open Source | Ja, MIT-Lizenz | Studio – Open Source, Backend – nein | Nein |
| Preis (kostenlos) | Kostenlos (nur Hosting) | Bis 10K Dok., 100K Anfragen/Mon. | Bis 50K Einträge |
| Preis (kostenpflichtig) | ~60–200 USD/Mon. (Cloud) | 99–1000+ USD/Mon. | 300+ USD/Mon. |
| Editor | Solide, gut | Sehr anpassbar (Studio) | Ausgereift, für Teams |
| API | REST + GraphQL | GROQ + GraphQL | REST + GraphQL |
| Für wen geeignet | Teams mit DevOps, Kontrolle | Start-ups, Flexibilität, schneller Start | Enterprise, große Teams |
Meine Empfehlungen nach Szenarien:
- MVP oder Prototyp, begrenztes Budget. Sanity Free Tier. Start in 2–3 Tagen, Editor-Schemata im Code, kostenlos lange genug.
- Unternehmensprojekt, Flexibilität + Kontrolle. Strapi self-hosted auf eigenem VPS oder Strapi Cloud. Volle Kontrolle über die Daten.
- Enterprise mit Team und Compliance. Contentful. SLA, Support, Sicherheit ab Werk, fertige Integration mit Marketingplattformen.
7 typische Fehler
- Headless wählen, „weil es modern ist". Wenn Sie 5 Redakteure und eine Website haben – ist ein traditionelles CMS meist günstiger. Headless ist architektonisch begründet, nicht „weil es auf Twitter gelobt wird".
- Kosten der Frontend-Entwicklung unterschätzen. Headless CMS sind nur 30 % des Systems. 70 % sind die Frontend-Anwendung. Das Budget für den Frontend-Entwickler und dessen Wartung ist oft höher als für das CMS selbst.
- Preview vergessen. Der Redakteur möchte sehen, wie ein Beitrag aussehen wird. Bei einem traditionellen CMS ist das „standardmäßig" vorhanden. Bei Headless muss Preview separat gebaut werden (Next.js Preview Mode, Sanity Visual Editing).
- i18n von Anfang an ignorieren. Wenn später Mehrsprachigkeit benötigt wird, ist die Migration schwieriger. Planen Sie die Unterstützung von der Architektur aus ein – über Locale in den Schemata.
- API-Caching nicht konfigurieren. Jede Anfrage an die Headless-API ist eine HTTP-Anfrage. Bei Spitzenlasten ohne CDN-Cache fällt die API aus. Cloudflare R2 / Vercel ISR / Astro Static – Lösung.
- Headless für ein Team ohne Frontend-Entwickler verwenden. Wenn Sie keinen festen Frontend-Entwickler haben – wer aktualisiert in 6 Monaten Next.js und React? Das CMS wird zum „herumhängenden Projekt".
- Sofort den Enterprise-Tier wählen. Contentful Pro für 300 USD/Monat ist überflüssig für ein Projekt mit 1000 Seiten. Beginnen Sie mit Free/Starter und wechseln Sie mit dem Wachstum.
Häufige Fragen
Was ist ein Headless CMS einfach erklärt?
Es ist ein CMS, das nur ein Backend hat (Admin-Bereich + API), während Sie das Frontend selbst erstellen – mit einem beliebigen Framework (React, Vue, Astro, Next.js). Bei einem traditionellen CMS wie Joomla oder WordPress sind Admin-Bereich und Frontend fest verbunden. Bei Headless erhalten Sie Inhalte über REST oder GraphQL und rendern sie nach Belieben. Vorteil: Flexibilität, Geschwindigkeit, Multi-Channel. Nachteil: Sie benötigen einen Frontend-Entwickler.
Wann ist Headless besser als ein traditionelles CMS?
Wenn Sie mehrere Kanäle zur Content-Nutzung haben (Website + mobile App + digitale Schaufenster + E-Mail), wenn maximale Geschwindigkeit benötigt wird (Jamstack-Ansatz), wenn das Team mit modernen Frontend-Frameworks arbeitet oder wenn eine feinkörnige UI-Anpassung ohne CMS-Theme-Beschränkungen erforderlich ist. Für eine typische Unternehmenswebsite oder einen Blog reicht ein traditionelles CMS meistens aus.
Wie viel kostet ein Headless CMS?
Hängt von der Wahl ab. Strapi self-hosted – kostenlos (nur Hosting). Sanity Free Tier – bis zu 10K Dokumente und 100K API-Anfragen pro Monat kostenlos. Contentful Free – bis zu 50K Einträge. Kostenpflichtige Pläne von Sanity/Contentful: 99–300 USD/Monat. Joomla/WordPress – 0 USD (nur Hosting). Headless ist in der Regel teurer, da sowohl ein Frontend-Entwickler als auch ein CMS-Service erforderlich sind.
Strapi vs Sanity vs Contentful – was ist besser?
Strapi – self-hosted, Open Source, maximale Kontrolle, ideal für Teams mit DevOps. Sanity – managed, flexible Datenschemata, hervorragender Editor (Sanity Studio). Contentful – die ausgereifteste Enterprise-Variante, mehr Plugins und Integrationen, aber teurer. Für Prototypen und Start-ups – Sanity. Für Großunternehmen – Contentful. Für alle, die alles selbst hosten möchten – Strapi.
Kann man von WordPress zu Headless migrieren?
Ja. Sie können WordPress als Headless beibehalten – es hat eine REST-API und das WPGraphQL-Plugin. Das bietet eine Übergangsvariante: Das Team arbeitet weiter im WP-Admin, während das Frontend mit Next.js oder Astro gebaut wird. Das ist oft der optimale Migrationspfad – Prozesse nicht stören, aber Jamstack-Performance erreichen. Migrationszeit – 3 bis 6 Wochen, abhängig vom Umfang.
Denken Sie über Headless oder klassisches CMS nach?
Beschreiben Sie Ihre Aufgabe – ich sende Ihnen ein PDF mit einer Stack-Empfehlung für Ihren Fall, inklusive Zeitplan und Kosten. Kostenlos, innerhalb von 24 Stunden.