Lohnt sich das — oder ist es nur modern?

Was man gewinnt.

• Tempo. Fertig erzeugte Seiten ohne PHP-Verarbeitung sind schwer zu schlagen (Ladezeit).
• Volle Kontrolle über das Frontend. Kein Theme, das etwas vorgibt, keine Plugins, die ungefragt Dateien laden.
• Kleinere Angriffsfläche. WordPress ist nicht öffentlich erreichbar (Sicherheit).
• Robustheit. Fällt WordPress aus, bleiben die erzeugten Seiten erreichbar.
• Mehrere Ausgabekanäle aus denselben Inhalten.
• Moderne Entwicklungsarbeit mit Versionsverwaltung, Testumgebungen und automatischen Prüfungen.

Der vierte Punkt wird selten genannt und ist handfest: Bei statisch erzeugten Seiten kann das Redaktionssystem stundenlang offline sein, ohne dass ein Besucher etwas merkt. Nur veröffentlichen lässt sich dann nichts.

Was man verliert.

• Das Plugin-Ökosystem fürs Frontend. Alles, was Darstellung betrifft, fällt weg.
• Die Vorschau funktioniert nicht mehr von selbst (Vorschau).
• Den visuellen Seitenaufbau. Page Builder sind damit vorbei.
• Einfachheit im Betrieb. Zwei Systeme statt einem.
• Austauschbarkeit. Deutlich weniger Dienstleister können das übernehmen.
• Schnelle kleine Änderungen. Was früher ein Plugin war, ist jetzt eine Entwicklungsaufgabe.

Der dritte Punkt ist für viele der Knackpunkt. Wenn das Marketing gewohnt ist, Landingpages selbst zusammenzuklicken, ist headless ein harter Bruch — dann kann die Redaktion plötzlich nur noch Inhalte in vorgegebene Strukturen füllen (Page Builder).

Argumente, die trügen.

Zeile drei verdient einen Moment: WordPress gibt es seit über zwanzig Jahren und wird es in zehn Jahren noch geben. Bei Frontend-Frameworks sieht die Halbwertszeit anders aus — ein Projekt von heute braucht in fünf Jahren eine größere Überarbeitung. Das ist kein Gegenargument, gehört aber in die Rechnung.

Zeile vier ist die, die in Angeboten am häufigsten vorkommt. Frag dich ehrlich: Gibt es tatsächlich einen zweiten Kanal, oder ist es eine App, die seit drei Jahren geplant ist?

Wann es passt.

1. Viele Seiten, deutlich über tausend, mit automatisch erzeugten Inhalten.
2. Anspruchsvolles Frontend: starke Interaktion, Animationen, 3D, Werkzeuge im Browser (3D im Web).
3. Mehrere echte Kanäle, nicht geplante.
4. Entwickler vorhanden, intern oder dauerhaft beauftragt.
5. Hohe Lastspitzen, bei denen statische Auslieferung Gold wert ist.
6. Bestehendes Frontend-Team, das ohnehin mit diesen Werkzeugen arbeitet.
7. WordPress soll nicht öffentlich sein, aus Sicherheits- oder Vorgabegründen.

Punkt eins und zwei sind die häufigsten echten Gründe. Bei einer Plattform mit mehreren tausend Seiten, die jeweils aus Daten zusammengesetzt werden, spielt die Bauweise ihren Vorteil tatsächlich aus — und zwar spürbar.

Wann es nicht passt.

• Normale Unternehmenswebsite mit zwanzig bis zweihundert Seiten.
• Kein Entwickler im Haus oder dauerhaft verfügbar.
• Marketing baut selbst Seiten und will das behalten.
• Knappes Budget — das Geld ist in Inhalten und Ladezeitarbeit besser angelegt.
• Viele Plugins im Einsatz, die fürs Frontend arbeiten.
• Shop ohne besonderen Anspruch (WooCommerce headless).
• Das Problem heißt „zu langsam“.

