WordPress, Headless oder Baukasten? Entscheidungskriterien für Unternehmen

Die Frage nach dem richtigen CMS ist eine der am häufigsten falsch beantworteten Fragen in Unternehmen. Nicht weil die Antwort so schwer wäre. Sondern weil die meisten Entscheider die falsche Frage stellen. Sie fragen: Was kostet das? Statt: Was kostet uns das in drei Jahren? Sie fragen: Können unsere Redakteure damit arbeiten? Statt: Können unsere Entwickler damit skalieren? Sie fragen: Was nutzen die anderen? Statt: Was passt zu unserer Architektur?

Ich schreibe das als jemand, der sechs Jahre in einer Werbeagentur gearbeitet hat. Dort haben wir WordPress-Seiten gebaut. Dutzende. Und ich habe gesehen, was nach zwei, drei Jahren mit diesen Projekten passiert. Die Plugin-Hölle. Die Performance-Probleme. Die Sicherheitslücken. Das ist kein WordPress-Bashing — das ist Erfahrung.

Bei happycoding setzen wir auf einen anderen Stack: Next.js, Tailwind, Sanity, Payload CMS, Supabase. Das ist keine religiöse Entscheidung. Das ist das Ergebnis von vielen gescheiterten und gelungenen Projekten. Aber ich bin auch ehrlich genug zuzugeben, dass Headless nicht für jeden die richtige Wahl ist. Dieser Artikel soll helfen, die richtige Entscheidung zu treffen — auch wenn das bedeutet, dass die Antwort manchmal unbequem ist.

WordPress ist Open Source. Der Download kostet nichts. Das ist ein Fakt. Aber es ist ungefähr so relevant wie die Aussage, dass ein Grundstück günstig ist — ohne zu erwähnen, dass man noch ein Haus darauf bauen muss. Die Software selbst ist nur der Anfang. Das eigentliche Investment beginnt danach.

Ein typisches WordPress-Setup für ein mittelständisches B2B-Unternehmen sieht so aus: Ein Premium-Theme für 50 bis 100 Euro. Ein Page Builder wie Elementor Pro für 50 Euro im Jahr. Diverse Premium-Plugins — SEO, Formulare, Caching, Security, Backup — zusammen schnell 300 bis 500 Euro im Jahr. Managed Hosting, das tatsächlich performant ist, nochmal 30 bis 100 Euro im Monat. Dann kommen die versteckten Kosten: Ein Entwickler, der regelmäßig Updates einspielen und testen muss, ob danach noch alles funktioniert. Ein anderer Entwickler, der nach einem Year die Performance optimiert, weil das Zusammenspiel aus Theme, Page Builder und 30 Plugins die Seite langsam gemacht hat.

Die Total Cost of Ownership eines WordPress-Projekts über drei Jahre liegt für ein B2B-Unternehmen realistisch bei 15.000 bis 40.000 Euro — und das ohne grundlegende Redesigns oder größere Feature-Entwicklungen. Bei einem Headless-Setup mit Sanity oder Payload CMS liegt das initiale Investment höher, typischerweise bei 20.000 bis 50.000 Euro für die Erstentwicklung. Aber die laufenden Kosten sind drastisch niedriger. Keine Plugin-Updates, die andere Plugins zerschießen. Keine Performance-Optimierung alle sechs Monate. Keine Sicherheitspatches im Wochentakt. Über drei Jahre rechnet sich Headless fast immer — vorausgesetzt, man plant überhaupt so weit.

Wix, Squarespace, Webflow — diese Tools haben ihre Berechtigung. Für eine Landingpage, einen Freelancer-Auftritt oder ein MVP sind sie fantastisch. In wenigen Stunden steht eine ansehnliche Seite. Das Design ist solid. Die Ladezeiten sind akzeptabel. Der Preis ist überschaubar. Ich sage das ohne Ironie: Für bestimmte Anwendungsfälle sind Baukästen die beste Wahl.

