WordPress als Headless CMS: wp-admin bleibt, das Frontend baut Astro.

Headless heißt: WordPress verwaltet weiterhin die Inhalte, erzeugt aber nicht mehr die öffentliche Website. Statt eines Themes holt ein eigenes Frontend – hier Astro – die Inhalte über die Schnittstelle ab und baut daraus die Seiten. Der Kopf, also die Darstellung, wird vom Körper getrennt. Astro dokumentiert diesen Weg in einem eigenen CMS-Guide für WordPress im Headless-Betrieb.

An der täglichen Arbeit fast nichts: gleicher Login, gleiches wp-admin, gleicher Gutenberg-Editor, gleiche Medienbibliothek, gleiche Rollen und Freigaben. Zwei Dinge ändern sich spürbar. Erstens dauert es nach dem Veröffentlichen Minuten statt Sekunden, bis eine Änderung live ist. Zweitens zeigt die Entwurfs-Vorschau auf eine eigens gebaute Vorschau-Route – das muss vorher eingerichtet werden.

Die REST API steckt im WordPress-Kern und ist ohne Installation da; sie reicht für überschaubare Inhaltsmodelle. WPGraphQL kommt als zusätzliches Plugin, holt verschachtelte Daten in einer einzigen Abfrage und stellt ein abfragbares Schema bereit, aus dem sich Typen erzeugen lassen. Bei vielen Inhaltstypen und Beziehungen spart das im Build viel Nacharbeit. Dafür ist es ein Plugin mehr, das gepflegt werden will.

Ja – aber nur, wenn sie gebaut wird. Wir richten eine serverseitig gerenderte Vorschau-Route im Astro-Projekt ein, die den Entwurf authentifiziert aus WordPress holt und ihn durch dieselben Komponenten rendert, die auch der Build nutzt. Dazu kommen ein umgebogener Vorschau-Link in wp-admin und ein Zugriffsschutz. Das ist der aufwendigste Einzelteil eines Headless-Projekts, und wir weisen ihn getrennt aus.

Es kommt darauf an, wo sie arbeiten. Plugins, die nur im Backend wirken – benutzerdefinierte Felder, Workflows, SEO-Metadaten, Übersetzungsverwaltung –, laufen unverändert weiter und liefern ihre Daten über die Schnittstelle. Plugins, die Frontend-Ausgabe erzeugen – Page Builder, Slider, Formulare, Cookie-Banner, Popups –, wirken nicht mehr, weil es kein Theme-Frontend mehr gibt. Jedes davon bekommt bei uns eine Entscheidung: nachbauen, ersetzen oder streichen.

Im statischen Normalfall ja: Ein Webhook stößt beim Veröffentlichen den Build an, der Minuten dauert und im Hintergrund läuft. Die bisherige Fassung bleibt so lange online. Wo das nicht reicht – Preise, Verfügbarkeiten, Termine, Vorschau –, rendern wir einzelne Routen serverseitig mit export const prerender = false und einem passenden Adapter. Beides lässt sich in einem Projekt mischen.

Nicht, wenn sauber gearbeitet wird. Die URL-Struktur kommt aus WordPress und bleibt in aller Regel identisch; wo sie sich ändert, gehört ein Redirect-Konzept dazu. Titel, Descriptions und strukturierte Daten aus Ihrem SEO-Plugin werden ausgelesen und im Astro-Layout gesetzt, Sitemap und Feeds erzeugt danach Astro. Wir messen die Core Web Vitals vor und nach dem Umschalten mit Ihren eigenen Felddaten.

Bleiben Sie, wenn die Seite klein ist, das Team mit einem Page Builder Layouts baut oder niemand die Build-Pipeline betreuen wird. Verlassen Sie WordPress ganz, wenn die Redaktion klein und technisch ist und Sie ein System loswerden wollen – dann sind Content Collections einfacher als jede Schnittstelle. Die beiden Wege beschreiben wir auf Astro vs. WordPress und WordPress zu Astro.

