Wartung und Sicherheit: was eine WordPress-Installation im Jahr wirklich kostet

Eine gepflegte WordPress-Installation kostet ein Schweizer KMU im Jahr selten die Hosting-Gebühr, sondern die Arbeitszeit dahinter: In einem realistischen Modell mit rund 20 Seiten, 18 Plugins und einem monatlichen Update-Fenster summieren sich die Jahreskosten auf etwa CHF 3'100, wovon weniger als zehn Prozent auf den Server entfallen. Eine statisch ausgelieferte Seite desselben Umfangs liegt in derselben Rechnung bei rund einem Viertel davon — nicht weil WordPress schlecht wäre, sondern weil eine Seite ohne Datenbank, ohne PHP-Laufzeit und ohne Plugin-Ökosystem schlicht weniger bewegliche Teile hat, die aktuell gehalten werden müssen.

Vorweg die faire Einordnung, weil dieser Vergleich sonst schief steht: WordPress ist ein ausgereiftes System, es rankt hervorragend, es hat ein Redaktionssystem, das Mitarbeitende ohne Schulung bedienen können, und für einen Blog mit wöchentlichen Beiträgen ist es oft genau richtig. Die Frage ist nicht, ob WordPress taugt. Die Frage ist, welchen Betriebsaufwand man sich mit welcher Architektur einkauft — und dieser Aufwand lässt sich beziffern, statt ihn zu behaupten.

Woraus sich die Jahresrechnung zusammensetzt

Die Jahreskosten einer WordPress-Site bestehen aus sechs Posten, und nur einer davon erscheint je auf einer Rechnung: das Hosting. Alle übrigen sind Arbeitszeit oder Lizenzen, die entweder intern anfallen oder in einem Wartungsvertrag verschwinden, in dem niemand nachrechnet, wofür genau gezahlt wird.

Der erste Posten ist das Hosting selbst, bei einem Schweizer Anbieter für eine Firmenwebsite typischerweise ein zweistelliger Monatsbetrag — wie sich dieser Betrag zwischen den Hosting-Architekturen unterscheidet, haben wir separat durchgerechnet. Der zweite sind Lizenzen: Ein kommerzielles Theme, ein Page Builder, ein Formular-Plugin und ein SEO-Plugin in der Bezahlvariante kosten zusammen schnell mehrere hundert Franken jährlich, weil praktisch alle Anbieter auf Jahreslizenzen mit Update-Anspruch umgestellt haben. Wer die Lizenz auslaufen lässt, behält die Funktion, verliert aber die Sicherheitsupdates — und genau daraus entsteht das Risiko, das weiter unten in Zahlen steht.

Der dritte Posten ist das eigentliche Update-Fenster: Core, Plugins und Theme einspielen, danach prüfen, ob Formular, Checkout, Navigation und Layout noch funktionieren. Der vierte sind ausserplanmässige Sicherheitsupdates, die sich nicht auf den Monatsrhythmus verschieben lassen. Der fünfte ist die Backup-Kontrolle inklusive gelegentlichem Wiederherstellungstest — ein Punkt, den wir in Backups und Ausfallsicherheit ausführlich behandelt haben und der in fast jedem KMU-Setup zu optimistisch eingeschätzt wird. Der sechste ist die Reparatur nach einem Update-Konflikt, die nicht jedes Jahr anfällt, aber wenn, dann teuer.

Wie oft tatsächlich aktualisiert werden muss

Ein WordPress-Projekt bekommt mehrere Core-Releases pro Quartal, und die Plugin-Updates laufen unabhängig davon weiter. Nachprüfbar im offiziellen Release-Archiv: Zwischen dem 20. Mai 2026 (Version 7.0) und dem 19. August 2026 (Version 7.1) erschienen sechs Core-Versionen, darunter vier Wartungs- und Sicherheitsreleases der 7.0-Linie innerhalb von rund fünf Wochen.

Das ist an sich ein gutes Zeichen — ein Projekt, das schnell patcht, ist ein gepflegtes Projekt. Für den Betrieb bedeutet es aber, dass ein quartalsweiser Wartungsrhythmus zu grob ist. Wer alle drei Monate aktualisiert, läuft im Schnitt mit mehreren offenen Wartungsreleases, und bei einem Sicherheitsrelease zählen nicht Wochen, sondern Tage.