Aber. Und das ist ein großes Aber. Sobald ein Unternehmen wächst, stößt man an Grenzen, die nicht verschiebbar sind. Webflow ist hier noch am flexibelsten — man kann mit dem CMS arbeiten, hat Zugriff auf den generierten Code und kann relativ komplexe Strukturen bauen. Aber auch Webflow hat Grenzen bei der Content-Modellierung. Versuchen Sie mal, ein komplexes B2B-Produktportfolio mit Varianten, Konfigurationen und Preislogik in Webflow abzubilden. Oder eine mehrsprachige Seite mit regionalen Unterschieden in Inhalten und Struktur. Oder eine Integration mit Ihrem PIM-System, Ihrem CRM und Ihrer Marketing-Automation.

Der größte Nachteil von Baukästen ist das Vendor Lock-in. Ihre Inhalte, Ihre Strukturen, Ihr Design — alles lebt in der Plattform. Wenn Sie Wix verlassen wollen, nehmen Sie Ihre Texte mit, aber sonst nichts. Keine Struktur, keine Logik, kein Design. Sie fangen von vorn an. Bei Squarespace ist es ähnlich. Webflow erlaubt zumindest den Export des HTML/CSS, aber das ist auch nur bedingt nützlich, wenn man zu einem modernen Framework-basierten Setup wechseln will.

Für ein Startup, das noch nicht weiß, wohin die Reise geht, ist ein Baukasten trotzdem oft der richtige erste Schritt. Schnell live gehen, testen, lernen. Aber man sollte von Anfang an wissen: Das ist eine temporäre Lösung. Kein Fundament für die nächsten fünf Jahre.

Hier muss ich deutlich werden, auch wenn es Agenturen gibt, die das nicht gerne hören. WordPress mit Page Buildern wie Elementor, Divi oder WPBakery ist technische Schulden auf Raten. Die ersten Monate fühlen sich großartig an. Die Redakteure können alles per Drag-and-Drop zusammenbauen. Änderungen sind schnell gemacht. Niemand braucht einen Entwickler. So sieht es zumindest aus.

Was unter der Haube passiert, ist weniger schön. Page Builder generieren aufgeblähten HTML-Code. Sie laden Dutzende von JavaScript- und CSS-Dateien, die meistens nicht benötigt werden. Sie speichern Inhalte in proprietären Formaten in der Datenbank — Shortcodes, serialisierte Arrays, verschachtelte JSON-Strukturen, die kein anderes System lesen kann. Jeder Page Builder hat sein eigenes Format. Wechseln Sie von Elementor zu einem anderen System, müssen Sie jeden einzelnen Inhalt neu aufbauen.

Und dann ist da die Sicherheit. WordPress ist das meistgenutzte CMS der Welt — und damit das meistangegriffene. Das ist keine Schwäche von WordPress selbst. Der WordPress-Core ist gut gepflegt. Das Problem sind die Plugins. Jedes Plugin ist ein potenzielles Einfallstor. Elementor allein hatte in den letzten zwei Jahren mehrere kritische Sicherheitslücken. Multiplizieren Sie das mit 20 oder 30 Plugins, und Sie haben ein System, das permanent Pflege braucht. Nicht weil es schlecht gebaut ist, sondern weil es architektonisch nicht anders geht.

Die Performance-Situation ist ähnlich problematisch. Ein gut optimiertes WordPress kann schnell sein. Aber ein WordPress mit Page Builder, Kontaktformular-Plugin, Cookie-Banner-Plugin, Analytics-Plugin, SEO-Plugin und fünf weiteren Plugins ist es in der Regel nicht. Google PageSpeed Scores von 30 bis 50 sind keine Seltenheit. Und ja, das wirkt sich auf Rankings und Conversion Rates aus. Nicht dramatisch, aber messbar.

Ein Argument, das für WordPress angeführt wird: Es gibt überall WordPress-Entwickler. Das stimmt quantitativ. Qualitativ ist es komplizierter. Die besten Entwickler arbeiten heute nicht mehr mit WordPress. Sie arbeiten mit React, Next.js, Vue, Svelte. Sie wollen mit modernen Tools arbeiten, mit TypeScript, mit komponentenbasierter Architektur, mit Git-basierten Workflows. Ein WordPress-Entwickler, der wirklich gut ist, kostet Sie genau so viel wie ein React-Entwickler. Und er ist schwerer zu finden, weil die guten Leute den Stack gewechselt haben.