Das Endergebnis, wenn sie richtig gebaut ist. Unsere Vorschau-Route rendert den Entwurf durch dieselben Astro-Komponenten, die auch der Build benutzt: dieselben Layouts, dieselben Blöcke, dasselbe CSS. Anders ist nur die Datenquelle – der unveröffentlichte Entwurf statt des zuletzt gebauten Stands. Eine Vorschau mit eigenen Vorlagen wäre schlimmer als keine, weil sie Vertrauen erzeugt, das sie nicht einlöst.

Ja, beides gehört in den Umfang – und beides wird in Angeboten gern vergessen. Geplante Beiträge liegen in WordPress mit eigenem Status und sind über denselben authentifizierten Abruf erreichbar. Bei Änderungen an bereits veröffentlichten Seiten arbeitet WordPress mit Revisionen: Die Vorschau muss ausdrücklich die neueste Revision holen, nicht den veröffentlichten Stand, sonst sieht die Redaktion ihre eigene Änderung nicht. Wir testen beide Fälle vor der Abnahme.

Vierstellige Beitragszahlen sind Normalbetrieb, brauchen aber Planung. Wir holen die Inhalte seitenweise statt in einer einzigen Riesenantwort und prüfen früh mit Ihrem echten Datenbestand statt mit zehn Testbeiträgen. Wie lange ein Build dann tatsächlich läuft, messen wir im Projekt, statt es vorher zu versprechen. Schlägt ein Build fehl, wird nichts ausgeliefert: Die bisherige Fassung bleibt online, wir bekommen eine Meldung und beheben die Ursache. Eine Ausfallzeit entsteht dabei nicht.

Ja, aber nicht von allein. Felder aus ACF und verwandten Plugins müssen für die Ausgabe freigegeben werden: bei der REST API über die entsprechende Einstellung beziehungsweise die Registrierung des Feldes, bei WPGraphQL über eine Zusatzerweiterung, die die Felder ins Schema hebt. Was nicht freigegeben ist, fehlt still in der Antwort. Deshalb steht in unserer Bestandsaufnahme jede Feldgruppe einzeln – auch Repeater und flexible Inhalte, die im Frontend echte Nachbauarbeit sind.

Die Redaktion arbeitet weiter mit denselben Blöcken, gerendert werden sie nur woanders. Über die Schnittstelle kommt entweder das fertige HTML eines Beitrags oder – sauberer – die Blockstruktur mit ihren Attributen. Wir bauen die Blocktypen, die Sie tatsächlich verwenden, als Astro-Komponenten nach und ordnen sie zu. Der Aufwand hängt an der Zahl der genutzten Blocktypen, nicht an der Zahl der Beiträge. Eigene und wiederverwendbare Blöcke gehen genauso, brauchen aber je eine Entscheidung.

Nicht, wenn sie ausgelesen werden. Beide Plugins arbeiten im Backend und laufen headless normal weiter; Titel, Descriptions, Canonicals, Robots-Anweisungen und Open-Graph-Felder sind über die Schnittstelle erreichbar, bei WPGraphQL über die passende Erweiterung. Diese Felder müssen im Astro-Layout gesetzt werden, sonst greifen Standardwerte und Sie verlieren still gepflegte Metadaten. Sitemap und Feeds erzeugt danach Astro. Wir prüfen das im Staging Seite für Seite gegen den alten Stand, bevor umgeschaltet wird.

In Stufen, je nachdem, wie Ihre Redaktion arbeitet. Üblich sind: wp-admin nur noch über bekannte Netze, VPN oder eine vorgelagerte Basisauthentifizierung, Schreibzugriffe auf die Schnittstelle nur mit Anwendungspasswort oder Token, anonyme Abrufe eingeschränkt, XML-RPC aus, Zwei-Faktor-Anmeldung für alle Redaktionskonten, eigene Subdomain getrennt von der öffentlichen. Was bleibt: Updates und Backups. Eine unsichtbare WordPress-Installation ist noch keine gepflegte.

