Ein Kunde rief mich 2021 an, eine mittelständische E-Commerce-Marke aus Manchester, etwa 40.000 SKUs, mehrere regionale Storefronts, sie waren außer sich. Sie hatten £180.000 über 18 Monate für einen Headless-Shopify-Build mit Next.js-Frontend ausgegeben, und ihre Seitenladezeiten waren langsamer als das Shopify-Theme, das sie ersetzt hatten. Ihr Entwicklerteam war von einem Auftragnehmer auf vier gewachsen. Content-Redakteure brauchten einen Developer, nur um einen Blog-Post live zu schalten.
Wichtigste Erkenntnis: Geh zu Headless, wenn du wirklich mehrere Frontends brauchst oder eine Performance, die ein Monolith nicht schafft; eine WordPress-Website mit einem guten Theme schlägt drei Developer, die einen Stack unterhalten, den du gar nicht brauchtest.
Headless war ihnen als die Zukunft verkauft worden. Und technisch gesehen ist es das auch. Aber niemand hatte ihnen gesagt, was es wirklich kosten würde, es zu betreiben.
Ich habe bei Seahawk Media über 12.000 Websites gebaut oder überwacht. Headless war vielleicht bei 8-10% davon der richtige Call. Die anderen 90%? Das hätte eine Katastrophe sein können – teuer, langsam beim Ausliefern und elend zu warten. Dieser Post geht darum, zu wissen, welche Kategorie dein Projekt ausmacht, bevor du die Schecks schon geschrieben hast.
---
Was „Headless" in der Praxis eigentlich bedeutet
Lass uns die Definition schnell erledigen. Ein traditionelles CMS – WordPress, Squarespace, egal was – verbindet das Content-Management-Backend mit der Front-End-Präsentationsschicht. Sie sprechen nativ miteinander. Headless entkoppelt sie. Dein CMS (Contentful, Sanity, Strapi, WordPress im Headless-Modus) wird zu einer reinen Content-API. Dein Frontend – Next.js, Nuxt, Astro, SvelteKit, was dir gefällt – holt sich den Content und rendert ihn, wie es will.
Einfache Idee. Die Komplexität schleicht sich überall sonst ein.
Der Stack, der tatsächlich in Projekten auftaucht
In der Praxis meint man mit „Headless" gewöhnlich eine dieser Kombinationen:
- Contentful oder Sanity als CMS, das JSON über REST oder GraphQL bereitstellt
- Next.js auf dem Frontend, entweder statisch generiert (SSG) oder serverseitig gerendert (SSR)
- Vercel oder Netlify für Deployment und Edge Functions
- Shopify Storefront API oder BigCommerce, falls Commerce involviert ist
- Eine Variante von Algolia für die Suche, da die nativen Suchoptionen meist miserabel sind
Jedes davon ist eine separate Herstellerbeziehung, eine separate Rechnungsposition und eine separate Sache, die um 2 Uhr morgens an einem Freitag schiefgehen kann.
---
Der echte Fall für den Umstieg auf Headless
Hier ist das Ding: Es gibt echte, legitime Gründe, das zu tun. Ich lehne die Architektur nicht ab. Mir ist nur leid, dass sie wahllos angewendet wird.
Multi-Channel-Content-Auslieferung ist das stärkste Argument. Wenn derselbe Content auf einer Website, einer mobilen App, einem Kiosk-Display und einer Smart-TV-Schnittstelle erscheinen muss, wird ein gekoppeltes CMS echt schmerzhaft. Eine Content-API, die alle vier Oberflächen abfragen? Das macht wirklich Sinn. Seahawk hatte einen Hospitality-Client in Dubai, eine dieser Resort-Gruppen mit einer öffentlich zugänglichen Website, einer internen Staff-App und Digital Signage überall auf dem Gelände. Eine Sanity-Instanz versorgt alles. Das war der richtige Call, Punkt.
Performance bei echter Skalierung ist das zweite legitime Argument. Statisch generierte Seiten, von einem CDN-Edge aus bereitgestellt, sind schnell auf eine Weise, die PHP-gerenderte WordPress-Seiten einfach nicht sind, egal wie gut du deinen Server optimiert hast. Wenn du von Millionen Seitenaufrufen pro Monat sprichst, summieren sich diese Millisekunden zu bedeutsamen Umsatzunterschieden. Googles Forschung hat die Korrelation zwischen Ladegeschwindigkeit und Konversionsrate immer wieder dokumentiert – das ist nicht theoretisch.
Teamtrennung ist auch wichtig, aber nur für Organisationen, die groß genug sind, um separate Front-End- und Back-End-Teams zu haben. Wenn dein Content-Team eine 20-köpfige Marketing-Abteilung ist, die unabhängig von deinem Engineering-Team arbeiten möchte, ermöglicht ein sauberer API-Vertrag zwischen CMS und Frontend beiden Seiten, ohne sich gegenseitig zu blockieren.
Diese drei Fälle? Wirklich den Komplexitätskostenaufwand wert. Alles andere ist normalerweise Wunschdenken, das sich als Architektur verkleidet.
---
Wenn Headless nur teure Over-Engineering ist
Eine fünfseitige Broschüren-Website für eine Londoner Accountancy-Firma braucht keine Headless-Architektur. Genauso wenig wie ein 200-Produkte-WooCommerce-Shop mit einem Entwickler auf Abruf.
Ich sehe diesen Fehler ständig, besonders von Entwicklern, die gerade Next.js entdeckt haben und es auf alles anwenden wollen. (Ich war 2019 selbst schuldig daran, habe einen Headless-Blog für einen kleinen Charity-Client gebaut, drei Tage damit verbracht, Webhooks zu konfigurieren, um Netlify-Rebuilds bei neuen Posts auszulösen, habe ihnen dafür Geld berechnet, und sie rufen mich immer noch an, wenn etwas kaputt geht.) Das Problem ist, dass Headless die operative Komplexität vom CMS zur Infrastruktur verschiebt. WordPress aktualisiert sich selbst. Deine custom Next.js + Contentful Pipeline nicht.
Spezifische Szenarien, in denen headless normalerweise mehr kostet, als es bringt:
- Kleine Content-Teams – wenn eine oder zwei Personen alle Inhalte verwalten – ist die Editorial-DX eines ordentlichen gekoppelten CMS wie WordPress genuinely besser als ein Headless-CMS. Preview-Umgebungen sind schwieriger. Inline-Bearbeitung ist weg. WYSIWYG ist gelähmt.
- Knappe Budgets – ein ordentlicher Headless-Build kostet 2–3x so viel wie ein vergleichbarer WordPress-Build in der Entwicklung, und die laufende Wartung ist höher. Wenn Budget eine Beschränkung ist, tut das Geld fast immer anderswo mehr Gutes.
- Häufige Inhaltsänderungen und statische Generierung bedeuten Build-Zeiten. Ein Nachrichtenverlag, der täglich 50 Artikel veröffentlicht, will nicht 8 Minuten auf einen vollständigen Site-Rebuild warten, jedes Mal wenn ein neuer Artikel kommt. (Ja, inkrementelle statische Regeneration hilft. Sie bringt aber auch ihre eigene Komplexität mit sich.)
- Ohne dediziertes DevOps muss jemand die Deployment-Pipeline, die CDN-Konfiguration, die Umgebungsvariablen und die Preview-URLs verwalten. In kleinen Teams ist das normalerweise der Entwickler, der ohnehin schon alles andere macht.
---
Die WordPress-Headless-Mittelposition
Eine Sache, bei der ich widersprechen würde, ist die falsche Dichotomie zwischen „traditionellem WordPress" und „vollständig headless mit separatem CMS." Es gibt einen Mittelweg, der wirklich gut für eine bestimmte Klasse von Projekten funktioniert.
WordPress als Headless-Backend mit WP REST API oder WPGraphQL gibt dir die Content-Management-Erfahrung, die deine Clients schon kennen (und ehrlich gesagt, die meisten Clients kennen WordPress), kombiniert mit der Flexibilität eines modernen Frontends. Du zahlst nicht für Contentful. Du musst niemanden umschulen. Das Editorial-Team behält Gutenberg. Das Frontend kann sein, welches Framework zum Projekt passt.
Ich habe dieses Pattern wahrscheinlich über die letzten vier Jahre auf 30–40 Projekten verwendet. Es funktioniert besonders gut für Marketing-Seiten, die eine umfangreiche bestehende Content-Bibliothek in WordPress haben und nicht migrieren wollen, aber ein React-Frontend für Performance oder Interaktivität brauchen. Der Trade-off ist, dass WPGraphQL Plugin-Wartung knifflig werden kann, und du läufst immer noch einen PHP-Server, du bist nicht ganz aus dem WordPress-Hosting raus.
---
Wahl deines Headless CMS: Ein praktischer Vergleich
Nicht alle Headless-CMSe sind gleich, und die Wahl ist wichtiger, als Leute zugeben, wenn sie vom Frontend-Framework begeistert sind.
Contentful
Die Enterprise-Lösung. Solide API, gute SDKs, vernünftige Editorial-UI. Das Pricing ist der Schmerzpunkt – der kostenlose Plan ist für kleine Projekte wirklich brauchbar, aber sobald du die Limits erreichst, zahlst du 300 $/Monat und hast noch nichts Interessantes gemacht. Ich würde Contentful bei Projekten mit echtem Budget und Organisationen, die echte Rollen- und Berechtigungsworkflows brauchen, wählen.
Sanity
Mein persönlicher Favorit für die meisten Mid-Market-Headless-Projekte. Die GROQ-Query-Language ist ausdrucksstark, wenn du einen Tag damit verbracht hast, Sanity Studio ist auf Wegen anpassbar, die Contentful nicht bietet, und die Echtzeit-Zusammenarbeit ist exzellent. Das Pricing ist vertretbarer. Der Nachteil ist, dass die Lernkurve für nicht-technische Content-Editoren steiler ist, Studio sieht anders genug aus als WordPress, dass es immer eine Trainingsphase gibt.
Strapi
Open-Source, selbstgehostet, kostenlos zu betreiben. Wenn du einen Kunden hast, der SaaS-CMS-Gebühren nicht bezahlen wird und einen Server hat, ist Strapi einen Blick wert. Das Admin-Panel ist ordentlich. Aber du übernimmst das Hosting, Updates und Sicherheitspatches selbst. Das ist nicht nichts.
Astro mit Content Collections
Für inhaltsreiche Sites, die hauptsächlich statisch sind – Dokumentation, Blogs, Marketing-Seiten – ist Astro mit lokalen Content Collections einen Blick wert. Gar kein CMS. Content lebt als Markdown- oder MDX-Dateien im Repo. Entwickler lieben es. Nicht-technische Editoren hassen es normalerweise. Kenne dein Publikum, bevor du diesen Weg gehst.
---
Das Performance-Argument: Was die Zahlen wirklich aussagen
Lass mich dir eine echte Benchmark geben, statt einer vagen Aussage über Geschwindigkeit.
Ein Seahawk-Client, ein SaaS-Unternehmen, etwa 80 Seiten, moderater Traffic, migriert von einer verwalteten WordPress-Installation zu Next.js mit Sanity, deployed auf Vercel. Vor der Migration lagen die Lighthouse-Scores auf Mobile bei etwa 62–68. Danach konstant 91–96. Time to First Byte fiel von etwa 420 ms auf unter 80 ms. Das ist keine marginale Verbesserung. Das ist ein anderes Produkt.
Aber, und das ist wichtig, sie hatten einen dedizierten Frontend-Developer, ein Content-Team aus vier Personen, die Sanity-Training durchlaufen haben, und ein Budget, das einen achtwochen-Build aufgefangen hat. Die Performance-Gewinne waren real, weil die Voraussetzungen für Headless erfüllt waren.
Die Web Almanac-Daten zur CMS-Performance zeigen, dass der Performance-Gap zwischen Headless-orientierten Frameworks und traditionellen gekoppelten CMSen real ist, aber nicht automatisch. Eine schlecht implementierte Next.js-Website kann eine gut konfigurierte WordPress-Website absolut unterbieten. Architektur allein rettet dich nicht.
---
Die Entscheidung treffen: Ein Framework, das ich tatsächlich verwende
Wenn ein Kundenbriefing auf meinem Schreibtisch landet und es irgendeine Frage gibt, ob Headless geeignet ist, durchlaufe ich fünf Fragen, bevor ich mich zu einer Empfehlung verpflichte.
- Muss der Content auf mehr als einer Oberfläche erscheinen? Falls ja, verdient Headless einen ernsthaften Blick. Falls nein, verliert es eine große Begründung.
- Wie ist das technische Komfortniveau des Content-Teams? Nicht-technische Editoren unter Zeitdruck in einem unbekannten CMS sind eine schlechte Kombination.
- Welcher Traffic und welche Performance-Anforderungen werden erwartet? Unter 50.000 monatliche Besucher auf einem vernünftigen Host? WordPress bewältigt das problemlos.
- Gibt es einen dedizierten Entwickler für die laufende Wartung? Falls die Antwort „wir rufen jemanden an, wenn es kaputtgeht" lautet, ist die Headless-Infrastruktur ein Risiko.
- Wie ist das tatsächliche Budget, inklusive des ersten Betriebsjahres? Nicht nur die Entwicklung. Hosting, CMS-Abonnements, Entwicklerzeit für Updates. Gesamtkosten der Eigentümerschaft.
Falls die Fragen 1, 4 und 5 nicht übereinstimmen, empfehle ich einen traditionellen oder Hybrid-Ansatz und schlafe ruhig.
---
FAQ
Ist Headless WordPress besser als ein traditionelles WordPress-Setup?
Hängt ganz davon ab, was „besser" für dein spezifisches Projekt bedeutet. Für Multi-Channel-Delivery, Team-Trennung oder Performance bei hohem Traffic können Headless WordPress oder das Ersetzen von WordPress durch ein dediziertes Headless-CMS Dinge bedeutsam verbessern. Für eine Standard-Business-Website mit kleinem Team und moderatem Traffic ist traditionelles WordPress mit einem guten Theme und ordentlichem Caching einfacher zu bauen, günstiger zu betreiben und unkomplizierter an einen Client zu übergeben.
Bedeutet Headless immer bessere Performance?
Nein. Und dieser Mythos verursacht echten Schaden an Projekt-Budgets. Statisch generierte Seiten, die von einem CDN ausgeliefert werden, sind von Haus aus schneller, aber ein schlecht konfigurierter Headless-Build mit unoptimerten Bildern, sequenziellen API-Anfragen und ohne ordentliches Caching kann absolut hinter einer gut abgestimmten WordPress-Site zurückbleiben. Performance geht um Umsetzung, nicht nur um Architektur.
Was ist der günstigste Weg zu Headless?
Strapi auf einem 5-Pfund-VPS kombiniert mit Astro oder Next.js, deployed auf Vercels kostenlosem Tier, kann dir ein funktionales Headless-Setup mit sehr geringen monatlichen Kosten ermöglichen. Du zahlst dafür mit Entwicklerzeit. Nichts ist wirklich kostenlos, du wählst nur, wo die Kosten anfallen.
Wie lange dauert ein Headless-Build typischerweise im Vergleich zu einem traditionellen CMS-Build?
Nach meiner Erfahrung: Ein vergleichbares Projekt dauert in einem Headless-Setup grob 1,5x bis 2,5x länger als in WordPress, besonders wenn es das erste Headless-Projekt des Teams ist. Diese Lücke schließt sich, je mehr Vertrautheit das Team mit dem Stack aufbaut. Berücksichtige das ehrlich in Timelines und Angeboten – Clients, denen man "nur ein paar Wochen" für einen Headless-Build versprochen hat und die dann vier Monate warten, kommen nicht zurück.
Stirbt Headless jetzt aus, weil WordPress den Block Editor hat?
Nein, aber die Use Cases werden im unteren Bereich enger. Gutenberg hat in einige Szenarien eingegriffen, wo Headless früher berechtigt war – interaktive, komponentengesteuerte Content-Experiences sind jetzt in WordPress auch ohne Entkopplung besser erreichbar. Im oberen Bereich, für großmaßstäbliches Multi-Channel-Publishing und Commerce, ist Headless genauso relevant wie immer.
---
Headless ist kein Statussymbol. Es ist ein Trade-off: mehr Flexibilität, mehr Komplexität, mehr Kosten, im Austausch für echte Gewinne in bestimmten Situationen. Kenne die Situation, bevor du dich festlegst. Der Manchester-E-Commerce-Client, den ich oben erwähnt habe, migrierte schließlich zurück zu einem Shopify-Theme mit einigen benutzerdefinierten Front-End-Komponenten. Er reduzierte seinen Entwicklungs-Overhead um 60% und seine Ladezeiten verbesserten sich endlich. Manchmal ist die alte Methode die richtige. Es gibt dafür keinen Grund, sich zu schämen.