Für ein Unternehmen, das langfristig digitale Produkte baut, ist die Talentfrage entscheidend. Wenn Sie heute ein Team aufbauen oder eine Agentur beauftragen, wollen Sie auf einen Tech-Stack setzen, der Talente anzieht. Und das ist im Jahr 2025 nicht WordPress mit PHP und jQuery. Das ist React oder Vue mit einem Headless CMS als Content-Backend. Das ist ein Stack, in dem Entwickler gerne arbeiten — und in dem sie produktiv sind, weil die Tools modern sind.

Ein weiterer Aspekt: Bei Headless-Architekturen kann das Frontend-Team unabhängig vom Content-Team arbeiten. Neue Features im Frontend haben keinen Einfluss auf das CMS. Content-Änderungen brauchen kein Deployment. Diese Entkopplung ist ein enormer Produktivitätsgewinn, den man erst schätzt, wenn man ihn erlebt hat.

Bei einem Headless CMS wie Sanity oder Payload trennt man Inhaltsverwaltung und Darstellung. Das CMS kümmert sich ausschließlich um strukturierte Inhalte — Texte, Bilder, Referenzen, Metadaten. Wie diese Inhalte dargestellt werden, entscheidet das Frontend. Das kann eine Website sein. Oder eine App. Oder ein Intranet. Oder alle drei gleichzeitig, gespeist aus derselben Content-Quelle.

Für B2B-Unternehmen ist das ein enormer Vorteil. Produktinformationen, die auf der Website, im Kundenportal und in der Sales-App identisch sein müssen — mit einem Headless CMS kein Problem. Blog-Inhalte, die gleichzeitig auf der Website und im Newsletter verwendet werden — eine Content-Quelle, keine Dopplungen, keine Inkonsistenzen. Content-Modellierung, die exakt auf die Geschäftslogik zugeschnitten ist — nicht eingeschränkt durch die Vorgaben eines Themes oder Page Builders.

Sanity ist dabei besonders stark in der Flexibilität der Content-Modellierung. Sie definieren Ihre Datenstrukturen exakt so, wie Ihr Business sie braucht. Nicht andersherum. Payload CMS geht noch einen Schritt weiter und gibt Ihnen die volle Kontrolle über die Datenbank — Postgres oder MongoDB, selbst gehostet, Ihre Daten gehören Ihnen. Beide Systeme liefern ihre Inhalte über APIs aus, die von jedem Frontend konsumiert werden können. TypeScript-Support von Anfang an. Echtzeit-Kollaboration. Versionierung. Alles, was man von einem modernen Content-System erwartet.

Ein Headless-Setup mit Next.js als Frontend liefert statisch generierte Seiten aus, die auf einem CDN liegen. Das bedeutet: Ladezeiten im Bereich von unter einer Sekunde. Weltweit. Ohne dass ein Server bei jedem Seitenaufruf eine Datenbankabfrage starten muss. WordPress generiert jede Seite dynamisch — bei jedem Aufruf. Ja, es gibt Caching-Plugins, die das abmildern. Aber sie fügen Komplexität hinzu und sind eine weitere potenzielle Fehlerquelle.

Bei plötzlichem Traffic — etwa nach einer erfolgreichen Kampagne oder einer Pressemeldung — skaliert ein statisches Frontend mühelos. Es sind nur Dateien auf einem CDN. WordPress-Server hingegen können unter Last in die Knie gehen, wenn das Caching nicht perfekt konfiguriert ist. Und "perfekt konfiguriert" ist bei WordPress ein relativer Begriff, der sich mit jedem Plugin-Update ändern kann.

In der B2B-Welt steht kein System allein. Das CMS muss mit dem CRM kommunizieren, Daten aus dem ERP anzeigen, sich in die Marketing-Automation einklinken und vielleicht noch Inhalte an ein Kundenportal liefern. WordPress kann das — über Plugins und Custom Development. Aber jede Integration ist ein weiteres Plugin, eine weitere Abhängigkeit, ein weiteres Risiko. Headless-Systeme sind von Grund auf API-first gebaut. Sie sind dafür gemacht, mit anderen Systemen zu sprechen. Webhooks, REST, GraphQL — die Integrationsschicht ist nativ, nicht nachgerüstet.

