Die Grundidee
WordPress bleibt, aber nur als Redaktionssystem. Es liefert keine einzige Seite mehr an Besucher aus. Stattdessen holt ein Build-Prozess alle Inhalte über die Schnittstelle ab und erzeugt daraus fertige HTML-Dateien, die auf dem Webspace liegen. Ein Besucher bekommt reine Dateien: kein PHP, keine Datenbankabfrage, keine Angriffsfläche.
Der Anlass war handfest, kein Architektur-Idealismus: Die alte Seite hing an einem selbstgebauten Editor-Baustein der Vorgänger-Agentur. Als WordPress sich weiterentwickelte, brach der, und die Redaktion schrieb plötzlich rohes HTML in die Eingabemasken. Ein System, das bei jedem Update kaputtgehen kann, wollten wir nicht noch einmal bauen.
Das Backend: schlank statt Plugin-Zoo
Die Redaktionsumgebung läuft unter eigener Adresse hinter Passwortschutz. Drin steckt bewusst wenig:
- Das gekaufte Theme als Grundlage, ein kleines Kindtheme darüber. Das Kindtheme schaltet genau die drei Dinge ab, die den alten Ärger verursacht haben, und lässt alles Nützliche stehen: die 38 Seitenvorlagen, die Bildzuschnitte, die Gestaltung der Eingabemasken.
- Fünf eigene Mini-Plugins, jedes mit genau einer Aufgabe: Editor auf Core-Blöcke beschränken (damit kein Update mehr etwas zerlegt), Schnittstellen fürs Frontend bereitstellen, nach jedem Speichern den Neubau anstoßen, den Magazinbereich aufräumen, die Vorschau ermöglichen.
- Das Datenmodell in ACF: 18 Inhaltstypen, rund 230 veröffentlichte Beiträge, 32 Seiten. Fremde Plugins gibt es außer ACF keine mehr.
Das ist die halbe Sicherheits-Geschichte: Jedes Plugin, das nicht installiert ist, kann weder brechen noch gehackt werden.
Die Schnittstelle und ihre stillen Lücken
Das Frontend liest über die REST-Schnittstelle von WordPress, ergänzt um eigene Endpunkte für Website-Einstellungen und Menüs. Dazu eigene Felder für Dinge, die WordPress nicht sauber herausgibt: das Beitragsbild (WordPress verweigert Bilder, die einmal in einem Entwurf hochgeladen wurden), die Bildrechte, die Downloads und die Bilder im Fließtext.
Genau hier lagen die meisten Fehler des Projekts, und das ist die wichtigste Warnung für Nachahmer: Die REST-API liefert scheinbar alles, verschweigt aber im Einzelfall etwas, ohne zu meckern. Kein Fehlercode, kein Hinweis, einfach ein leeres Feld. Wer Headless baut, braucht deshalb Prüfungen auf der Frontend-Seite, die fehlende Pflichtdaten laut machen, statt still leere Seiten zu bauen.
Das Frontend: Astro und die Volltextsuche im Browser
Gebaut ist das Frontend mit Astro, dem derzeit am schnellsten wachsenden Framework für solche Projekte, weil es standardmäßig null JavaScript ausliefert. Jede Theme-Vorlage der alten Seite wurde als Komponente nachgebaut, mit demselben Markup und denselben Klassen, weil die Stylesheets daran hängen. Die Stylesheets sind unverändert übernommen; das Verhalten (Menü, Blättern, Galerie, Downloads) ist neu geschrieben, ohne die schwergewichtige Animationsbibliothek der alten Seite.
Ein Build-Lauf holt alle Inhalte und erzeugt 1.380 Seiten in etwa 46 Sekunden, darunter 813 Seiten Altarchiv aus dem früheren System, die als Dateien mitgeführt werden. Eine statische Seite hat keinen Server, der Suchanfragen beantworten könnte, also läuft die Suchfunktion andersherum: Der Build erzeugt aus allen Inhalten eine Indexdatei von rund 850 KB, etwa so groß wie ein einzelnes Foto. Beim ersten Tippen ins Suchfeld lädt der Browser diese Datei einmal und durchsucht sie danach lokal per JavaScript, mit Treffern in Millisekunden. Der Nebeneffekt ist ein echter Vorteil: Kein Suchbegriff verlässt das Gerät, es braucht keinen Suchdienst und keine Einwilligung. Die Grenze ist absehbar, aber weit weg: Der Index wächst mit den Inhalten, und erst bei einem Vielfachen der heutigen Seitenzahl würde man auf einen ausgelagerten Suchdienst wechseln.
Die Plugin-Route: Headless ohne Eigenbau
Nicht jedes Projekt braucht eigene Endpunkte und einen maßgeschneiderten Build. Für den Einstieg gibt es einen etablierten Werkzeugkasten:
- WPGraphQL macht aus WordPress eine GraphQL-Schnittstelle, inklusive eingebauter Abfrage-Oberfläche zum Testen. Der praktische Vorteil gegenüber REST: Man fragt explizit die Felder ab, die man braucht, und merkt dadurch schneller, wenn eines leer bleibt. Das Ökosystem (Apollo, Next.js, Gatsby) ist das größte im Headless-WordPress-Umfeld.
- Faust.js, das offizielle Framework von WP Engine, bringt fertige Lösungen für die zwei härtesten Nüsse mit: Authentifizierung und die Redaktions-Vorschau, für die wir unseren Einmal-Schlüssel-Build gebaut haben.
- CoCart ergänzt WooCommerce um Warenkorb-Endpunkte, falls ein Shop headless werden soll.
- Statik-Export-Plugins wie Simply Static erzeugen HTML-Dateien direkt aus WordPress heraus, ganz ohne eigenes Frontend. Der günstigste Einstieg in „statisch ausliefern", allerdings mit dem alten Theme samt seiner Altlasten.
Eine Warnung aus aktuellem Anlass: Ältere Tutorials (auch das viel verlinkte von Hostinger) empfehlen noch Frontity. Dessen Entwicklung ist seit Jahren eingestellt, das Team ist zu Automattic gewechselt. Wer heute darauf aufsetzt, baut auf einem verlassenen Fundament, und genau diese Sorte Abhängigkeit war ja der Anlass unseres Projekts. Die zeitgemäße Alternative ist ein aktiv gepflegtes, leichtgewichtiges Framework wie Astro oder Next.js, also genau der Aufbau aus diesem Bericht. Solche Frontends bauen wir als Agentur komplett selbst: Datenmodell, Schnittstellen, Build-Pipeline und Betrieb.
Unsere Einordnung: Die Plugin-Route senkt die Einstiegskosten deutlich und reicht für viele Projekte. Wir haben uns für den Eigenbau entschieden, weil drei Anforderungen sie sprengten: das pixelgenaue Nachbauen der 38 Bestandsvorlagen, die Vorschau mit exakt denselben Templates und die nächtliche Neuberechnung ablaufender Termine. Wer diese Sonderfälle nicht hat, fährt mit WPGraphQL plus Faust.js oder einem Statik-Export schneller und günstiger.
Bauen und Veröffentlichen
Gebaut wird bei GitHub, nicht auf dem Webspace. Vier Auslöser: Speichern im Backend, ein nächtlicher Lauf, ein Knopf für die Hand-Auslösung und jede Änderung am Quelltext. Das Ergebnis geht per rsync auf den Webspace. Zwei Schutzvorrichtungen haben sich als notwendig erwiesen, beide durch Schmerz gelernt:
- Eine Mindestzahl an Seiten. Ein Netzwerkfehler beim Bauen kann einen halb fertigen, formal erfolgreichen Build liefern. Ohne die Untergrenze hätte genau so ein Build einmal die Website geleert.
- Regeln, was beim Aufräumen stehen bleiben muss. An dieser Stelle ist das Altarchiv wochenlang ohne Gestaltung ausgeliefert worden, weil der Sync dessen Assets als „nicht mehr gebraucht" entsorgt hatte.
Der nächtliche Lauf ist kein Luxus: Die alte Seite prüfte bei jedem Aufruf, ob eine Veranstaltung vorbei ist. Eine statische Seite kennt nur den Stand ihres letzten Builds, also muss sie einmal am Tag nachrechnen. Das ist das Grundmuster von Headless: Alles, was früher zur Laufzeit passierte, braucht einen neuen Ort.
Die Vorschau-Frage
Redaktionen brauchen eine Vorschau, und bei statischen Seiten ist das die konzeptionell härteste Nuss. Unsere Lösung: Der Vorschau-Knopf im Editor erzeugt einen geheimen Einmal-Schlüssel und stößt einen eigenen Build an. Der holt den Entwurf über diesen Schlüssel, baut ihn mit denselben Vorlagen wie alles andere und legt genau diese eine Seite unter einer unrateabaren Adresse ab. Eine separate Vorschau-Ansicht wäre der falsche Weg: Sie sähe über kurz oder lang anders aus als die Website, und dann wäre sie wertlos.
Prüfen im echten Browser
Der Teil, den wir unterschätzt hatten und der am meisten gebracht hat. Nach zwei Runden Rückläufern vom Kunden haben wir aufgehört, HTML zu vergleichen, und prüfen seither im echten Browser: Screenshots beider Seiten nebeneinander, gemessene Abstände und Breiten, tatsächlich angeklickte Knöpfe. Dazu eine Abnahmeliste mit inzwischen 46 Prüfungen, die jede gemeldete Korrektur an der ausgelieferten Datei nachweist.
Die Erkenntnis dahinter gilt weit über dieses Projekt hinaus: Die meisten Fehler waren im HTML gar nicht zu sehen. Sie entstanden erst im Zusammenspiel von CSS, Schriften und JavaScript, oder das Prüfwerkzeug selbst hat unbemerkt nichts geprüft. Wer nur Quelltext vergleicht, testet die Baupläne, nicht das Haus. Nach demselben Prinzip verifizieren wir übrigens auch unsere eigene Website und jedes Tracking-Setup: im gerenderten Browser, nicht in der Theorie.
Bilanz: was es bringt, wo die Grenzen sind
Die Seite ist schnell und praktisch unangreifbar, weil auf dem Webserver kein Programm läuft. Sie lädt nichts von fremden Servern, setzt keine Cookies und kommt deshalb ohne Einwilligungsbanner aus. Ein WordPress-Update kann die öffentliche Seite nicht mehr beschädigen; schlimmstenfalls steht das Backend still, und die Website läuft weiter. Die Redaktion behält ihre vertraute Oberfläche.
Die Grenzen gehören genauso auf den Tisch: Alles, was normalerweise beim Seitenaufruf passiert, muss anders gelöst werden. Ablaufende Termine über den nächtlichen Lauf, die Volltextsuche im Browser, die Vorschau über einen eigenen Build. Änderungen sind nicht sofort sichtbar, sondern nach ein bis zwei Minuten. Und der Aufbau kostet anfangs mehr Entwicklungszeit als ein klassisches Theme; Headless lohnt sich, wenn Stabilität, Sicherheit und Tempo über Jahre wichtiger sind als der günstigste Start. Für eine Fünf-Seiten-Firmenseite wäre es Overkill, das sagen wir auch so. Wie wir solche Entscheidungen abwägen, steht auf unserer Seite zu Webtechnik & WebOps; gebaut wird so etwas bei uns als individuelle Programmierung.
Wohin sich WordPress entwickelt
Man könnte meinen, wer WordPress auf die Redaktion reduziert, wette gegen WordPress. Das Gegenteil ist gerade der Fall. Seit 2025 baut das eigens gegründete WordPress-AI-Team an offiziellen KI-Bausteinen, und die Richtung stärkt genau das Backend-Szenario:
- Abilities API (seit WordPress 6.9 im Core): Funktionen einer Site werden als typisierte, auffindbare „Fähigkeiten" registriert, mit Eingabe- und Ausgabe-Schema und Rechteprüfung.
- Offizieller MCP-Adapter (seit Februar 2026): Er verbindet diese Fähigkeiten mit dem Model Context Protocol, sodass KI-Assistenten wie Claude oder ChatGPT Inhalte anlegen und Aufgaben ausführen können, über einen Standard statt über Bastel-Integrationen.
- Roadmap bis 7.2 (Dezember 2026): wiederverwendbarer Site-Kontext für KI-Funktionen und Embedding-Unterstützung für semantische Suche auf den eigenen Inhalten.
Für Headless-Setups heißt das: Das Redaktionssystem, das ohnehin nur noch Inhalte verwaltet, wird zur sauberen Andockstelle für KI-Werkzeuge, während die ausgelieferte Website davon komplett unberührt bleibt. Und die Verbreitung zieht an: Laut einer Analyse des Hosters HostPress laufen bereits rund 8 Prozent der WordPress-Installationen headless. Redaktion mit KI-Unterstützung im Backend, statisches HTML ohne einen einzigen Skript-Anbieter im Frontend: Diese Trennung wird eher wertvoller. Wer dagegen Interaktivität zur Laufzeit braucht (Shops, Portale, personalisierte Inhalte), fährt mit klassischem oder hybridem WordPress weiter richtig; der Markt sortiert sich 2026 sichtbar in genau diese Lager.
Wenn ihr vor der Frage steht, ob eure WordPress-Seite ein Rebuild, ein Headless-Umbau oder nur eine gründliche Aufräumaktion braucht: Wir bauen und betreiben seit 2010 Websites als Agentur und sagen im Erstgespräch ehrlich, welcher der drei Wege zu Budget und Team passt. Die Umsetzung übernehmen wir auf Wunsch komplett, vom Datenmodell über die Build-Pipeline bis zur Browser-Abnahme.
FAQ
Warum WordPress behalten, wenn die Seite statisch wird?
Weil die Redaktion es kennt und das Datenmodell dort gepflegt wird. Headless tauscht nur die Auslieferung, nicht die Eingabemaske. Mit Abilities API und MCP wird das Backend zudem gerade KI-fähig.
Kann ein WordPress-Update die Website noch kaputt machen?
Die öffentliche Seite nicht. Schlimmstenfalls steht das Backend still, die statischen Dateien laufen weiter.
Wie schnell sind Änderungen live?
Ein bis zwei Minuten nach dem Speichern. Für Minutentakt-News zu langsam, für die meisten Sites egal.
Braucht die Seite noch ein Cookie-Banner?
In diesem Aufbau nicht: keine fremden Server, keine Cookies, Volltextsuche lokal im Browser. Erst mit Analytics oder Einbettungen gilt wieder Consent-Pflicht.