WordPress oder Headless CMS: was ist 2026 richtig?

Die CMS-Debatte ist in zwei Lager verhärtet: WordPress ist Altlast, oder Headless ist Over-Engineering für Leute, die Neues mögen. Beide Positionen sind oft genug falsch, um unbrauchbar zu sein. Die Entscheidung hängt daran, wer die Inhalte pflegt, wie viel das Frontend leisten muss, und ob du zwei Systeme statt einem tragen kannst.

Wo WordPress tatsächlich steht

Im Juli 2026 weist W3Techs WordPress mit 41,2 % aller Websites und 59,1 % aller Seiten mit bekanntem CMS aus — die nächsten Wettbewerber sind Shopify mit 7,6 % und Wix mit 6,1 %. Die installierte Basis ist enorm und wächst absolut weiter, und das Plugin- und Theme-Ökosystem hat nirgends ein echtes Äquivalent.

Das ehrliche Gegenargument: Der Anteil an neu gebauten, entwicklergeführten Projekten sinkt, von unten gedrückt durch Wix und Squarespace, von oben durch Frameworks und Headless-Plattformen. Ein Teil dieses Rückgangs ist auch ein Messartefakt: Eine Headless-WordPress-Seite, die von einem JavaScript-Framework gerendert wird, wird oft überhaupt nicht als WordPress erkannt.

Wofür WordPress weiterhin die beste Antwort ist

Inhaltsstarke Websites, die täglich von nicht-technischen Menschen bearbeitet werden. Nichts in der Headless-Welt kommt an eine ausgereifte WordPress-Redaktion heran, wenn jemand einfach einen Beitrag mit drei Bildern veröffentlichen und live sehen will. Dazu ein großes Ökosystem fertiger Funktionalität, ein tiefer Entwicklerpool in jeder Preisklasse und die niedrigsten Baukosten für eine Standard-Unternehmensseite — unser WordPress-Starterpaket kostet 999 € — und für viele Unternehmen ist die Entscheidung damit gefallen.

Es ist auch die pragmatische Antwort, wenn die Website die Agenturbeziehung überleben muss. Was auch mit deinem Dienstleister passiert: Eine WordPress-Seite kann jemand vor Ort pflegen. Für jeden Stack gilt das nicht.

Was Headless bedeutet — und was es kostet

Headless trennt Inhaltsspeicherung von Darstellung: Das CMS wird eine API, und das Frontend ist eine separate Anwendung — typischerweise Next.js — die daraus liest. Du gewinnst eine deutlich höhere Performance-Obergrenze, Freiheit für jede Oberfläche, denselben Inhalt für Website und App, und eine erheblich kleinere öffentliche Angriffsfläche.

Was du zahlst, wird selten ehrlich besprochen. Zwei Systeme zu hosten, zu deployen und zu überwachen statt einem. Inhaltsvorschau, die gebaut und nicht vorausgesetzt wird. Kein Plugin, das in fünf Minuten ein Kontaktformular hinzufügt — jede Funktion ist Entwicklungsarbeit. Und ein höherer Mindestanspruch an Wartungskompetenz: Es gibt keinen örtlichen Generalisten, der dienstags einen Patch einspielt.

Wie jedes von beidem scheitert

WordPress scheitert durch Anhäufung. Achtundzwanzig Plugins, vier davon verwaist, jedes lädt eigenes CSS und JavaScript auf jeder Seite. Core Web Vitals werden ein Kampf bergauf, die Sicherheitsfläche wächst mit jeder Erweiterung, und irgendwann bricht ein Update das Layout im schlechtesten Moment. Das ist mehr ein Disziplin- als ein Plattformproblem, aber die Plattform macht Undiszipliniertheit sehr leicht.

Headless scheitert durch Reibung. Redakteure sehen nicht, was sie veröffentlichen, also veröffentlichen sie nicht mehr. Eine Textänderung wartet auf ein Deployment. Das Marketing-Team, dem mehr Kontrolle versprochen wurde, hat weniger. Ein technisch exzellenter Headless-Bau, der Inhaltspflege erschwert hat, ist ein gescheitertes Projekt — unabhängig vom Lighthouse-Score.

Headless WordPress: die Option, die man vergisst

Du kannst das WordPress-Backend behalten, das dein Team kennt, und die öffentliche Seite mit einem Framework rendern, das Inhalte über die REST- oder GraphQL-API liest. Redakteure bekommen die gewohnte Oberfläche, Besucher servergerenderte Seiten mit vollständiger Kontrolle über Performance und Markup, und das PHP-Frontend ist nie exponiert.

Kostenlos ist das nicht — du betreibst weiter zwei Systeme, und die Vorschau muss verdrahtet werden — aber es löst den häufigsten echten Konflikt, in dem die Redaktion für WordPress und die Performance-Anforderung dagegen spricht. Für eine inhaltsstarke Seite, die zusätzlich schnell sein muss, ist das häufig die richtige Antwort.

Wie du es mit einer Frage entscheidest

Wer ändert die Inhalte, wie oft, und wie viel muss das Frontend leisten? Marketing-Team, das mehrmals pro Woche auf einer konventionellen Seite veröffentlicht: WordPress. Gelegentliche Aktualisierungen hinter einer stark individuellen Oberfläche, oder Inhalte für mehr als einen Kanal: Headless. Häufiges Veröffentlichen und anspruchsvolles Frontend zusammen: Headless WordPress. Eine Seite, die nach dem Launch niemand bearbeitet: Vielleicht brauchst du überhaupt kein CMS, und eines zu bezahlen ist eine laufende Position ohne Ertrag.

Quellen

Die Marktanteile stammen aus laufend erhobenen Daten, geprüft im Juli 2026.

• W3Techs — Usage statistics of content management systems ↗

  Täglich aktualisiert. WordPress bei 41,2 % aller Websites und 59,1 % der Seiten mit CMS; Shopify 7,6 %, Wix 6,1 %, Squarespace 3,5 %, Joomla 1,7 %.

• HTTP Archive — Web Almanac 2025, CMS-Kapitel ↗

  Echte Core-Web-Vitals-Bestehensquoten auf Mobilgeräten nach Plattform — WordPress bei 45 % gegenüber Duda 85 %, TYPO3 79 % und Wix 74 % — plus das Gewicht, das Page Builder zusätzlich zur Plattform ausliefern.

• Patchstack — State of WordPress Security in 2026 ↗

  11.334 neue Schwachstellen im WordPress-Ökosystem im Jahr 2025, 42 % mehr als 2024, davon 91 % in Plugins und nur 6 Probleme niedriger Priorität im Core — die Wartungskosten, die das Plugin-Ökosystem mitbringt.