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.Next.js front end, and their page load times were 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.
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.Go headless when you genuinely need multiple front ends or performance a monolith cannot hit; one WordPress site with a good theme beats three developers maintaining a stack you did not need.
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.WordPress, Squarespace, whatever, couples the content management back end to the front-end presentation layer. They talk to each other natively. Headless decouples them. Your CMS (Contentful, Sanity, Strapi, WordPress in headless mode) becomes a pure content API. Your front end, Next.js, Nuxt, Astro, SvelteKit, whatever you fancy, fetches that content and renders it however it wants.
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, 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. 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 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. 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 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., 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.
- 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., 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 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.), 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.)
- 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., 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-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.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 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.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 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.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-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.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?
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.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 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.