Was kostet das — und was kostet es jedes Jahr?

Die Posten im Bau.

Zwölf Posten, von denen bei einem klassischen Projekt etwa die Hälfte entfällt oder stark verkürzt ist. Das ist der ganze Unterschied — nicht irgendeine Technikmagie.

Besonders unterschätzt werden Zeile fünf und zehn. Die Blockdarstellung bedeutet, jeden im Editor verwendbaren Block im Frontend nachzubauen; wer zwanzig Blocktypen erlaubt, baut zwanzig Darstellungen (Aufbau).

Warum der Vergleich hinkt.

„Klassisch kostet X, headless kostet das Doppelte“ ist eine Aussage, die ohne Kontext nichts taugt. Zwei Gründe.

Erstens vergleicht man meist nicht dasselbe. Ein headless-Projekt wird oft gewählt, weil das Frontend etwas Besonderes können soll — und dieses Besondere ist der Mehrpreis, nicht die Bauweise. Dieselbe Funktion klassisch zu bauen, wäre ähnlich teuer oder gar nicht möglich.

Zweitens wird klassisch oft ein fertiges Theme gekauft und angepasst. Das ist keine Vergleichsgröße zu einem individuell gebauten Frontend — es ist eine andere Leistung.

Der faire Vergleich lautet: individuelles Theme gegen individuelles Frontend. Dann wird der Abstand deutlich kleiner, bleibt aber bestehen.

Laufende Kosten.

• Hosting für WordPress — kann klein sein, es kommen keine Besucher.
• Hosting oder Dienst fürs Frontend — je nach Lösung kostenlos bis spürbar.
• Bildverarbeitung, falls über einen Dienst.
• Suchdienst, falls eingesetzt.
• Abhängigkeiten aktuell halten — der größte Posten.
• Versionssprünge des Frameworks, alle ein bis zwei Jahre größer.
• WordPress und Plugins weiterhin aktualisieren.

Punkt fünf und sechs sind der Unterschied zum klassischen Betrieb. Ein Frontend-Projekt hat Dutzende Abhängigkeiten, die veralten; bleibt das zwei Jahre liegen, wird aus einer Routineaufgabe ein Projekt. Rechne mit mehreren Tagen im Jahr, die jemand aufwenden muss (Betrieb).

Versteckte Posten.

Die zweite Zeile verdient einen eigenen Satz: Bei einer bestehenden Website mit Jahren an Inhalten existieren Adressen, Weiterleitungen und Sonderfälle, die niemand mehr auf dem Schirm hat. Die vollständig zu erfassen und zu übertragen ist ein eigener Arbeitsblock (Umstellung).

Was den Preis treibt.

1. Zahl der Seitentypen. Jede Vorlage ist Arbeit.
2. Zahl der Blocktypen, die die Redaktion verwenden darf.
3. Interaktion im Frontend — Filter, Rechner, Konfiguratoren.
4. Mehrsprachigkeit.
5. Bestehende Seite statt Neubau, wegen Adressen und Altlasten.
6. Shop.
7. Sonderwünsche an die Vorschau und an Freigabeprozesse.

Punkt zwei ist der wirksamste Hebel, den man selbst in der Hand hat. Wer der Redaktion acht gut gebaute Blocktypen gibt statt dreißig, spart erheblich — und bekommt nebenbei eine einheitlichere Website.

Wo man sparen kann.

• Weniger Blocktypen, dafür durchdachte.
• Mit einem Bereich anfangen statt alles auf einmal.
• Bestehende Adressstruktur übernehmen, statt sie neu zu erfinden.
• Einfache Suche zum Start, Ausbau später.
• Fertige Bausteine fürs Frontend nutzen, wo sie passen.
• Inhalte selbst pflegen und migrieren.

Punkt zwei ist meine häufigste Empfehlung: erst einen abgegrenzten Bereich headless bauen — etwa den Blog oder einen Produktbereich — und den Rest klassisch lassen. Das halbiert das Risiko und zeigt nach wenigen Wochen, ob der Weg trägt.

Wo nicht.

• An der Vorschau. Ohne sie arbeitet die Redaktion im Blindflug und das Projekt wird abgelehnt.
• An den Weiterleitungen. Verlorene Adressen kosten Sichtbarkeit, die teuer zurückzuholen ist.
• An der Dokumentation. Sonst kann es niemand übernehmen.
• An der Überwachung. Ein fehlgeschlagener Bauvorgang, den niemand merkt, friert die Website ein.
• An der Einweisung. Die Redaktion muss die neuen Abläufe kennen.

Der vierte Punkt ist ein echter Fallstrick bei statisch erzeugten Seiten: Wenn der Bauvorgang scheitert, bleibt die alte Fassung online. Das sieht aus, als sei alles in Ordnung — und niemand merkt wochenlang, dass nichts mehr aktualisiert wird.

Wie ein Angebot aussehen sollte.

Woran du ein brauchbares Angebot erkennst:

• Es listet die Posten einzeln auf, nicht als eine Summe.
• Es benennt, wie viele Seitentypen und Blocktypen enthalten sind.
• Es sagt etwas zur Vorschau.
• Es sagt etwas zu Weiterleitungen aus dem Altbestand.
• Es nennt die laufenden Kosten, nicht nur die Bausumme.
• Es sagt, wer es danach warten kann.
• Es nennt Grenzen — was ausdrücklich nicht enthalten ist.

Ein Angebot ohne die Punkte fünf und sechs würde ich zurückgeben. Nicht weil es unseriös sein muss, sondern weil genau dort die Überraschungen stecken.

Eine ehrliche Rechnung.

Statt einer Zahl ein Rechenweg, den du selbst anwenden kannst. Nimm den Aufwand für ein individuelles Theme deiner Website als Grundlage. Rechne dazu: die Posten aus der Tabelle oben, die klassisch entfallen würden, und den laufenden Pflegeaufwand über die geplante Laufzeit — üblich sind fünf Jahre.

Stell dieser Summe gegenüber, was der klassische Weg kosten würde, einschließlich Ladezeitarbeit und Hosting. Und frag dich dann, ob der Unterschied durch das gerechtfertigt ist, was du zusätzlich bekommst.

Wenn du bei dieser Frage ins Stocken gerätst, ist das eine Antwort (Lohnt es sich?).

Wie ich arbeite.

Ich gebe keine Pauschalpreise für headless-Projekte, weil die Spanne zu groß ist — zwischen einem abgegrenzten Bereich und einer Plattform mit mehreren tausend Seiten liegt ein Vielfaches. Was ich gebe, ist eine Einschätzung nach einem Gespräch, in dem die Fragen oben geklärt werden.

Und ich sage dir vorher, wenn ich den klassischen Weg für richtig halte. Das kommt häufiger vor, als mir geschäftlich lieb ist, aber ein Projekt, das nach zwei Jahren niemand mehr pflegen kann, nützt uns beiden nichts.

Wenn du weiterkommen willst.

Wenn du ein Angebot bewerten willst oder wissen musst, was realistisch auf dich zukommt. 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.