WordPress-Wartung: was ein Update-Prozess wirklich leisten muss

Warum verursacht blindes Aktualisieren im laufenden Betrieb die meisten Ausfälle?

Blindes Aktualisieren im laufenden Betrieb fällt so oft aus, weil dabei mehrere unabhängig entwickelte Codebasen gleichzeitig ihren Zustand ändern und niemand vorher geprüft hat, ob die neuen Zustände zusammenpassen. Eine gewachsene WordPress-Installation besteht nicht aus einem Programm. Sie besteht aus dem Kern, einem Theme, oft einem Child-Theme, dazu zwanzig bis fünfzig Plugins, einem Page-Builder mit eigenen Addons, bei WooCommerce zusätzlich Zahlungs- und Versandmodulen, dazu einer PHP-Version, einer Datenbankversion und einem Webserver mit eigener Konfiguration. Jede dieser Teile hat einen eigenen Herausgeber, einen eigenen Releasetakt und eine eigene Vorstellung davon, was Rückwärtskompatibilität bedeutet.

Der Ausfall entsteht selten im Wesentlichen. Er entsteht an den Nahtstellen. Ein Plugin ruft eine Funktion auf, die in der neuen Kernversion als veraltet markiert oder entfernt wurde. Ein Theme erwartet eine Klasse aus einer Builder-Version, die es nach dem Update nicht mehr gibt. Ein Zahlungsmodul aktualisiert seinen Datenbankschema-Migrator, der Migrator läuft in einen Timeout, und der Shop bleibt in einem halb migrierten Zustand stehen. Solche Zustände sind besonders unangenehm, weil sie sich nicht durch ein zweites Update reparieren lassen, sondern nur durch Zurücksetzen auf einen Stand vor dem Vorgang.

Dazu kommt der Effekt vieler gleichzeitiger Änderungen. Wer in der Update-Übersicht alles anhakt und einmal auslost, ändert in dreißig Sekunden zwanzig Dinge. Wenn danach die Kasse leer bleibt, ist unklar, welche der zwanzig Änderungen es war. Die Fehlersuche in so einem Zustand kostet regelmäßig ein Vielfaches der Zeit, die eine gestaffelte Reihenfolge gekostet hätte. Belegen lässt sich das nicht mit einer Statistik, nur mit der Wiederholung über viele Projekte hinweg. Es deckt sich aber mit dem, was die offizielle WordPress-Dokumentation empfiehlt: vor einem manuellen Upgrade erst sichern, dann alle Plugins deaktivieren, dann den Kern tauschen.

Die zweite Hälfte des Problems ist Zeitdruck. Die Patchstack-Auswertung für 2025 nennt einen gewichteten Median von fünf Stunden zwischen Veröffentlichung einer stark ausgenutzten Lücke und dem ersten beobachteten Angriff, und rund die Hälfte der Lücken mit hoher Auswirkung wird innerhalb von 24 Stunden angegriffen. Wer also grundsätzlich langsam und vorsichtig arbeitet, verliert an anderer Stelle. Ein ernsthafter Prozess braucht beides: einen schnellen Pfad für Sicherheitsreleases und einen langsamen, geprüften Pfad für alles andere.

Nicht das Update ist das Risiko, sondern die Kombination aus vielen gleichzeitigen Änderungen und keinem Rückweg.

Ein Beispiel aus dem laufenden Jahr zeigt, wie eng die Fristen sind. WordPress 7.0 erschien am 20. Mai 2026, am 9. Juli folgte 7.0.1 als Wartungsrelease, und am 17. Juli 2026 kam 7.0.2 als Sicherheitsrelease mit einer als kritisch und einer als hoch eingestuften Lücke. Wegen der Schwere hat das Team auf wordpress.org für betroffene Versionen erzwungene Auto-Updates aktiviert. Gleichzeitig erschienen 6.9.5 und 6.8.6 mit den zurückportierten Korrekturen. Wer in dieser Woche eine Freigabe für Sicherheitsreleases nicht vorbereitet hatte, hat entweder zu spät aktualisiert oder wurde von einem erzwungenen Update überrascht. Beides ist vermeidbar, wenn die Regel vorher schriftlich feststeht. Mehr zum Rahmen steht auf unserer Seite zur Website-Wartung.