Dazu kommt die Plugin-Seite, und die ist der eigentliche Treiber. Bei 18 installierten Plugins ist es normal, dass in jedem Monat eine Handvoll Updates bereitliegt. Jedes einzelne ist trivial einzuspielen. Der Aufwand steckt nicht im Klick, sondern in der Kontrolle danach: Ein Page-Builder-Update, das die Darstellung einer einzigen Sektion verschiebt, fällt ohne Sichtprüfung tagelang niemandem auf. Genau deshalb rechnen wir im Modell unten nicht mit fünf Minuten pro Monat, sondern mit einer Dreiviertelstunde.

Woher die Sicherheitslücken tatsächlich kommen

Die Schwachstellen liegen fast nie in WordPress selbst, sondern in dem, was man dazu installiert. Patchstack zählte in seinem Jahresbericht für 2025 11'334 neue Schwachstellen im WordPress-Ökosystem, ein Plus von 42 Prozent gegenüber dem Vorjahr. Davon entfielen 91 Prozent auf Plugins, 9 Prozent auf Themes und sechs Meldungen auf den Core. Im Vorjahresbericht sah das Verhältnis mit 7'966 Schwachstellen, 96 Prozent aus Plugins und sieben Core-Meldungen praktisch gleich aus.

Zwei Zahlen aus demselben Bericht sind für die Kostenfrage wichtiger als die Gesamtsumme. Erstens: 46 Prozent der Schwachstellen hatten zum Zeitpunkt der öffentlichen Bekanntgabe noch keinen Fix des Herstellers — 2024 waren es 33 Prozent. Ein Update-Prozess, wie sorgfältig auch immer, hilft in diesen Fällen per Definition nicht, weil es nichts zu aktualisieren gibt. Zweitens: 29 Prozent der Meldungen betrafen kostenpflichtige oder Freemium-Komponenten. Die verbreitete Annahme, ein bezahltes Plugin sei automatisch das sicherere, hält der Statistik nicht stand.

Daraus folgt eine unspektakuläre, aber wirksame Regel: Die wichtigste Sicherheitsmassnahme in einem WordPress-Projekt ist die Reduktion der Plugin-Anzahl. Jedes entfernte Plugin senkt die Angriffsfläche, den Update-Aufwand und die Wahrscheinlichkeit eines Kompatibilitätsproblems in einem Zug. In der Praxis lassen sich bei den meisten gewachsenen Installationen fünf bis acht Plugins ersatzlos streichen, weil ihre Funktion längst im Theme, im Core oder gar nicht mehr gebraucht wird. Ein strukturiertes Website-Audit beginnt in aller Regel genau hier.

Was eine statisch ausgelieferte Seite an Wartung braucht

Eine statisch ausgelieferte Seite hat keine öffentlich erreichbare Datenbank und keine PHP-Laufzeit, die gepatcht werden muss — die Wartung reduziert sich deshalb auf Abhängigkeits-Updates im Build und einen gelegentlichen Neubau. Der entscheidende Unterschied ist nicht, dass weniger Code veraltet, sondern wo er veraltet: im Build-Prozess statt auf dem Server, den das Internet erreichen kann.

Konkret heisst das: Wer ein modernes Framework einsetzt, aktualisiert ein bis zweimal jährlich die Abhängigkeiten, lässt den Build laufen und schaut sich das Ergebnis in einer Vorschau-Umgebung an. Bricht etwas, bricht es in der Vorschau. Die Live-Seite bleibt unverändert, bis der Build grün ist. Ein WordPress-Update spielt man dagegen in aller Regel direkt auf dem System ein, das gerade Besucher bedient — Staging-Umgebungen existieren in KMU-Projekten deutlich seltener, als die Best-Practice-Literatur unterstellt.

Ehrlich bleiben muss man an zwei Stellen. Erstens hat eine statische Seite ohne Zusatzarbeit kein Redaktionssystem: Wenn die Marketingabteilung selbst Texte ändern soll, braucht es ein Headless CMS oder einen definierten Redaktionsworkflow, und dieser Aufwand gehört in die Rechnung. Zweitens verschwindet Sicherheitsarbeit nicht, sie verlagert sich — Formulare, Zahlungsanbindungen und APIs bleiben Angriffsfläche, egal wie die Seiten ausgeliefert werden. Was verschwindet, ist die Klasse von Lücken, die ein Angreifer massenhaft und automatisiert über eine bekannte Plugin-Version ausnutzen kann.

Die Rechnung nebeneinander

