WordPress Wartung: welcher Aufwand wirklich anfällt

Wer wissen will, was WordPress-Wartung verlangt, bekommt selten eine brauchbare Antwort, weil fast alle über den Betrag sprechen und kaum jemand über die Arbeit dahinter. Die Arbeit ist aber der Punkt: WordPress wird auf drei Ebenen gepflegt, die Zahl der Erweiterungen bestimmt den Aufwand fast allein, PHP-Wechsel kommen regelmäßig wieder, und der häufigste Schaden ist kein Angriff, sondern ein Update, das still etwas kaputt macht.

In diesem Artikel lesen Sie, was an einer WordPress-Installation konkret gepflegt wird, warum Plugin-Wildwuchs der eigentliche Aufwandstreiber ist, was Staging und Rücksprung bedeuten, warum PHP-Upgrades wiederkehren und was bei einer Übergabe an einen anderen Dienstleister vorliegen muss.

Was Website-Wartung grundsätzlich umfasst, unabhängig vom System, beschreibt der Beitrag dazu, was Website-Wartung ist. Was den Monatsbetrag treibt, behandelt der Beitrag zu den Kosten der Website-Wartung, und was vertraglich geregelt gehört, der Beitrag zum Website-Wartungsvertrag und SLA. Diese Seite geht nicht noch einmal durch dieselben Fragen, sondern durch das, was speziell an WordPress hängt.

Die drei Ebenen, die gepflegt werden

Eine WordPress-Installation ist kein einzelnes Produkt, sondern ein Kern mit fremdem Code darauf. Diese Trennung erklärt fast alles am Wartungsaufwand.

Ebene	Wer sie pflegt	Rhythmus	Risiko beim Aktualisieren
Core	Das WordPress-Projekt	Wenige größere Versionen im Jahr, dazwischen Sicherheitskorrekturen	Gering, aber Änderungen an Schnittstellen können Erweiterungen brechen
Plugins	Jeweils ein eigener Hersteller	Vollständig unabhängig, teils wöchentlich, teils nie	Hoch, weil Code von Dritten in Ihre Seite eingreift
Themes	Hersteller oder Ihre eigene Anpassung	Unregelmäßig	Hoch, wenn ohne Child-Theme angepasst wurde
Übersetzungen	Community und Hersteller	Folgt den Versionen	Gering, aber inkonsistente Oberfläche bei Lücken

Der Kern ist das kleinste Problem. Sicherheitskorrekturen für den Kern werden in vielen Installationen automatisch eingespielt, und größere Versionswechsel sind gut dokumentiert. Der Aufwand entsteht auf den beiden mittleren Ebenen, weil dort Code von Dritten läuft, den weder Sie noch das WordPress-Projekt kontrollieren.

Ein Sonderfall, der regelmäßig übersehen wird: Wenn ein Theme direkt bearbeitet wurde, statt über ein Child-Theme, überschreibt jede Theme-Aktualisierung diese Änderungen. Viele Installationen werden deshalb seit Jahren nicht mehr aktualisiert, weil niemand mehr weiß, was beim Aktualisieren verloren ginge. Das ist keine Sparmaßnahme, sondern aufgeschobene Arbeit mit Zinsen.

Warum Plugin-Wildwuchs der eigentliche Aufwandstreiber ist

Die Frage “was verlangt WordPress-Wartung” hat eine ehrliche Gegenfrage: Wie viele Plugins sind installiert, und wer pflegt sie? Nicht die Zahl der Seiten und nicht die Zahl der Besucher bestimmt den Aufwand, sondern die Zahl der beweglichen Teile.

Fünf Mechaniken machen daraus einen laufenden Posten:

Jedes Plugin hat einen eigenen Veröffentlichungsrhythmus. Zwanzig Plugins bedeuten zwanzig unabhängige Terminkalender. Es gibt keinen Zeitpunkt, an dem alles gleichzeitig aktuell ist, sondern nur einen Rhythmus, in dem Sie hinterherkommen oder nicht.

