WordPress ist nicht immer die richtige Wahl für das Content-Backend – und wir sagen das offen, weil es uns langfristig mehr bringt als Ihnen gegenüber eine Technologie zu bewerben, die nicht optimal passt. Der ehrliche Vergleich mit den anderen CMS-Optionen in unserem Tech Stack gehört zur Beratung dazu.

Wann WordPress Headless die richtige Wahl ist

WordPress Headless funktioniert besonders gut, wenn eine bestehende WordPress-Installation migriert oder erweitert werden soll – das Redaktionswissen und die vorhandenen Inhalte bleiben erhalten, das Frontend wird modernisiert. Es funktioniert ebenso gut, wenn ein Team WordPress bereits kennt und nicht umlernen soll, wenn ein breites Plugin-Ökosystem genutzt werden soll, oder wenn die Kombination aus WordPress und WooCommerce als Headless-Commerce-Backend gefragt ist.

FĂĽr contentgetriebene Websites mit einem klaren Redaktionsteam und hohem Traffic ist WordPress Headless eine ausgereifte, wirtschaftlich attraktive Wahl.

Wann Sanity oder Payload CMS die bessere Alternative sind

Für Projekte, die von Grund auf neu gebaut werden, empfehlen wir häufig Sanity oder Payload CMS. Sanity ist dann interessant, wenn strukturierte Inhalte über mehrere Kanäle ausgespielt werden sollen – Website, App, Newsletter, Digital Signage – und wenn das Inhaltsmodell komplex und mehrsprachig ist. Die Entwicklererfahrung ist moderner als bei WordPress, das Inhaltsmodell flexibler zu gestalten.

Payload CMS ist unsere Wahl, wenn ein CMS eng mit einer NextJS-Applikation verzahnt werden soll und maximale Kontrolle über Datenmodell und Logik gefragt ist. Payload läuft im selben NextJS-Projekt, teilt die Datenbank, braucht keine separate API. Für anspruchsvolle Webanwendungen, die inhaltsverwaltete Bereiche enthalten, ist das oft die elegantere Lösung.

WordPress Headless ist also nicht automatisch das Richtige – aber dort, wo es passt, ist es schwer zu schlagen.

Die Rolle von Supabase in hybriden Architekturen

In Projekten, die neben dem CMS auch Nutzerkonten, Formularverarbeitungen, komplexere Datenstrukturen oder Echtzeit-Funktionen erfordern, ergänzen wir WordPress Headless mit Supabase als Datenschicht. Supabase liefert PostgreSQL-Datenbank, Authentifizierung und Echtzeit-Subscriptions – und lässt sich nahtlos in ein NextJS-Frontend integrieren. Beide Systeme sprechen über APIs mit dem Frontend, ohne voneinander abhängig zu sein. So entsteht eine Architektur, in der WordPress das ist, was es gut kann – Inhalte verwalten – und Supabase das, was WordPress nie gut konnte: strukturierte Geschäftsdaten in Echtzeit verwalten.

DSGVO, digitale Souveränität und warum Hosting-Entscheidungen unterschätzt werden

Klassisches WordPress ist in diesem Punkt oft das geringste Problem – es läuft auf eigener Infrastruktur, die Daten bleiben dort, wo man sie hinstellt. Das Headless-Setup ändert daran grundsätzlich nichts, eröffnet aber Wahlmöglichkeiten, die im klassischen Setup nicht bestehen.

Wo liegt das Frontend?

Headless-Frontends werden häufig auf Plattformen wie Vercel oder Netlify deployt – US-amerikanische Anbieter, die zwar hervorragende Entwicklererfahrungen bieten, aber denselben strukturellen Datenschutzfragen unterliegen wie andere US-Cloud-Dienste. Der Cloud Act ist keine hypothetische Bedrohung; er ist geltendes US-Recht. Für Unternehmen, die Wert auf digitale Souveränität legen, empfehlen wir Deployments auf Hetzner – deutsches Unternehmen, Rechenzentren in Deutschland und Finnland, keine Verbindung zu US-amerikanischen Hyperscalern. Vercel und Netlify bleiben eine Option für Projekte, bei denen Entwicklungsgeschwindigkeit und globale Edge-Performance Priorität haben und die Datenschutzanforderungen weniger streng sind.

Das Backend: WordPress auf kontrollierter Infrastruktur

Das WordPress-Backend läuft bei uns bevorzugt auf Hetzner – oder auf Raidboxes für Projekte, bei denen verwaltetes WordPress-Hosting mit automatischen Updates und professionellem Support sinnvoll ist. Raidboxes ist ein deutsches Unternehmen mit Fokus auf genau diesen Anwendungsfall: sicheres, DSGVO-konformes WordPress-Hosting ohne den operativen Aufwand des Selbstbetriebs. Für Projekte mit strengen Compliance-Anforderungen oder hohem Datenvolumen bevorzugen wir eigene Hetzner-Server mit vollständiger Kontrolle über Konfiguration, Updates und Backup-Prozesse.

Entkopplung als Sicherheitsvorteil

Ein oft übersehener Vorteil des Headless-Setups: Die WordPress-Instanz ist nicht direkt öffentlich zugänglich. Das Frontend kommuniziert über eine API – das WordPress-Admin-Interface ist nicht über die öffentliche URL erreichbar. Das reduziert die Angriffsfläche erheblich. Kein automatisierter Scanner findet das wp-login.php. Kein Brute-Force-Angriff trifft direkt den Kern des Systems. Security-Hardening auf API-Ebene ersetzt die aufwändige Plugin-basierte Absicherung, die klassische WordPress-Setups erfordern.

Make or Buy: Auch bei CMS-Entscheidungen neu zu bewerten

