WordPress-Wartung: Sicherheitsupdates, Backups, laufender Betrieb

Enthalten sind Beobachtung und Bewertung der Sicherheitsmeldungen zu Core, Plugins und Theme, Updates erst auf Staging und dann live, Plugin- und Theme-Pflege, Pflege von PHP, Datenbank, TLS und Mailversand, Backups mit Rücksicherungstest, Monitoring, Redaktionssupport und ein Protokoll der Arbeiten. Reguläre Versionssprünge auf einem gepflegten System, etwa von 7.0 auf 7.1, gehören dazu. Nicht enthalten sind Redesigns, neue Funktionen, die Entwicklung eigener Plugins und Blöcke sowie das Aufholen einer Installation, die jahrelang nicht angefasst wurde — das ist ein eigenes Projekt mit eigener Planung.

WordPress aktualisiert seit Version 3.7 Minor-Releases automatisch, und seit Version 5.6 sind bei neuen Installationen auch Major-Releases voreingestellt, sofern kein Version-Control-Checkout erkannt wird; bestehende Installationen behalten das alte Verhalten. Automatisiert ist damit der Core. Nicht automatisiert ist die Frage, ob Plugins, Theme und Custom-Code zur neuen Version noch passen. Genau dort liegt das Risiko: Von den 11.334 Schwachstellen, die Patchstack für 2025 im WordPress-Umfeld zählt, lagen 91 Prozent in Plugins und 9 Prozent in Themes; auf den Core entfielen im ganzen Jahr sechs Meldungen. Wartung heißt, den Teil zu prüfen, den kein Automatismus prüft.

WordPress-Wartung wird bei Sharpness als Monatspauschale netto je Projekt abgerechnet, gestaffelt nach vereinbarter Reaktionszeit: BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden. Den Preis nennen wir im Angebot und nicht auf dieser Seite, weil er an nachprüfbaren Größen hängt: Zahl und Art der Plugins, Umfang des Custom-Codes im Theme, ob das Hosting dazugehört, ob mehrere Installationen betreut werden. Wer ohne Blick in die Installation einen Monatspreis nennt, kalkuliert einen Durchschnitt, den Sie mitbezahlen. Die Ersteinschätzung nach Domain und Backend-Zugang ist kostenfrei.

Die Reaktionszeit ist die Zeit, bis jemand mit der Bearbeitung beginnt — nicht die Zeit bis zur Lösung. Es gibt vier Stufen: BASIC 24 Stunden für Systeme, bei denen ein Ausfall Arbeit verschiebt, aber keinen Umsatz kostet; STANDARD 8 Stunden für Websites im Tagesgeschäft; ADVANCED 4 Stunden für Installationen mit angebundenen Systemen; PREMIUM 2 Stunden für Systeme, bei denen jede Stunde Stillstand unmittelbar Geld kostet. Jede Stufe gilt erst mit abgeschlossener Vereinbarung. Ohne sie gilt unsere Grundzusage: Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr. Abdeckung außerhalb dieser Zeiten setzt eine ausdrücklich vereinbarte Rufbereitschaft voraus.

Die Bewertung beginnt am Tag der Meldung: Wir prüfen, ob die genannte Version und Konfiguration Ihre Installation betrifft, denn viele Plugin-Schwachstellen greifen nur bei bestimmten Einstellungen oder ab einer bestimmten Benutzerrolle. Danach folgt der Testlauf auf Staging, dann das Deployment. Wie schnell das je nach Schweregrad zu geschehen hat, steht in der vereinbarten Service-Level-Stufe. Ein Sonderfall ist häufiger, als man denkt: Bei 46 Prozent der 2025 veröffentlichten Schwachstellen lag laut Patchstack zum Zeitpunkt der Veröffentlichung kein Patch vor. Dann wird die Funktion abgeschaltet, die Komponente ersetzt oder der Angriffsweg vorgelagert blockiert.

Für eine Erweiterung ohne Betreuer gibt es vier Wege: eine gepflegte Alternative einsetzen, die Funktion ins eigene Theme holen, den Code übernehmen und selbst weiterpflegen, oder die Funktion streichen, weil sie niemand nutzt. Welcher Weg günstiger ist, entscheidet der Funktionsumfang. Der Hinweis auf WordPress.org, ein Plugin sei nicht mit den letzten drei Hauptversionen getestet, ist dabei nur ein Warnsignal: Er hängt am Feld „Tested up to" in der readme.txt und lässt sich ändern, ohne eine Zeile Code anzufassen. Wir bewerten am Code, nicht am Datum — ein kleines Hilfsplugin ist ein anderes Risiko als ein Formular-Plugin mit Zugriff auf Kundendaten.

Selten am Aussehen der Website. Typisch sind Weiterleitungen, die nur bei einem Suchmaschinen-Referrer oder bestimmten User-Agents greifen, während der direkte Aufruf normal aussieht; per CSS versteckte Links auf fremde Seiten; und Mailversand über den Server, bis die IP auf Sperrlisten landet und die eigene Geschäftspost nicht mehr ankommt. Prüfen lassen sich PHP-Dateien unter wp-content/uploads, ein unerwartetes Verzeichnis wp-content/mu-plugins, obfuskierter Code am Anfang der functions.php, neue Administratorkonten und zusätzliche Cron-Einträge. Der erste Hinweis kommt in der Praxis von außen: aus der Search Console, vom Hoster oder von einem Kunden.