Ein konkretes Beispiel aus unserer Praxis: Ein B2B-Kunde wollte Produktdaten aus seinem PIM-System automatisch in die Website einfließen lassen, gleichzeitig sollten Blog-Artikel als Grundlage für automatisierte Newsletter dienen, und das Kundenportal brauchte personalisierte Inhalte basierend auf der Kundenrolle. Mit Sanity als zentralem Content-Hub, Next.js als Frontend und n8n für die Automatisierung haben wir das in wenigen Wochen umgesetzt. In WordPress hätte allein die Plugin-Evaluation länger gedauert.

Es gibt eine weitere Kategorie, die in der Diskussion oft auftaucht: die Enterprise-CMS-Systeme der alten Schule. TYPO3 hat in Deutschland eine treue Fangemeinde, vor allem im öffentlichen Sektor und bei größeren Mittelständlern. Sitecore spielt im Enterprise-Segment. Contao hat seine Nische im deutschsprachigen Raum. Alle drei haben eines gemeinsam: Sie lösen Probleme, die es vor zehn Jahren gab, auf die Art und Weise, wie man es vor zehn Jahren getan hat.

TYPO3 ist ein monolithisches System, das eine enorme Komplexität mitbringt. Die Konfiguration über TypoScript ist für Außenstehende nahezu unverständlich. Die Entwickler-Community schrumpft. Junge Entwickler lernen kein TypoScript — sie lernen React und TypeScript. Ein TYPO3-Projekt heute zu starten bedeutet, sich bewusst für ein System zu entscheiden, dessen beste Tage hinter ihm liegen. Das klingt hart, aber schauen Sie sich die Zahlen an: die Zahl der aktiven TYPO3-Installationen stagniert, die Community-Events werden kleiner, die Agenturlandschaft konsolidiert sich.

Sitecore ist das andere Extrem: extrem teuer, extrem komplex, extrem abhängig von zertifizierten Partnern. Lizenzkosten von 40.000 Euro aufwärts pro Jahr. Implementierungen, die Monate dauern und sechsstellige Budgets verschlingen. Für einen DAX-Konzern mag das akzeptabel sein. Für ein mittelständisches Unternehmen ist es in den meisten Fällen Overkill. Die Features, die Sitecore bietet — Personalisierung, A/B-Testing, Marketing-Automation — bekommt man heute mit einer Kombination aus Headless CMS, Vercel und spezialisierten Tools günstiger und flexibler.

Contao möchte ich nicht unfair behandeln. Es ist ein solides System für einfachere Websites und hat eine loyal Community. Aber es spielt in einer anderen Liga als moderne Headless-Systeme. Die Content-Modellierung ist limitiert, die API-Fähigkeit eingeschränkt, und die Entwickler-Experience entspricht nicht dem, was man heute erwarten kann. Für ein Unternehmen, das eine digitale Plattform bauen will — nicht nur eine Website —, ist Contao keine ernsthafte Option.

Ich habe eine klare Meinung. Aber eine klare Meinung bedeutet nicht, blind zu sein für die Realität. Deshalb hier eine ehrliche Einordnung, wann welcher Ansatz Sinn ergibt — auch wenn das nicht immer in mein Geschäftsmodell passt.

...Sie einen einfachen Blog oder eine Unternehmenswebsite brauchen, die nicht in andere Systeme integriert werden muss. Wenn Ihr Budget für die Erstentwicklung unter 10.000 Euro liegt. Wenn Sie bereits ein Team haben, das WordPress kennt und pflegt. Wenn die Website kein zentraler Bestandteil Ihrer digitalen Strategie ist, sondern eher eine digitale Visitenkarte. In diesen Fällen ist WordPress eine pragmatische Wahl. Aber verwenden Sie kein Page-Builder-Plugin. Nutzen Sie den Gutenberg-Editor mit Custom Blocks oder — noch besser — WordPress als Headless Backend mit der REST-API. Das gibt Ihnen die Vertrautheit von WordPress ohne die schlimmsten Nachteile.

