Headless WordPress im B2B-Mittelstand
Headless WordPress trennt Redaktion und Frontend: WordPress verwaltet die Inhalte, ein eigenes Frontend stellt sie dar. Der Schnitt rechnet sich bei wenigen, klar benennbaren Anforderungen und verlangt im Betrieb dauerhaft mehr Aufwand als ein klassisches Setup.
In Relaunch-Workshops fällt der Begriff Headless früh. Die Inhalte liegen weiter in WordPress, das Frontend entsteht in React oder Next.js, dazwischen sitzt eine Schnittstelle. Dahinter stehen meist zwei Erwartungen: schnellere Seiten und mehr gestalterische Freiheit.
Beides erreicht ihr mit Headless, bei vielen Unternehmenswebsites aber auch ohne. Ein sauber gebautes Theme mit gutem Caching besteht die Core Web Vitals, und eigene Gutenberg-Blöcke erlauben Gestaltung jenseits von Vorlagen. Entscheidend ist deshalb, ob euer Projekt etwas verlangt, das nur ein entkoppeltes Frontend leistet.
Was Headless technisch bedeutet
Headless WordPress heißt, dass WordPress nur noch Inhalte verwaltet und ausliefert, während ein eigenständiges Frontend die Darstellung übernimmt. Die Verbindung läuft über die REST-API, die Schnittstelle für strukturierten Datenaustausch zwischen Systemen. Sie gehört seit Version 4.7 aus dem Jahr 2016 zum Core und stellt Beiträge, Seiten, Medien und eigene Inhaltstypen als JSON bereit. Das Frontend, gebaut mit React, Vue oder Next.js, holt diese Daten ab und rendert sie ohne PHP und ohne Theme.
Im klassischen Setup erledigt WordPress beides. Theme und Blöcke bestimmen das Aussehen, die Redaktion sieht im Editor ungefähr das spätere Ergebnis, und zwischen Inhalt und Ausgabe steht kein weiteres System. Welche Variante passt, gehört zu den Grundentscheidungen einer WordPress-Architektur.
Wofür sich die Trennung rechnet
Am stärksten wirkt Headless, wenn ihr dieselben Inhalte mehrfach ausspielt. Stehen Texte auf der Website, in einer App, auf Showroom-Terminals und im Newsletter, spart eine zentrale Quelle echte Redaktionszeit. Dasselbe gilt für Frontends, die eher Anwendung als Website sind: Konfiguratoren, Portale mit Login, Suchen mit vielen Filtern und Zuständen.
Bei Performance-Zielen jenseits von gutem Caching hilft ein entkoppeltes Frontend ebenfalls. Statisch vorgerenderte Seiten über ein CDN auszuliefern, lässt sich dort genauer steuern als über die Renderkette von WordPress. Wer ohnehin ein TypeScript-Team hat und von Anfang an entkoppelt plant, fährt mit Payload CMS oft besser als mit einem nachträglich aufgetrennten WordPress.
Was zwei Systeme im Alltag kosten
Ab dem Tag der Trennung betreibt ihr zwei Anwendungen. Zwei Deployments, zwei Update-Zyklen, zwei Fehlerquellen und eine Schnittstelle dazwischen, die abgesichert und versioniert sein will. Wer bisher ein Plugin installiert hat, um ein Formular oder eine Filtersuche zu bekommen, programmiert diese Funktion künftig selbst.
Am deutlichsten spürt die Redaktion den Unterschied. Der Block-Editor verzahnt Inhalt und Darstellung absichtlich, deshalb verlieren entkoppelte Projekte häufig die Live-Vorschau und die Gestaltungsspielräume, die in den Blöcken stecken. Beim Lernstudio Barbarossa pflegen über 165 Standortleitungen ihre Inhalte selbst, ohne Agentur-Ticket. So ein Setup lebt von dem Editor, den eine Trennung schwächt.
Dafür spricht
- Website, App und weitere Kanäle aus einer Inhaltsquelle
- Frontends mit App-Charakter: Konfiguratoren, Portale, Filtersuchen
- Statisches Rendern und CDN-Auslieferung genauer steuerbar
- Freie Wahl des Frontend-Stacks, ohne Bindung an PHP und Theme
Dagegen spricht
- Zwei Anwendungen mit eigenen Deployments und Update-Zyklen
- Formular, Suche und Vorschau werden zur Eigenentwicklung
- Editor-Komfort geht der Redaktion teilweise verloren
- Dauerhafter Bedarf an Frontend-Kompetenz im Team oder beim Dienstleister
Worauf es bei der Umsetzung ankommt
Fällt die Wahl auf Headless, übernimmt das Frontend Aufgaben, die im klassischen Setup WordPress und seine Plugins erledigen. Vier davon entscheiden, ob Redaktion und Suchmaschinen mit dem neuen Frontend zurechtkommen.
Neue Inhalte ins Frontend bringen
Statisch generierte Seiten laden schnell, zeigen aber nur den Stand des letzten Builds. Veröffentlicht die Redaktion einen Beitrag, benachrichtigt WordPress das Frontend, meist per Webhook, und das Frontend erzeugt die betroffenen Seiten neu. Next.js löst das mit Incremental Static Regeneration und der gezielten Revalidierung einzelner Pfade. Fehlt dieser Mechanismus, erscheinen Änderungen erst beim nächsten vollständigen Build.
Vorschau für Entwürfe einrichten
Die REST-API gibt Entwürfe nur an angemeldete Konten heraus. Für eine Vorschau braucht das Frontend deshalb einen authentifizierten Zugang, etwa über ein Application Password, das WordPress seit Version 5.6 mitbringt. Dazu kommt ein eigener Vorschaumodus, in Next.js heißt er Draft Mode. Ein Filter in WordPress leitet den Vorschau-Button im Editor anschließend auf diese Route um. Plant diese Arbeit ins Angebot ein, sonst sehen Redakteur:innen ihre Seite erst nach dem Veröffentlichen.
SEO-Angaben, Sitemap und Weiterleitungen übertragen
Rank Math und Yoast liefern Title, Meta-Description und strukturierte Daten auch über die REST-API aus. Das Frontend holt diese Angaben ab und schreibt sie selbst in den Head jeder Seite. Weiterleitungen aus dem Redirection-Plugin greifen dagegen nur auf der WordPress-Domain. Im entkoppelten Setup gehören sie in die Frontend-Konfiguration oder ans CDN. Auch die XML-Sitemap braucht eine Anpassung, damit ihre URLs auf die Frontend-Domain zeigen.
Das Backend abschirmen
Rendert das Frontend statisch oder serverseitig, muss das WordPress-Backend nicht mehr öffentlich erreichbar sein. Es kann auf einer eigenen Subdomain hinter einer IP-Freigabe liegen, Besucher:innen sehen nur das Frontend. Die Schnittstelle braucht trotzdem klare Regeln, welche Endpunkte ohne Anmeldung antworten und welche Felder sie preisgeben. Unter /wp-json/wp/v2/users listet WordPress zum Beispiel standardmäßig die Konten aller Autor:innen auf.
Nur einzelne Bereiche entkoppeln
Zwischen klassischem und vollständig entkoppeltem WordPress liegt eine Variante, die für viele Mittelstandsprojekte reicht. WordPress rendert die Website weiter selbst, nur die Bereiche mit App-Charakter laufen als eigene React-Anwendung. Ein Produktkonfigurator oder eine Händlersuche sitzt dann als Block auf der Seite und holt seine Daten über die REST-API. Liegen Produkte oder Standorte per API-Integration aus ERP oder CRM ohnehin in WordPress, nutzt die Anwendung dieselben Daten wie der Rest der Website.
Für kleinere interaktive Bausteine wie Filter, Tabs oder Merklisten reicht oft die Interactivity API, die seit WordPress 6.5 im Core steckt. Sie bringt Zustand und Reaktivität in eigene Blöcke, ohne zweites Frontend und ohne eigenes Deployment.
Die Redaktion behält auf allen übrigen Seiten Editor, Vorschau und Plugins. Frontend-Kompetenz braucht ihr nur für die eine Anwendung. Reicht dieser Zuschnitt später nicht mehr, sind Inhaltsmodell und Schnittstelle schon vorbereitet, und der Schritt zur vollständigen Trennung fällt kleiner aus.
Häufige Fragen vor der Entscheidung
Was ist ein Headless CMS?
Ein Headless CMS verwaltet Inhalte und liefert kein fertiges HTML aus. Die Darstellung übernimmt ein eigenes Frontend, das die Inhalte über eine Schnittstelle abruft, meist als JSON. Der Begriff bezieht sich auf den fehlenden Kopf, also die fehlende Ausgabeschicht. WordPress, Payload CMS und Strapi lassen sich alle so einsetzen.
Kann man WordPress als Headless CMS nutzen?
Ja, technisch ohne Umwege. Die REST-API liefert Beiträge, Seiten, Medien und eigene Inhaltstypen als JSON, WPGraphQL ergänzt eine GraphQL-Schicht. Danach beginnt der Aufwand. Ihr baut, hostet und pflegt das Frontend selbst, und vertraute Plugin-Funktionen fallen weg.
Lässt sich eine bestehende WordPress-Website auf Headless umstellen?
Ja. WordPress läuft als Backend weiter, Inhalte, Medien und Benutzerkonten bleiben erhalten. Das Frontend entsteht dagegen komplett neu, samt Vorschau, SEO-Angaben und Weiterleitungen. Aufwendig wird es bei Seiten aus Page-Buildern wie Elementor, weil diese ihre Inhalte als Layout-Daten speichern, die eng an die Darstellung gebunden sind.
Braucht KI-Sichtbarkeit ein Headless-CMS?
Nein. Für AI Visibility kommt es darauf an, wie eure Inhalte modelliert sind. WordPress mit sauber definierten Custom Post Types, Custom Fields und Schema.org-Auszeichnung erfüllt die Anforderungen genauso wie ein entkoppeltes System. Freitextliche Seiten ohne Struktur sind auch in Payload schwer verwertbar.
Was unterscheidet Headless von klassischem WordPress?
Im klassischen Setup rendert WordPress die Seite selbst, Theme und Blöcke bestimmen die Ausgabe, und die Redaktion sieht im Editor eine Vorschau. Im Headless-Setup liefert WordPress nur Daten, ein separates Frontend erzeugt das HTML. Dieselben Inhalte liegen in beiden Fällen dahinter, verschieden ist der Betrieb.
Was kostet ein Headless-Setup zusätzlich?
Verlässliche Pauschalen gibt es nicht, die Treiber sind aber benennbar. Eine zweite Anwendung mit eigenem Hosting und Deployment, Eigenentwicklung für Formular, Suche und Vorschau, dazu dauerhaft Frontend-Kompetenz im Team oder beim Dienstleister. Diese Posten fallen jedes Jahr an.
Was bedeutet Headless für SEO?
Beides ist beherrschbar, der Aufwand verteilt sich anders. Rank Math oder Yoast liefern Meta-Angaben und strukturierte Daten weiterhin, ausspielen muss sie im entkoppelten Setup aber das Frontend, ebenso Sitemap und Weiterleitungen. Serverseitiges Rendern oder statische Generierung sind Pflicht. Google rendert JavaScript mit Verzögerung, viele KI-Crawler führen es gar nicht aus.
Wer pflegt das Frontend langfristig?
Diese Frage gehört vor den Projektstart. Ein React- oder Next.js-Frontend braucht dauerhaft passende Kompetenz, intern oder beim Dienstleister. Bei Anbindungen wie der onOffice-Schnittstelle von Kampmeyer Immobilien entscheidet außerdem die Datenrichtung stärker über den Aufwand als die Wahl der Frontend-Technologie.
Weitere Fragen dieser Art sammeln wir unter Antworten.
Wovon die Wahl abhängt
Headless beantwortet eine Frontend-Anforderung. Liegt diese Anforderung vor, rechtfertigt sie den Mehraufwand. Fehlt sie, bezahlt ihr Komplexität ohne Gegenwert.
Prüft vor dem Projektstart, welche Kanäle eure Inhalte bedienen und wer das Frontend in drei Jahren noch pflegt. Bei vielen Projekten reicht danach ein klassisches Setup mit einer einzelnen entkoppelten Anwendung. Diese Abwägung treffen wir als WordPress-Agentur seit 2012, inzwischen in über 500 Projekten.
Steht bei euch eine Headless-Entscheidung an?
Beschreibt uns euren Fall. Wir sagen euch, ob die Entkopplung ihren Aufwand wert ist.
