Was ist ein Headless CMS? Einfach erklärt, mit echten Messungen (2026)

Irgendwann fällt das Wort in jedem Website-Projekt: „Wir sollten auf ein Headless CMS gehen.“ Meistens sagt es jemand aus der Entwicklung, und meistens nicken alle anderen, ohne genau zu wissen, was sich dadurch für sie ändert.

Was ist ein Headless CMS? Ein Headless CMS ist ein Content-Management-System, das nur noch Inhalte verwaltet und sie über eine Schnittstelle (API) ausliefert, aber selbst keine Website mehr darstellt. Der „Kopf“, also das Frontend mit Layout, Design und HTML, wird abgetrennt und separat gebaut. Dasselbe Backend kann dann eine Website, eine App, einen Newsletter oder ein Display im Laden beliefern.

In diesem Artikel erklären wir das ohne Marketing-Nebel: was technisch passiert, wenn ein Headless CMS eine Seite ausliefert, worin es sich von WordPress im Normalbetrieb unterscheidet, welche Systeme es gibt, was das alles kostet und wann ein klassisches CMS die bessere Wahl bleibt. Die Zahlen stammen aus eigenen Messungen am 16. Oktober 2026 an einem WordPress-Testcontainer auf unserem Server und an dieser Website, die selbst ganz ohne CMS läuft.

Das Video von Codista ist von Juni 2024, also älter als ein Jahr. Wir binden es trotzdem ein, weil es eine der wenigen deutschsprachigen Erklärungen ist, die wirklich ohne Fachbegriffe auskommen, und weil sich das Grundprinzip seitdem nicht verändert hat. Weiter unten folgt eine englische Erklärung von Februar 2026.

Was ist ein Headless CMS — die kurze Antwort

Wenn du nur fünf Sätze lesen willst, dann diese:

1. Ein CMS (Content-Management-System) ist die Software, in der Inhalte gepflegt werden: Texte, Bilder, Produkte, Termine.
2. Ein klassisches CMS wie WordPress im Standardbetrieb speichert diese Inhalte und baut daraus die fertige HTML-Seite mit Theme, Menü und Footer.
3. Ein Headless CMS macht nur den ersten Teil. Es speichert und verwaltet, liefert die Inhalte aber als rohe Daten (meist JSON) über eine API aus.
4. Das Frontend, also das, was Besucher sehen, ist ein eigenes Projekt, gebaut mit Astro, Next.js, Nuxt, einer App oder was auch immer.
5. Der Vorteil ist Freiheit bei der Darstellung und Wiederverwendung, der Preis ist ein zweites System, das jemand bauen und betreiben muss.

Der Name ist wörtlich gemeint: Man schlägt dem CMS den Kopf ab. Der Körper (Datenbank, Redaktionsoberfläche, Rechte, Versionen) bleibt, der Kopf (Templates, Theme, Seitenausgabe) fliegt raus und wird durch einen oder mehrere neue Köpfe ersetzt.

Klassisches CMS vs. Headless CMS: der Unterschied

Um zu verstehen, was „headless“ wegnimmt, hilft ein Blick darauf, was ein klassisches CMS bei jedem Seitenaufruf tut.

So arbeitet ein klassisches CMS

Rufst du einen Blogartikel auf einer normalen WordPress-Seite auf, passiert ungefähr das:

1. Der Webserver gibt die Anfrage an PHP weiter.
2. WordPress lädt seinen Kern, alle aktiven Plugins und das Theme.
3. Es fragt die Datenbank nach dem Artikel, dem Menü, den Widgets, den Einstellungen.
4. Das Theme setzt alles zu einer kompletten HTML-Seite zusammen, inklusive aller Skripte und Stylesheets, die Plugins sich dazu wünschen.
5. Die fertige Seite geht an den Browser.

Inhalt und Darstellung sind hier eng verheiratet. Das ist nicht schlecht: Genau deshalb kann eine Redakteurin in WordPress auf „Vorschau“ klicken und sieht exakt, wie die Seite aussehen wird. Es heißt aber auch, dass jedes Plugin, das etwas auf der Seite anzeigen will, sich in diese Ausgabe einklinkt.

So arbeitet ein Headless CMS