Der letzte Punkt ist der wichtigste, weil er der häufigste Anlass ist. Eine langsame WordPress-Seite wird durch headless schnell — aber sie wird es auch durch Caching, vernünftige Bilder, weniger Plugins und ein ordentliches Hosting, und das kostet einen Bruchteil (Core Web Vitals).

Die Wartbarkeitsfrage.

Die Frage, die in Angeboten nicht vorkommt und nach zwei Jahren entscheidet: Wer pflegt das?

Eine klassische WordPress-Seite kann fast jede Agentur und jeder Freiberufler übernehmen. Ein eigenes Frontend in einem Framework kann das nicht — man braucht jemanden mit genau diesen Kenntnissen, und der muss sich in eine gewachsene Struktur einarbeiten.

Dazu kommt die laufende Pflege: Abhängigkeiten veralten, das Framework bringt größere Versionssprünge, Sicherheitsmeldungen wollen bearbeitet werden. Das ist keine theoretische Last, sondern mehrere Tage im Jahr — und wenn es zwei Jahre liegen bleibt, wird aus dem Update ein Projekt.

Wer headless geht, sollte deshalb von Anfang an klären, wer das dauerhaft betreut und was es im Jahr kostet (Kosten).

Die Teamfrage.

Ich frage bei solchen Projekten zuerst nach den Menschen, nicht nach der Technik:

• Wer schreibt die Inhalte, und wie technisch ist diese Person?
• Baut jemand im Marketing selbst Seiten zusammen?
• Gibt es jemanden, der Code anfassen kann?
• Wer ruft an, wenn etwas nicht geht?
• Was passiert, wenn der bisherige Dienstleister ausfällt?

Antworten darauf sagen mehr über die richtige Lösung als jede Anforderungsliste. Ein technisch überlegener Aufbau, den im Unternehmen niemand bedienen oder beauftragen kann, ist die schlechtere Lösung.

Was es sonst noch gibt.

Zeile drei wird zu selten erwogen und ist oft die beste Antwort: Die Website bleibt klassisch, und nur ein Bereich — ein Konfigurator, ein Rechner, eine interaktive Darstellung — wird als eigenständige Anwendung gebaut und eingebunden. Man bekommt die Freiheit dort, wo man sie braucht, und behält den Rest einfach (Rechner im Browser).

Sechs Fragen.

1. Wie viele Seiten hat die Website, und wie viele werden automatisch erzeugt?
2. Was soll das Frontend können, was ein Theme nicht kann?
3. Wer pflegt es in drei Jahren?
4. Muss das Marketing selbst Seiten bauen?
5. Gibt es wirklich einen zweiten Kanal?
6. Was ist das eigentliche Problem — und ist headless die günstigste Lösung dafür?

Wenn du bei Frage zwei nichts Konkretes nennen kannst und bei Frage sechs „die Seite ist langsam“ antwortest, lautet meine Empfehlung klassisch. Das sage ich auch, wenn ich damit ein größeres Projekt verliere.

Mein ehrlicher Rat.

Ich baue headless-Projekte und betreibe eigene Plattformen so. Trotzdem: Von zehn Anfragen, bei denen jemand headless möchte, ist es bei zwei die richtige Antwort. Bei den anderen acht ist das Ziel mit Ladezeitarbeit, ordentlichem Hosting und einem Plugin-Aufräumen günstiger und schneller erreicht.

Wenn du unsicher bist: Beschreib mir dein Vorhaben in fünf Sätzen. Ich sage dir, in welche Gruppe du gehörst — und wenn es die zweite ist, bekommst du von mir einen Plan für den klassischen Weg statt eines Angebots für den teuren.

Wenn du weiterkommen willst.

Wenn dir jemand headless empfohlen hat und du eine zweite Meinung ohne Verkaufsinteresse willst. Ich schaue mir an, was du vorhast, und sage dir, ob headless passt — und wenn nicht, was stattdessen: Headless WordPress. Geht es nur um Tempo, ist oft Ladezeitarbeit an der bestehenden Seite der günstigere Weg.

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.