Headless WordPress oder klassisch: Wann sich der Aufwand wirklich lohnt

Headless WordPress ist eines der meistdiskutierten Themen in der WordPress-Entwicklung der letzten Jahre. Der Begriff klingt modern, die Versprechen klingen verlockend: maximale Performance, totale Freiheit beim Frontend, Inhalte auf allen Kanälen gleichzeitig. Ich arbeite seit 13 Jahren mit WordPress und habe in dieser Zeit einige Headless-Projekte begleitet - und noch mehr Projekte, bei denen Kunden anfangs von Headless überzeugt waren und am Ende bei klassischem WordPress geblieben sind.

Dieser Artikel ist kein Tutorial. Es geht um eine ehrliche Einschätzung: Wann macht Headless WordPress tatsächlich Sinn, wann bringt es nur Komplexität ohne echten Mehrwert, und was sollten Sie beim Vergleich wirklich beachten?

Was Headless WordPress bedeutet

Bei einer klassischen WordPress-Installation sind Backend und Frontend eng verzahnt. WordPress verwaltet die Inhalte, rendert die Seiten per PHP und liefert fertig zusammengebautes HTML an den Browser. Theme, Templates und Plugins greifen direkt auf die WordPress-Funktionen zu.

Bei Headless WordPress bleibt nur das Backend: WordPress dient als Content-Repository mit Redaktionsoberfläche. Das Frontend ist ein eigenständiges Projekt, meistens in React oder Next.js, das die Inhalte über die WordPress REST API oder WPGraphQL abruft und selbst rendert. Die zwei Systeme laufen getrennt, kommunizieren über API-Anfragen und werden separat deployed.

Die ehrliche Kostenfrage

Ein klassisches WordPress-Projekt für eine Unternehmenswebseite kostet bei einer deutschen Agentur je nach Umfang zwischen 3.500 und 20.000 Euro. Bei einem vergleichbaren Headless-Projekt rechnen erfahrene Teams mit dem Drei- bis Fünffachen dieses Betrags.

Der Grund: Sie entwickeln nicht ein, sondern zwei vollständige Systeme. Das WordPress-Backend muss konfiguriert, abgesichert und gepflegt werden. Das React-Frontend muss aufgebaut, mit einer Deploy-Pipeline versorgt, auf Vercel oder Netlify gehostet und ebenfalls gewartet werden. Beide Systeme müssen zuverlässig miteinander kommunizieren, und Fehler an der API-Schnittstelle können die ganze Webseite lahmlegen.

Dazu kommen laufende Hosting-Kosten für zwei Infrastrukturen: WordPress-Hosting plus Frontend-Hosting. Wer auf Vercel im kostenlosen Tier bleibt, stößt bei Unternehmensanforderungen schnell an Grenzen.

Was Headless tatsächlich besser kann

Es gibt klare Szenarien, in denen Headless WordPress einen echten Vorteil bietet.

Mehrkanal-Ausgabe: Wenn Sie dieselben Inhalte gleichzeitig auf einer Website, in einer nativen App, auf Digital-Signage-Systemen und vielleicht noch in einem Newsletter-Tool ausspielen, macht eine zentrale Content-API Sinn. WordPress als Headless CMS ist dann die Content-Drehscheibe, und jeder Kanal konsumiert die Daten nach eigenen Bedürfnissen.

Hochkomplexe Frontend-Interaktionen: Ein stark interaktiver Web-App-Bereich - denken Sie an Konfiguratoren, Buchungssysteme oder datenintensive Dashboards - lässt sich mit einem React-Frontend sauberer umsetzen als mit WordPress-Templates plus JavaScript-Overlay.

Extreme Performance-Ziele mit Static Generation: Wenn Next.js zur Build-Zeit statische HTML-Dateien aus Ihren WordPress-Inhalten generiert und diese über ein CDN ausliefert, erreichen Sie Ladezeiten, die mit klassischem PHP-Rendering kaum erreichbar sind. Das ist relevant für sehr trafficstarke Seiten mit wenig dynamischen Inhalten.

Was Headless schlechter kann - die ehrliche Liste

Hier wird es selten so klar kommuniziert. Headless WordPress hat erhebliche Einschränkungen, die im Alltag schmerzen.

Gutenberg-Blöcke sind das größte Problem. WordPress-Core liefert keine vollständige Server-Registry aller Blöcke. CSS-Styles aus dem Editor landen teilweise als Inline-Stile, teilweise in separaten Stylesheets. Im Headless-Frontend müssen Sie diese Styles manuell einbinden und die Block-Struktur im React-Code nachbauen. Interne Links aus Gutenberg-Blöcken zeigen noch auf die WordPress-Domain - das erfordert zusätzliche Parser-Logik.

Live-Preview funktioniert nicht out-of-the-box. Redakteure sind gewohnt, im Editor sofort zu sehen, wie die Seite aussieht. Im Headless-Betrieb muss Preview über einen separaten Preview-Mode im Next.js-Frontend implementiert werden. Das ist lösbar, aber mit Aufwand verbunden.