Bei einem Headless CMS endet die Kette nach Schritt 3. Statt HTML kommt eine Datenantwort zurück, etwa so:

{
  "id": 6,
  "date": "2026-10-15T12:54:12",
  "title": { "rendered": "Hello Tacilytics" },
  "content": { "rendered": "<p>Read the <a href=\"/files/guide.pdf\">PDF guide</a> …</p>" }
}

Das ist keine erfundene Beispielantwort, sondern die echte Ausgabe unseres WordPress-Testcontainers für einen Beitrag, abgefragt über die eingebaute REST-API. Mehr dazu gleich bei den Messungen.

Was mit diesen Daten passiert, entscheidet ein anderes Programm: Ein Static-Site-Generator wie Astro holt sie beim Build ab und schreibt daraus fertige HTML-Dateien. Eine Next.js-App holt sie bei jedem Aufruf oder aus einem Cache. Eine iOS-App zeigt sie nativ an. Ein Kassensystem im Laden zeigt nur den Titel und den Preis.

Die Begriffe, die dabei herumschwirren

• Backend — das CMS selbst, mit Datenbank und Redaktionsoberfläche.
• Frontend oder „Head“ — das, was Besucher sehen.
• API — die Schnittstelle zwischen beiden. Fast immer REST oder GraphQL. Wenn dir das Wort noch fremd ist: Wir haben ausführlich erklärt, was eine API ist, und warum man sich zwischen REST und GraphQL entscheiden muss.
• Content-Modell — die Struktur der Inhalte. Statt „eine Seite mit Text“ definierst du Felder: Titel, Teaser, Autor, Bild, Preis, Zutatenliste.
• Decoupled CMS — ein Mittelding: Das CMS hat noch ein eigenes Frontend, bietet aber zusätzlich eine API. WordPress mit REST-API ist genau das.
• Jamstack — ein Architekturbegriff für Seiten aus JavaScript, APIs und vorgebautem Markup. Headless CMS sind dort die übliche Datenquelle.

Vergleich auf einen Blick

Wie ein Headless CMS Inhalte ausliefert: unsere Messung

Theorie ist billig, also haben wir nachgemessen. Auf unserem Server läuft ein WordPress-Testcontainer (WordPress 6.7, PHP 8.3, MariaDB 11), den wir für Plugin-Tests nutzen. WordPress bringt seit Version 4.7 eine REST-API mit und kann deshalb beides: klassisch HTML ausliefern und headless Daten. Damit lässt sich derselbe Beitrag auf beiden Wegen abrufen und vergleichen.

Gleicher Beitrag, zwei Wege

Gemessen mit curl direkt auf dem Server, je drei Aufrufe hintereinander:

Was man daraus lesen kann und was nicht:

Die Datenmenge schrumpft drastisch. Der eigentliche Inhalt des Beitrags sind 248 Bytes. Die HTML-Seite drumherum ist über 400-mal so groß und enthält 21 <script>-Tags, die Theme und Plugins einbauen. Das ist der Kern des Headless-Gedankens: Das CMS schickt nur, was wirklich Inhalt ist, und das Frontend entscheidet, wie viel Ballast es dazupackt.

Die API ist schneller, aber nicht magisch. Auch die JSON-Antwort braucht 60 bis 170 Millisekunden, weil WordPress trotzdem PHP startet und die Datenbank fragt. Ein Headless CMS macht die Datenbankarbeit nicht billiger, es verlagert nur die Darstellung woanders hin.

Am schnellsten ist, wer zur Laufzeit gar nicht fragt. Die statische Astro-Seite antwortet in rund 20 Millisekunden, weil sie schon fertig auf der Platte liegt. Genau deshalb kombiniert man Headless CMS so oft mit Static-Site-Generatoren: Das CMS wird nur beim Build gefragt, Besucher bekommen fertige Dateien. Warum das bei uns so gut funktioniert, haben wir im Vergleich Astro vs. Next.js ausführlich beschrieben.

Ehrliche Einschränkung: Das ist ein Testcontainer mit kaum Inhalten und WooCommerce-Plugins, gemessen auf demselben Server ohne Netzwerkweg dazwischen. Absolute Zahlen auf deinem Hosting werden anders aussehen. Die Größenverhältnisse aber sind typisch.