Was prüft man auf der Kopie, die man Staging nennt?

Auf der Kopie prüft man genau die Wege, an denen Geld, Daten oder Rechte den Besitzer wechseln, und zwar mit echten Inhalten und derselben PHP- und Datenbankversion wie im Betrieb. Eine Kopie, die nur die Startseite zeigt, beweist nichts. Ein Staging verdient den Namen erst, wenn es die Produktionsdatenbank in aktuellem Stand enthält, dieselbe PHP-Nebenversion fährt, dieselben Serverbeschränkungen kennt und dieselben Plugins in denselben Versionen aktiv hat. Abweichungen bei Speichergrenze, maximaler Ausführungszeit oder Dateirechten erzeugen Fehler, die es im Betrieb nicht gibt, und verdecken Fehler, die es dort geben wird.

Der Prüflauf selbst ist eine Liste, keine Stimmung. Wir arbeiten sie ab, protokollieren jeden Punkt und halten fest, in welcher Version welcher Punkt zuletzt grün war. Dieses Protokoll ist später das Werkzeug, mit dem sich ein Fehler auf ein bestimmtes Update zurückführen lässt.

Was auf der Kopie regelmäßig übersehen wird

Die wiederkehrenden Lücken im Prüflauf liegen fast immer bei Dingen, die auf einer Kopie technisch nicht funktionieren dürfen. Ausgehende Mails sind der Klassiker: Auf Staging werden sie oft abgefangen, damit keine Testbestellung beim Kunden landet. Genau deshalb fällt nicht auf, dass das Update den Mailversand kaputt gemacht hat. Dasselbe gilt für Zahlungsanbieter im Testmodus, für Schnittstellen zum Warenwirtschaftssystem, die auf Staging auf ein Dummy-Ziel zeigen, und für Cronjobs, die auf der Kopie abgeschaltet sind, damit sie keine Rechnungen doppelt schreiben.

Der zweite blinde Fleck sind Dateirechte und Pfade. Wer die Kopie in ein Unterverzeichnis legt, prüft nicht dieselbe Adressstruktur, und Umschreiberegeln in der htaccess verhalten sich anders. Der dritte ist Datenmenge. Eine Kopie mit fünfzig Produkten sagt nichts über ein Update, das bei zwanzigtausend Produkten eine Tabellenmigration ausführt. Wenn eine Migration im Spiel ist, muss die Kopie den vollen Datenbestand enthalten, sonst ist die gemessene Laufzeit ohne Wert.

Der vierte blinde Fleck ist der Weg zurück von der Kopie in den Betrieb. Wer auf Staging arbeitet und die Änderungen dann von Hand im Betrieb nachzieht, hat zwei Systeme, die auseinanderlaufen. Wer die Kopie komplett über den Betrieb schreibt, überschreibt die Bestellungen und Kommentare, die in der Zwischenzeit hereingekommen sind. Der belastbare Weg besteht darin, auf der Kopie nur zu prüfen und im Betrieb dieselben Schritte in derselben Reihenfolge zu wiederholen, mit dem Protokoll aus dem Prüflauf als Vorlage.

Woran erkennt man ein Backup, das man wirklich zurückspielen kann?

Ein Backup ist erst dann brauchbar, wenn es einmal vollständig auf ein leeres System zurückgespielt und dort geprüft wurde, und zwar ohne Zugriff auf das Original. Alles andere ist eine Datei mit einem beruhigenden Namen. Die offizielle WordPress-Dokumentation formuliert das im Abschnitt zum manuellen Upgrade ungewöhnlich deutlich: Prüfen Sie, dass die erzeugten Sicherungen vorhanden und benutzbar sind, das ist wesentlich. Diese Prüfung ist der Punkt, an dem die meisten Wartungsangebote endet, und der Punkt, an dem ein Wartungsvertrag seinen Wert beweist.