Die Konfliktfläche wächst schneller als die Zahl der Plugins. Zwei Erweiterungen können sich stören, drei können sich auf mehr Arten stören. Deshalb ist die zwanzigste Erweiterung teurer in der Pflege als die zweite, obwohl sie dasselbe kostet.

Qualität und Lebensdauer schwanken stark. Manche Erweiterungen werden von Firmen mit Sicherheitsprozess gepflegt, andere von einer einzelnen Person in der Freizeit. Ein Plugin, dessen Entwicklung eingestellt wurde, bleibt funktionsfähig und wird trotzdem zum Risiko, weil bekannt gewordene Lücken nicht mehr geschlossen werden. Diese Erweiterungen zu erkennen und zu ersetzen ist Wartungsarbeit, die in keinem Update-Bildschirm auftaucht.

Lizenzschlüssel laufen ab. Kostenpflichtige Erweiterungen und Themes liefern Aktualisierungen nur bei gültiger Lizenz. Läuft eine Lizenz unbemerkt aus, bleibt die Funktion bestehen, die Sicherheitsaktualisierungen hören aber auf. Das ist eine der häufigsten stillen Lücken in gewachsenen Installationen, und sie fällt erst auf, wenn jemand gezielt danach sucht.

Seitenbaukästen binden Inhalte an sich. Wird die Gestaltung über einen Baukasten erstellt, liegen die Inhalte in dessen eigenem Format. Das erhöht die Abhängigkeit von genau dieser Erweiterung: Sie können sie nicht mehr entfernen, ohne die Seiten neu aufzubauen, also muss sie dauerhaft gepflegt werden, unabhängig davon, wie sie sich entwickelt.

Die Sicherheitsauswertung von Patchstack für das WordPress-Ökosystem zeigt genau dieses Muster: Die überwiegende Mehrheit der gefundenen Schwachstellen steckt in Erweiterungen und Themes und nicht im Kern, und ein erheblicher Teil der kompromittierten Installationen hatte Korrekturen nicht eingespielt, die längst verfügbar waren.

Staging und Rücksprung: die Frage, die vor jedem Update steht

Bei gehosteten Plattformen spielt der Anbieter Änderungen ein und trägt das Risiko. Bei WordPress tragen Sie es, und deshalb ist die Frage, wie aktualisiert wird, keine Formalie.

Eine Testumgebung ist die Grundausstattung, keine Kür. Eine Kopie der Installation, in der Aktualisierungen zuerst eingespielt und die wichtigen Abläufe geprüft werden, bevor sie in den Livebetrieb gehen. Viele Hosting-Angebote bringen so etwas mit. Wird direkt live aktualisiert, ist jede Aktualisierung ein Test mit echten Besuchern.

Die Testumgebung driftet. Das ist der Punkt, an dem der Ansatz in der Praxis scheitert. Inhalte werden im Livebetrieb gepflegt, nicht in der Kopie, also unterscheiden sich die Datenbanken nach wenigen Tagen. Eine Änderung aus der Testumgebung zurück in den Livebetrieb zu spielen bedeutet deshalb nicht, die Datenbank zurückzukopieren, sondern dieselbe Aktualisierung dort erneut auszuführen. Wer das nicht trennt, überschreibt beim ersten Mal die Inhalte von zwei Wochen.

Rücksprung muss definiert sein, bevor er gebraucht wird. Es gibt zwei Wege: eine einzelne Erweiterung auf die Vorversion zurücksetzen, oder aus einer Sicherung wiederherstellen. Der erste ist schnell und eng begrenzt, der zweite vollständig, verwirft aber alles, was seit der Sicherung passiert ist, einschließlich eingegangener Formularanfragen und Bestellungen. Welchen Weg Sie in welchem Fall gehen, gehört vorher festgelegt.

Automatische Aktualisierungen sind eine Abwägung, keine Einstellung. Aktiviert für alles bedeutet, dass Lücken schnell geschlossen werden und ein fehlerhaftes Update unbeaufsichtigt live geht. Deaktiviert für alles bedeutet Kontrolle und die Gefahr, dass eine bekannte Lücke wochenlang offen bleibt. Die praktikable Aufteilung liegt dazwischen: Sicherheitskorrekturen des Kerns automatisch, größere Versionswechsel und alles, was Formulare, Zahlungen oder Anbindungen berührt, von Hand und nach Prüfung.