Die Falle mit dem riesigen API-Index

Ein Nebenbefund, der für Headless-Projekte wichtig ist: Der Einstiegspunkt /wp-json/ unseres Testcontainers ist 1.240.990 Bytes groß, also rund 1,2 MB. Er listet jede Route jedes Plugins mit allen Parametern auf. Wer im Frontend ungeschickt erst mal „alles abfragt“, lädt Megabytes, um 248 Bytes Inhalt zu bekommen.

Darum steht in unserer Messung ?_fields=id,title,content,date: Damit liefert WordPress nur die Felder, die wir brauchen. Ohne diesen Parameter war schon die Antwort für einen Beitrag 1.735 Bytes groß, also siebenmal so viel wie nötig. Bei einer Liste von 100 Beiträgen summiert sich das schnell. Gute Headless-Systeme machen genau diese Auswahl leicht, GraphQL-APIs sind dafür sogar gebaut.

Was die API öffentlich verrät

Zweiter Nebenbefund: Ohne jede Anmeldung lieferte /wp-json/wp/v2/users den Benutzernamen des Admin-Kontos zurück. Das ist WordPress-Standard und keine Sicherheitslücke im engeren Sinn, aber es halbiert die Arbeit für jemanden, der Passwörter durchprobieren will. Schreibzugriffe waren dagegen sauber gesperrt: Ein POST auf /wp-json/wp/v2/posts ohne Anmeldung bekam ein 401.

Die Lektion für jedes Headless-Projekt: Eine API ist eine öffentliche Tür, auch wenn deine Website sie gar nicht benutzt. Prüfe, welche Endpunkte ohne Anmeldung antworten, und schalte ab, was das Frontend nicht braucht. Wie viele Bots täglich nach solchen Türen suchen, haben wir in unserem eigenen Serverlog gezählt, nachzulesen im Abschnitt über Scanner im API-Artikel.

Vorteile eines Headless CMS

Ein Inhalt, viele Kanäle

Das stärkste Argument. Wenn ein Produkttext auf der Website, in der App, im Newsletter und auf dem Bildschirm im Schaufenster erscheinen soll, pflegst du ihn einmal. Jeder Kanal holt sich die Felder, die er braucht. Mit einem klassischen CMS kopiert man in so einem Fall Texte von Hand hin und her, und spätestens nach dem dritten Preis-Update stimmen sie nicht mehr überein.

Freie Wahl der Frontend-Technik

Das Frontend-Team ist nicht mehr an PHP-Templates gebunden. Es kann React, Vue, Svelte, Astro oder native Apps nutzen und den Stack wechseln, ohne die Inhalte anzufassen. Umgekehrt kannst du das CMS austauschen, ohne das Design neu zu bauen, solange das neue System dieselben Felder liefert.

Performance

Weil das Frontend nur Daten bekommt, kann es selbst entscheiden, wie schlank es bleibt. In Kombination mit einem Static-Site-Generator und einem CDN liegen fertige Seiten weltweit verteilt bereit, das CMS wird zur Laufzeit gar nicht gefragt. Unsere Messung oben zeigt den Unterschied: 20 Millisekunden für die statische Seite gegen 100 bis 500 Millisekunden für die vom CMS gerenderte.

Sicherheit durch Trennung

Bei einem klassischen CMS ist die Redaktionsoberfläche Teil der öffentlichen Website. Bei einem Headless-Setup kann das CMS hinter einer Firewall, einem VPN oder auf einer anderen Domain stehen, während Besucher nur statische Dateien sehen. Wer die öffentliche Seite angreift, findet kein Login, keine Plugins, keine Datenbank. Wichtig: Das gilt nur, wenn du die API wirklich abschirmst. Ein Headless CMS mit öffentlich erreichbarem Admin ist genauso angreifbar wie WordPress.

Strukturierte Inhalte

Headless CMS zwingen dich, Inhalte als Felder zu denken statt als „eine große Textbox“. Das fühlt sich anfangs bürokratisch an, zahlt sich aber aus: Strukturierte Daten lassen sich filtern, übersetzen, als Schema-Markup ausgeben und von KI-Systemen sauber auslesen.

