Die Debatte "WordPress oder Headless" wird gefühlt seit zehn Jahren geführt — und sie ist 2026 spannender denn je, weil sich beide Seiten weiterentwickelt haben. WordPress hat einen Block-Editor und solide REST- und GraphQL-Schnittstellen bekommen. Headless-CMS wie Sanity oder Strapi sind ausgereift und liefern Studios, die für Redakteure brauchbar sind. Statt ideologisch zu wählen, beschreiben wir, wie wir in unserer Agentur-Arbeit konkret entscheiden.
Was "klassisch" und "headless" wirklich unterscheidet
Klassisches WordPress liefert ein komplettes Paket: Backend, Theme-System, Templates, gerenderte HTML-Seiten — alles in einem System. Bei Headless trennt man Backend (Content-Verwaltung) und Frontend (eigene App mit Next.js, Nuxt oder SvelteKit). Beide Ansätze haben das Ziel, Content auf eine Website zu bringen — sie wählen nur einen anderen Weg dorthin.
Wichtig zu wissen: WordPress kann beides. Klassisch (Themes, php-gerendertes HTML) oder headless (WP als Datenquelle via REST oder WPGraphQL, Frontend mit Next.js). Die Wahl ist eine Architektur-Entscheidung, kein Tool-Wechsel.
Wann klassisches WordPress die richtige Wahl ist
Wir nehmen klassisches WordPress, wenn die Redaktion erfahren ist, die Anforderungen Content-getrieben sind und Performance nicht das Top-Argument ist. In dieser Konstellation ist es schwer zu schlagen: Block-Editor, ein riesiges Plugin-Ökosystem, niedrige Hosting-Kosten.
Klassisch-WordPress passt bei:
- Corporate Sites mit klassischem Redaktions-Workflow (Texte, Bilder, Block-Editor)
- Magazinen und Blogs mit hoher Publikations-Frequenz
- Sites, deren Redaktion bereits WordPress kennt und kein Umlernen will
- Projekten mit knappem Budget — klassisches Hosting ist günstig
- Sites mit klassischem Plugin-Bedarf (Forms, Membership, Analytics)
Realistische Grenzen:
- Performance: ohne Caching-Strategie wird WordPress bei mittleren Traffic-Lasten träge
- Frontend-Modernisierung schwer — Theme-System gibt Patterns vor
- Plugin-Hygiene wichtig — 30 Plugins erzeugen 30 Update-Risiken
Wann Headless-CMS die bessere Wahl ist
Headless wird interessant, wenn Frontend-Performance zum Verkaufsargument wird, wenn die Inhalte mehrere Kanäle bedienen müssen (Website + App + Newsletter aus einer Quelle), oder wenn Custom-Datenmodelle das Standard-WordPress sprengen.
Headless passt bei:
- Marketing-Sites mit hohem Performance-Anspruch (Core Web Vitals als SEO-Hebel)
- Multi-Channel-Strategien — Inhalte fließen in Website + App + Newsletter
- Komplexen Datenmodellen mit vielen Beziehungen (Sanity, Strapi mit Custom-Schema)
- Sites, die Teil einer größeren App-Architektur sind
- Strenger Trennung von Content-Team und Frontend-Team
Was man dabei nicht unterschätzen sollte:
- Zwei Systeme bedeuten doppelte Pflege — Updates, Authentifizierung, Hosting für beide Seiten
- Preview- und Draft-Workflows brauchen Setup — kein "Vorschau-Button out of the box"
- Embeds, Forms, Shop-Funktionalitäten muss man selbst integrieren statt einfach ein Plugin zu nutzen
Der Hybrid-Weg: WordPress als Headless
Spannend wird es bei einem oft übersehenen Mittelweg: WordPress als Backend behalten — weil Redaktion das System kennt und liebt — aber das Frontend modern mit Next.js, Nuxt oder SvelteKit bauen. Daten kommen über die WP-REST-API oder über WPGraphQL, das Frontend rendert SSR oder SSG.
Wofür wir Hybrid-WordPress einsetzen:
- Bestandskunden mit WordPress-Redaktion, die ein modernes Frontend wollen
- Performance-getriebene Relaunches ohne Backend-Migrationsschmerz
- Multi-Site-Setups mit zentraler Content-Pflege und mehreren Frontend-Apps
- Projekte, die langfristig in Richtung Headless wollen — Hybrid ist die Brücke
Was Hybrid-Setups brauchen:
- Sauber dokumentierte API-Schicht (REST oder WPGraphQL)
- Caching-Strategie auf Frontend-Seite (ISR mit Next.js, Route-Rules in Nuxt)
- Preview-Modus für Redakteure — sonst frustrierend
- Plugin-Disziplin: weniger ist mehr, alles muss API-tauglich sein
Entscheidung in drei Fragen
Schnell-Check:
- Ist Frontend-Performance ein hartes Verkaufsargument oder SEO-Faktor? — Wenn ja: Headless oder Hybrid.
- Hat die Redaktion WordPress-Erfahrung, die nicht aufgegeben werden soll? — Wenn ja: klassisch oder Hybrid.
- Müssen Inhalte mehrere Kanäle bedienen (Website + App + Newsletter)? — Wenn ja: Headless.
Was wir in der Praxis öfter sehen
In den letzten Jahren ist der Anteil unserer Hybrid-Projekte gewachsen. Der Grund: Es ist der pragmatische Mittelweg. Kunden bekommen die Performance und UX, die sie wollen, ohne dass die Redaktion neu trainiert werden muss. Reines Headless ist bei uns dort am Platz, wo der Kunde mehrere Kanäle hat oder bewusst auf ein Code-getriebenes Schema (Sanity) setzt. Klassisches WordPress bleibt der Standard für Content-Sites, bei denen Redaktion und Pragmatismus über Performance gehen.
Fazit
Die richtige Wahl hängt selten am Tool und fast immer am Team und am Use-Case. Wer als Agentur alle drei Ansätze kennt und ehrlich empfiehlt, statt ein Lieblings-Tool zu pushen, baut die langfristig nachhaltigeren Sites. Bei uns laufen alle drei Varianten — und wir empfehlen offen, was zum jeweiligen Projekt passt.