Der häufigste Schadensfall: ein Update, das still etwas bricht

Bei WordPress denken die meisten beim Wort Sicherheit an einen Angriff. Der teurere und weit häufigere Fall ist unspektakulär: Eine Aktualisierung ändert etwas, ein Formular sendet nicht mehr, und niemand merkt es.

Das passiert, weil ein defektes Formular selten wie ein Fehler aussieht. Die Seite lädt, das Formular wird angezeigt, die Absendung wirkt erfolgreich, und die Nachricht kommt nirgends an. Typische Auslöser sind eine Änderung im Formular-Plugin, eine unterbrochene Verbindung zum CRM oder Newsletter-System nach einer Aktualisierung, ein Spamschutz, der nach einer Schlüsseländerung alles abweist, oder ein Mailversand, der nach einem Serverwechsel nicht mehr zugestellt wird.

Für ein B2B-Unternehmen ist das der teuerste denkbare Fehler, weil er genau die Anfragen kostet, für die die Website gebaut wurde, und weil er sich nicht nachträglich reparieren lässt. Die Gegenmaßnahme ist billig und wird trotzdem selten eingerichtet:

Nach jeder Aktualisierung, die Formulare, Anbindungen oder Zahlungen berührt, eine echte Testabsendung bis in den Posteingang.
Unabhängig davon eine monatliche Testabsendung, auch wenn nichts aktualisiert wurde.
Eine Überwachung, die meldet, wenn über einen ungewöhnlich langen Zeitraum keine Anfrage eingegangen ist. Ausbleibende Anfragen sind das einzige Signal, das ein still defektes Formular erzeugt.

PHP und die Hosting-Ebene: das wiederkehrende kleine Projekt

WordPress läuft auf PHP, und PHP-Versionen werden nur für einen begrenzten Zeitraum mit Sicherheitsaktualisierungen versorgt. Das PHP-Projekt veröffentlicht diesen Zeitplan offen. Praktisch heißt das: Alle paar Jahre muss Ihre Installation auf eine neuere PHP-Version wechseln, ob Sie wollen oder nicht, weil Ihr Hoster die alte irgendwann abschaltet.

Dieser Wechsel ist der Punkt, an dem gewachsene Installationen auffallen. Der Kern selbst kommt in der Regel gut mit neueren PHP-Versionen zurecht. Alte oder nicht mehr gepflegte Erweiterungen tun das nicht, und dann erscheint entweder eine Fehlermeldung oder, unangenehmer, eine leere Seite. Ein PHP-Wechsel ist deshalb kein Hosting-Detail, sondern ein kleines Projekt: erst in der Testumgebung wechseln, prüfen, welche Erweiterungen protestieren, diese aktualisieren oder ersetzen, dann live wechseln.

Zwei weitere Punkte auf derselben Ebene, die selten in Wartungsangeboten stehen:

Die Datenbankversion wandert mit. Auch die Datenbank hinter WordPress bekommt Versionswechsel, meist vom Hoster durchgeführt. Sie sind unproblematischer als PHP-Wechsel, gehören aber in dieselbe Prüfroutine.

Zwischenspeicher machen Fehler unsichtbar. Viele Installationen arbeiten mit Zwischenspeicherung auf Seiten- oder Objektebene und oft zusätzlich mit einem CDN. Das ist gut für die Ladezeit und sorgt regelmäßig dafür, dass eine Änderung scheinbar nicht wirkt oder ein Fehler scheinbar behoben ist. Wer diese Ebenen nicht kennt, sucht den Fehler an der falschen Stelle. Prüfen lässt sich das Ergebnis mit unserem Website-Geschwindigkeitstest.

Was den Aufwand bei Ihrer Installation bestimmt

Zwei WordPress-Websites mit derselben Seitenzahl können in der Pflege weit auseinanderliegen. Diese Merkmale erklären den Unterschied. Gehen Sie die Liste für Ihre eigene Installation durch, bevor Sie Angebote einholen.