Ein vollständiges Backup einer WordPress-Instanz umfasst vier Dinge, nicht zwei. Erstens die Datenbank als Export mit Zeichensatz und Tabellenpräfix. Zweitens das Verzeichnis wp-content mit Uploads, Themes, Plugins und Sprachdateien. Drittens die Konfiguration, also wp-config.php, die htaccess mit eigenen Regeln, dazu Cronjob-Definitionen und, wenn vorhanden, die Serverkonfiguration für diese Domain. Viertens die Randbedingungen: PHP-Version, PHP-Erweiterungen, Datenbankversion, Zertifikat und DNS-Einträge. Wer die vierte Gruppe nicht dokumentiert, hat im Notfall die Daten und weiß nicht, in welche Umgebung sie gehören.

Aufbewahrung gehört dazu. Eine einzelne Kopie, die jede Nacht überschrieben wird, hilft gegen ein misslungenes Update und nicht gegen eine Infektion, die vier Wochen unbemerkt lief. Wir arbeiten mit gestaffelten Stufen: täglich mit kurzer Haltezeit, wöchentlich mit mittlerer, monatlich mit langer. Mindestens eine Stufe liegt auf einem Ziel, das der Webserver nicht selbst beschreiben kann, damit ein Angreifer mit Schreibrechten auf dem Server die Sicherungen nicht mit vernichtet. Das BSI beschreibt diesen Aufbau im IT-Grundschutz-Kompendium als Datensicherungskonzept mit definierten Aufbewahrungsfristen und getrennter Ablage.

Wie oft eine Rückspielung geübt wird

Wir spielen pro betreuter Installation mindestens einmal im Quartal eine vollständige Sicherung auf eine leere Umgebung zurück und messen dabei die Zeit. Bei Shops mit Umsatzabhängigkeit machen wir das monatlich. Die gemessene Zeit ist die eigentliche Kennzahl, denn sie ist die Antwort auf die Frage, die im Vorfall gestellt wird: Wie lange dauert es, bis die Seite wieder läuft. Wer diese Zahl nicht hat, verhandelt im Vorfall unter Druck über Erwartungen statt über Abläufe.

Zusätzlich prüft ein täglicher automatischer Lauf drei billige Merkmale: Ist die Archivdatei entstanden, hat sie eine plausible Größe im Vergleich zum Vortag, und lässt sich der Datenbankexport ohne Fehler einlesen. Diese drei Prüfungen kosten wenige Minuten Rechenzeit und fangen die häufigsten stillen Fehler ab, nämlich einen abgebrochenen Export, ein volles Ziel und eine Sicherung, die seit einem Serverumzug auf ein Verzeichnis zeigt, das es nicht mehr gibt. In Projekten ist uns die abgeschnittene Datenbank deutlich häufiger begegnet als der komplett fehlende Lauf, weil ein fehlender Lauf auffällt und eine zu kleine Datei nicht.

In welcher Reihenfolge gehen PHP, Kern, Plugins und Theme?

Die Reihenfolge lautet: erst PHP auf die höchste Version heben, die der aktuelle Stand verträgt, dann den Kern, dann die Plugins in Gruppen, dann das Theme, und jeder Schritt einzeln mit einem Prüflauf dazwischen. Der Grund ist nicht Aberglaube, sondern Zurechenbarkeit. Wenn nach einem Schritt ein Fehler auftritt, kennt man die Ursache ohne Suche. Wer PHP und Kern gleichzeitig hebt, hat bei einem Fehler zwei Verdächtige und braucht einen zusätzlichen Durchgang, um sie zu trennen.

PHP zuerst hat einen weiteren Vorteil. Neue Kern- und Plugin-Versionen setzen zunehmend höhere PHP-Mindestversionen voraus. WordPress empfiehlt in den offiziellen Anforderungen PHP 8.3 oder neuer, dazu MariaDB ab 10.11 oder MySQL ab 8.0, und bezeichnet HTTPS als Pflicht für jede Installation. Technisch läuft WordPress weiter ab PHP 7.4 und MySQL 5.5.5, aber die Projektseite weist selbst darauf hin, dass diese Versionen ihr Lebensende erreicht haben und die Seite Schwachstellen aussetzen können. Wer PHP als letztes anfasst, schiebt die Arbeit vor sich her, bis ein Sicherheitsrelease sie erzwingt.