...Sie schnell live gehen müssen und das Budget knapp ist. Wenn Sie ein Startup sind, das erst validieren muss, ob das Geschäftsmodell funktioniert. Wenn Sie eine Landingpage für eine Kampagne brauchen und keine drei Monate auf die Agentur warten wollen. Wenn Ihre Anforderungen an Content-Struktur und Integrationen überschaubar sind. Webflow ist hier die beste Option, weil es am meisten Flexibilität bietet und der Export-Pfad am wenigsten schmerzhaft ist. Aber planen Sie von Anfang an die Migration ein. Nicht als vages "irgendwann", sondern als konkreten Meilenstein in Ihrer Roadmap.

...Ihre Website mehr ist als eine Broschüre. Wenn Sie Content über mehrere Kanäle ausspielen wollen oder müssen. Wenn Sie Integrationen mit CRM, ERP, PIM oder Marketing-Tools brauchen. Wenn Performance und Core Web Vitals geschäftskritisch sind. Wenn Sie ein Entwicklerteam haben oder aufbauen wollen, das mit modernen Tools arbeitet. Wenn Sie in den nächsten drei bis fünf Jahren skalieren wollen — mehr Märkte, mehr Sprachen, mehr digitale Touchpoints. In all diesen Fällen ist ein Headless CMS die richtige Grundlage. Die initiale Investition ist höher, aber Sie bauen auf einem Fundament, das mitwächst.

Viele Unternehmen stehen nicht vor einer Greenfield-Entscheidung. Sie haben bereits ein CMS. Meistens WordPress. Manchmal TYPO3. Gelegentlich etwas Exotischeres. Die Frage ist nicht nur: Was ist das beste System? Sondern auch: Wie kommen wir von hier nach dort?

Eine CMS-Migration ist kein Wochenendprojekt. Aber sie ist auch kein Grund, bei einem System zu bleiben, das nicht mehr passt. Der Schlüssel ist ein inkrementeller Ansatz. Sie müssen nicht alles auf einmal migrieren. Starten Sie mit den Inhalten, die den größten Business-Impact haben. Für ein B2B-Unternehmen sind das typischerweise die Produktseiten und der Blog. Setzen Sie das neue System parallel auf, migrieren Sie schrittweise und leiten Sie den Traffic um, sobald Bereiche fertig sind.

Die Content-Migration selbst ist bei einem Wechsel zu einem Headless CMS oft einfacher als erwartet. WordPress-Inhalte lassen sich über die REST-API exportieren und per Script in die Zielstruktur transformieren. Bei Sanity gibt es dafür eigene Import-Tools. Bei Payload CMS können Sie direkt auf die Datenbank schreiben. Die eigentliche Arbeit liegt nicht im technischen Transfer, sondern in der Content-Modellierung: Wie sollen Ihre Inhalte in der neuen Welt strukturiert sein? Das ist die Gelegenheit, Altlasten loszuwerden — doppelte Inhalte, inkonsistente Strukturen, SEO-Leichen.

Ein Punkt, der bei Migrationen oft übersehen wird: die SEO-Kontinuität. Jede URL, die sich ändert, braucht ein Redirect. Jede Seite, die wegfällt, muss bewertet werden. Die internen Verlinkungen müssen angepasst werden. Das klingt trivial, aber ich habe Migrationen gesehen, die 30 Prozent des organischen Traffics gekostet haben, weil die Redirects vergessen oder fehlerhaft implementiert wurden. Planen Sie das ein. Dokumentieren Sie jede URL. Testen Sie die Redirects vor dem Launch.

Diese Frage wird zu selten gestellt. Bei WordPress gehören Ihnen die Inhalte — sie liegen in einer MySQL-Datenbank, die Sie kontrollieren. Das ist gut. Aber die Strukturierung der Inhalte — vor allem wenn Page Builder im Spiel sind — ist proprietär und praktisch nicht portabel. Bei Wix und Squarespace gehören Ihnen die Inhalte theoretisch, aber der Export ist limitiert. Sie bekommen Ihre Texte, aber nicht die Struktur, nicht die Beziehungen zwischen Inhalten, nicht die Metadaten.

Bei Sanity liegen Ihre Inhalte in der Sanity-Cloud, aber sie sind über die API vollständig zugänglich und exportierbar — strukturiert, mit allen Referenzen und Metadaten. Bei Payload CMS liegen die Daten in Ihrer eigenen Datenbank. Sie haben die volle Kontrolle. Kein Vendor kann Ihnen den Zugang zu Ihren Inhalten verwehren. Das ist ein fundamentaler Unterschied, der in der Evaluierung oft untergeht, weil er erst dann relevant wird, wenn man wechseln will oder muss.