Ja, und der Schritt ist kleiner, als er klingt. Eine Astro-Komponente ist im Kern HTML mit einem Skriptteil darüber; wer PHP-Templates gebaut hat, findet sich schnell zurecht. Für interaktive Bausteine lässt sich das UI-Framework verwenden, das Ihr Team ohnehin kennt – React, Preact, Svelte, Vue, SolidJS und Alpine.js sind als offizielle Integrationen vorgesehen. Wir übergeben Repository, Dokumentation und eine Einführung und bleiben auf Wunsch Rückfallebene: Astro Support und Wartung.

Dann arbeiten Sie ohne uns weiter. Repository, Hosting-Konten, Domains und die WordPress-Instanz laufen auf Ihren Namen, nicht auf unseren – wir bekommen Zugänge, wir vergeben sie nicht. Das Projekt ist ein gewöhnliches Git-Repository mit Standardwerkzeugen: Astro, Node, ein Hoster Ihrer Wahl. Es gibt keine proprietäre Zwischenschicht, die nur wir bedienen können. Zur Übergabe gehören Dokumentation zum Inhaltsmodell, zur Vorschau-Route und zum Deploy-Weg.

Für das, was wir gebaut haben, haften wir im Rahmen der vertraglich vereinbarten Gewährleistung – und in den ersten Wochen nach dem Umschalten schauen wir ohnehin genauer hin. Davon getrennt ist, was außerhalb unserer Arbeit liegt: ein WordPress- oder Plugin-Update, das eine Schnittstelle verändert, eine Änderung in Ihrer Redaktion, ein Ausfall beim Hoster. Solche Fälle beheben wir im Rahmen der Wartung, aber sie sind kein Gewährleistungsfall. Das steht so im Angebot und nicht im Kleingedruckten.

Ja. Astro ist freie Open-Source-Software unter MIT-Lizenz; für das Framework selbst fallen keine Lizenzkosten an. Kosten entstehen durch Entwicklung, Hosting und Betrieb – im Headless-Fall zusätzlich durch die WordPress-Instanz, die weiterläuft.

Ja. Die REST API ist Teil des WordPress-Kerns, die Endpunkte unter /wp-json/ sind ohne Installation vorhanden. Astro führt WordPress im Headless-Betrieb als eigenen CMS-Guide. Für typisierte Abfragen kommt WPGraphQL als zusätzliches Plugin dazu.

Ein Plugin, das WordPress einen GraphQL-Endpunkt gibt. Statt mehrerer REST-Aufrufe beschreibt eine einzige Abfrage genau die Felder, die eine Seite braucht – über Beitrag, Autor, Taxonomien und benutzerdefinierte Felder hinweg. Das Schema ist abfragbar, Typen lassen sich daraus erzeugen.

In der Regel ja: WordPress läuft weiter auf einem PHP-Hosting, das Astro-Frontend wird als statische Auslieferung über einen Hoster oder ein CDN bereitgestellt. Dafür darf das WordPress-Hosting kleiner ausfallen – es bedient keine Besucher mehr, sondern nur noch Redaktion und Build.

Die Angriffsfläche wird kleiner, weil das öffentlich erreichbare Frontend wegfällt und Besucher statisches HTML bekommen. Sicherer wird es aber erst, wenn die Instanz danach tatsächlich abgeschirmt und weiter aktualisiert wird. Ohne Updates ist auch eine unsichtbare Installation verwundbar.

Bei überschaubarem Inhaltsmodell rechnen wir mit 4–6 Wochen, bei einer typischen Unternehmens-Website mit 7–11 Wochen, bei mehreren Sprachen oder großem Inhaltsmodell ab 12 Wochen. Plugins mit eigenem Frontend werden getrennt geschätzt. Die Variablen stehen im Abschnitt Zeitrahmen.