Wartungsplan für WordPress: wöchentliche, monatliche und jährliche Aufgaben mit Prüfbefehlen
Ein schriftlicher Wartungsplan für WordPress: welche Aufgaben wöchentlich, monatlich, vierteljährlich und jährlich anstehen, mit getesteten WP-CLI-Befehlen für Updates, Prüfsummen, Benutzer und Datenbank.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu

Eine WordPress-Website ist nach dem Start nicht fertig. Plugins erhalten Sicherheitskorrekturen, PHP-Versionen laufen aus, Benutzerkonten veralten, Backups werden nie geprüft. Meist fällt das erst auf, wenn etwas schiefgeht. Ein schriftlicher Wartungsplan verteilt die Aufgaben auf feste Intervalle: wöchentlich das Dringende, monatlich die Kontrolle, jährlich die Grundsatzfragen. Diese Anleitung liefert einen solchen Plan mit konkreten Prüfbefehlen, die wir in einer Testinstanz mit WordPress 7.1.2 ausgeführt haben.
Voraussetzungen
- WordPress in einer aktuellen Version (getestet mit 7.1.2) auf einer von WordPress unterstützten PHP-Version (Test: PHP 8.4)
- Benutzerkonto mit der Rolle Administrator
- Für die Befehle: SSH-Zugang zum Server mit WP-CLI (getestet mit WP-CLI 2.12.0); ohne SSH erledigen Sie die meisten Punkte im Backend
- Ein funktionierendes Backup von Dateien und Datenbank außerhalb des Webspace, bevor Sie Plugins löschen oder Updates einspielen
- Ein Ort für das Wartungsprotokoll: Tabelle, Ticketsystem oder Textdatei, Hauptsache zentral und für eine Vertretung auffindbar
- Pro Woche etwa 15 Minuten, pro Monat etwa eine Stunde
Schritt 1: Zuständigkeit und Protokoll festlegen
Der häufigste Grund für verwahrloste Websites ist keine Technik, sondern ungeklärte Zuständigkeit. Die Agentur hat die Seite gebaut, der Hoster betreibt den Server, im Unternehmen pflegt jemand die Inhalte, und für Updates fühlt sich niemand verantwortlich. Schreiben Sie deshalb einen Namen und eine Vertretung auf. Legen Sie fest, wer Updates einspielen darf und wer bei einer Störung entscheidet.
Das Protokoll muss nicht aufwendig sein. Pro Termin reichen Datum, Person, erledigte Punkte, Auffälligkeiten und getroffene Maßnahmen. Es hat zwei Zwecke: Sie sehen später, wann ein Fehler begann, und Sie können gegenüber Kunden, Versicherern oder im Rahmen der DSGVO-Rechenschaftspflicht belegen, dass die Website gepflegt wird.
Der folgende Plan dient als Vorlage. Passen Sie Intervalle an die Bedeutung der Website an: Ein Shop mit täglichen Bestellungen braucht häufigere Kontrollen als eine Visitenkarten-Seite.
| Intervall | Aufgaben |
|---|---|
| wöchentlich | Updates prüfen und einspielen, letztes Backup kontrollieren, Startseite, Formulare und Kasse testen |
| monatlich | Prüfsummen, ungenutzte Plugins und Themes, Benutzerkonten, Website-Zustand, Datenbank |
| vierteljährlich | Restore-Test, PHP-Version, aufgegebene Plugins |
| jährlich | Zugänge und Passwörter, Admin-E-Mail, Verträge und Domain, Plugin-Bestand grundsätzlich |
Verifizieren: Name, Vertretung und Ablageort des Protokolls stehen schriftlich fest, der erste wöchentliche Termin ist im Kalender eingetragen.
Schritt 2: Wöchentliche Aufgaben
Die Woche dreht sich um drei Fragen: Gibt es Sicherheitsupdates? Ist das letzte Backup vorhanden? Funktioniert die Seite für Besucher? Im Backend sehen Sie ausstehende Updates unter Dashboard > Aktualisierungen. Per WP-CLI geht es schneller:
wp core check-update
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version
wp language core updateIn der Testinstanz meldete wp core check-update Success: WordPress is at the latest version.. Nachdem wir testweise eine ältere Plugin-Version installiert hatten, zeigte die Plugin-Liste die Zeile hello-dolly 1.6 1.7.2, also installierte und verfügbare Version nebeneinander.
Spielen Sie Updates erst ein, wenn das Backup vom Vortag oder vom selben Tag vorliegt. Wie Sie Updates Schritt für Schritt per Kommandozeile einspielen, zeigt die Anleitung WordPress-Updates per WP-CLI. Welche Updates WordPress ohne Ihr Zutun installiert, legen Sie nach der Anleitung Automatische Updates in WordPress steuern fest. Auch bei automatischen Updates bleibt die wöchentliche Sichtprüfung nötig, denn sie erkennt Fehler, die kein Updater meldet.
Kontrollieren Sie beim Backup nicht nur, ob das Plugin „erfolgreich“ meldet. Sehen Sie auf dem Zielspeicher nach, ob die Datei vom erwarteten Datum existiert und eine plausible Größe hat. Ein Backup, das seit Wochen nur noch wenige Kilobyte groß ist, meldet oft trotzdem Erfolg.
Zum Schluss rufen Sie die Startseite, das Kontaktformular und, falls vorhanden, Warenkorb und Kasse auf, am besten in einem privaten Browserfenster. Senden Sie eine Testanfrage über das Formular und prüfen Sie, ob die E-Mail ankommt.
Verifizieren: Keine offenen Sicherheitsupdates, eine Backup-Datei vom aktuellen Zeitraum auf dem externen Speicher, die Testanfrage ist im Postfach angekommen. Alles steht im Protokoll.
Schritt 3: Monatliche Aufgaben
Einmal im Monat sehen Sie tiefer hinein. Beginnen Sie mit der Unversehrtheit der Dateien. WP-CLI vergleicht Kern- und Plugin-Dateien mit den Prüfsummen von wordpress.org:
wp core verify-checksums
wp plugin verify-checksums --allIm Normalfall lautet die Ausgabe Success: WordPress installation verifies against checksums. und Success: Verified 2 of 2 plugins. Um zu zeigen, wie ein Befund aussieht, haben wir in der Testinstanz eine Kerndatei geändert und eine fremde Datei angelegt. Die Ausgabe lautete dann:
Warning: File doesn't verify against checksum: wp-includes/version.php
Warning: File should not exist: wp-includes/xyz-extra.php
Error: WordPress installation doesn't verify against checksums.Eine unbekannte PHP-Datei in wp-includes ist ein ernstes Warnsignal für einen Einbruch. Prüfen Sie dann nichts auf eigene Faust weiter, sondern sichern Sie den Zustand und holen Sie Unterstützung. Premium-Plugins, die nicht auf wordpress.org liegen, kann dieser Befehl nicht prüfen; sie erscheinen als nicht verifizierbar.
Danach räumen Sie auf. Jedes installierte Plugin ist Code auf Ihrem Server, auch wenn es deaktiviert ist. Deaktivierte Plugins und Themes, die Sie nicht mehr brauchen, löschen Sie nach einem Backup. Ein Standard-Theme sollte als Rückfallebene installiert bleiben.
wp plugin list --status=inactive --fields=name
wp theme list --status=inactive --fields=name,versionAnschließend prüfen Sie die Benutzerkonten. Unter Benutzer > Alle Benutzer oder per wp user list --role=administrator --fields=user_login,user_email,user_registered sehen Sie, wer Administrator ist. Ehemalige Mitarbeiter, frühere Agenturen und Testkonten entfernen Sie oder stufen sie herab. Beim Löschen fragt WordPress, welchem Benutzer die Inhalte zugeordnet werden sollen; wählen Sie diese Option bewusst, sonst verschwinden Beiträge mit dem Konto.
Öffnen Sie Werkzeuge > Website-Zustand und arbeiten Sie die Hinweise ab. Zum Schluss die Datenbank:
wp db check
wp db size --human-readable
wp transient delete --expiredwp db check meldet für jede Tabelle OK. Die Größe notieren Sie im Protokoll: Wächst die Datenbank von Monat zu Monat sprunghaft, lohnt ein Blick auf Protokoll- oder Statistik-Plugins, die Daten sammeln.
Verifizieren: Beide Prüfsummenbefehle melden Success, keine ungenutzten Plugins mehr installiert, nur bekannte Administratorkonten, alle Tabellen OK.
Schritt 4: Vierteljährliche Aufgaben
Ein Backup ist erst dann etwas wert, wenn die Wiederherstellung funktioniert. Einmal im Quartal spielen Sie deshalb ein Backup in eine Testumgebung ein, nie über die Live-Website. Das kann eine lokale Instanz, eine Staging-Umgebung beim Hoster oder ein eigener Testserver sein, etwa nach der Anleitung WordPress auf dem Synology NAS als Staging-Umgebung. Messen Sie die Zeit bis zur funktionierenden Seite. Diese Zahl ist die ehrliche Antwort auf die Frage, wie lange Ihre Website nach einem Totalausfall offline wäre.
Prüfen Sie außerdem die PHP-Version. Sie steht unter Werkzeuge > Website-Zustand > Information im Bereich „Server“. Vergleichen Sie sie mit der Übersicht der unterstützten Versionen auf php.net. Läuft der aktive Support für Ihre Version bald aus, planen Sie den Wechsel. Das Vorgehen beschreibt die Anleitung PHP-Version für WordPress aktualisieren.
Zuletzt die aufgegebenen Plugins: Öffnen Sie für jedes aktive Plugin die Seite auf wordpress.org und sehen Sie nach, wann es zuletzt aktualisiert wurde und ob es mit aktuellen WordPress-Versionen getestet ist. Ein Plugin, das seit Jahren keine neue Version erhalten hat, bekommt auch keine Sicherheitskorrekturen mehr. Suchen Sie rechtzeitig Ersatz, statt auf den Ernstfall zu warten.
Verifizieren: Die Testinstanz aus dem Backup zeigt Startseite, Inhalte und Medien vollständig, die Dauer steht im Protokoll. Die PHP-Version erhält noch Sicherheitsupdates, für kein aktives Plugin ist ein Ende der Pflege erkennbar.
Schritt 5: Jährliche Aufgaben
Einmal im Jahr geht es um Grundsätzliches. Prüfen Sie unter Einstellungen > Allgemein die „Administrative E-Mail-Adresse“. Dorthin schickt WordPress Hinweise zu automatischen Updates, zur Wiederherstellung nach Fehlern und zu Datenschutzanfragen. Ein Funktionspostfach wie webmaster@ ist besser als die persönliche Adresse eines Mitarbeiters.
Ändern Sie Passwörter für Hosting, Datenbank, SFTP und Administratorkonten, wenn Personen ausgeschieden sind oder ein Verdacht besteht. Prüfen Sie, ob Zwei-Faktor-Anmeldung für alle Administratoren aktiv ist. Kontrollieren Sie unter Benutzer > Profil die „Anwendungspasswörter“ und widerrufen Sie Einträge, die niemand mehr zuordnen kann.
Außerhalb von WordPress gehören Domain-Laufzeit, Hosting-Vertrag und die Lizenzen kostenpflichtiger Plugins und Themes auf die Liste. Eine abgelaufene Plugin-Lizenz bedeutet meist: keine Updates mehr, auch keine Sicherheitsupdates. Stellen Sie außerdem den gesamten Plugin-Bestand infrage. Jede Erweiterung, die Sie entfernen, verringert Angriffsfläche und Wartungsaufwand dauerhaft.
Nach einem Jahr zeigt das Protokoll auch, wie viel Zeit die Wartung tatsächlich kostet und wie oft etwas liegen geblieben ist. Das ist die Grundlage für die Entscheidung, ob Sie die Aufgaben weiter selbst übernehmen. Wer die wiederkehrenden Punkte nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung sowie Einrichtung und Wartung der Firewall. Die Kontrolle von Inhalten, Benutzerkonten und Verträgen bleibt auch dann bei Ihnen.
Verifizieren: Die administrative E-Mail-Adresse ist ein gelesenes Funktionspostfach, alle Administratoren nutzen Zwei-Faktor-Anmeldung, Domain und Lizenzen haben ein bekanntes Ablaufdatum im Kalender.
Typische Fehler
Prüfsummenwarnung für wp-config-docker.php oder andere Zusatzdateien: In der Testinstanz, die auf dem offiziellen Docker-Image lief, meldete wp core verify-checksums Warning: File should not exist: wp-config-docker.php. Diese Datei bringt das Image selbst mit. Auch Hoster legen manchmal eigene Dateien ab. Prüfen Sie jede Meldung einmal, dokumentieren Sie harmlose Dateien im Protokoll und achten Sie bei späteren Läufen nur auf neue Einträge.
Plugin-Prüfsumme stimmt nicht: Die Meldung lautete im Test akismet akismet.php Checksum does not match. Entweder wurde die Datei von Hand angepasst oder fremder Code eingeschleust. Installieren Sie das Plugin in derselben Version neu, nachdem Sie ein Backup angelegt haben, und prüfen Sie erneut.
Warnung „Failed to create directory '/.wp-cli/cache/'“: WP-CLI findet kein beschreibbares Home-Verzeichnis für seinen Cache. Der Befehl funktioniert trotzdem. Dauerhaft beheben Sie das, indem Sie WP-CLI mit einem Benutzer mit eigenem Home-Verzeichnis ausführen oder die Umgebungsvariable WP_CLI_CACHE_DIR auf einen beschreibbaren Ordner setzen.
Wartung nur „bei Gelegenheit“: Ohne feste Termine rutscht die Wartung hinter das Tagesgeschäft. Tragen Sie die Termine als Serientermine ein, mit Vertretung.
Häufige Fragen
Reichen automatische Updates nicht aus?
Sie decken einen Teil der wöchentlichen Aufgaben ab. Backups, Restore-Tests, Benutzerkonten, PHP-Version und aufgegebene Plugins erledigen sie nicht. Außerdem erkennt niemand, ob nach einem Update das Kontaktformular noch funktioniert.
Kann ich die Prüfungen ohne SSH erledigen?
Größtenteils ja: Updates, Benutzer und Website-Zustand prüfen Sie im Backend. Für Prüfsummen brauchen Sie dann ein Sicherheits-Plugin mit Dateiprüfung. WP-CLI spart aber viel Zeit und liefert Ausgaben, die Sie direkt ins Protokoll kopieren können.
Wie lange soll ich das Protokoll aufbewahren?
Eine feste Vorgabe gibt es nicht. Für die Fehlersuche und als Nachweis ist mindestens ein Jahr sinnvoll. Personenbezogene Daten gehören nicht hinein.
Testumfang
Wir haben die Anleitung am 30.09.2026 in einer isolierten Testinstanz mit WordPress 7.1.2 durchgespielt und alle genannten WP-CLI-Befehle ausprobiert. Dabei haben wir auch gezielt einen Prüfsummenbefund in Kern und Plugin provoziert.
Den Restore-Test, den E-Mail-Versand und die Zwei-Faktor-Anmeldung haben wir nicht geprüft, weil sie von Hosting und Plugins abhängen. Probieren Sie diese Punkte deshalb zuerst auf einer Kopie Ihrer Seite aus.
Fazit
Ein Wartungsplan macht aus vielen kleinen, leicht vergessenen Aufgaben eine Routine mit festen Terminen. Wöchentlich Updates, Backup und Funktionsprüfung, monatlich Prüfsummen, Aufräumen und Benutzerkonten, vierteljährlich Restore-Test und PHP-Version, jährlich Zugänge und Verträge: Mit WP-CLI dauert das meiste nur Minuten. Entscheidend ist, dass eine benannte Person es tatsächlich tut und protokolliert. Wenn Sie Updates und Backups abgeben möchten, übernimmt die WordPress-Wartung von Marcel Schönfelder diesen Teil des Plans.
Weiterführende Anleitungen und Quellen
- WordPress-Core-Updates sicher einspielen
- WordPress-Updates per WP-CLI
- Automatische Updates in WordPress steuern
- PHP-Version für WordPress aktualisieren
- WP-CLI-Handbuch: wp core verify-checksums
- WP-CLI-Handbuch: wp plugin verify-checksums
- WordPress-Dokumentation: Site Health Screen
- Advanced Administration Handbook: Backups
- php.net: Supported Versions


