Was ist ein Headless-CMS, und wann brauchen Sie wirklich eines?
Ein Headless-CMS trennt Inhalt von Präsentation — und für eine fünfseitige Broschüren-Website ist es das falsche Werkzeug. Hier steht, wann es sich wirklich lohnt.
Ein Headless-CMS speichert Ihre Inhalte und gibt sie über eine API heraus. Es rendert keine Seiten. Es gibt kein Theme, kein Template, kein Frontend — diesen Teil bauen Sie.
Das ist die ganze Definition. Alles andere in diesem Artikel dreht sich darum, ob das ein guter Handel für Sie ist, und der ehrliche Teil der Antwort lautet meist „Es kommt darauf an, wie viele Frontends Sie haben“.
In einem traditionellen CMS — WordPress, Drupal, das meiste, was Sie genutzt haben — leben Inhaltsspeicherung und Seitenrendering im selben System. Sie schreiben einen Beitrag, das CMS legt ihn in eine Datenbank, und dasselbe CMS verwandelt ihn mithilfe eines Themes in HTML. Bequem und untrennbar.
„Headless“ bedeutet, die Rendering-Hälfte zu entfernen. Was übrig bleibt, ist:
ein Ort, um Inhaltstypen und ihre Felder zu definieren
ein Editor für die Menschen, die schreiben
eine API, die strukturierte Inhalte zurückgibt — JSON, nicht HTML
Der Handel ist deutlich. Sie verlieren die kostenlose Website. Sie gewinnen Inhalte, die nicht wie eine Webseite geformt sind und daher von Dingen genutzt werden können, die keine Webseiten sind.
Sie werden beide Wörter sehen. Streng genommen liefert ein entkoppeltes CMS weiterhin eine Rendering-Ebene, die Sie nutzen können; ein Headless-CMS hat keine. In der Praxis verwenden die Leute sie austauschbar, und die Unterscheidung ändert selten eine Entscheidung.
Die Frage, die es wert ist, zu jedem Produkt zu stellen, ist einfacher: Kann es eine Seite rendern? Wenn ja, bedeutet es headless zu gehen, einen Renderer zu betreiben und dann seine Ausgabe zu ignorieren.
Sie haben mehr als ein Frontend. Eine Website, eine iOS-App, ein Kiosk, ein Partner, der einen Feed möchte. In einem traditionellen CMS ist der zweite Konsument ein Scraping-Problem. In einem Headless-CMS ist er ein zweiter API-Client.
Sie haben mehr als ein Projekt. Eine Agentur mit zehn Kunden, eine Gruppe mit fünf Marken, ein SaaS, bei dem jeder Kunde seine eigenen Inhalte braucht. Hier beginnen die Preismodelle stark auseinanderzugehen — manche Produkte rechnen pro Projekt, pro Dataset oder pro Space ab, und beim dritten Projekt finden Sie es heraus.
Ihre Inhalte sind nicht seitenförmig. Ein Produktkatalog, eine Docs-Seite, ein Changelog, ein Jobboard. Wenn Sie mit benutzerdefinierten Feldern gegen das „Beitrags“-Modell kämpfen, zahlen Sie bereits die Steuer ohne den Nutzen.
Lokalisierung ist real. Nicht „wir haben das Menü übersetzt“ — echte parallele Inhalte in mehreren Sprachen, mit unterschiedlichen Veröffentlichungsstatus pro Sprache. Traditionelle CMS machen das mit Plugins. Headless-CMS behandeln es als Eigenschaft auf Feldebene.
Frontend-Performance ist eine Geschäftszahl. Entkopplung erlaubt es Ihnen, vorgerenderte, cachebare Ausgabe auszuliefern, statt eine Seite pro Anfrage zu berechnen. Das ist nicht automatisch, aber es wird möglich.
Das ist der Abschnitt, den die meisten Vendor-Artikel überspringen, weil sie verkaufen.
Eine Seite, eine Sprache, ein Team, kein Entwickler. Ein Headless-CMS verlagert die Rendering-Arbeit zu Ihnen. Wenn niemand diese Arbeit machen wird, haben Sie für eine Subtraktion bezahlt. Nutzen Sie WordPress oder einen Website-Baukasten und geben Sie das Geld für Inhalte aus.
Eine fünfseitige Broschüren-Website. Die API, der Build-Schritt, die Deploy-Pipeline und das Frontend-Repo sind alle Overhead gegen fünf Seiten, die sich zweimal im Jahr ändern.
Ihr Team bearbeitet mit einer visuellen Vorschau und wird sie nicht aufgeben. Manche Headless-Produkte haben eine ausgezeichnete Live-Vorschau; viele haben keine. Wenn „Ich möchte die Seite sehen, während ich tippe“ nicht verhandelbar ist, setzen Sie das an die Spitze Ihrer Kriterien und lassen Sie es Kandidaten früh ausscheiden.
Sie brauchen ein Plugin-Ökosystem. Buchungen, Formulare, Mitgliedschaften, E-Commerce — wenn Ihre Seite von Standardmodulen abhängt, bedeutet headless, sie zu schreiben. Das ist eine Budgetposition, kein Detail.
Ein nützlicher Test: Zählen Sie Ihre Frontends und zählen Sie Ihre Projekte. Wenn beide eins sind, lautet die ehrliche Antwort meist „noch nicht“.
Sobald Sie entschieden haben, dass Sie eines brauchen, ist das Modell, das Ihre Rechnung entscheidet, wie der Anbieter für Lesezugriffe berechnet.
Die meisten gehosteten Headless-Produkte messen etwas ab, das Besucher-Traffic bewegt: API-Aufrufe, Bandbreite, CDN-Anfragen oder ein kombiniertes Nutzungskontingent. Die Konsequenz ist leicht zu formulieren und leicht zu übersehen: Ein erfolgreicher Launch ist von einem Abrechnungsvorfall nicht zu unterscheiden. Nichts an Ihren Inhalten oder Ihrer Arbeit hat sich geändert — nur die Zahl der Fremden, die sie lesen.
Es gibt eine architektonische Alternative, und es lohnt sich, sie zu verstehen, egal welches Produkt Sie wählen: veröffentlichte Inhalte als vorab gebaute, unveränderliche Dateien aus einem Cache auszuliefern, statt eine Antwort pro Anfrage zu berechnen.
So funktioniert corpusctl. Auf Veröffentlichen zu klicken führt einen Build aus: Der Inhalt wird validiert, gerendert und in eine hash-adressierte Datei im Objektspeicher geschrieben, dann wird das Manifest aktualisiert. Der Client des Lesers löst den Slug lokal zu einem Manifest-Shard auf und ruft dann diese Adresse aus dem nginx-Edge-Cache ab. Weil die Adresse ein Content-Hash ist, kann dieselbe Adresse niemals andere Inhalte zurückgeben — sie kann also dreißig Tage lang ganz ohne Invalidierungsstrategie gecacht werden. Das Veröffentlichen schreibt eine neue Adresse.
Zwei HTTP-Anfragen, beide aus dem Cache. Keine erreicht die API. Keine erreicht die Datenbank. Es gibt keinen Zähler pro Aufruf, weil es keinen Aufruf gibt.
Sie müssen corpusctl nicht wählen, um das als Kriterium zu nutzen. Fragen Sie jeden Anbieter: Was passiert mit meiner Rechnung, wenn dieser Beitrag zehnmal besser abschneidet als erwartet?
Ist Headless-WordPress ein echtes Headless-CMS? Funktional ja — die REST-API und WPGraphQL legen Inhalte offen. Architektonisch ist es eine Nachrüstung: Sie behalten die Seitenrendering-Maschinerie und verwerfen dann ihre Ausgabe.
Schadet es der SEO? Nicht von Natur aus. Die drei häufigen Wege, wie Teams bei einer Migration Traffic verlieren, sind: nur auf dem Client rendern, Canonical-Tags beim Rebuild fallen lassen und von einem langsamen Origin statt aus einem Cache ausliefern.
Ist es teurer? Meist teurer in Engineering-Zeit im Voraus und günstiger im spezifischen Fall, in dem Sie im Begriff waren, drei Websites zu bauen.
Was „Open Source“ bei einem Headless-CMS tatsächlich kostet
Open Source bedeutet selten kostenlos im Betrieb. Lizenzen, Cloud-Upsells und die verifizierten Kosten von sechs beliebten Headless-CMS — mit den Zahlen von ihren eigenen Seiten.