Beide Modelle unten gehen von derselben Website aus: rund 20 Seiten, ein Kontaktformular, ein Newsletter-Anschluss, kein Shop, moderater Traffic. Der Stundensatz ist mit CHF 150 angenommen, die Zeiten sind Erfahrungswerte aus unserer Betreuung und keine Messreihe. Wer intern günstiger arbeitet, skaliert die Arbeitsposten entsprechend herunter — die Verhältnisse bleiben.

Die Differenz liegt bei rund CHF 2'100 bis 2'350 pro Jahr, und sie steckt praktisch vollständig in Arbeitszeit. Über fünf Jahre sind das gut CHF 11'000 — eine Grössenordnung, die in der Nähe eines kompletten Website-Neubaus liegt und deshalb in jede Budgetdiskussion gehört. Welche Bandbreite ein Neubau abdeckt, haben wir in der Übersicht zu Webdesign-Preisen aufgeschlüsselt.

Wo die Rechnung zugunsten von WordPress kippt

Es gibt drei Konstellationen, in denen WordPress betriebswirtschaftlich die richtige Wahl bleibt, und sie sind häufiger, als es dieser Artikel bis hierher nahelegt. Die erste ist eine schlanke Installation: ein solides Theme, fünf statt achtzehn Plugins, automatische Updates aktiv. Der Wartungsposten in der Tabelle oben halbiert sich damit, und der Abstand zur statischen Variante wird klein genug, um andere Argumente entscheiden zu lassen.

Die zweite ist Managed WordPress mit automatisierten Updates und Staging. Das tauscht Arbeitszeit gegen eine höhere Hosting-Rechnung, und in einem Land mit Schweizer Stundensätzen ist das oft ein guter Tausch. Der Punkt, den solche Angebote nicht abnehmen, bleibt die inhaltliche Kontrolle nach dem Update — aber die Häufigkeit der Handgriffe sinkt spürbar.

Die dritte ist ein hohes Publikationsvolumen mit mehreren Redaktorinnen und Redaktoren. Wenn wöchentlich Beiträge entstehen, Bilder hochgeladen und Seiten umgebaut werden, ist ein etabliertes Redaktionssystem mit Rollen, Vorschau und Medienbibliothek ein handfester Vorteil. Diesen Vorteil in einer statischen Architektur nachzubauen kostet mehr, als die Wartung einspart.

Umgekehrt ist die Entscheidung fast immer klar, wenn eine Firmenwebsite im Wesentlichen steht: zwanzig bis fünfzig Seiten, ein paar Aktualisierungen im Quartal, hohe Anforderungen an Ladezeit und Sichtbarkeit. Genau dieser Fall macht in unserer Arbeit als Web-Agentur den Grossteil der Anfragen aus, und dort ist die statische Auslieferung sowohl technisch als auch über fünf Jahre gerechnet die ruhigere Variante.

Was das für die Entscheidung heisst

Die brauchbare Frage lautet nicht, welches System besser ist, sondern wie viel bewegliche Teile eine Website braucht, um ihren Zweck zu erfüllen. Jede Komponente, die im Live-System läuft und aktualisiert werden muss, erzeugt jedes Jahr aufs Neue Kosten und Risiko. Jede Komponente, die im Build läuft, tut das nicht.

Wer aktuell mit WordPress arbeitet und nicht neu bauen will, holt den grössten Teil der Ersparnis ohne Migration: Plugins ausmisten, automatische Updates aktivieren, Lizenzen prüfen, einen Wiederherstellungstest ansetzen. Das kostet einen halben Tag und senkt den Jahresaufwand messbar. Wer ohnehin vor einem Relaunch steht, sollte die Betriebskosten von Anfang an im Angebot sehen — bei einem Projekt, bei dem wir eine Website erstellen, ist der Wartungsposten ein Bestandteil der Entscheidungsgrundlage und keine Überraschung im zweiten Jahr.

Für Teams, die den Weg über einen eigenen Server gehen wollen, ist Self-Hosting mit Coolify eine ernsthafte Option mit planbaren Fixkosten; wo die Daten dabei liegen dürfen, klärt unser Beitrag zu DSG-konformem Hosting. Und wenn der Neubau selbst schnell gehen soll, ohne dass am Ende wieder ein Wartungsmonster steht, lohnt ein Blick darauf, wie KI-gestützte Entwicklung die Bauzeit verkürzt, ohne die Zahl der beweglichen Teile zu erhöhen.