Nachteile, über die Anbieter ungern reden

Zwei Systeme statt einem

Das ist der Punkt, der in Verkaufsgesprächen am leisesten gesagt wird. Du betreibst ein CMS und ein Frontend. Zwei Codebasen, zwei Deployments, zwei Sätze an Updates, zwei Stellen, an denen etwas kaputtgehen kann. Wenn das Frontend den Build nicht schafft, ist die Website nicht aktuell, obwohl im CMS alles stimmt.

Die Redaktion verliert Komfort

In WordPress zieht eine Redakteurin einen Block auf die Seite und sieht sofort das Ergebnis. In einem reinen Headless CMS füllt sie Felder aus und sieht zunächst … Felder. Eine echte Vorschau muss das Entwicklungsteam extra bauen. Viele Anbieter haben das erkannt und bieten „Visual Editing“ an (Storyblok ist darauf spezialisiert, Sanity und Payload haben nachgezogen), aber es bleibt Einrichtungsarbeit.

Ohne Entwickler geht nichts

Ein neues Seitenlayout? Ein zusätzliches Feld im Teaser? Bei einem Headless-Setup heißt das fast immer: Ticket an die Entwicklung. Das ist für Teams mit eigener Entwicklungsabteilung kein Problem, für einen Handwerksbetrieb mit fünf Mitarbeitenden aber ein K.-o.-Kriterium.

Kosten

Bei SaaS-Anbietern zahlst du nach Nutzern, API-Aufrufen oder Datenmenge, und die Preise springen beim Wachstum schnell. Bei Open-Source-Systemen zahlst du mit Hosting und Wartungszeit. Dazu kommt in beiden Fällen das Frontend. Eine grobe Größenordnung aus unserer Erfahrung findest du weiter unten.

SEO ist nicht automatisch erledigt

Ein klassisches CMS bringt Sitemap, Meta-Tags, Weiterleitungen und Canonical-URLs oft per Plugin mit. Im Headless-Setup muss das Frontend all das selbst erzeugen. Wer das vergisst, baut eine schnelle Seite, die Google schlecht versteht. Wenn du gerade erst dabei bist, gibt dir unser Meta-Title-Generator wenigstens für die Titel eine schnelle Hilfe.

Englisch, von Februar 2026. Sam Anthony erklärt Headless CMS „ohne den Hype“, und das Video sagt ausdrücklich, für wen ein klassisches CMS die bessere Wahl bleibt. Passt gut zu unserem Fazit.

Welche Headless CMS gibt es?

Der Markt ist groß. Wir sortieren nach dem, was in der Praxis die erste Frage ist: Willst du selbst hosten oder einen Dienst mieten? Die Einschätzungen beruhen auf den offiziellen Dokumentationen und unserer Projekterfahrung, nicht auf einem Benchmark aller Systeme.

Open Source zum Selbsthosten

• Strapi — der bekannteste Open-Source-Vertreter, Node.js, visueller Builder für Inhaltstypen, REST und GraphQL. Solider Allrounder mit großer Community.
• Payload — in TypeScript geschrieben, Code-first: Das Content-Modell steht im Code und lässt sich versionieren. Seit Version 3 direkt in eine Next.js-App integrierbar. Unser Favorit für TypeScript-Teams.
• Directus — legt sich über eine bestehende SQL-Datenbank, statt eine eigene Struktur zu erzwingen. Ideal, wenn die Daten auch von anderen Systemen genutzt werden.
• Ghost — eigentlich eine Publishing-Plattform mit Newsletter und Mitgliedschaften, lässt sich aber headless über die Content-API betreiben.
• WordPress — ja, wirklich. Mit der eingebauten REST-API oder dem Plugin WPGraphQL ist WordPress das meistgenutzte Headless-Backend der Welt, weil die Redaktionen es schon kennen.

Als Cloud-Dienst (SaaS)

• Sanity — sehr flexibles Content-Modell, Echtzeit-Zusammenarbeit, eigene Abfragesprache GROQ. Abrechnung nach Nutzung.
• Contentful — der Enterprise-Klassiker, ausgereift, aber in größeren Plänen teuer.
• Storyblok — Fokus auf visuelles Bearbeiten, Redakteure sehen die Seite beim Tippen. Für marketinglastige Teams oft die zugänglichste Lösung.
• Hygraph (früher GraphCMS) — konsequent GraphQL, stark bei Projekten, die Daten aus mehreren Quellen zusammenführen.

