Im Jahr 2021 kam ein Fintech-Client zu Seahawk mit einer WordPress-Website, die unter Traffic-Spitzen zusammenbrach und ein Content-Team, das ständig gegen die Templates ihres Themes kämpfte. Ihr Marketing-Director hatte drei Blog-Posts über Headless gelesen und war überzeugt, dass das die Lösung war. Wir verbrachten zwei Monate mit der Planung eines Next.js + Contentful-Aufbaus. Dann musste ich in einem Call höflich mitteilen, dass sie es eigentlich gar nicht brauchten. Sie brauchten einen gut optimierten Monolithen und einen besseren Content-Workflow.
Wichtigste Erkenntnis: Headless-Architektur lohnt sich, wenn du mehrere Frontends brauchst, strikte Performance-Anforderungen hast oder eine App-ähnliche UX benötigst; für eine Standard-Marketing-Website ist es Over-Engineering mit einer Wartungsrechnung.
Dieses Gespräch kostete uns einen potenziellen Zusatzverkauf. Aber es war die richtige Entscheidung.
Headless-Architektur ist für das richtige Projekt wirklich mächtig. Sie ist auch für sehr viele Projekte wirklich Overkill. Ich habe Websites auf Sanity, Hygraph, Contentful und Strapi gebaut, und ich habe viele Projekte bewusst bei WordPress oder Craft belassen. Also lass mich dir das echte Bild geben, nicht die Version aus dem Vendor-Pitch.
---
Was „Headless" eigentlich bedeutet
Kurz zur Orientierung, bevor wir ins Detail gehen. Headless-Architektur trennt Backend und Frontend komplett: dein CMS kümmert sich um Content-Speicherung, Modellierung und API-Auslieferung, während dein Frontend (Next.js, Nuxt, Astro, was immer du magst) diesen Content über die API konsumiert und ihn rendert, wie es ihm passt. Es gibt keine gekoppelte Template-Schicht. Kein Theme. Keine „the-loop".
Traditionelle CMS-Systeme wie WordPress haben alle drei Schichten zusammen gebündelt: Speicherung von Inhalten, die redaktionelle Benutzeroberfläche und die Präsentationsschicht. Das ist praktisch. Es ist aber auch das, was sie einschränkend anfühlen lässt, sobald man etwas wirklich Komplexes macht.
Headless trennt diese Schichten auf. Was befreiend sein kann. Oder kompliziert. Hängt ganz von deinem Team und der Aufgabe ab.
---
Die echten Vorteile
Frontend-Freiheit, die wirklich bedeutsam ist
Der größte ehrliche Vorteil ist, dass dein Frontend-Team nicht durch das eingeengt wird, was das CMS rendern kann. Du wählst deinen Stack. Dein Backend-Checkout-Team kann Go für die Transaktionsverarbeitung nutzen, während dein Frontend Next.js verwendet – diese beiden Welten kollidieren nicht. Crystallize bringt es gut auf den Punkt: Headless fördert echte Interoperabilität zwischen verschiedenen Technologien und lässt jedes Team den idealen Stack für ihren spezifischen Bereich wählen.
Das habe ich auf emotionaler Ebene bei einem Media-Client gespürt, den wir Ende 2022 übernommen haben. Sie hatten etwa 40 Content-Editoren und brauchten ein komplett maßgeschneidertes Leseerlebnis – animierte Article-Übergänge, personalisierte Content-Schienen, alles. Auf WordPress wäre das ein JavaScript-Alptraum gewesen, überlagert auf einem Theme. Auf Sanity + Next.js war es einfach… Frontend-Arbeit. Sauber, getrennt, vernünftig.
Performance, die nicht nur theoretisch ist
Es gibt viel Geschwätz darüber, dass Headless schneller ist. Das kann es sein, aber es ist nicht automatisch. Was es dir gibt, ist die Möglichkeit, Content über ein CDN am Edge auszuliefern, es mit einem Static-Site-Generator zu koppeln und den PHP-Rendering-Overhead zu beseitigen, den traditionelle CMSs mit sich bringen. Sanity weist darauf hin, dass SSG-basierte Headless-Builds eine neue Version deiner Website bei Updates deployen, was bedeutet, dass die meisten Seiten praktisch statische Dateien sind, die sofort ausgeliefert werden.
Bei einem stark frequentierten E-Commerce-Projekt, das wir letztes Jahr durchgeführt haben, reduzierte der Wechsel von WooCommerce zu einem headless Shopify + Next.js-Setup die Time-to-first-byte von etwa 800ms auf durchschnittlich unter 200ms. Das ist nicht nichts. Es hat die Conversion positiv beeinflusst.
Omnichannel-Lieferung ohne Alpträume
Wenn du Content auf eine Website, eine Mobile-App, ein Kiosk-System, eine Smartwatch-Schnittstelle und irgendein zukünftiges Ding pushst, das du noch gar nicht kennst – ein Headless-CMS macht das alles deutlich weniger schmerzhaft. Dein Content lebt an einer Stelle. Deine API liefert ihn überall hin. Du kopierst und einfügst nicht aus einem WordPress-Post in ein App-CMS.
Hier glänzt Headless so offensichtlich, dass man dagegen kaum argumentieren kann. Das ELCA-Team fasst es richtig zusammen: Frontend und Backend skalieren unabhängig voneinander, und du kannst völlig unterschiedliche Frontend-Erlebnisse von derselben Content-Quelle aus liefern.
Die Sicherheit verbessert sich strukturell.
Erwähnenswert, weil die Leute es unterschätzen. In einem gekoppelten System sind Sie, wenn jemand durch Ihr Frontend eindringt, bereits nah an Ihrer Datenbank. Bei Headless ist das Content-Backend ein völlig separates System, das nur über definierte API-Endpunkte zugänglich ist. Sie kontrollieren genau, welche Daten bereitgestellt werden und wie. Eine kompromittierte Schicht führt nicht automatisch zu einer Kaskade. Das ist ein bedeutender struktureller Vorteil, besonders für alles, das Benutzerdaten verarbeitet.
---
Die echten Nachteile
Mehr Arbeit am Anfang. Punkt.
Ich werde nicht so tun, als wäre es anders. Brightspot sagt es deutlich: Headless erfordert mehr Planung und Entwicklungsaufwand am Anfang. Es gibt keine Standard-Templates. Kein Theme, das du installieren und anpassen kannst. Dein Team muss die gesamte Presentation Layer von Grund auf entwerfen und bauen.
Bei einem kleinen Unternehmen, das eine 10-seitige Marketing-Website in sechs Wochen benötigt, ist dies ein schlechter Deal. Ich habe beobachtet, wie Agenturen Headless-Projekte an Kunden angeboten haben, die weder das Budget noch die laufenden Entwicklerressourcen zur Wartung hatten. Das ist keine gute Leistung.
Deine Editoren werden kämpfen. Anfangs.
Die meisten nicht-technischen Content-Editoren fühlen sich bei etwas wie WordPress wohl, weil die Vorschau direkt da ist – sie tippen, sie sehen, wie es aussieht, sie publizieren. In einer Headless-Lösung ist diese Rückkopplungsschleife von vornherein unterbrochen. Du musst Live-Preview implementieren, es ordnungsgemäß einrichten, testen und deine Editoren darin trainieren. Wenn du diesen Teil überspringst, hat dein Content-Team in einem Monat Beschwerden bei deinem Project Manager eingereicht.
Ich habe das schiefgehen sehen. Eine Einzelhandelsklientin kündigte ihrer Content-Managerin innerhalb von acht Wochen nach dem Headless-Launch, weil sie nicht herausfinden konnte, wie ihre Werbebanner vor der Veröffentlichung aussahen. Das war kein technisches Versagen, sondern ein Planungsfehler. Wir hatten uns nicht gründlich genug Gedanken über das Redakteurserlebnis gemacht.
Die Entwicklerabhängigkeit steigt
Bei einem monolithischen CMS kann ein einigermaßen technisch versierter Content Manager ein Plugin installieren, ein Template aktualisieren, ein Feld hinzufügen. Bei Headless braucht fast jede Änderung von substanzieller Bedeutung einen Entwickler. Neuer Content-Typ? Entwickler. Neues Seitenlayout? Entwickler. Diese ständige Abhängigkeit hat Kosten – zeitlich, finanziell und in organisatorischer Frustration, wenn dein Dev-Team beschäftigt ist und dein Marketing-Team eine Kampagnendeadline hat.
Komplexität erzeugt Bugs
Mehr bewegliche Teile bedeuten mehr Stellen, an denen etwas schiefgehen kann. Du verwaltest API-Ratenlimits, Caching-Schichten, Webhook-Ketten, CDN-Invalidierungsregeln, Build-Pipelines. Wenn etwas kaputt geht, und etwas geht immer kaputt, ist der Debugging-Weg länger. Anatta macht das ehrlich deutlich: mehr Komplexität bedeutet mehr Fehlerquellen, und das Debuggen von Problemen über mehrere miteinander verbundene Systeme hinweg ist wirklich mühsam.
---
Wann Headless sinnvoll ist
Das ist der praktische Teil. Hier würde ich es tatsächlich empfehlen:
- Du lieferst Content an mehr als einen Kanal – Web, App, IoT, Integrationen von Drittanbietern. Hier amortisiert sich Headless schnell.
- Du hast ein dediziertes Frontend-Team, das volle Kontrolle über den Stack haben möchte und nicht blockiert werden will, während es auf CMS-Templating-Beschränkungen wartet.
- Performance ist eine echte Geschäftsanforderung, nicht nur ein nice-to-have – hochfrequente E-Commerce, Medienverlage, alles, wo eine Verbesserung der Ladezeit um 100 ms zu messbaren Umsatzsteigerungen führt.
- Dein Content-Modell ist komplex, viele Content-Typen, Beziehungen zwischen ihnen, Content, der über viele Kontexte hinweg wiederverwendet werden muss.
- Du baust etwas mit einer echten Custom-UX, bei der ein Theme-basiertes System dir Steine in den Weg legen würde.
---
Wann man monolithisch bleiben sollte
Und hier würde ich dich entschieden abraten:
- Kleine Teams ohne einen dedizierten Frontend-Entwickler
- Projekte, die in weniger als 8 Wochen starten müssen
- Kunden, die sich auf nicht-technisches Personal verlassen, um die Website täglich zu verwalten
- Einfache Content-Anforderungen – Blog, Portfolio, Broschürenseite, einfacher E-Commerce mit wenigen hundert SKUs.
- Knappe laufende Wartungsbudgets
Ehrlich gesagt: WordPress mit einem gut gebauten Theme und gutem Caching deckt das ab, was die meisten Unternehmen wirklich brauchen. Der Facebook-/Netflix-Vergleich, der in Headless-Diskussionen immer wieder auftaucht, ist größtenteils irrelevant. Wie ImageX aufzeigt, brauchen die meisten Organisationen gar nicht dieses Maß an Komplexität und Skalierbarkeit. Ein paar Zehntel Sekunde Ladezeit zu sparen ist für die meisten nicht die Investition von sechs Ziffern wert.
---
Die Hybrid-Option, die es wert ist, zu kennen
Es gibt einen Mittelweg, der nicht genug Aufmerksamkeit bekommt: entkoppelt oder „Hybrid Headless". Manche CMS-Plattformen – Craft CMS ist mein persönlicher Favorit dafür – lassen dich ein traditionelles Template-System nutzen, wenn das ausreichend ist, und Content via API konsumieren, wenn du das brauchst. Du bekommst redaktionelle Einfachheit, wo sie wichtig ist, und API-Flexibilität, wo du sie benötigst.
Es ist nicht die glamouröseste Architektur, um sie in einem Pitch Deck einzubauen. Aber es hat mehrere meiner Kunden davor bewahrt, sich in einen Wartungsalptraum hinein zu über-engineern.
---
Häufig gestellte Fragen
Ist Headless immer schneller als ein traditionelles CMS?
Nicht automatisch. Headless kann deutlich schnellere Performance liefern, besonders wenn es mit Static Site Generation und CDN-Delivery kombiniert wird, aber ein schlecht umgesetzter Headless-Build kann langsamer sein als eine gut optimierte WordPress-Website. Geschwindigkeit kommt davon, wie du Dinge baust und cachst, nicht nur davon, dass du eine Headless-Architektur wählst.
Wie viel teurer ist ein Headless-Projekt?
Nach meiner Erfahrung solltest du für den initialen Aufbau ungefähr 40–80 % mehr budgetieren im Vergleich zu einem äquivalenten Traditional-CMS-Projekt. Die laufenden Kosten variieren stark je nachdem, wie sehr dein Content-Workflow von Entwicklern abhängig ist. Wenn Redakteure Inhalte ohne Entwickler-Beteiligung verwalten können, stabilisieren sich die Betriebskosten. Wenn nicht, zahlst du kontinuierlich für Entwicklerzeit.
Kann Headless CMS für kleine Unternehmen funktionieren?
Das kann es. Ob es das sollte, ist eine andere Frage. Wenn ein kleines Unternehmen spezifische Omnichannel-Anforderungen oder eine echte UX-Anforderung hat, könnte Headless die Kosten rechtfertigen. Für die meisten kleinen Unternehmen? Ein traditionelles CMS wird ihm besser dienen und mehr Budget für echtes Marketing übrig lassen.
Was ist das beste Headless CMS für ein erstes Headless-Projekt?
Sanity ist dort, wo ich die meisten Teams anfangen würde. Die Developer Experience ist stark, die Content-Modellierung ist flexibel, der kostenlose Plan ist großzügig genug zum ordnungsgemäßen Prototyping, und die Community-Dokumentation ist hervorragend. Hygraph ist ein starker Zweitplatzierter für content-lastige Projekte. Contentful ist solide, aber teuer, sobald Sie ihre bezahlten Tarife erreichen.
Muss ich alles neu aufbauen, wenn ich von einer bestehenden Site zu Headless wechsle?
Normalerweise ja, zumindest die Präsentationsschicht. Du kannst Content von einem traditionellen CMS zu einem Headless-System migrieren (es gibt dafür Tools), aber du baust dein Frontend von Grund auf neu. Manche Teams gehen schrittweise vor und halten die bestehende Website live, während der Headless-Build parallel läuft. Das dauert länger, reduziert aber das Risiko.
---
Headless-Architektur ist ein legitimer, gut durchdachter Ansatz zum Aufbau von inhaltgesteuerten digitalen Produkten. Sie wird aber auch Clients überverkauft, die sie gar nicht brauchen, und denjenigen, die sie brauchen, unzureichend erklärt. Bevor du dich auf die zusätzliche Komplexität einlässt, frag dich selbst, ob dein Projekt wirklich das verlangt, was Headless bietet, oder ob dich nur das Neuere und Glänzendere reizt. Beides sind menschliche Impulse. Nur einer von ihnen führt zu einer guten Kundenbeziehung.