In dieser Reihenfolge: Installation in den Wartungsmodus oder vom Netz nehmen. Einen Snapshot des befallenen Zustands sichern, statt ihn zu überschreiben — er ist die einzige Grundlage für die Ursachenklärung. Zugänge entziehen: Passwörter aller Konten, Application Passwords, Datenbankbenutzer, SFTP- und SSH-Schlüssel, dazu die Salts und Keys in der wp-config.php, was alle Sitzungen beendet. Dann Core und Plugins gegen die Originale vergleichen, Benutzerliste und Cron-Einträge durchgehen. Erst danach wiederherstellen oder neu aufsetzen, und dabei Inhalte übernehmen statt Dateien. Sind personenbezogene Daten betroffen, läuft die 72-Stunden-Frist nach Artikel 33 DSGVO.

Eine Säuberung ohne Ursachenklärung ist sinnlos, weil der Einstiegsweg offen bleibt und derselbe Befund in Wochen wieder auftaucht. Deshalb gehört zur Reinigung immer die Frage, wie jemand hereinkam: veraltetes Plugin, gestohlenes Redaktionspasswort, ein Nachbarprojekt auf demselben Hosting-Paket, ein alter FTP-Zugang. Und dazu gehört eine Einschränkung, die wir aussprechen, statt sie zu umgehen: Auf einer Installation, die jahrelang nicht gepflegt wurde und deren Logs rotiert sind, lässt sich der Weg oft nicht mehr bestimmen. Dann ist ein sauberer Neuaufbau mit übernommenen Inhalten belastbarer als ein zweiter Reinigungsdurchlauf.

Nein, aber es ist auch nicht wertlos. Eine Web Application Firewall oder ein Sicherheits-Plugin filtert bekannte Angriffsmuster und kauft Zeit — besonders in den Fällen, in denen eine Schwachstelle veröffentlicht ist, aber noch kein Patch vorliegt. Was sie nicht leisten: einen Angriff über legitime, authentifizierte Anfragen erkennen, ein Plugin ersetzen, das keinen Betreuer mehr hat, eine PHP-Version aktualisieren, die selbst keine Sicherheitsupdates bekommt, oder ein Backup zurückspielbar machen. Als Ergänzung zur Wartung sinnvoll, als Ersatz nicht. Zusätzliche Plugins sind zudem selbst Code, der gepflegt werden muss.

Betreuung auf fremdem Hosting ist möglich und häufig. Voraussetzungen sind SSH-Zugang, ein brauchbarer Deployment-Weg, eine Staging-Umgebung oder die Möglichkeit, eine einzurichten, und Zugriff auf die Backups. Fehlt das, wird jedes Update-Fenster teurer als der Umzug, und wir sagen das vor dem Vertrag. Wir betreiben eigene Server in Deutschland auf Proxmox-Clustern; ein Wechsel ist möglich, aber keine Bedingung. Die Verantwortungsgrenze zwischen Hosting und Anwendung halten wir vorab schriftlich fest, damit im Störungsfall niemand erst suchen muss, wer zuständig ist.

WordPress empfiehlt auf der eigenen Anforderungsseite PHP 8.3 oder neuer und MariaDB ab 10.11 beziehungsweise MySQL ab 8.0 (Abruf 17.08.2026). Die technischen Mindestwerte liegen mit PHP 7.4 und MySQL 5.5.5 deutlich darunter, betreffen aber Versionen am Ende ihres Lebenszyklus, die keine Sicherheitsupdates mehr erhalten — WordPress weist auf derselben Seite ausdrücklich darauf hin. Für den Betrieb heißt das zwei Dinge: Die PHP-Version gehört in die Wartung, nicht in ein Extraprojekt. Und ein Sprung auf eine neuere PHP-Version wird auf Staging getestet, weil ältere Plugins dort zuverlässiger brechen als beim Core-Update.

Ja, das ist der häufigste Anlass für eine Anfrage. Gebraucht werden ein Administratorkonto im Backend, SSH- oder SFTP-Zugang, Datenbankzugang und, falls vorhanden, das Repository. Wir sehen vor der Zusage in Code, Plugin-Bestand und Hosting und geben eine schriftliche Einschätzung ab; erst danach entsteht ein Vertrag. Das ist keine Formalie, sondern die Bedingung — für einen Zustand, den man nicht kennt, kann man keine Verantwortung übernehmen. In seltenen Fällen sagen wir ab, etwa bei Spuren einer Kompromittierung oder bei zentralen Individualentwicklungen ohne Quellcode. Dann ist ein Neuaufbau ehrlicher als ein Wartungsvertrag.

Eine ausdrückliche Pflicht, WordPress zu aktualisieren, steht in keinem Gesetz. Artikel 32 Absatz 1 DSGVO verlangt aber technische und organisatorische Maßnahmen nach dem Stand der Technik und ein Verfahren zu deren regelmäßiger Überprüfung; die Rechenschaftspflicht aus Artikel 5 Absatz 2 liegt beim Verantwortlichen, nicht bei der Agentur. Praktisch heißt das: Sie brauchen kein gutes Gefühl, sondern ein Protokoll, aus dem hervorgeht, wann was aktualisiert und wann ein Backup geprüft wurde. Das liefern wir als festen Bestandteil der Wartung. Ob Ihr Unternehmen darüber hinaus besonderen Pflichten unterliegt, beurteilt Ihre Rechtsberatung.