Merkmal	Erhöht den Aufwand	Senkt ihn
Zahl der Erweiterungen	Viele, teils überlappend	Wenige, bewusst ausgewählt
Herkunft der Erweiterungen	Einzelentwickler, lange keine Aktualisierung	Aktiv gepflegt, klare Sicherheitspraxis
Lizenzen	Mehrere kostenpflichtige Lizenzen mit eigenen Laufzeiten	Wenige oder keine
Theme	Direkt bearbeitet, ohne Child-Theme	Child-Theme oder Standardtheme mit Anpassung an vorgesehener Stelle
Sonderentwicklung	Eigener Code ohne Dokumentation	Kein oder dokumentierter eigener Code
Aufbau	Mehrsprachigkeit, Shop-Funktion, Mehrfachinstallation	Eine Unternehmenswebsite
Anbindungen	CRM, Buchung, Warenwirtschaft, Zahlungen	Formular an eine Mailadresse
Hosting	Einfaches geteiltes Hosting ohne Testumgebung	Hosting mit Testumgebung, Sicherungen und PHP-Verwaltung
Änderungsfrequenz	Wöchentlich neue Inhalte, mehrere Redaktionszugänge	Seltene Änderungen, ein Zugang

Der Punkt Hosting wird am häufigsten unterschätzt. Ein Hosting-Angebot mit Testumgebung, automatischen Sicherungen und bequemem PHP-Wechsel nimmt Ihnen einen erheblichen Teil der wiederkehrenden Arbeit ab. Bei einem Angebot, das nichts davon mitbringt, wandert dieser Aufwand in Ihre Wartung, wo er sichtbarer und meist teurer ist.

Was eine WordPress-Übergabe enthalten muss

Dies ist der Punkt, an dem ein Wechsel des Dienstleisters unnötig teuer wird, und er ist bei WordPress konkreter als bei gehosteten Plattformen, weil mehr Teile einzeln übergeben werden müssen. Klären Sie das zu Beginn und nicht bei der Kündigung.

Ein Administratorzugang auf Ihren Namen, nicht auf den des Dienstleisters, mit dem Sie weitere Zugänge anlegen und entziehen können.
Zugang zum Hosting und zur Verwaltungsoberfläche, einschließlich Datenbankzugang und der Möglichkeit, die PHP-Version zu ändern.
Kontrolle über die Domain und die DNS-Einträge. Diese gehört ohnehin Ihnen und liegt trotzdem häufig beim Dienstleister.
Alle Lizenzschlüssel für kostenpflichtige Erweiterungen und Themes, mit dem Konto, auf das sie ausgestellt sind. Laufen Lizenzen über das Sammelkonto einer Agentur, verlieren Sie beim Wechsel alle Aktualisierungen auf einmal.
Der Quellcode des Child-Themes und jeder Sonderentwicklung, idealerweise in einem Repository, auf das Sie Zugriff haben.
Zugang zur Testumgebung und die Information, wie sie mit dem Livebetrieb abgeglichen wird.
Ort, Zugangsdaten und Aufbewahrungsdauer der Sicherungen, plus die Angabe, wann zuletzt eine Wiederherstellung geprüft wurde.
Eine Liste der Erweiterungen mit Zweck. Ohne sie beginnt der nächste Dienstleister mit einer Bestandsaufnahme, die Sie bezahlen.

Eine Einordnung zur Plattformwahl

Dieser Artikel behandelt WordPress, weil das die Frage ist, die gestellt wird, und nicht, weil WordPress für jedes Vorhaben die richtige Wahl wäre. Die ehrliche Einordnung lautet: Der Aufwand verschiebt sich zwischen den Plattformkategorien, er verschwindet bei keiner.

Bei einer gehosteten Baukasten- oder SaaS-Plattform entfällt ein großer Teil der hier beschriebenen technischen Pflege, weil der Anbieter Kern, PHP-Ebene und Sicherheit übernimmt. Dafür geben Sie Kontrolle ab: Umbauten, Funktionsänderungen und Konditionen entscheidet der Anbieter, und Inhalt, Recht, Überwachung und Auffindbarkeit bleiben trotzdem vollständig bei Ihnen. Bei Individualentwicklung wandert die Pflege in den Code und die eingebundenen Bibliotheken, was weniger Klickarbeit bedeutet, aber verlässlichen Zugriff auf jemanden mit Entwicklungskenntnis voraussetzt.

