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: Was kostet das? Statt: Was kostet uns das in drei Jahren?

Gefragt wird auch: Können unsere Redakteure damit arbeiten? Statt: Können unsere Entwickler damit skalieren? Und: 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, sondern das Ergebnis von vielen gescheiterten und gelungenen Projekten. Aber ich bin ehrlich genug zuzugeben, dass Headless nicht für jeden die richtige Wahl ist. Dieser Artikel soll dir helfen, die richtige Entscheidung zu treffen — auch wenn die Antwort manchmal unbequem ist.

WordPress ist Open Source, der Download kostet nichts. Das ist ein Fakt. Aber er ist ungefähr so relevant wie die Aussage, dass ein Grundstück günstig ist — ohne zu erwähnen, dass du noch ein Haus darauf bauen musst. 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. Dazu diverse Premium-Plugins für SEO, Formulare, Caching, Security und Backup — zusammen schnell 300 bis 500 Euro im Jahr. Managed Hosting, das tatsächlich performant ist, kostet nochmal 30 bis 100 Euro im Monat.

Dann kommen die versteckten Kosten: ein Entwickler, der regelmäßig Updates einspielt und testet, ob danach noch alles funktioniert. Ein anderer Entwickler, der nach einem Jahr 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, du planst ü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 solide, 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 du an Grenzen, die nicht verschiebbar sind. Webflow ist hier noch am flexibelsten: Du kannst mit dem CMS arbeiten, hast Zugriff auf den generierten Code und kannst relativ komplexe Strukturen bauen.

Aber auch Webflow hat Grenzen bei der Content-Modellierung. Versuch 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 deinem PIM-System, deinem CRM und deiner Marketing-Automation.

Der größte Nachteil von Baukästen ist das Vendor Lock-in. Deine Inhalte, deine Strukturen, dein Design: Alles lebt in der Plattform. Wenn du Wix verlässt, nimmst du deine Texte mit, aber sonst nichts. Keine Struktur, keine Logik, kein Design — du fängst von vorn an.

Bei Squarespace ist es ähnlich. Webflow erlaubt zumindest den Export des HTML/CSS, aber das ist nur bedingt nützlich, wenn du zu einem modernen Framework-basierten Setup wechseln willst.

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 du solltest 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 bauen alles per Drag-and-Drop zusammen, Ä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 und laden Dutzende von JavaScript- und CSS-Dateien, die meistens niemand braucht.

Inhalte landen 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. Wechselst du von Elementor zu einem anderen System, musst du 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. Multipliziere das mit 20 oder 30 Plugins, und du hast 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, sondern mit React, Next.js, Vue oder Svelte.

Diese Entwickler wollen mit modernen Tools arbeiten: mit TypeScript, mit komponentenbasierter Architektur, mit Git-basierten Workflows. Ein WordPress-Entwickler, der wirklich gut ist, kostet dich genauso 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 du heute ein Team aufbaust oder eine Agentur beauftragst, willst du auf einen Tech-Stack setzen, der Talente anzieht. Und das ist im Jahr 2025 nicht WordPress mit PHP und jQuery, sondern React oder Vue mit einem Headless CMS als Content-Backend. Ein Stack, in dem Entwickler gerne arbeiten — und in dem sie produktiv sind, weil die Tools modern sind.

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

Bei einem Headless CMS wie Sanity oder Payload trennst du 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, eine App, 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 laufen: eine Content-Quelle, keine Dopplungen, keine Inkonsistenzen.

Dazu kommt Content-Modellierung, die exakt auf deine Geschäftslogik zugeschnitten ist — nicht eingeschränkt durch die Vorgaben eines Themes oder Page Builders.

Sanity ist besonders stark in der Flexibilität der Content-Modellierung: Du definierst deine Datenstrukturen exakt so, wie dein Business sie braucht. Nicht andersherum. Payload CMS geht noch einen Schritt weiter und gibt dir die volle Kontrolle über die Datenbank — Postgres oder MongoDB, selbst gehostet, deine Daten gehören dir.

Beide Systeme liefern ihre Inhalte über APIs aus, die jedes Frontend konsumieren kann. TypeScript-Support von Anfang an, Echtzeit-Kollaboration, Versionierung: alles, was du von einem modernen Content-System erwartest.

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 und 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: Diese Systeme 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 schau dir 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, bekommst du heute günstiger und flexibler: Personalisierung, A/B-Testing und Marketing-Automation gehen auch mit einer Kombination aus Headless CMS, Vercel und spezialisierten Tools.

Contao möchte ich nicht unfair behandeln: Es ist ein solides System für einfachere Websites mit einer loyalen 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 du heute erwarten kannst.

Willst du eine digitale Plattform bauen und 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.

...du einen einfachen Blog oder eine Unternehmenswebsite brauchst, die nicht in andere Systeme integriert werden muss. Wenn dein Budget für die Erstentwicklung unter 10.000 Euro liegt. Wenn du bereits ein Team hast, das WordPress kennt und pflegt. Wenn die Website kein zentraler Bestandteil deiner digitalen Strategie ist, sondern eher eine digitale Visitenkarte.

