Headless WordPress — und wann es die falsche Antwort ist.

Das Prinzip.

Klassisch erledigt WordPress beides: Inhalte verwalten und Seiten ausliefern. Entkoppelt macht es nur noch das Erste. Die Inhalte werden über eine Schnittstelle abgerufen, und ein eigenständiges Programm — meist Next.js — baut daraus die Seiten, entweder beim Veröffentlichen oder beim Aufruf.

Für die Redaktion ändert sich wenig: Sie arbeitet weiter in WordPress. Was sich ändert, liegt dahinter — Theme, Darstellungs-Plugins, Vorschau, Suche, Sitemap. Das wird alles neu gebaut (Headless erklärt).

Die ehrliche Einordnung.

Von zehn Anfragen, bei denen jemand headless möchte, ist es bei etwa zwei die richtige Antwort. Bei den anderen acht lautet das eigentliche Ziel „die Seite soll schneller werden“ — und das erreicht man mit Caching, vernünftigen Bildern, weniger Plugins und ordentlichem Hosting für einen Bruchteil (Ladezeit optimieren).

Das sage ich, obwohl ich mit dem teureren Weg mehr verdienen würde. Ein Projekt, das nach zwei Jahren niemand mehr pflegen kann, nützt uns beiden nichts — und genau das ist die Frage, die in Angeboten am seltensten vorkommt.

Wann es passt.

Zeile vier ist keine Empfehlung, sondern eine Bedingung. Ohne jemanden, der Code anfassen kann, wird aus jeder kleinen Änderung ein beauftragter Vorgang — und aus einer liegengebliebenen Aktualisierung nach zwei Jahren ein Projekt (Ausführliche Abwägung).

Wie der Aufbau aussieht.

• WordPress auf einer eigenen Adresse, abgeschirmt, nicht indexierbar.
• Schnittstelle — die eingebaute REST-Variante oder GraphQL per Plugin (REST oder GraphQL).
• Next.js baut die Seiten, je Seitentyp statisch oder beim Aufruf.
• Bauprozess, der bei Änderungen nur die betroffenen Seiten erneuert.
• Vorschau über einen Entwurfsmodus im Frontend.
• Überwachung, die meldet, wenn ein Bauvorgang scheitert.

Punkt vier und sechs trennen eine saubere von einer schlechten Umsetzung. Wird bei jedem gespeicherten Beitrag alles neu gebaut, dauert eine Tippfehlerkorrektur bei einer großen Website zwanzig Minuten. Und ein gescheiterter Bauvorgang lässt die alte Fassung online — es sieht alles normal aus, aber nichts Neues erscheint (Aufbau in der Praxis, Betrieb).

Wo die Arbeit steckt.

Nicht in der Verbindung — die steht an einem Tag. Die Arbeit steckt in allem, was WordPress vorher nebenbei erledigt hat:

Die letzte Zeile wird am häufigsten unterschätzt. Wer der Redaktion dreißig Blocktypen erlaubt, baut dreißig Darstellungen. Acht gut gemachte sind meist die bessere Entscheidung — günstiger und mit einheitlicherem Ergebnis.

Was es kostet.

Ich nenne hier keine Pauschale, weil die Spanne zu groß ist — zwischen einem abgegrenzten Bereich und einer Plattform mit mehreren tausend Seiten liegt ein Vielfaches. Was ich sagen kann, ist der Rechenweg.

Nimm den Aufwand für ein individuelles Theme deiner Website als Grundlage. Rechne die Posten aus der Tabelle oben dazu, die klassisch entfallen würden. Und dann — das wird am häufigsten vergessen — den laufenden Pflegeaufwand über fünf Jahre: Abhängigkeiten aktuell halten, Versionssprünge des Frameworks, zwei Systeme statt einem (Kosten und Aufwand).

Alle Anleitungen.

Die fünf häufigsten Fehler.

1. Die Vorschau nicht eingeplant. Die Redaktion arbeitet im Blindflug und lehnt den neuen Aufbau ab — zu Recht. Nachträglich eingebaut kostet es mehr (Vorschau).
2. WordPress bleibt öffentlich erreichbar. Dann steht die Website doppelt im Index.
3. Die Sperre für Suchmaschinen nach dem Start nicht entfernt. Wochenlang wird nichts indexiert — der teuerste Einzelfehler überhaupt.
4. Weiterleitungen nicht übernommen. Alte Adressen laufen ins Leere, Sichtbarkeit geht verloren (SEO).
5. Keine Überwachung des Bauprozesses. Ein Fehlschlag bleibt unbemerkt, und nach drei Wochen fällt auf, dass nichts mehr live geht.

Der Mittelweg.

Die Lösung, die ich am häufigsten empfehle und die zu selten erwogen wird: Die Website bleibt klassisch, und nur ein Bereich wird entkoppelt oder als eigenständige Anwendung gebaut — ein Konfigurator, ein Rechner, eine interaktive Darstellung, der Blog.

Man bekommt die Freiheit dort, wo man sie braucht, behält den Rest einfach und wartbar, und das Risiko ist überschaubar. Bei einem Shop ist das fast immer die richtige Antwort: Katalog und Inhalte entkoppelt, der Bestellprozess klassisch — dort, wo Geld und Recht hängen, ändert man nichts ohne Not (Shop headless, Anwendung einbinden).

Wie ich arbeite.

1. Gespräch über das Ziel, nicht über die Technik. Was soll die Seite können, was geht heute nicht?
2. Ehrliche Einschätzung, ob headless die richtige Antwort ist — oft lautet sie nein.
3. Wenn ja: Bestandsaufnahme — Seitentypen, Felder, Blocktypen, Adressen, Plugins.
4. Konzept schriftlich, einschließlich Vorschau, Weiterleitungen und Betrieb.
5. In Etappen bauen, beginnend mit einem abgegrenzten Bereich.
6. Parallelbetrieb und Vergleich vor der Umschaltung.
7. Übergabe mit Dokumentation und Einweisung der Redaktion.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.

Wie es weitergeht.

Beschreib mir dein Vorhaben in fünf Sätzen: was die Website heute ist, was sie können soll, wie viele Seiten, wer sie pflegt. Darauf bekommst du eine ehrliche Einschätzung — und wenn der klassische Weg der richtige ist, einen Plan dafür statt eines Angebots für den teuren.

Wenn dir jemand headless empfohlen hat und du eine zweite Meinung willst: Schick mir das Angebot. Ich sage dir, ob die Punkte drinstehen, die erfahrungsgemäß später teuer werden — Vorschau, Weiterleitungen, laufende Pflege und die Frage, wer es in drei Jahren warten kann.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich arbeite seit Jahren mit WordPress und baue daneben eigene Plattformen mit Next.js — Lernplattformen mit mehreren tausend Seiten, bei denen WordPress als Redaktionssystem im Hintergrund läuft und das Frontend davon getrennt ist. Das ist also keine Theorie, sondern das, womit ich meine eigenen Projekte betreibe.

Genau deshalb sage ich auch offen, wann es sich nicht lohnt. Headless ist aufwendiger im Bau und im Betrieb, und für eine normale Unternehmenswebsite ist es fast immer die falsche Antwort. Wer mir schreibt und eine fünfzehnseitige Firmenwebsite headless bauen lassen will, bekommt von mir eine Rückfrage und keinen Kostenvoranschlag.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.