Plugin-Ökosystem schrumpft. Viele WordPress-Plugins, die hervorragende Funktionen bieten, funktionieren im Headless-Kontext nicht oder nur teilweise. WooCommerce, Contact Form 7, WP Rocket, WPML - diese Plugins sind auf klassisches Rendering ausgelegt. Headless-Alternativen existieren, müssen aber evaluiert und oft neu implementiert werden.

Ein Blick aus der Praxis

Bei einem Projekt für einen Hamburger Bildungsanbieter kam anfangs der Wunsch nach Headless auf den Tisch. Die Begründung: bessere Performance und eine mögliche App in der Zukunft. Nach einer Bestandsaufnahme stellte sich heraus, dass die Webseite rund 80 Seiten hatte, keine App konkret geplant war, und das Team keine React-Erfahrung hatte.

Statt Headless haben wir klassisches WordPress mit LiteSpeed-Cache, einem sauber optimierten Custom-Theme und Rank Math für SEO aufgebaut. Die Core Web Vitals lagen nach dem Launch im grünen Bereich, die Entwicklungszeit betrug sechs Wochen statt der für Headless kalkulierten fünf Monate, und das Team kann Inhalte eigenständig pflegen.

Ein anderes Projekt zeigt, wann Headless richtig ist: Ein Verlag mit mehrsprachigem Content, der sowohl auf der Website als auch in einer bestehenden iOS-App ausgespielt werden sollte. Hier hat sich der Aufwand klar gelohnt, weil die API von Anfang an für zwei Frontends genutzt werden konnte und das Entwicklerteam des Verlags bereits mit React arbeitete.

Klassisches WordPress: Was oft unterschätzt wird

Modernes klassisches WordPress ist nicht das träge System von vor zehn Jahren. Mit PHP 8.3, einem HTTP/2-fähigen Hosting, LiteSpeed oder nginx, Objekt-Cache (Redis) und einem CDN vor dem Server erreichen Sie Ladezeiten, die in der Praxis für die allermeisten Unternehmenswebseiten ausreichen.

Die Core Web Vitals - LCP, INP, CLS - lassen sich mit klassischem WordPress gut optimieren, wenn das Theme sauber gebaut ist und unkritische Ressourcen korrekt verzögert laden. Ich sehe in meiner täglichen Arbeit viele klassische WordPress-Seiten mit PageSpeed-Scores über 90, wenn die Grundlagen stimmen.

Für Unternehmen in Deutschland, die eine Firmenwebseite professionell umsetzen lassen wollen, ist klassisches WordPress in den meisten Fällen die pragmatischere, kostengünstigere und wartungsfreundlichere Wahl.

Wann ich Headless WordPress empfehle

Nach 13 Jahren und mehr als 120 Projekten ist meine Empfehlung klar: Headless WordPress ist eine ausgezeichnete Wahl, wenn drei Bedingungen gleichzeitig zutreffen.

Erstens muss ein konkreter Mehrkanal-Bedarf bestehen, nicht nur theoretisch. Wenn heute schon eine App existiert oder konkret geplant ist, die denselben Content-Pool nutzt, ist Headless der richtige Weg.

Zweitens muss das Projekt-Budget und der Zeithorizont den Aufwand decken. Zwei Systeme zu bauen, zu deployen und langfristig zu pflegen kostet signifikant mehr als ein System.

Drittens muss das technische Know-how vorhanden sein. Das bedeutet entweder interne React-Entwickler oder eine langfristige Agenturbeziehung, die Headless-Projekte aktiv betreut. Eine Headless-Webseite, die nach dem Launch niemand anfassen kann, ist ein teures Problem.

Für alle anderen Fälle - und das ist die große Mehrheit der kleinen und mittleren Unternehmen in Deutschland, die ich betreue - ist klassisches WordPress mit sauberem Theme, aktivem Caching und gutem Hosting die richtige Entscheidung. Wenn Sie unsicher sind, welche Architektur für Ihr Projekt passt, helfe ich Ihnen bei der Planung Ihrer Webseite gerne weiter.

Die technische Umsetzung: Kurzer Überblick

Für den Fall, dass Headless für Ihr Projekt tatsächlich die richtige Wahl ist, hier die gängigen Kombinationen aus der Praxis:

Next.js + WPGraphQL ist aktuell die meistgenutzte Kombination. WPGraphQL ermöglicht präzise Abfragen über einen einzelnen Endpunkt (/graphql), Next.js nutzt Server Components und Static Generation. Deployment auf Vercel oder Cloudflare Pages.

Astro + WordPress REST API ist eine gute Option für primär inhaltsorientierte Seiten ohne viel Interaktivität. Astro baut standardmäßig minimales JavaScript, die Seiten sind extrem leicht.

React Single Page Application + REST API sollte für öffentliche Webseiten vermieden werden. SEO ist ohne Server-Side Rendering erheblich schwieriger, und der Initialaufbau ist langsamer.

Für den technischen Aufbau des WordPress-Backends empfehle ich: ACF Pro für Custom Fields (kompatibel mit WPGraphQL), strikte Berechtigungen (REST API nur für notwendige Endpoints öffentlich), separate Staging-Umgebung für Content-Änderungen, und regelmäßige Backups beider Systeme.