In diesen Fällen ist WordPress eine pragmatische Wahl. Aber verwende kein Page-Builder-Plugin: Nutze den Gutenberg-Editor mit Custom Blocks oder, noch besser, WordPress als Headless Backend mit der REST-API. Das gibt dir die Vertrautheit von WordPress ohne die schlimmsten Nachteile.

...du schnell live gehen musst und das Budget knapp ist. Wenn du ein Startup bist, das erst validieren muss, ob das Geschäftsmodell funktioniert. Wenn du eine Landingpage für eine Kampagne brauchst und keine drei Monate auf die Agentur warten willst. Wenn deine 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 plane von Anfang an die Migration ein: nicht als vages «irgendwann», sondern als konkreten Meilenstein in deiner Roadmap.

...deine Website mehr ist als eine Broschüre. Wenn du Content über mehrere Kanäle ausspielen willst oder musst. Wenn du Integrationen mit CRM, ERP, PIM oder Marketing-Tools brauchst. Wenn Performance und Core Web Vitals geschäftskritisch sind.

Wenn du ein Entwicklerteam hast oder aufbauen willst, das mit modernen Tools arbeitet. Wenn du in den nächsten drei bis fünf Jahren skalieren willst: 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 du baust auf einem Fundament, das mitwächst.

Viele Unternehmen stehen nicht vor einer Greenfield-Entscheidung. Ein CMS ist bereits da: 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: Du musst nicht alles auf einmal migrieren.

Starte mit den Inhalten, die den größten Business-Impact haben. Für ein B2B-Unternehmen sind das typischerweise die Produktseiten und der Blog. Setz das neue System parallel auf, migriere schrittweise und leite den Traffic um, sobald Bereiche fertig sind.

Die Content-Migration selbst ist beim 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 kannst du direkt auf die Datenbank schreiben.

Die eigentliche Arbeit liegt nicht im technischen Transfer, sondern in der Content-Modellierung: Wie sollen deine 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. Plane das ein: Dokumentiere jede URL und teste die Redirects vor dem Launch.

Diese Frage wird zu selten gestellt. Bei WordPress gehören dir die Inhalte, denn sie liegen in einer MySQL-Datenbank, die du kontrollierst. Das ist gut.

Aber die Strukturierung der Inhalte ist proprietär und praktisch nicht portabel — vor allem, wenn Page Builder im Spiel sind. Bei Wix und Squarespace gehören dir die Inhalte theoretisch, aber der Export ist limitiert: Du bekommst deine Texte, aber nicht die Struktur, nicht die Beziehungen zwischen Inhalten, nicht die Metadaten.

Bei Sanity liegen deine 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 deiner eigenen Datenbank, du hast die volle Kontrolle. Kein Vendor kann dir den Zugang zu deinen Inhalten verwehren.

Das ist ein fundamentaler Unterschied, der in der Evaluierung oft untergeht — weil er erst dann relevant wird, wenn du wechseln willst oder musst.

Auch beim Frontend gibt es Lock-in-Risiken. Basiert deine Website auf einem proprietären Framework eines Anbieters, bist du von diesem Anbieter abhängig. Bei einem Open-Source-Stack wie Next.js, React und Tailwind gibt es dieses Risiko nicht: Die Tools sind offen, die Community ist riesig, und wenn ein Tool morgen verschwindet, gibt es Alternativen. Ein Luxus, den du mit proprietären Systemen nicht hast.

Wo deine 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 dir die Hosting-Frage ab, dafür zahlst du mit Flexibilität und Kontrolle.

Bei einem Headless-Setup hast du mehr Optionen. Das Frontend kann auf Vercel oder Netlify laufen: mit automatischem Deployment, globalen CDNs und Zero-Config-Skalierung. Oder du hostest 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, sondern um deine 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?

Brauchst du ein einfaches System für eine überschaubare Website? Dann nimm WordPress oder einen Baukasten und investiere das gesparte Budget in Inhalte und Marketing. Das ist eine valide Entscheidung.

Willst du aber eine digitale Plattform bauen, die mitwächst, die sich in deine Systemlandschaft integriert und dir 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 — behandle 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. Nimm dir zwei Wochen für eine strukturierte Evaluation. Definiere deine Anforderungen — nicht nur die heutigen, sondern die in drei Jahren.

Sprich mit deinem Entwicklerteam, nicht nur mit den Redakteuren. Rechne die Total Cost of Ownership über den gesamten Lebenszyklus. Und dann triff eine informierte Entscheidung. Die Technologie ist da — die Frage ist nur, ob du bereit bist, die richtigen Fragen zu stellen.

Du willst diese Systemwahl nicht allein treffen? Als Agentur für Softwareentwicklung in Berlin begleiten wir genau solche Entscheidungen regelmäßig.

Du stehst vor genau dieser Entscheidung und willst eine ehrliche Einschätzung, welcher Ansatz zu deinem Unternehmen passt? Dann lass uns reden: Buch dir ein unverbindliches Erstgespräch. Wir schauen gemeinsam auf deine Anforderungen und finden heraus, ob WordPress, Baukasten oder Headless für dich der richtige Weg ist.