Auch beim Frontend gibt es Lock-in-Risiken. Wenn Ihre Website auf einem proprietären Framework eines Anbieters basiert, sind Sie von diesem Anbieter abhängig. Bei einem Open-Source-Stack — Next.js, React, Tailwind — gibt es dieses Risiko nicht. Die Tools sind offen, die Community ist riesig, und wenn ein Tool morgen verschwindet, gibt es Alternativen. Das ist ein Luxus, den man mit proprietären Systemen nicht hat.

Wo Ihre Website läuft, beeinflusst Performance, Sicherheit und Kosten maßgeblich. WordPress braucht einen Server mit PHP und MySQL. Das kann ein günstiger Shared-Hosting-Account sein — dann ist die Performance mäßig und die Sicherheit fragwürdig. Oder ein Managed-WordPress-Host wie Raidboxes oder Kinsta — dann stimmt die Performance, aber die Kosten liegen bei 30 bis 100 Euro im Monat. Baukästen nehmen Ihnen die Hosting-Frage ab, dafür zahlen Sie mit Flexibilität und Kontrolle.

Bei einem Headless-Setup haben Sie mehr Optionen. Das Frontend kann auf Vercel oder Netlify laufen — mit automatischem Deployment, globalen CDNs und Zero-Config-Skalierung. Oder Sie hosten selbst, zum Beispiel auf Hetzner mit Coolify und Docker. Das kostet einen Bruchteil, erfordert aber DevOps-Know-how. Wir bei happycoding nutzen je nach Projekt beide Ansätze. Für Kunden, die maximale Kontrolle und Datensouveränität wollen — etwa wegen DSGVO-Anforderungen —, ist Self-Hosting auf europäischen Servern oft die bessere Wahl. Für Kunden, die schnell skalieren wollen und kein eigenes Ops-Team haben, ist Vercel die pragmatische Lösung.

Am Ende geht es nicht um Technologie. Es geht um Ihre Geschäftsziele. Ein CMS ist ein Werkzeug. Kein Selbstzweck. Die Frage ist nicht: Was ist das beste CMS? Die Frage ist: Welches CMS ermöglicht es uns, unsere digitalen Ziele in den nächsten drei bis fünf Jahren zu erreichen — ohne dass uns die Technologie dabei im Weg steht?

Wenn die Antwort auf diese Frage ist, dass Sie ein einfaches System für eine überschaubare Website brauchen, dann nehmen Sie WordPress oder einen Baukasten und investieren das gesparte Budget in Inhalte und Marketing. Das ist eine valide Entscheidung. Wenn die Antwort aber ist, dass Sie eine digitale Plattform bauen wollen, die mitwächst, die sich in Ihre Systemlandschaft integriert und die Ihnen langfristig Flexibilität gibt, dann führt an einem Headless-Ansatz kaum ein Weg vorbei.

Die unbequeme Wahrheit ist: Die billigste Lösung am Anfang ist selten die günstigste Lösung am Ende. Und die Lösung, die sich am einfachsten anfühlt, ist selten die, die am besten skaliert. Technologie-Entscheidungen sind Investment-Entscheidungen. Behandeln Sie sie auch so.

Was mich in Erstgesprächen mit Unternehmen immer wieder überrascht: Wie wenig Zeit in die CMS-Evaluation fließt, verglichen mit der Zeit, die man mit den Konsequenzen einer falschen Wahl verbringt. Nehmen Sie sich zwei Wochen für eine strukturierte Evaluation. Definieren Sie Ihre Anforderungen — nicht nur die heutigen, sondern die in drei Jahren. Sprechen Sie mit Ihrem Entwicklerteam, nicht nur mit den Redakteuren. Rechnen Sie die Total Cost of Ownership über den gesamten Lebenszyklus. Und dann treffen Sie eine informierte Entscheidung. Die Technologie ist da. Die Frage ist nur, ob Sie bereit sind, die richtigen Fragen zu stellen.