Innerhalb der Plugins hilft eine Gruppierung nach Wirkung. Zuerst gehen die Plugins, die nur an einer Stelle wirken und keine Daten schreiben, etwa ein Kontaktformular oder ein Cookie-Hinweis. Dann die, die Inhalte erzeugen, also Builder und Blocksammlungen. Dann die, die in die Datenbank migrieren, also Shop, Buchhaltung, Mitgliederverwaltung. Zuletzt das Theme, weil es auf allem aufsitzt und weil Themefehler optisch auffallen und selten den Betrieb anhalten. Sicherheitsreleases brechen diese Reihenfolge bewusst: Wenn eine aktiv ausgenutzte Lücke gemeldet ist, geht dieses eine Paket sofort und allein, danach folgt der geplante Rest.

Große Kernsprünge behandeln wir wie ein kleines Projekt und nicht wie Wartung. Der Sprung von einer Hauptversion auf die nächste, etwa von der 6.9er Linie auf 7.0, bringt Änderungen an Editor und Vorlagen mit, die Redaktionsarbeit betreffen. Solche Sprünge planen wir mit Termin, mit einem Zeitfenster geringer Nutzung und mit einer Person auf Abruf, die im Zweifel zurücksetzt. Zwischen den Sprüngen laufen die Nebenversionen im normalen Takt.

Wo sind automatische Updates sinnvoll und wo nicht?

Automatische Updates sind sinnvoll für Nebenversionen des Kerns, für Sprachdateien und für wenige, sehr gut gepflegte Plugins ohne Datenbankmigration, und sie sind ungeeignet für Hauptversionen, für Page-Builder, für Shop-Erweiterungen und für alles, was Bestell- oder Kundendaten anfasst. WordPress kennt diese Unterscheidung selbst. Automatische Hintergrund-Updates gibt es seit Version 3.7, standardmäßig aktiv für Nebenversionen des Kerns und Übersetzungen. Seit Version 5.6 sind bei neuen Installationen auch Hauptversionen voreingestellt, sofern WordPress keine Arbeitskopie einer Versionsverwaltung erkennt; bestehende Installationen behalten das alte Verhalten.

Steuern lässt sich das über die Konstante WP_AUTO_UPDATE_CORE in der wp-config.php mit den Werten true, false und minor, wobei minor genau die Kombination erzeugt, die für betreute Seiten meistens richtig ist: Nebenversionen automatisch, Hauptversionen von Hand. Die Konstante AUTOMATIC_UPDATER_DISABLED schaltet alles ab, was die Dokumentation ausdrücklich nicht empfiehlt. Für einzelne Plugins und Themes gibt es seit WordPress 5.5 eine Oberfläche in der Verwaltung, mit der sich die automatische Aktualisierung pro Paket einschalten lässt.

Die Grenze der Automatik liegt dort, wo ein Update etwas verändert, das sich nicht durch ein zweites Update heilen lässt. Eine Schemamigration im Shop gehört dazu, eine Änderung an der Adressstruktur, eine neue Pflichtangabe in einem Formular. In diesen Fällen ist die Automatik nicht zu langsam, sondern zu ahnungslos: Sie kennt den Zustand nach dem Vorgang nicht und kann nicht zurücksetzen. Ein Wartungsprozess bildet das ab, indem er der Automatik nur die Klassen überlässt, bei denen ein Fehlschlag durch das nächste Update behoben wird.

Wichtig ist der Sonderfall, den WordPress selbst nutzt. Bei besonders schweren Lücken schaltet wordpress.org erzwungene Auto-Updates für betroffene Versionen frei, wie im Juli 2026 bei 7.0.2 dokumentiert. Wer alle Automatik abgeschaltet hat, verliert damit auch diesen Notpfad. Wir lassen die Nebenversionen des Kerns deshalb grundsätzlich automatisch laufen und begleiten sie mit Überwachung, statt sie zu blockieren.

Was muss eine Überwachung melden, damit sie etwas wert ist?

Eine Überwachung ist erst dann etwas wert, wenn sie einen Menschen erreicht, der zuständig ist und handeln darf, und wenn sie mehr prüft als die Frage, ob der Server antwortet. Ein Ping auf die Startseite meldet nichts, wenn die Kasse einen Fehler wirft, wenn das Zertifikat in vier Tagen abläuft oder wenn seit vorgestern eine Weiterleitung auf eine fremde Domain in der index.php steht. Die Signale, die im Betrieb wirklich Arbeit auslösen, sind überschaubar, und jedes braucht eine Schwelle und einen Weg.

