Inhalt
Der Build ist bezahlt, die Site ist live — und dann fängt der Betrieb erst an. Genau hier liegt der teuerste Irrtum bei Headless: die Annahme, ein statisch ausgeliefertes Frontend sei wartungsfrei und damit gratis. Das ist falsch. Eine Headless-Architektur verschiebt die laufenden Kosten, sie löscht sie nicht. Dieser Beitrag rechnet ehrlich durch, was nach dem Launch wiederkehrend anfällt — und überlässt die einmaligen Projektkosten bewusst dem Beitrag zu den Headless-WordPress-Kosten 2026. Wer die Architektur dahinter noch einordnen will, findet sie auf der Themenseite zu Headless WordPress.
Kurz vorab, weil die Erwartung oft schief ist: Sie betreiben bei Headless nicht eine Site, sondern zwei Systeme — ein WordPress-Backend und ein separates Frontend. Beide kosten Hosting, beide brauchen Updates. Das ist der rote Faden dieses Beitrags.
Was kostet eine Headless-Site im Betrieb wirklich?
Eine Headless-WordPress-Site verursacht im Betrieb wiederkehrende Kosten auf sechs Achsen: WordPress-Backend-Hosting, Frontend-Hosting, Backend-Updates, Frontend-/Dependency-Updates, Monitoring samt Sicherheits-Überwachung und Content-Pflege. Der entscheidende Unterschied zum klassischen Setup: Hosting und Updates fallen auf zwei Systemen an, nicht auf einem.
Die meisten dieser Posten sind nutzungsabhängig oder aufwandsabhängig, nicht fix — was die Gesamtsumme schwer pauschalisierbar macht. Eine schlanke Marketing-Site mit moderatem Traffic und einem aufgeräumten Plugin-Stack bleibt im niedrigen Bereich; eine traffic-starke Site mit vielen Integrationen, häufigen Deployments und sensiblen Inhalten skaliert in allen sechs Posten nach oben. Die folgenden Abschnitte zeigen jede Achse einzeln, mit realen Listenpreisen dort, wo es sie gibt, und klar gekennzeichneten Erfahrungsspannen dort, wo der Aufwand individuell ist.
Hosting auf zwei Seiten — der vergessene Mehrposten
Bei Headless zahlen Sie Hosting zweimal: einmal für das WordPress-Backend, einmal für das Frontend. Das ist kein Architekturfehler, sondern die Folge der Entkopplung — beide Systeme laufen parallel und werden separat betrieben. Wer nur das Frontend-Hosting budgetiert, unterschätzt die laufenden Kosten systematisch.
Das WordPress-Backend läuft weiter. Es ist kein Wegwerf-Teil: WordPress betreibt weiterhin rund 43 Prozent aller Websites und etwa 60 Prozent des bekannten CMS-Markts (W3Techs, via WordPress.com 2025) — ein langlebiges, mainstreamiges Backend, das über Jahre betrieben und aktualisiert wird. Managed-WordPress-Hosting kostet entsprechend laufend: Einstiegspläne starten bei WP Engine bei rund 25 bis 30 USD pro Monat, bei Kinsta ab etwa 35 USD pro Monat für eine Einzel-Site (Kinsta-Preise 2025). Das sind USD-Listenpreise ohne Schweizer Mehrwertsteuer.
Das Frontend-Hosting kommt obendrauf. Wer auf Vercel deployt, zahlt im Pro-Plan aktuell 20 USD pro Sitz und Monat, plus nutzungsabhängige Posten: Seit Vercel auf nutzungsbasierte Abrechnung umgestellt hat, wird pro Dimension gemessen — Bandbreite, Edge-Requests, Function-Aufrufe, Build-Compute, Bildoptimierung. Bandbreiten-Überschuss liegt aktuell bei 0,15 USD pro zusätzlichem GB in den Standardregionen (Vercel-Preisdokumentation). Auch das sind USD-Listenpreise. Welche Plattform für welches Profil passt, vertieft der Beitrag zum Hosting für Headless WordPress — hier zählt nur: es ist ein zweiter, eigenständiger Posten.
Warum das WordPress-Backend laufend Updates braucht
Das WordPress-Backend ist im Headless-Setup nicht wartungsfrei — es braucht dieselbe laufende Update-Pflege wie ein klassisches WordPress, nur ohne öffentliches Frontend. WordPress liefert seit der Cadence-Umstellung von 2025 etwa einen Major pro Jahr, dazu Minor- und Sicherheitsreleases nach Bedarf (Make WordPress Core, 2025). Das klingt nach wenig — ist es aber nicht.
Der Grund: Auto-Updates, die WordPress seit Version 3.7 standardmässig mitbringt, decken nur Minor- und Sicherheitsreleases ab. Major-Upgrades bleiben manuelle Arbeit — inklusive der Prüfung, ob alle Plugins, das aktive Theme und die PHP-Version mit der neuen Major-Version kompatibel sind. Genau diese Kompatibilitätsarbeit ist der eigentliche wiederkehrende Aufwand, nicht das Einspielen selbst.
Und das Sicherheitsrisiko sitzt fast vollständig in der Erweiterungsschicht. Im Jahr 2024 wurden im WordPress-Ökosystem 7'966 neue Schwachstellen gemeldet — ein Anstieg von 34 Prozent gegenüber 2023. Davon lagen 96 Prozent in Plugins, 4 Prozent in Themes und nur sieben im WordPress-Core, keine davon mit breitem Bedrohungspotenzial (Patchstack, State of WordPress Security 2024). Die Lehre daraus ist nicht «WordPress ist unsicher» — der Kern ist solide gepflegt. Die Lehre ist: Pflegen Sie die Erweiterungen, nicht den Kern. Und diese Pflege ist Pflicht, nicht Kür.
Warum so schnell? Patchstacks Auswertung der 2025er-Daten fand eine gewichtete mediane Zeit von der öffentlichen Bekanntgabe einer WordPress-Schwachstelle bis zur ersten beobachteten Ausnutzung von rund fünf Stunden; etwa die Hälfte der stark ausgenutzten Lücken wurde innerhalb von 24 Stunden getroffen (Patchstack, State of WordPress Security 2026). Ein Backend, das tagelang auf ein Plugin-Update wartet, ist exponiert — auch wenn es nicht öffentlich im Netz steht. Wie sich diese Fläche durch Entkopplung verändert, ordnet der Beitrag zur Sicherheit von Headless WordPress ein.
Was das Frontend an laufendem Aufwand erzeugt
Das Frontend einer Headless-Site ist statisch in der Auslieferung, aber nicht statisch in der Wartung. Das Framework hat kürzere Major-Zyklen als WordPress, und der JavaScript-Abhängigkeitsbaum ist ein eigener, laufender Sicherheitsposten. Beides erzeugt wiederkehrenden Aufwand, der im Build-Budget nicht enthalten ist.
Kürzere Framework-Zyklen. Next.js — das verbreitetste Headless-Frontend-Framework — liefert grob jährlich eine Major-Version: 14.x im Oktober 2023, 15.x im Oktober 2024, 16.x im Oktober 2025. Eine Major bleibt im aktiven Support, bis die nächste erscheint, danach folgen zwei Jahre Maintenance-Support mit ausschliesslich kritischen Fehler- und Sicherheitsfixes (Next.js Support Policy). Wer auf einer alten Major sitzen bleibt, verliert irgendwann den Anspruch auf reguläre Fixes — regelmässige Framework-Upgrades sind damit ein eingeplanter Posten, kein optionaler.
Die npm-Lieferkette wächst — und ist ein aktives Risiko. Ein Next.js-Frontend hängt an hunderten transitiven Paketen, die Sie nicht einzeln ausgewählt haben. Dass «statisch = sicher» ein Trugschluss ist, zeigte der axios-Vorfall: Am 31. März 2026 wurden zwei manipulierte axios-Versionen (1.14.1 und 0.30.4) auf npm veröffentlicht, die eine versteckte Abhängigkeit nachluden, deren Postinstall-Skript einen plattformübergreifenden Remote-Access-Trojaner installierte. axios hat rund 100 Millionen wöchentliche Downloads; die manipulierten Versionen waren etwa drei Stunden live, bevor sie entfernt wurden (StepSecurity, 2026).
Ein statisches Frontend ist robust in der Auslieferung — aber seine Lieferkette ist so lebendig und angreifbar wie jeder Plugin-Stack.
Microsoft veröffentlichte zum selben Vorfall eine Handlungsempfehlung: exakte Versions-Pins, Override-Kontrolle, Prüfung der CI/CD-Logs, Rotation von Secrets und npm ci --ignore-scripts (Microsoft Security Blog, 2026). Die Lehre für den Betrieb: Schon ein dreistündiges Zeitfenster in einem stark genutzten Paket verlangt aktive Dependency-Überwachung und schnelle Reaktion. Das ist ein realer, wiederkehrender Aufwand — kein Restposten vom Build.
Die sechs Betriebsposten im Überblick
Die folgende Tabelle fasst die wiederkehrenden Posten einer Headless-Site zusammen — mit realen Listenpreisen dort, wo sie existieren, und klar als Erfahrungsspanne gekennzeichnetem Aufwand dort, wo er individuell ist. Sie ersetzt keine projektspezifische Kalkulation, gibt aber die Grössenordnung und die Treiber.
| Posten | Grössenordnung | Was ihn treibt |
|---|---|---|
| WordPress-Backend-Hosting | ab ~25–35 USD/Mo (Managed, Einstieg) | Datenmenge, Traffic auf die API, gewünschtes Support-Level |
| Frontend-Hosting (z. B. Vercel) | ab 20 USD/Sitz/Mo + Nutzung | Bandbreite, Edge-Requests, Function-Aufrufe, Build-Minuten |
| Backend-Updates (Core, Plugins, Themes) | Erfahrungswert: rund 1–4 Std/Mo, in Major-Monaten mehr | Grösse des Plugin-Stacks, Major-Upgrade-Frequenz, PHP-Kompatibilität |
| Frontend-/Dependency-Updates | Erfahrungswert: rund 1–3 Std/Mo, plus Vorfälle | Framework-Major-Zyklus, Anzahl npm-Pakete, Lieferketten-Vorfälle |
| Monitoring + Sicherheits-Überwachung | Tool-Abos im niedrigen zweistelligen USD-Bereich + Reaktionsbereitschaft | Uptime-, Fehler- und Dependency-Monitoring; Reaktionszeit-Anspruch |
| Content-Pflege | redaktionsabhängig, skaliert mit Sprachen und Frequenz | Publishing-Frequenz, Anzahl Redaktoren, Mehrsprachigkeit |
Aus unseren eigenen Projekten 2024–2026: Bei einer mehrsprachigen Marketing-Site mit moderatem Traffic dominierten nicht die Hosting-Rechnungen den laufenden Aufwand, sondern die Update- und Überwachungsarbeit auf beiden Systemen zusammen. Die reinen Hosting-Posten blieben planbar; der variable Teil war der menschliche Aufwand, beide Seiten aktuell und überwacht zu halten.
Was der Betrieb nicht automatisch löst — der ehrliche Teil
Hier wird die Rechnung unbequem. Headless senkt manche Betriebsrisiken, aber wer «static = wartungsfrei» glaubt, baut sich ein falsches Kostenbild — und das ist der teuerste Irrtum überhaupt. Drei Punkte gehören ehrlich dazu.
Die einmaligen Build-Kosten gehören nicht hierher. Dieser Beitrag besitzt ausschliesslich den laufenden Betrieb. Was die Erstinvestition treibt — Architektur, Migration, Design, Integrationen — steht im Beitrag zu den Headless-WordPress-Kosten 2026. Wer noch grundsätzlich abwägt, ob sich der Schritt überhaupt rechnet, findet die Schwelle im Beitrag dazu, wann sich Headless WordPress lohnt. Diese Trennung ist Absicht: Betrieb und Build sind zwei verschiedene Budgets.
Headless reduziert den Wartungsaufwand nicht — es verteilt ihn anders. Statt eines Systems pflegen Sie zwei: das WordPress-Backend mit seiner Plugin-Schicht und das Frontend mit seinem npm-Baum. Die Update-Pflicht verschwindet auf keiner Seite. Sie tauschen die bekannte, gut dokumentierte Wartung eines klassischen WordPress gegen eine verteilte Wartung über zwei Stacks — netto oft ein guter Tausch, aber eben kein Wegfall.
Ohne operative Reife wird der Betrieb teurer, nicht günstiger. Wer keinen kontrollierten Update-Prozess, kein Dependency-Monitoring und keine saubere Secret-Verwaltung betreibt, zahlt den Unterschied später — als Incident, als Notfall-Patch, als ungeplanten Aufwand. Die laufende Überwachung der Lieferkette ist genau der Posten, den der axios-Vorfall sichtbar gemacht hat: real, wiederkehrend, nicht delegierbar an «es ist ja statisch».
Wo Ihre Site heute steht — der schnelle Check
Bevor Sie laufende Kosten budgetieren, lohnt der Blick auf den Ist-Zustand. Der kostenlose Website-Check prüft sichtbare Indikatoren von aussen — Performance, gesetzte Sicherheits-Header und typische WordPress-Endpunkte — und liefert eine erste Standortbestimmung. Daraus ergibt sich, wie viel Betriebsaufwand Ihr aktuelles Setup heute schon erzeugt und wo eine Entkopplung den laufenden Aufwand eher senkt oder eher erhöht.
Wer den Aufwand lieber an ein Team abgibt, statt beide Stacks selbst zu pflegen, findet das Vorgehen auf der Seite Leistungen — inklusive der Frage, welche Betriebsposten sich sinnvoll auslagern lassen und welche im Haus bleiben sollten.
Nächster Schritt
Die laufenden Kosten einer Headless-Site sind planbar — aber nur, wenn man beide Systeme, beide Hosting-Posten und die Update-Pflicht auf beiden Seiten von Anfang an einrechnet. Ob Ihr Projekt im niedrigen zweistelligen Monatsbereich bleibt oder durch Traffic, Integrationen und Reaktionszeit-Ansprüche darüber hinaus skaliert, lässt sich in einem kurzen Gespräch sauber einordnen. Wenn Sie Ihre Betriebskosten realistisch durchrechnen wollen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos.
Wer zuerst weitere Strategie-Themen vertiefen will, findet in der Strategie-Kategorie im Blog die passenden Beiträge zu Budget, Entscheidung und Vorgehen.