Spezialfall: Git-basierte CMS

Systeme wie Decap CMS oder TinaCMS speichern Inhalte nicht in einer Datenbank, sondern als Markdown-Dateien direkt im Git-Repository. Die Redaktionsoberfläche erzeugt im Hintergrund Commits. Für Blogs und Dokumentationen ist das elegant, weil es keine Datenbank gibt, die ausfallen oder gehackt werden kann.

Welche Plattformen außerhalb der Headless-Welt als WordPress-Ersatz infrage kommen, also auch Webflow, Kirby oder Statamic, haben wir im Überblick moderne WordPress-Alternativen gesammelt.

Was kostet ein Headless CMS?

Eine Pauschalzahl wäre gelogen, aber die Kostenblöcke sind immer dieselben:

Der Posten, der am häufigsten unterschätzt wird, ist nicht die Lizenz, sondern das Frontend. Ein klassisches WordPress-Theme kaufst du für ein paar Dutzend Euro und passt es an. Ein Headless-Frontend wird gebaut, Seite für Seite, Komponente für Komponente. Für eine einfache Firmenwebsite heißt das oft ein Vielfaches des Aufwands einer Theme-Lösung. Bei großen Projekten mit mehreren Kanälen kippt die Rechnung, weil man den Inhalt dort sonst mehrfach pflegen müsste.

Wer selbst hostet, braucht nicht viel Leistung: Ein Strapi oder Payload für eine mittelgroße Seite läuft auf einem kleinen VPS. Wie viel Arbeitsspeicher realistisch ist, haben wir in Wie viel RAM braucht ein Server? gemessen. Und weil das CMS dann ein Dienst wie jeder andere ist, gehört ein Reverse Proxy mit HTTPS davor und eine echte Backup-Strategie dahinter.

Wann lohnt sich ein Headless CMS — und wann nicht?

Headless lohnt sich, wenn …

• mehrere Kanäle dieselben Inhalte brauchen (Website plus App, mehrere Marken-Websites, Displays, Kassen).
• ein Entwicklungsteam da ist, das das Frontend dauerhaft betreut.
• Performance ein Geschäftsfaktor ist und du statisch ausliefern willst.
• Inhalte stark strukturiert sind: Produktdaten, Rezepte, Termine, Stellenanzeigen.
• das CMS aus Sicherheitsgründen nicht öffentlich erreichbar sein soll.
• du ein bestehendes Frontend behalten und nur das Backend modernisieren willst (oder umgekehrt).

Ein klassisches CMS ist besser, wenn …

• eine kleine Firma ihre Website selbst pflegen will, ohne für jede Layoutänderung Entwickler zu rufen.
• das Budget einmalig ist und keine laufende Entwicklung vorsieht.
• die Redaktion Page-Builder und Live-Vorschau gewohnt ist und darauf angewiesen ist.
• es nur eine Website gibt und keinen zweiten Kanal in Sicht.
• schnell etwas live gehen muss.

Ein ehrliches Muster aus der Praxis: Viele Projekte gehen auf Headless, weil es modern klingt, und landen bei einer Website, die nur noch die Agentur ändern kann. Das ist keine Architektur-, sondern eine Organisationsfrage. Wer pflegt die Seite in zwei Jahren, und kann diese Person das?

Aus unserer Praxis: getmind.io hat gar kein CMS

Diese Website ist ein gutes Gegenbeispiel, weil sie die Headless-Idee bis zum Ende denkt und dann noch einen Schritt weitergeht. getmind.io läuft auf Astro, jeder Artikel ist eine MDX-Datei im Repository. Es gibt kein CMS, keine Datenbank und keine API, die Besucher erreichen könnten. Beim Build werden alle Seiten fertig gerendert und als Dateien auf den Server kopiert.