Welche Kategorie zu Ihnen passt, hängt daran, wer bei Ihnen pflegt, wie oft sich Inhalte ändern und wie viel Kontrolle Sie behalten wollen. Der Vergleich der Kategorien steht im Beitrag dazu, was Website-Wartung ist, und wie Ihr Team im Alltag mit dem System arbeitet, ordnet der Beitrag dazu ein, wie Sie Ihre Website selbst bearbeiten. Wir bauen plattformseitig nach Anforderung und nicht nach Vorliebe.

Häufige Fragen

Wie oft muss eine WordPress-Website gewartet werden?

Sicherheitsrelevante Aktualisierungen zeitnah, sobald sie erscheinen. Übrige Aktualisierungen, Sicherungsprüfung und Formulartest sinnvollerweise monatlich in einem festen Termin. Einmal im Quartal zusätzlich eine Durchsicht des Erweiterungsbestands, der Lizenzlaufzeiten und der PHP-Version. Der Rhythmus wiegt schwerer als der Umfang: Eine kleine, verlässliche Routine schlägt eine große, unregelmäßige Aktion.

Können wir einfach alle automatischen Updates einschalten?

Für Sicherheitskorrekturen des Kerns ist das vertretbar und meist sinnvoll. Für alles, was Formulare, Zahlungen, Anbindungen oder die Gestaltung berührt, ist es riskant, weil ein fehlerhaftes Update dann unbeaufsichtigt live geht und der Schaden still bleibt. Die praktikable Regel lautet: automatisch, wo der Ausfall sofort sichtbar wäre, von Hand, wo er unsichtbar bliebe.

Was passiert, wenn wir ein Jahr lang gar nichts machen?

Die Website läuft in der Regel weiter, und genau das ist die Falle. In der Zwischenzeit sammeln sich ungeschlossene Lücken in Erweiterungen an, Lizenzen laufen ab, der Abstand zur aktuellen PHP-Version wächst, und die spätere Aktualisierung wird von einer Routine zu einem Projekt, weil zu viele Versionssprünge auf einmal nachgeholt werden müssen. Der Aufwand verschwindet nicht, er wird größer.

Brauchen wir ein Sicherheits-Plugin?

Ein Plugin ersetzt keine Aktualisierungen. Der weit größere Hebel sind aktuelle Erweiterungen, saubere Zugänge mit Zwei-Faktor-Anmeldung, ein gültiges SSL-Zertifikat und geprüfte Sicherungen. Ein zusätzliches Sicherheits-Plugin kann sinnvoll sein, ist aber selbst wieder eine Erweiterung, die gepflegt werden muss.

Sollten wir die Wartung selbst machen oder abgeben?

Das hängt daran, ob jemand intern dafür benannt ist und Zeit dafür hat. Der häufigste Grund für vernachlässigte Installationen ist nicht fehlende Kompetenz, sondern fehlende Zuständigkeit. Die Abwägung im Detail behandelt der Beitrag dazu, die WordPress-Wartung auszulagern.

Was gehört in den Vertrag, wenn wir abgeben?

Leistungsumfang, Reaktionszeiten, Eigentum an Zugängen und die Übergabe bei Vertragsende. Diese Punkte sind nicht WordPress-spezifisch und stehen vollständig im Beitrag zum Website-Wartungsvertrag und SLA.

Bereit, Ihre Installation ehrlich zu prüfen?

Sagen Sie uns, wie viele Erweiterungen Ihre Installation trägt, wer sie heute pflegt und wann zuletzt eine Sicherung zurückgespielt wurde, und wir sagen Ihnen, wo die Lücken liegen. So arbeiten wir auch, wenn wir eine Website erstellen lassen begleiten: Der Livegang ist der Anfang, nicht das Ende. Vereinbaren Sie Ihr kostenloses Erstgespräch.