Headless WordPress: WordPress behalten, Frontend austauschen
WordPress bleibt Redaktionssystem, ein eigenes Frontend holt die Inhalte über WPGraphQL oder die REST-API. Was das löst, was es nicht löst und warum wir diesen Weg nicht mehr bauen.
Headless WordPress heißt: WordPress bleibt Redaktionssystem und Datenbank, die sichtbare Website baut ein eigenes Frontend, das die Inhalte über eine Schnittstelle abruft, meist über WPGraphQL oder die REST-API. Das Theme fällt weg, die Redaktion bleibt. Für Unternehmen mit viel Bestandsinhalt und einer Redaktion, die WordPress gewohnt ist, ist das ein sauberer Zwischenschritt. Für alle anderen ist es ein zweites System, das mitgewartet werden will. Dieser Artikel zeigt den technischen Aufbau, den Vergleich mit klassischem WordPress und einem Headless CMS, was der Umbau löst, was er nicht löst, und wann du besser gleich das Redaktionssystem wechselst.
Das Wichtigste in Kürze
- Headless WordPress trennt Redaktion und Darstellung: WordPress liefert Inhalte über WPGraphQL oder die REST-API, ein eigenes Frontend in Astro oder Next.js rendert daraus die Seiten.
- Du betreibst danach zwei Systeme statt einem. Die WordPress-Installation mit Updates und Angriffsfläche bleibt, dazu kommt ein Frontend mit Build, Deploy und Cache-Logik.
- Der Editor bleibt Gutenberg, und die Vorschau zeigt nicht mehr die Live-Seite. Sanity löst das mit Presentation Mode, WordPress im Headless-Betrieb nicht.
- Plugins, die ins Theme rendern, fallen aus: Formulare, Suche, SEO-Plugins, Caching-Plugins, Page-Builder. Diese Funktionen baust du im Frontend neu.
- Der Tempo-Gewinn kommt vom Frontend, nicht von WordPress. leanwave.com, statisch mit Astro gebaut, lädt auf der Startseite rund 39 KB JavaScript in drei Dateien.
- Unsere Haltung: Headless WordPress ist eine Zwischenlösung, keine Zielarchitektur. Wir bauen sie nicht. Wenn ein Unternehmen WordPress verlässt, gehen wir direkt auf Sanity mit eigenem Frontend.
Die kurze Antwort
Headless WordPress ist eine Betriebsart, bei der WordPress nur noch Redaktionssystem und Datenbank ist. Die Inhalte werden nicht mehr von einem WordPress-Theme in HTML gegossen, sondern über eine Schnittstelle ausgeliefert: über WPGraphQL, ein Plugin, das die Inhalte als GraphQL-Abfrage verfügbar macht, oder über die REST-API, die Schnittstelle, die in WordPress bereits eingebaut ist. Ein eigenes Frontend, gebaut in Astro oder Next.js, holt die Daten dort ab und erzeugt daraus die Seiten. Headless heißt genau das: der Kopf, also die Darstellungsschicht, wird abgetrennt.
Technisch funktioniert das. Die Frage ist, was du dir damit einhandelst. Du betreibst nach dem Umbau zwei Systeme statt einem: die WordPress-Installation mit Updates, Plugin-Abhängigkeiten und Angriffsfläche bleibt stehen, und davor steht ein Frontend mit Build, Deploy und Cache-Logik. Der Teil, der die Arbeit macht, bleibt also genau da, wo er vorher war. Gelöst ist am Ende nur die Ausgabe.
Deshalb bauen wir Headless WordPress nicht. Wenn ein Unternehmen ohnehin ein neues Frontend braucht, ist der Aufwand, die Inhalte gleich nach Sanity zu ziehen, kaum größer als der Umbau auf headless, und danach betreibst du ein System statt zwei. Die Ausnahme sind Installationen, an denen echte Geschäftslogik hängt, etwa WooCommerce. Dazu unten mehr.
Wie Headless WordPress technisch funktioniert
Der Aufbau hat fünf Ebenen. Jede davon kannst du einzeln austauschen, und genau darin liegt der Reiz für Entwicklerteams.
WordPress als Backend
Die Installation läuft weiter auf deinem Hosting, aber kein Besucher ruft sie auf. Redakteure arbeiten in Gutenberg, dem Block-Editor von WordPress. Das Theme rendert nichts mehr, es existiert nur noch als Pflichtdatei im Hintergrund. Die öffentlichen WordPress-URLs werden gesperrt oder umgeleitet, damit nicht zwei Versionen derselben Seite im Index landen.
Die Schnittstelle
Zwei Wege stehen offen. Die REST-API liefert Beiträge, Seiten und Felder als JSON, ein maschinenlesbares Textformat, und ist ohne Zusatz vorhanden. WPGraphQL ist ein Plugin und stellt dieselben Inhalte als GraphQL-Abfrage bereit: du fragst in einem Aufruf genau die Felder ab, die du brauchst, statt mehrere REST-Aufrufe zusammenzubauen. Eigene Feldtypen brauchen dafür eine passende Erweiterung, sonst tauchen sie in der Abfrage nicht auf.
Das Frontend
Hier fällt die Entscheidung, die über das Tempo bestimmt. Astro ist unser Default für Inhaltsseiten: es liefert für statische Inhalte standardmäßig 0 KB JavaScript, nur interaktive Teile, sogenannte Islands, laden Skripte nach. Next.js nimmst du, sobald Login, App-Logik oder Daten pro Anfrage dazukommen. Der Unterschied ist im Detail in Astro oder Next.js auseinandergenommen.
Build und Deploy
Beim Build zieht das Frontend alle Inhalte über die Schnittstelle und schreibt fertige HTML-Dateien, das nennt man statisches Rendering oder SSG. Alternativ rendert der Server bei jeder Anfrage neu, das ist SSR, und ergibt Sinn bei personalisierten oder sehr häufig wechselnden Inhalten. Ausgeliefert wird über ein CDN, ein Netz aus Servern, das die Dateien nah am Besucher vorhält.
Cache-Invalidierung beim Publish
Ohne diesen Schritt sieht die Redaktion ihre Änderung nie. Ein Webhook, also ein automatischer Aufruf, den WordPress beim Speichern auslöst, stößt den Rebuild an. Bei LeanWave läuft genau dieses Muster mit Sanity: Rebuild per Webhook bei jeder Änderung. Bei großen Beständen baust du nicht alles neu, sondern nur die betroffenen Seiten plus die Übersichten, auf denen sie auftauchen.
Der Punkt, an dem Projekte kippen, ist fast immer Punkt fünf. Content-Ebene und Darstellungsebene sind jetzt getrennt, also muss jede Änderung den Weg über den Build finden. Wer das nicht sauber verdrahtet, hat eine Redaktion, die publiziert und dann nichts passieren sieht.
Klassisches WordPress, Headless WordPress und Sanity im Vergleich
Die drei Modelle unterscheiden sich weniger im Funktionsumfang als in der Frage, wo die Arbeit anfällt. Die Tabelle zeigt zehn Kriterien, die in unseren Projekten regelmäßig den Ausschlag geben.
Klassisches WordPress, Headless WordPress und Sanity im Vergleich
| Kriterium | Klassisches WordPress | Headless WordPress | Headless CMS mit Sanity |
|---|---|---|---|
| Editor | Gutenberg, auf das Theme abgestimmt | Gutenberg, ohne Bezug zum Frontend | Sanity Studio, Felder frei modelliert |
| Vorschau | zeigt die spätere Seite | zeigt das Theme, nicht die Live-Seite | Presentation Mode zeigt die echte Seite |
| Rendering | Theme und PHP, Plugin-abhängig | frei wählbar, statisch oder serverseitig | frei wählbar, statisch oder serverseitig |
| JavaScript-Last | hängt an Theme und Plugins | bestimmt allein das Frontend | bestimmt allein das Frontend |
| Plugins | volles Ökosystem nutzbar | nur Plugins, die Daten liefern | keine Plugins, Funktionen im Code |
| Wartung | eine Installation, Updates, Angriffsfläche | eine Installation plus Frontend | gehostetes Redaktionssystem, keine eigene Installation |
| Mehrsprachigkeit | über Plugin | über Plugin, hreflang setzt das Frontend | im Content-Modell angelegt, hreflang aus dem Code |
| Inhalte wiederverwenden | an die eigene Website gebunden | über die Schnittstelle für jeden Kanal | über die Schnittstelle für jeden Kanal |
| Laufende Plattformkosten | Hosting plus Theme- und Plugin-Lizenzen | WordPress-Hosting plus Frontend-Hosting | Sanity Free 0 $ mit 10.000 Dokumenten, Vercel Pro 20 $ pro Platz |
| Systeme im Betrieb | eines | zwei | eines plus Hosting |
hreflang ist die Auszeichnung, mit der du Google sagst, welche Sprachversion zu welchem Markt gehört. Sie muss wechselseitig gesetzt sein, sonst ignoriert Google sie. Im Headless-Betrieb übernimmt das dein Frontend, nicht mehr das Übersetzungs-Plugin, und das ist eher ein Vorteil: du kontrollierst die Ausgabe im Code. Wie wir das in der Praxis lösen, steht in technisches SEO.
Was Headless WordPress löst
Vier Dinge werden mit dem Umbau tatsächlich besser, und sie sind der Grund, warum Teams den Aufwand auf sich nehmen.
- Tempo. Die Ladezeit hängt im klassischen Aufbau an Theme, Page-Builder und der Summe aller Plugins, die ihr JavaScript in die Seite schreiben. Im Headless-Betrieb entscheidest du, was ausgeliefert wird. Zur Einordnung aus unserer eigenen Messung: leanwave.com, das wir statisch mit Astro bauen, lädt auf der Startseite rund 39 KB JavaScript in drei Dateien. Eine unserer Webflow-Kundenseiten lädt an derselben Stelle rund 740 KB in dreizehn Dateien. Der Unterschied kommt nicht vom Redaktionssystem, er kommt vom Frontend.
- Kontrolle über Rendering und Schema. Du legst fest, welche Seite statisch vorgebaut wird und welche der Server pro Anfrage rendert. Strukturierte Daten wie FAQPage-Markup, Canonical-Angaben, also der Hinweis auf die maßgebliche Version einer Seite, und die Sitemap entstehen im Code statt in drei konkurrierenden Plugins. Das ist die Grundlage dafür, in KI-Antworten zitiert zu werden, weil die Modelle strukturierte, schnell ladende Seiten bevorzugt verarbeiten.
- Trennung von Inhalt und Layout. Redakteure schreiben Inhalte, keine Layouts. Wenn das Design sich ändert, ändert sich das Frontend, nicht der Bestand. Wer schon einmal einen Page-Builder abgelöst hat, weiß, wie viel Layout in Beiträgen steckt, das da nicht hingehört.
- Wiederverwendung der Inhalte. Was einmal über die Schnittstelle verfügbar ist, kannst du überall ausspielen: Website, Landingpages, App, ein Partnerportal. Inhalte werden zu Daten statt zu Seiten.
Die ersten beiden Punkte wiegen im B2B am schwersten. Eine Website, die Angebote erklären und Anfragen erzeugen soll, gewinnt durch Ladezeit und saubere Auszeichnung mehr als durch jedes zusätzliche Plugin. Wie wir das aufsetzen, zeigt unsere Webentwicklung.
Was Headless WordPress nicht löst
Der ehrliche Teil, und der Grund, warum wir den Umbau nicht bei jedem Kunden empfehlen. Headless WordPress nimmt dir nichts von dem ab, was an WordPress Arbeit macht.
- Die WordPress-Installation bleibt. Kern-Updates, Plugin-Updates, PHP-Versionen, Backups, Angriffsfläche: alles unverändert. Eine Installation, die aus dem Netz erreichbar sein muss, damit dein Build sie abfragen kann, ist eine Installation, die abgesichert gehört. Der Umbau reduziert die Fläche für Besucher, nicht für Angreifer.
- Der Editor bleibt Gutenberg. Wer mit dem Block-Editor unzufrieden ist, ist es danach immer noch. Felder lassen sich nicht so frei modellieren wie in einem Headless CMS, und die Blöcke bleiben ein Layout-Konzept in einem System, das jetzt keine Layouts mehr rendert.
- Die Vorschau passt nicht mehr. Das ist der Schmerzpunkt im Tagesbetrieb. Die WordPress-Vorschau zeigt das Theme, die Live-Seite zeigt dein Frontend, und beide sehen unterschiedlich aus. Sanity löst genau das mit dem Presentation Mode, in dem die Redaktion links die Felder und rechts die echte Seite sieht. Bei LeanWave läuft das im Tagesbetrieb. Für Headless WordPress musst du eine Vorschau selbst bauen, und sie bleibt eine Nachbildung.
- Viele Plugins funktionieren nicht mehr. Alles, was ins Theme rendert, fällt aus: Formulare, die Suche, SEO-Plugins mit ihren Meta-Ausgaben, Caching-Plugins, Page-Builder wie Elementor oder Divi. Diese Funktionen baust du im Frontend neu oder ersetzt sie durch Dienste. Rechne das in die Projektkosten ein, bevor du dich entscheidest.
- Zwei Systeme statt einem. Zwei Deployments, zwei Update-Zyklen, zwei Fehlerquellen, und im Zweifel zwei Dienstleister. Für ein Team ohne technische Betreuung ist das die eigentliche Hürde, nicht die Technik.
Genau diese Liste ist der Grund, warum viele Projekte, die mit Headless WordPress starten, später doch das Redaktionssystem wechseln. Wenn du ohnehin das Frontend neu baust, ist der Import der Inhalte der kleinere Teil der Arbeit. Die Wege dorthin stehen in WordPress zu Next.js migrieren und in unserem Überblick über WordPress-Alternativen.
Headless WordPress oder direkt ein Headless CMS
Beide Wege enden bei derselben Frontend-Technik. Der Unterschied liegt darin, ob du WordPress als Datenquelle behältst oder die Inhalte einmal umziehst und danach ein System betreibst. Unsere Haltung ist eindeutig: Headless WordPress ist kein Zwischenschritt auf dem Weg irgendwohin, sondern ein Zustand, in dem Projekte hängenbleiben. Der Umbau kostet einmal den vollen Relaunch-Aufwand, und danach hast du die WordPress-Wartung immer noch am Hals, plus eine zweite Betriebsschicht. Wer den Aufwand ohnehin investiert, sollte ihn einmal investieren und bei einem Headless CMS wie Sanity landen, wo Vorschau, Content-Modell und Wartung in einem System liegen.
Der einzige Fall, in dem Headless WordPress trägt
Es gibt eine Konstellation, in der wir jemandem nicht zum vollständigen Wechsel raten würden: wenn an der WordPress-Installation Geschäftslogik hängt, die sich nicht in einem Zug ersetzen lässt.
- WooCommerce oder eine Mitgliederverwaltung trägt Umsatz- oder Zugriffslogik, die im ersten Schritt nicht ersetzt werden kann.
- Eine Schnittstelle in ein anderes System, etwa ein ERP oder eine Kundendatenbank, ist gegen WordPress gebaut und hat einen eigenen Wartungsvertrag.
- In dem Fall ist Headless eine Übergangslösung mit Enddatum, kein Dauerzustand. Ohne Enddatum bleibt es einfach ein zweites System.
Wähle ein Headless CMS, wenn
Diese Punkte sprechen dafür, den Umweg zu überspringen und die Inhalte einmal umzuziehen.
- Die Redaktion soll im Editor sehen, was live steht. Presentation Mode und Visual Editing sind bei Sanity schon im Free-Plan enthalten, zusammen mit 20 Plätzen und 10.000 Dokumenten.
- Du willst Inhalte als Datenbank betreiben und Content-Modell, Templates, Schema, Sitemap und interne Verlinkung im Code steuern, statt sie auf Plugins zu verteilen.
- Mehrsprachigkeit ist geplant oder schon da. Bei uns kostet jede weitere Sprache keinen Aufpreis pro Sprache, Übersetzungs-Plugins in WordPress und Add-ons in Baukästen schon.
- Niemand im Haus will eine WordPress-Installation mit Updates und Sicherheitsfläche weiterbetreiben, nur um Texte zu speichern.
Wenn du zwischen den Frontend-Optionen noch schwankst, ordnet der Vergleich von Webflow, Wix Studio und Next.js die Alternativen ein. Und als grobe Schwelle gilt bei uns cluster-weit: bis etwa 30 Seiten, eine oder zwei Sprachen, keine programmatischen Seiten geplant, dann reicht Webflow und der ganze Umbau erübrigt sich.
Was wir stattdessen machen
Wir bauen keine Headless-WordPress-Setups. Wenn du mit einer WordPress-Website zu uns kommst und ein neues Frontend brauchst, ziehen wir die Inhalte nach Sanity und schalten WordPress ab. Wir behandeln das als Relaunch, weil es einer ist: die URLs ändern sich, das Rendering ändert sich, und die Rankings hängen an beidem. Der Ablauf ist derselbe, den wir bei jeder Migration fahren.
Bestandsaufnahme
Vorher-Crawl mit Screaming Frog oder Ahrefs und ein Ranking-Snapshot. Wir listen jede URL, jedes Template und jede Funktion, die heute ein Plugin übernimmt. Diese Liste entscheidet über den Umfang, nicht das Bauchgefühl.
Inhalte und Content-Modell prüfen
Wir exportieren die Inhalte über WXR oder die REST-API und modellieren sie in Sanity neu. Gewachsene Feldstrukturen werden dabei einmal sauber geordnet, statt sie eins zu eins mitzuschleppen.
Frontend bauen
Astro für Inhaltsseiten, Next.js sobald App-Logik oder serverseitige Daten pro Anfrage nötig sind. Formulare, Suche, Meta-Ausgaben und Sitemap werden im Code gelöst, nicht per Plugin nachgezogen.
Redaktion und Publish-Kette
Sanity Studio mit Presentation Mode, damit die Redaktion im Editor die Live-Seite sieht. Webhook beim Speichern, Rebuild nur der betroffenen Seiten. Diesen Schritt testen wir mit den Leuten, die täglich publizieren.
Launch und Monitoring
Redirect-Map 1:1 für jede alte URL, Launch-Checkliste, Einreichung in Search Console und Bing, IndexNow. Danach zwei Wochen Monitoring mit 404-Report und Ranking-Abgleich.
Zeitlich liegt eine Marketing-Website mit 10-30 Seiten typischerweise bei 3-6 Wochen bis Go-Live, das Monitoring kommt obendrauf. Unsere Relaunch-Pakete starten bei 8.000 € netto. Was in solchen Projekten sonst noch den Preis bewegt, steht in Webentwicklung Kosten, und den Ablauf betreuen wir über unsere Relaunch-Begleitung.
Der Weg dafür ist eingespielt. WXR-Export oder REST-API beziehungsweise WPGraphQL, Transformation der Daten, Import nach Sanity als NDJSON, ein zeilenbasiertes JSON-Format für Massenimporte. Danach steht das Frontend auf einer strukturierten Content-Datenbank, und die WordPress-Installation kann abgeschaltet werden.
Häufige Fragen
Headless WordPress ist ein Aufbau, bei dem WordPress nur noch Redaktionssystem und Datenbank ist. Das Theme rendert die Seiten nicht mehr. Stattdessen holt ein eigenes Frontend, meist Astro oder Next.js, die Inhalte über WPGraphQL oder die eingebaute REST-API und erzeugt daraus die Website. Du betreibst danach zwei Systeme statt einem.
Alle, die ins Theme rendern. Das betrifft Formulare, die Suche, SEO-Plugins mit ihren Meta- und Schema-Ausgaben, Caching-Plugins und Page-Builder wie Elementor oder Divi. Plugins, die nur Daten bereitstellen oder Felder ergänzen, laufen weiter. Plane die Neuentwicklung dieser Funktionen im Frontend von Anfang an ein, sie ist ein echter Projektposten.
In der Regel ja, aber der Gewinn kommt vom Frontend, nicht von WordPress. Astro liefert für statische Inhalte standardmäßig 0 KB JavaScript, nur interaktive Teile laden Skripte. Unsere Messung vom 13.09.2026: leanwave.com lädt auf der Startseite rund 39 KB JavaScript in drei Dateien, eine Webflow-Kundenseite an derselben Stelle rund 740 KB in dreizehn Dateien.
Sie passt nicht mehr zur Live-Seite. Die WordPress-Vorschau rendert das Theme, ausgeliefert wird dein Frontend. Du kannst eine Vorschau nachbauen, sie bleibt aber eine Nachbildung. Sanity löst das mit Presentation Mode, bei dem Redakteure links die Felder und rechts die echte Seite sehen, im Free-Plan enthalten.
Nein. Der Umbau kostet den vollen Relaunch-Aufwand und lässt die WordPress-Wartung trotzdem stehen. Wenn ein neues Frontend gebaut wird, ziehen wir die Inhalte gleich nach Sanity und schalten WordPress ab. Unsere Relaunch-Pakete starten bei 8.000 € netto, eine Marketing-Website mit 10-30 Seiten liegt typischerweise bei 3-6 Wochen bis Go-Live.
Wechsle, außer an der Installation hängt Geschäftslogik wie WooCommerce oder eine Mitgliederverwaltung, die im ersten Schritt nicht ersetzt werden kann. Nur dann ist Headless eine Übergangslösung mit Enddatum. Sonst zahlst du den Umbau einmal und behältst zwei Systeme. Sanity Free deckt 20 Plätze und 10.000 Dokumente ab, der Import läuft über NDJSON.
Nächster Schritt
Schick uns deine WordPress-Website. Wir sagen dir, was der Umzug nach Sanity bei deinem Seitenbestand bedeutet und ob er sich in deinem Fall überhaupt lohnt.
Was ist ein Headless CMS?
Die Grundlagen, Vorteile, Grenzen und sieben Anbieter.
WordPress-Alternative 2026
Was B2B-Unternehmen statt WordPress nutzen.
WordPress oder Next.js
Das direkte Duell in zehn Kriterien, mit klarer Empfehlung.
TYPO3-Relaunch nach Next.js
Ablauf, Kosten und was aus TYPO3 wie übernommen wird.
CMS-Migration: Ablauf und Kosten
Der Überblick über jeden Systemwechsel, system-unabhängig.