Technisch ist das die extremste Form von „Inhalt und Darstellung getrennt“: Der Inhalt sind Textdateien, die Darstellung ist das Astro-Projekt, und die „API“ dazwischen ist das Dateisystem beim Build. Die Vorteile spüren wir jeden Tag: 20 Millisekunden Antwortzeit, nichts zu patchen, jede Änderung im Git-Verlauf nachvollziehbar.

Der Preis ist genau der Nachteil aus diesem Artikel: Wer hier einen Tippfehler korrigieren will, braucht Zugriff aufs Repository und einen Build. Für uns passt das, weil die Inhalte ohnehin aus dem Entwicklungsalltag kommen. Würde morgen eine Marketingabteilung mitschreiben, die nie eine Kommandozeile gesehen hat, wäre der nächste Schritt ein Git-basiertes CMS wie Decap oder Tina oben drauf, oder ein Headless CMS als Datenquelle für denselben Astro-Build. Am Frontend müsste sich dafür fast nichts ändern, und genau das ist der eigentliche Vorteil der Trennung.

So startest du mit einem Headless CMS

Wenn du es ausprobieren willst, ist der schnellste Weg einer, der nichts kostet und nichts kaputtmacht:

1. Content-Modell skizzieren. Bevor du ein System wählst, schreib auf, welche Inhaltstypen es gibt und welche Felder sie haben. Das ist die eigentliche Arbeit, und sie ist systemunabhängig.
2. Ein System lokal starten. Payload und Strapi lassen sich mit einem Befehl (npx create-payload-app bzw. npx create-strapi@latest) als Testprojekt anlegen. Directus gibt es als Docker-Container, am bequemsten mit einer Docker-Compose-Datei.
3. Ein paar echte Inhalte eintragen. Nicht „Lorem ipsum“, sondern drei echte Artikel oder Produkte. Erst dann merkst du, ob das Modell passt.
4. Die API von Hand abfragen. Mit curl oder im Browser. Schau dir an, was zurückkommt und wie groß es ist. Nutze Feldauswahl (?fields= bzw. _fields=), wie in unserer Messung.
5. Ein Mini-Frontend bauen. Eine Astro-Seite, die zur Build-Zeit die Artikel holt und als Liste ausgibt, sind wenige Dutzend Zeilen.
6. Die Redaktion ranlassen. Lass die Person, die später Inhalte pflegt, eine Stunde damit arbeiten. Ihr Gesicht nach dieser Stunde ist der wichtigste Datenpunkt der ganzen Evaluation.

Wenn du WordPress schon hast, kannst du Schritt 2 sogar überspringen: Ruf https://deine-seite.de/wp-json/wp/v2/posts?_fields=id,title auf, und du siehst deine eigene Seite als Headless CMS.

Fazit: Kopf ab, aber mit Plan

Ein Headless CMS ist kein Upgrade, sondern eine Arbeitsteilung. Es trennt das Pflegen von Inhalten vom Darstellen, und das ist enorm wertvoll, wenn mehrere Kanäle, ein eigenes Entwicklungsteam oder harte Performance-Ziele im Spiel sind. Unsere Messung zeigt, wie groß der Unterschied sein kann: 248 Bytes Inhalt gegen 104.803 Bytes fertig gerenderte Seite, und 20 Millisekunden für eine statisch ausgelieferte Seite.

Es ist aber auch ein zweites System mit eigenen Kosten, eigener Wartung und einer Redaktion, die ohne Vorschau erst einmal im Dunkeln tippt. Für die kleine Firmenwebsite, die eine Person nebenbei pflegt, ist ein gut gewartetes klassisches CMS meistens die ehrlichere Lösung. Die richtige Frage ist nicht „headless oder nicht?“, sondern „wer pflegt das in zwei Jahren, und auf wie vielen Kanälen?“.

Häufige Fragen zum Headless CMS

Was ist ein Headless CMS einfach erklärt?

Ein Headless CMS ist ein Programm, in dem du Inhalte wie Texte, Bilder und Produkte pflegst, das aber selbst keine Website anzeigt. Es gibt die Inhalte als Daten über eine Schnittstelle (API) heraus. Eine separate Website, App oder ein anderes Programm holt sich diese Daten und stellt sie dar.

Was ist der Unterschied zwischen einem Headless CMS und einem klassischen CMS?