Die Make-or-Buy-Diskussion findet in der Regel auf der Anwendungsebene statt – eigene Software oder Standardlösung. Seltener wird sie auf der CMS-Ebene geführt. Dabei ist sie auch hier relevant.

Was WordPress mitbringt, und was das bedeutet

WordPress hat einen Marktanteil von über 40 Prozent im Web. Das ist kein Zufall und kein Trend – es ist das Ergebnis von zwei Jahrzehnten Weiterentwicklung, einem riesigen Ökosystem und einer Redaktionsoberfläche, die Millionen von Menschen kennen. Die Investition in WordPress-Expertise ist eine Investition in etwas, das bleibt. Das Plugin-Ökosystem spart in vielen Fällen erheblichen Entwicklungsaufwand: Formularverarbeitung, SEO-Konfiguration, Mehrsprachigkeit, Zugriffskontrolle – für all das gibt es ausgereifte Lösungen, die nicht neu entwickelt werden müssen.

Im Headless-Kontext bedeutet das: Das CMS-Backend ist weitgehend fertig. Der Entwicklungsaufwand konzentriert sich auf das Frontend und die Integration – beides sind Bereiche, in denen KI-gestützte Entwicklung heute erhebliche Geschwindigkeitsgewinne ermöglicht. Ein NextJS-Frontend auf Basis einer WordPress-API lässt sich heute wesentlich schneller aufbauen als noch vor drei Jahren, weil ein Großteil der Code-Generierung durch KI-Werkzeuge unterstützt wird.

Wann eine vollständige Individualentwicklung sinnvoller ist

Wenn das, was gebaut werden soll, weit über Content-Management hinausgeht – eigene Benutzerkonten, komplexe Geschäftslogik, Echtzeit-Daten, transaktionale Funktionen –, dann ist WordPress als Backend zu begrenzt, egal ob Headless oder nicht. In diesen Fällen empfehlen wir den Wechsel zu Supabase als Datenschicht und Payload CMS oder gar keinem CMS als Inhaltsschicht. Der Stack wird dann gezielter, aber auch komplexer in der Einrichtung.

Die Entscheidung, die wir gemeinsam mit unseren Kunden treffen, ist nie technologiegetrieben. Sie beginnt immer mit der Frage: Was soll das System in drei Jahren können – und welche Architektur ermöglicht das mit dem geringsten strukturellen Widerstand?

Warum wir auf diesen Stack setzen

1. WordPress als Backend: Reife, die man nicht nachbauen kann

WordPress wird seit 2003 entwickelt. Das Plugin-Ökosystem umfasst zehntausende Erweiterungen, von denen viele über Jahre produktiv eingesetzt und weiterentwickelt wurden. Die Redaktionsoberfläche kennen Millionen von Menschen weltweit. Diese Reife hat einen echten wirtschaftlichen Wert: geringere Einarbeitungszeiten, bewährte Lösungen für häufige Anforderungen, ein breiter Markt an Entwicklern und Support-Anbietern. Für Content-Backend-Aufgaben gibt es wenig, das in dieser Kombination mithalten kann.

2. WPGraphQL: strukturierte Inhalte, sauber abgefragt

REST-APIs liefern mehr Daten als nötig. WPGraphQL ermöglicht präzise Abfragen – das Frontend erhält genau die Felder, die es braucht, in der Struktur, die es erwartet. Das reduziert Ladezeiten, vereinfacht die Datenverarbeitung im Frontend und macht das API-Design explizit statt implizit. Für komplexe Content-Modelle mit Beziehungen zwischen verschiedenen Inhaltstypen ist GraphQL der sauberere Ansatz.

3. NextJS als Frontend: Performance und Flexibilität ohne Kompromiss

NextJS ist nicht deshalb unsere Wahl, weil es gerade modern ist, sondern weil es die richtigen Eigenschaften für langlebige Projekte mitbringt. Serverseitiges Rendering für dynamische Inhalte, statische Generierung für stabile Seiten, Incremental Static Regeneration für Inhalte, die sich häufig aktualisieren – jede Seite bekommt die Rendering-Strategie, die zu ihrem Anwendungsfall passt. Das Ergebnis sind Ladezeiten im Millisekunden-Bereich, Core Web Vitals-Werte, die SEO-Anforderungen erfüllen, und eine Architektur, die unter Last stabil bleibt.

4. Edge-Caching und CDN: der letzte Kilometer

Ein technisch perfektes Frontend bringt wenig, wenn es beim Nutzer langsam ankommt. Wir integrieren Cloudflare oder vergleichbare CDN-Lösungen in unsere Deployments – statische Assets werden weltweit verteilt, dynamische Inhalte intelligent gecacht. Der Unterschied im Nutzererleben ist messbar, besonders auf mobilen Verbindungen und in Märkten außerhalb großer Städte.

5. Self-Hosting wo sinnvoll, Managed Services wo praktisch

Wir betreiben WordPress-Backends bevorzugt auf Hetzner oder Raidboxes – je nach Projektanforderungen. NextJS-Frontends deployen wir auf Hetzner, Vercel oder Netlify. Die Entscheidung hängt von Datenschutzanforderungen, Betriebsmodell und Budget ab. Wir empfehlen, was passt – nicht, was uns die höchste Marge bringt.

6. Erfahrung aus realen Projekten

Wir haben Headless-WordPress-Projekte für Unternehmen unterschiedlicher Branchen und Größen gebaut – von contentgetriebenen Marketing-Plattformen über mehrsprachige internationale Websites bis zu hybriden Setups mit Commerce-Integration. Diese Erfahrung fließt in jede Architekturentscheidung ein.