Beim Zertifikat lohnt der Blick auf die Fristen, weil sie sich gerade verkürzen. Die Baseline Requirements des CA/Browser Forum senken die maximale Gültigkeit von Serverzertifikaten stufenweise: 200 Tage für Zertifikate ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Parallel sinkt die Zeit, für die eine Domainprüfung wiederverwendet werden darf, ab 2029 auf zehn Tage. Let's Encrypt gibt Zertifikate ohnehin mit 90 Tagen Laufzeit aus und bietet auf Wunsch sechs Tage an. Damit wird die Erneuerung endgültig zur Maschinenaufgabe, und die Überwachung muss nicht das Ablaufdatum melden, sondern das Ausbleiben der automatischen Erneuerung.

Die Überwachung von Dateiänderungen verdient besondere Aufmerksamkeit, weil moderne Schadsoftware genau dort ansetzt. Die Patchstack-Auswertung für 2025 beschreibt, dass Angreifer verstärkt Schnipsel in vorhandene, legitime Kern-, Plugin- und Theme-Dateien einbauen statt eigene Dateien abzulegen, weil sich eingebaute Änderungen nicht einfach löschen lassen. Beschrieben ist auch eine Familie, die Code im Serverspeicher hält und Dateien wie index.php und htaccess unmittelbar nach dem Bereinigen erneut verändert. Ein Vergleich der Kerndateien gegen die Originale aus dem offiziellen Paket ist deshalb kein Luxus, sondern die einzige verlässliche Methode, solche Änderungen zu sehen.

Suchmaschinenwarnungen sind das Signal, das am häufigsten fehlt, weil niemand die Search Console eingerichtet hat. Dabei ist es oft das erste, das überhaupt Alarm gibt: Ein Teil der verbreiteten Kampagnen liefert Suchmaschinen anderen Inhalt als Menschen, und einzelne Varianten erkennen inzwischen sogar Crawler von KI-Diensten und zeigen ihnen saubere Seiten. Wer die Seite nur im eigenen Browser prüft, sieht nichts. Wer die Warnung von Google erhält, sieht es an dem Tag, an dem es passiert. Genau deshalb gehört der Zugang zur Search Console in die Bestandsliste und die Warnung in den Alarmweg.

Wer haftet, wenn nach einem Vorfall Daten abfließen?

Verantwortlich bleibt der Betreiber der Website, also das Unternehmen, das die Verarbeitung bestimmt, und diese Verantwortung lässt sich durch die Beauftragung einer Agentur nicht abgeben, sondern nur organisieren. Artikel 32 der Datenschutz-Grundverordnung verlangt vom Verantwortlichen technische und organisatorische Maßnahmen nach dem Stand der Technik, ausdrücklich einschließlich eines Verfahrens zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit dieser Maßnahmen. Genau das ist ein Wartungsprozess mit Protokoll: der belegbare Teil dieses Verfahrens.

Nach einem Vorfall greift Artikel 33: Eine Verletzung des Schutzes personenbezogener Daten ist der Aufsichtsbehörde möglichst binnen 72 Stunden nach Bekanntwerden zu melden, und wenn die Meldung später erfolgt, ist die Verzögerung zu begründen. Diese 72 Stunden sind der Grund, warum die Fragen nach Verweildauer, betroffenen Daten und Umfang schnell beantwortbar sein müssen. Ohne Logs, ohne Dateivergleich und ohne Backup-Historie ist keine dieser Fragen in drei Tagen zu klären, und die Meldung wird zur Vermutung.