Ein klassisches CMS verwaltet Inhalte und erzeugt daraus auch gleich die fertige HTML-Seite mit Design. Ein Headless CMS verwaltet nur die Inhalte und liefert sie als Daten aus, das Design entsteht in einem getrennten Frontend. Dadurch können dieselben Inhalte auf vielen Kanälen erscheinen, aber man braucht ein zweites System.

Warum heißt es „headless“?

„Head“ steht für das Frontend, also den sichtbaren Teil der Website. Ein Headless CMS ist ein CMS, dem dieser Kopf abgetrennt wurde. Übrig bleibt der „Körper“ mit Datenbank, Redaktionsoberfläche und API.

Ist WordPress ein Headless CMS?

Im Standardbetrieb nicht, da gibt WordPress fertige HTML-Seiten aus. Es kann aber headless genutzt werden: Seit Version 4.7 hat WordPress eine eingebaute REST-API unter /wp-json/, mit dem Plugin WPGraphQL auch GraphQL. Dann pflegt die Redaktion wie gewohnt in WordPress, und ein separates Frontend holt die Daten ab. Man spricht dabei oft von einem „decoupled“ Betrieb.

Welche Headless CMS gibt es?

Bekannte Open-Source-Systeme zum Selbsthosten sind Strapi, Payload, Directus und Ghost. Bekannte Cloud-Dienste sind Sanity, Contentful, Storyblok und Hygraph. Dazu kommen Git-basierte Systeme wie Decap CMS und TinaCMS, die Inhalte als Dateien im Repository speichern.

Welches Headless CMS ist das beste?

Es gibt kein bestes für alle. Für TypeScript-Teams, die alles im Code haben wollen, ist Payload stark. Für bestehende SQL-Datenbanken passt Directus. Wer einen bewährten Allrounder sucht, nimmt Strapi. Wenn Redakteure visuell arbeiten sollen, ist Storyblok oft am zugänglichsten. Teste mit echten Inhalten und echten Redakteuren, bevor du dich festlegst.

Ist ein Headless CMS schneller?

Es kann deutlich schneller sein, aber nicht automatisch. Schnell wird es vor allem, wenn das Frontend die Inhalte beim Build abholt und fertige statische Seiten ausliefert. In unserer Messung brauchte eine statische Seite rund 20 Millisekunden, die vom CMS gerenderte HTML-Seite 100 bis 500 Millisekunden. Fragt das Frontend dagegen bei jedem Aufruf die API, ist es nur so schnell wie die API selbst.

Ist ein Headless CMS sicherer?

Es kann sicherer sein, weil das CMS nicht öffentlich erreichbar sein muss und Besucher nur statische Dateien sehen. Diese Sicherheit entsteht aber nur, wenn die API und die Admin-Oberfläche wirklich abgeschirmt sind. Eine öffentliche API ist eine zusätzliche Tür, die geprüft werden muss. In unserem Test verriet WordPress ohne Anmeldung den Admin-Benutzernamen über die API.

Was kostet ein Headless CMS?

Open-Source-Systeme sind lizenzfrei, kosten aber Hosting und Wartungszeit. Cloud-Dienste haben meist einen kostenlosen Einstieg und berechnen danach nach Nutzern oder Nutzung. Der größte Kostenblock ist in beiden Fällen das Frontend, das eigens entwickelt werden muss, und der wird am häufigsten unterschätzt.

Brauche ich für ein Headless CMS Programmierkenntnisse?

Für die tägliche Pflege der Inhalte nicht, das funktioniert über eine Redaktionsoberfläche. Für Einrichtung, Content-Modell und vor allem das Frontend schon. Ohne Entwickler oder Agentur lässt sich ein Headless-Setup kaum aufbauen und nur schwer weiterentwickeln.

Was ist der Unterschied zwischen Headless CMS und Static Site Generator?

Ein Headless CMS speichert und verwaltet Inhalte. Ein Static-Site-Generator wie Astro oder Hugo erzeugt aus Inhalten fertige HTML-Dateien. Die beiden ergänzen sich: Der Generator holt beim Build die Inhalte aus dem Headless CMS und baut daraus die Website. Man kann einen Static-Site-Generator auch ganz ohne CMS nutzen, mit Markdown-Dateien, so wie getmind.io.