Ein Kunde rief mich 2021 an — eine mittelständische E-Commerce-Marke aus Manchester mit etwa 40.000 SKUs und mehreren regionalen Storefronts — und war außer sich. Sie hatten £180.000 über 18 Monate für einen Headless-Shopify-Aufbau mit Next.js-Frontend ausgegeben, und ihre Seitenladezeiten waren langsamer als das Shopify-Theme, das sie ersetzt hatten. Ihr Entwicklungsteam war von einem Auftragnehmer auf vier Personen gewachsen. Content-Editoren brauchten einen Entwickler, um nur einen Blog-Post live zu schalten.slower than the Shopify theme they'd replaced. Their development team had grown from one contractor to four. Content editors needed a developer present just to push a blog post live.
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 Sites gebaut oder überwacht. Headless war bei vielleicht 8–10% davon die richtige Entscheidung. Die anderen 90%? Das wäre eine Katastrophe gewesen — teuer, langsam in der Umsetzung und furchtbar zu verwalten. Dieser Beitrag geht darum, herauszufinden, in welche Kategorie dein Projekt fällt, bevor du bereits Schecks ausgestellt hast.
---
Was „Headless" in der Praxis eigentlich bedeutet
Schaffen wir die Definition schnell aus dem Weg. Ein traditionelles CMS — WordPress, Squarespace, egal welches — koppelt das Content-Management-Backend an die Frontend-Präsentationsschicht. Sie kommunizieren 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 — ruft diesen Inhalt ab und rendern 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 as the CMS, serving JSON over REST or GraphQL
- Next.js auf dem Frontend, entweder statisch generiert (SSG) oder serverseitig gerendert (SSR) on the front end, either statically generated (SSG) or server-side rendered (SSR)
- Vercel oder Netlify für Deployment und Edge Functions for deployment and edge functions
- Shopify Storefront API oder BigCommerce, falls Commerce involviert ist or BigCommerce if there's commerce involved
- Eine Variante von Algolia für die Suche, da die nativen Suchoptionen meist miserabel sindAlgolia for search, because the native search options are usually rubbish
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 dafür. Ich lehne die Architektur nicht ab. Ich bin nur müde davon, dass sie wahllos angewendet wird.
Multi-Channel-Content-Delivery ist das stärkste Argument. Wenn derselbe Content auf einer Website, einer mobilen App, einem Kiosk-Display und einer Smart-TV-Oberfläche erscheinen muss, wird ein gekoppeltes CMS wirklich schmerzhaft. Eine Content-API, die alle vier Oberflächen abfragen? Das ergibt tatsächlich Sinn. Seahawk hatte einen Hospitality-Kunden in Dubai — eine dieser Resortgruppen mit einer öffentlich zugänglichen Website, einer internen Mitarbeiter-App und Digital Signage auf dem gesamten Gelände. Eine einzelne Sanity-Instanz versorgt alles. Das war die richtige Entscheidung, Punkt. is the strongest argument. If the same content needs to appear on a website, a mobile app, a kiosk display, and a smart TV interface, a coupled CMS becomes genuinely painful. One content API that all four surfaces query? That actually makes sense. Seahawk had a hospitality client in Dubai — one of those resort groups with a public-facing site, an internal staff app, and digital signage across the property. Single Sanity instance feeding all of it. That was the right call, full stop.
Performance im echten Maßstab ist das zweite legitime Argument. Statisch generierte Seiten, die von einem CDN-Edge serviert werden, 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 Page Views pro Monat sprichst, addieren sich diese Millisekunden zu aussagekräftigen Umsatzunterschieden auf. Googles Forschung hat die Korrelation zwischen Ladegeschwindigkeit und Conversion Rate wiederholt dokumentiert — das ist nicht theoretisch. is the second legitimate argument. Statically generated pages served from a CDN edge are fast in a way that PHP-rendered WordPress pages simply aren't, regardless of how well you've optimised your server. When you're talking about millions of page views per month, those milliseconds compound into meaningful revenue differences. Google's research has documented the correlation between load speed and conversion rate repeatedly — it's not theoretical.
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. matters too, though only for organisations big enough to have separate front-end and back-end teams. If your content team is a 20-person marketing department that wants to move independently of your engineering team, a clean API contract between CMS and front end lets both sides work without blocking each other.
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 bei Entwicklern, die Next.js gerade entdeckt haben und es überall einsetzen wollen. (Ich war 2019 selbst schuldig — habe einen headless Blog für einen kleinen Charity-Client gebaut, drei Tage damit verbracht, Webhooks zu konfigurieren, um Netlify-Rebuilds bei neuen Beiträgen auszulösen, habe sie dafür 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 tut das nicht.
Spezifische Szenarien, in denen headless normalerweise mehr kostet, als es bringt:
- Kleine Content-Teams — wenn ein oder zwei Personen alle Inhalte verwalten, ist die Editorial DX eines echten gekoppelten CMS wie WordPress wirklich besser als ein headless CMS. Preview-Umgebungen sind schwieriger. Inline-Bearbeitung ist weg. WYSIWYG ist lahm gelegt. — if one or two people manage all the content, the editorial DX of a proper coupled CMS like WordPress is genuinely better than a headless CMS. Preview environments are harder. Inline editing is gone. WYSIWYG is neutered.
- Knappes Budget — ein echtes headless-Build kostet 2–3x so viel wie ein vergleichbares WordPress-Build in der Entwicklung, und die laufende Wartung ist höher. Wenn Budget ein Constraint ist, tut das Geld fast immer anderswo mehr Gutes. — a proper headless build costs 2–3x a comparable WordPress build to develop, and the ongoing maintenance is higher. If budget is a constraint, that money almost always does more good elsewhere.
- Häufige Content-Änderungen — statische Generierung bedeutet Build-Zeiten. Ein News-Publisher, der 50 Artikel pro Tag veröffentlicht, will nicht 8 Minuten auf einen vollständigen Site-Rebuild warten jedes Mal. (Ja, incremental static regeneration hilft. Es bringt aber auch eine eigene Komplexität mit sich.) — static generation means build times. A news publisher pushing 50 articles a day doesn't want to wait 8 minutes for a full site rebuild every time. (Yes, incremental static regeneration helps. It also adds its own complexity.)
- Kein dediziertes DevOps — jemand muss die Deployment-Pipeline, die CDN-Konfiguration, die Umgebungsvariablen, die Preview-URLs übernehmen. In einem kleinen Team ist das normalerweise der Entwickler, der auch noch alles andere macht. — someone has to own the deployment pipeline, the CDN config, the environment variables, the preview URLs. On a small team, that someone is usually the developer who's also doing everything else.
---
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 Back End — mit WP REST API oder WPGraphQL — gibt dir die Content-Management-Experience, die deine Clients bereits kennen (und ehrlich, die meisten Clients kennen WordPress), kombiniert mit der Flexibilität eines modernen Front End. Du zahlst nicht für Contentful. Du trainierst niemanden um. Das Editorial-Team behält Gutenberg. Das Front End kann jedes Framework sein, das zum Projekt passt.WP REST API or WPGraphQL — gives you the content management experience your clients already know (and honestly, most clients know WordPress), combined with the flexibility of a modern front end. You're not paying for Contentful. You're not retraining anyone. The editorial team keeps Gutenberg. The front end gets to be whatever framework suits the project.
Ich habe dieses Muster über die letzten vier Jahre hinweg wahrscheinlich bei 30–40 Projekten eingesetzt. Es funktioniert besonders gut für Marketing-Seiten, die eine umfangreiche bestehende Content-Bibliothek in WordPress haben und nicht migrieren möchten, aber aus Gründen der Performance oder Interaktivität ein React-Frontend wünschen. Der Kompromiss ist, dass die Wartung des WPGraphQL-Plugins knifflig werden kann, und du führst immer noch einen PHP-Server aus — du bist der WordPress-Hosting nicht vollständig entkommen.
---
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-Grade-Option. Solide API, gute SDKs, angemessene Editorial-UI. Der Preispunkt ist das Schmerzendes — der kostenlose Tarif ist für kleine Projekte wirklich brauchbar, aber sobald du die Grenzen erreichst, schaust du auf $300+/Monat bevor du überhaupt etwas Interessantes getan hast. Ich würde Contentful bei Projekten mit echten Budgets und Organisationen einsetzen, die ordentliche Rollen- und Berechtigungsworkflows benötigen.
Sanity
Mein persönlicher Favorit für die meisten Mid-Market-Headless-Projekte. Die GROQ-Abfragesprache ist ausdrucksstark, sobald du einen Tag damit verbracht hast, Sanity Studio ist auf Wegen anpassbar, auf die Contentful es nicht ist, und die Echtzeit-Zusammenarbeit ist exzellent. Die Preisgestaltung ist günstiger. Der Nachteil ist, dass die Lernkurve für nicht-technische Content-Redakteure steiler ist — das Studio sieht sich von WordPress genug unterscheidet, dass es immer eine Schulungsphase gibt.GROQ query language is expressive once you've spent a day with it, Sanity Studio is customisable in ways Contentful isn't, and the real-time collaboration is excellent. Pricing is more reasonable. The downside is that the learning curve for non-technical content editors is steeper — the Studio looks different enough from WordPress that there's always a training period.
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 Websites, die hauptsächlich statisch sind — Dokumentation, Blogs, Marketing-Websites — lohnt es sich, Astro mit lokalen Content Collections in Betracht zu ziehen. Gar kein CMS. Inhalte liegen als Markdown- oder MDX-Dateien im Repository. Entwickler lieben es. Nicht-technische Redakteure hassen es normalerweise. Kenne dein Publikum, bevor du diesen Weg gehst.Astro with local content collections is worth considering. No CMS at all. Content lives as Markdown or MDX files in the repo. Developers love it. Non-technical editors usually hate it. Know your audience before going this route.
---
Das Performance-Argument: Was die Zahlen wirklich aussagen
Lass mich dir eine echte Benchmark geben, statt einer vagen Aussage über Geschwindigkeit.
Ein Seahawk-Kunde — ein SaaS-Unternehmen mit etwa 80 Seiten und moderatem Traffic — ist von einer verwalteten WordPress-Installation zu Next.js mit Sanity migriert, deployed auf Vercel. Vor der Migration lagen die Lighthouse-Scores auf Mobile bei etwa 62–68. Danach durchgehend 91–96. Time to First Byte fiel von rund 420ms auf unter 80ms. Das ist keine marginale Verbesserung. Das ist ein anderes Produkt.
Aber — und das ist wichtig — sie hatten einen dedizierten Frontend-Entwickler, ein Content-Team aus vier Personen, das Sanity-Training durchlaufen hat, und ein Budget, das einen achtwöchigen Build aufgenommen hat. Die Performance-Gewinne waren real, weil die Bedingungen für Headless vorhanden 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.Web Almanac's data on CMS performance shows that the performance gap between headless-oriented frameworks and traditional coupled CMSes is real but not automatic. A badly implemented Next.js site can absolutely underperform a well-configured WordPress site. Architecture alone doesn't save you.
---
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. If yes, headless gets a serious look. If no, it loses a major justification.
- Wie ist das technische Komfortniveau des Content-Teams? Nicht-technische Editoren unter Zeitdruck in einem unbekannten CMS sind eine schlechte Kombination. Non-technical editors on a tight deadline in an unfamiliar CMS is a bad combination.
- Welcher Traffic und welche Performance-Anforderungen werden erwartet? Unter 50.000 monatliche Besucher auf einem vernünftigen Host? WordPress bewältigt das problemlos. Sub-50,000 monthly visitors on a reasonable host? WordPress handles it fine.
- 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. If the answer is "we'll call someone when it breaks," headless infrastructure is a liability.
- 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. Not just the build. Hosting, CMS subscriptions, developer time for updates. Total cost of ownership.
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?
Das hängt vollständig davon ab, was „besser" für dein spezifisches Projekt bedeutet. Für Multi-Channel-Auslieferung, Team-Separation oder Performance bei hohem Traffic-Aufkommen kann Headless WordPress — oder der Austausch von WordPress durch ein dediziertes Headless-CMS — sinnvolle Verbesserungen bringen. Für eine Standard-Geschäftswebsite 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 Kunden 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.by default, but a poorly configured headless build with unoptimised images, waterfall API requests, and no proper caching can absolutely underperform a well-tuned WordPress site. Performance is about execution, not just architecture.
Was ist der günstigste Weg zu Headless?
Strapi auf einer £5/Monat VPS kombiniert mit Astro oder Next.js deployed auf Vercels kostenlosem Tier kann dir ein funktionierendes Headless-Setup für sehr wenig monatliche Kosten geben. Du zahlst stattdessen in Entwickler-Zeit. Nichts ist wirklich umsonst — du entscheidest nur, wo die Kosten landen.
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 etwa 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, wenn das Team Vertrautheit mit dem Stack aufbaut. Berücksichtige das ehrlich in Timelines und Angeboten — Kunden, denen man „nur ein paar Wochen" für einen Headless-Build gesagt hat, und es dauert dann vier Monate, kommen nicht zurück.
Stirbt Headless jetzt aus, weil WordPress den Block Editor hat?
Nein, aber die Use-Cases werden am unteren Ende enger. Gutenberg hat in einige Szenarien eingegriffen, wo Headless früher gerechtfertigt war — interaktive, komponent-getriebene Content-Experiences sind jetzt in WordPress ohne Entkopplung besser erreichbar. Am oberen Ende, für großflächiges Multi-Channel-Publishing und Commerce, ist Headless so relevant wie je zuvor.
---
Headless ist kein Statussymbol. Es ist ein Kompromiss — mehr Flexibilität, mehr Komplexität, höhere Kosten, im Gegenzug für echte Gewinne in spezifischen Situationen. Kenne die Situation, bevor du dich festlegst. Der E-Commerce-Kunde aus Manchester, den ich am Anfang erwähnt habe, ist schließlich zu einem Shopify-Theme mit einigen benutzerdefinierten Frontend-Komponenten migriert. Sie haben ihren Entwicklungsaufwand um 60% reduziert und ihre Ladezeiten haben sich endlich verbessert. Manchmal ist die alte Methode die richtige. Es gibt da keine Schande drin.