Auf der Geldseite steht Artikel 82 mit dem Schadenersatzanspruch betroffener Personen. Im Verhältnis zwischen Auftraggeber und Dienstleister gilt Paragraf 280 BGB: Wer eine Pflicht aus dem Schuldverhältnis verletzt, haftet für den daraus entstehenden Schaden. Welche Pflichten das sind, steht im Vertrag, und deshalb ist die genaue Beschreibung der Wartungsleistung kein Papierkram, sondern die Grenze der Zurechnung. Innerhalb einer GmbH kommt Paragraf 43 GmbHG hinzu: Geschäftsführer haben die Sorgfalt eines ordentlichen Geschäftsmanns anzuwenden und haften der Gesellschaft für verursachte Schäden. Der Verzicht auf Sicherungen und Updates ist damit eine Entscheidung mit persönlicher Dimension und keine bloße Sparmaßnahme in der IT.

Praktisch heißt das: Der Wartungsvertrag benennt, wer welche Klasse von Updates in welcher Frist einspielt, wer Sicherungen erzeugt und prüft, wer im Vorfall die erste Meldung erhält und wer die Behördenmeldung verantwortet. Diese vier Punkte schriftlich zu haben, ist im Ernstfall mehr wert als jedes zusätzliche Sicherheitsplugin. Wenn der Ernstfall schon eingetreten ist, hilft die Beschreibung unter Website gehackt beim ersten Sortieren.

Was macht man mit verwaisten Plugins und Herstellern, die nicht mehr liefern?

Verwaiste Erweiterungen werden ersetzt, übernommen oder eingefroren und abgeschirmt, und die Entscheidung fällt nach Angriffsfläche und Ersetzbarkeit, nicht nach Gewohnheit. Die Zahlen sprechen dafür, das ernst zu nehmen. Patchstack zählt für das Jahr 2025 im WordPress-Umfeld 11.334 neue Schwachstellen, ein Plus von 42 Prozent gegenüber 2024. Das sind im Schnitt etwa 31 Meldungen pro Tag. 91 Prozent betrafen Plugins, 9 Prozent Themes, und im Wesentlichen selbst waren es sechs Meldungen mit niedriger Priorität. 1.966 Meldungen, also 17 Prozent, waren so eingestuft, dass eine massenhafte automatisierte Ausnutzung wahrscheinlich ist.

Der Punkt, der Wartung wirklich schwer macht, ist ein anderer: Bei 46 Prozent der Schwachstellen lag zum Zeitpunkt der Veröffentlichung keine Korrektur des Herstellers vor. Aktualisieren allein kann also knapp die Hälfte der bekannten Fälle nicht lösen, weil es nichts gibt, worauf man aktualisieren könnte. Wer sein Risiko ausschließlich mit Updates steuert, hat für diese Hälfte keinen Plan. Was dann bleibt, ist Reduktion der Angriffsfläche: Erweiterung entfernen, Funktion anders lösen, betroffene Endpunkte sperren oder den Zugriff auf angemeldete Benutzer beschränken.

Bezahlte Erweiterungen sind dabei nicht die sicherere Wahl. Aus den Bug-Bounty-Meldungen des Jahres 2025 waren 1.983 Berichte, also 29 Prozent, bezahlten oder teilbezahlten Komponenten zuzuordnen, und 76 Prozent davon waren in realen Angriffen ausnutzbar. Bei tatsächlich beobachteten Angriffen kamen auf bezahlte Komponenten dreimal so viele nachgewiesen ausgenutzte Lücken wie auf freie. Der Grund ist Sichtbarkeit: Wer den Quellcode nur nach Kauf bekommt, wird seltener geprüft, und seltener geprüft bedeutet nicht besser.

Für die Praxis sortieren wir jede Erweiterung nach vier Merkmalen: letztes Release, Reaktion auf offene Meldungen im Supportforum, Kompatibilitätsangabe zur aktuellen Kernversion und Verfügbarkeit des Quellcodes. Fehlt bei einem Paket seit zwei Jahren jedes Release, ist das ein Befund und nicht bloß ein Schönheitsfehler. Bei freien Plugins aus dem offiziellen Verzeichnis gibt es einen geordneten Weg, ein aufgegebenes Paket zu übernehmen; das Plugin-Team beschreibt Voraussetzungen und Ablauf in seinem Handbuch. Für Whitelabs ist dieser Weg die Ausnahme, weil Übernahme dauerhafte Pflege bedeutet, aber bei einer Erweiterung, die ein Geschäftsmodell trägt, ist er billiger als ein Neubau.

• Ersetzen: gleiche Funktion in einem gepflegten Paket, Datenmigration einmalig, danach kein Sonderfall mehr.
• Übernehmen: Quellcode vorhanden, Funktion geschäftskritisch, Pflege wird verabredet und bezahlt.
• Einfrieren und abschirmen: Version festnageln, Endpunkte sperren, Zugriff beschränken, Ausstiegstermin setzen.
• Entfernen: Funktion wird faktisch nicht genutzt, das kommt häufiger vor als erwartet und ist die billigste Lösung.
• Selbst bauen: nur bei kleinem, klar umrissenem Umfang, sonst wird aus einem verwaisten Plugin ein eigenes.

Zur Sortierung gehört auch die Ehrlichkeit, dass Schutzsoftware diese Lücke nicht schließt. Patchstack hat 2025 zwei Testreihen gegen verbreitete Abwehrmaßnahmen in Hosting-Umgebungen gefahren. In der ersten wurden 12 Prozent der WordPress-spezifischen Angriffe geblockt, in der zweiten mit breiterem Umfang 26 Prozent. Eine Firewall vor der Seite ist damit eine sinnvolle Ergänzung und kein Ersatz für aktuelle Software und begrenzte Angriffsfläche.

Wie verhindert Dokumentation, dass alles an einer Person hängt?

Dokumentation verhindert Personenabhängigkeit, wenn sie so geschrieben ist, dass eine fachlich geeignete Person ohne Vorwissen die Seite von einem leeren Server aus wieder aufbauen kann. Das ist der Prüfmaßstab, nicht Vollständigkeit und nicht Schönheit. Wir schreiben diese Unterlage bewusst kurz und prüfen sie bei jeder quartalsweisen Rückspielung mit, denn eine Anleitung, nach der niemand jemals gearbeitet hat, ist eine Vermutung.

• Bestandsliste: Domains, DNS-Verwalter, Hosting, Zertifikatsherkunft, Mailversand, externe Dienste mit Zweck.
• Softwarestand: Kernversion, PHP- und Datenbankversion, jede Erweiterung mit Version, Herkunft und Lizenz.
• Eigenbau: welche Datei welchen Zweck hat, warum sie existiert, was bricht, wenn sie fehlt.
• Sicherung: was gesichert wird, wohin, wie lange, wie man zurückspielt, wann das zuletzt geübt wurde.
• Zugänge: welche Konten existieren, wer sie besitzt, wo die Geheimnisse liegen, wer im Notfall ran darf.
• Update-Regeln: welche Klasse automatisch läuft, welche im Fenster, welche nur mit Freigabe.
• Vorfallweg: erste Meldung, Bereitschaft, Reihenfolge der Schritte, wer die Behördenmeldung verantwortet.

Zugänge sind der Teil, an dem Übergaben am häufigsten scheitern. Ein Wartungsvertrag sollte festhalten, dass der Kunde Eigentümer aller Konten bleibt, also der Domain, des Hostings, der Lizenzen und der Zugänge zu Zahlungsanbietern. Die Agentur arbeitet mit eigenen, benannten Zugängen, die sich einzeln entziehen lassen. Geteilte Sammelkonten sind bequem, aber sie machen jede Übergabe zu einer Vertrauensfrage und jeden Austritt eines Mitarbeiters zu einem Sicherheitsvorfall. Bei Joomla-, TYPO3- oder Contao-Installationen ist der Ablauf im Wesentlichen derselbe, nur die Namen der Verzeichnisse ändern sich.

Zur Übergabefähigkeit gehört auch, dass Änderungen nachvollziehbar sind. Wir halten Erweiterungen und eigene Anpassungen unter Versionsverwaltung und aktualisieren mit Kommandozeilenwerkzeugen statt über die Verwaltungsoberfläche, weil sich ein Befehl protokollieren, wiederholen und in ein Skript legen lässt. WP-CLI dokumentiert dafür eigene Befehle für Plugin-Aktualisierungen und Datenbankexporte. Der Nebeneffekt ist, dass der Prüflauf auf der Kopie und der Vorgang im Betrieb tatsächlich dieselben Schritte sind und nicht zwei ähnliche.

Welche Arbeit kann ein Kunde selbst übernehmen?

Ein Kunde kann alles übernehmen, was Kenntnis des eigenen Geschäfts verlangt und keinen Serverzugriff braucht, und genau dort ist seine Mitarbeit auch am wertvollsten. Der fachliche Prüflauf ist das beste Beispiel. Niemand in einer Agentur weiß so gut wie die Shopverwaltung, welche Gutscheinregel im letzten Jahr Ärger gemacht hat und welcher Versandfall der komplizierte ist. Wenn der Kunde nach einem Update fünfzehn Minuten die drei Vorgänge durchklickt, die bei ihm Geld bewegen, ersetzt das keine technische Prüfung, fängt aber genau die Fälle, die eine Liste nicht kennt.

Zwei Dinge sollten Kunden nicht selbst machen, auch wenn die Oberfläche es anbietet. Das erste ist das Update mit Datenbankmigration ohne Sicherung, also Shop, Buchhaltung, Mitgliederverwaltung. Das zweite sind Änderungen an wp-config.php, htaccess oder Dateirechten nach einer Anleitung aus dem Netz. Beides ist schnell erledigt und im Fehlerfall teuer, weil der Ausgangszustand nicht mehr bekannt ist. In Projekten war der teuerste Einzelposten oft nicht der Fehler selbst, sondern die Rekonstruktion dessen, was vorher da war.

Was sich zusätzlich lohnt, ist eine Ansprechperson auf Kundenseite, die Bescheid weiß. Nicht technisch, sondern organisatorisch: Wer entscheidet über ein Wartungsfenster, wer darf eine Bestellung stornieren, wer ist am Wochenende erreichbar. Diese eine Rolle spart im Vorfall mehr Zeit als jedes Werkzeug, weil Entscheidungen dann nicht warten müssen. Für die Abstimmung eines solchen Rahmens genügt ein Termin über Kontakt.

Welcher Takt hält eine Seite über Jahre stabil?

Stabil bleibt eine Seite mit vier verschachtelten Takten: täglich automatische Prüfungen, wöchentlich der gestaffelte Update-Lauf mit Prüflauf, quartalsweise die geübte Rückspielung samt Bestandsdurchsicht, jährlich die Entscheidung über PHP-Version, Hauptversionssprung und Ausmusterung alter Erweiterungen. Dazwischen liegt der Sonderpfad für Sicherheitsreleases, der jeden Takt unterbricht. Diese Struktur ist unspektakulär, aber sie hat den Vorteil, dass jede Aufgabe einen festen Platz hat und nichts von Aufmerksamkeit abhängt.

Der jährliche Takt bekommt derzeit zusätzliches Gewicht. PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates, PHP 8.3 ist seit Ende 2025 aus dem aktiven Support und bekommt bis Ende 2027 nur noch Sicherheitskorrekturen, und WordPress empfiehlt in den Anforderungen inzwischen mindestens PHP 8.3. Wer heute auf 8.2 läuft, hat also ein konkretes Datum im Kalender und nicht ein vages Später. Parallel steht mit der 7.1er Linie der nächste Hauptversionssprung an, der zum Zeitpunkt dieses Beitrags in der Beta-Phase ist.

Ein letzter Punkt aus der Praxis betrifft die Jahreszeit. Die Auswertung für 2025 beschreibt einen deutlichen Anstieg schädlicher Datei-Uploads im November und Dezember, mit einer nahezu Verdreifachung des Volumens, weil hoher Umsatz und dünne Personaldecke zusammenfallen. Für Shops heißt das: Hauptversionssprung und PHP-Wechsel gehören in den Sommer oder in den Januar, nicht in die Woche vor dem Weihnachtsgeschäft. Im November läuft nur der Sonderpfad für Sicherheitsreleases, und die Bereitschaft ist dichter besetzt.

Was ein Wartungsvertrag also leistet, ist keine Magie und kein Werkzeug, sondern die Zusage, dass diese Takte laufen, dass Befunde protokolliert werden und dass es einen geübten Rückweg gibt. Der Klick auf Aktualisieren ist darin der kürzeste Schritt. Alles davor und danach entscheidet, ob er ohne Folgen bleibt.