---
title: "Wartungsplan für WordPress: wöchentliche, monatliche und jährliche Aufgaben mit Prüfbefehlen"
date: 2026-09-30T21:03:43+02:00
modified: 2026-11-09T14:34:42+01:00
category: wordpress
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich
keywords:
  - WordPress
  - Wartung
  - WP-CLI
  - Backup
  - Sicherheit
reading_time: 9
---

# Wartungsplan für WordPress: wöchentliche, monatliche und jährliche Aufgaben mit Prüfbefehlen

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.

**Kurzfassung:** Legen Sie zuerst fest, wer die Wartung verantwortet und wo das Protokoll liegt. Wöchentlich prüfen Sie ausstehende Updates, das letzte Backup und die wichtigsten Seiten. Monatlich prüfen Sie Dateien per Prüfsumme, entfernen ungenutzte Plugins und Themes, kontrollieren Benutzerkonten und den Website-Zustand. Vierteljährlich testen Sie eine Wiederherstellung und die PHP-Version. Jährlich überprüfen Sie Zugänge, Verträge und die Frage, ob jedes Plugin noch gebraucht wird. Die meisten Prüfungen gehen mit WP-CLI in wenigen Minuten.

## 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 |

> **Prüfen:** 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:

```bash
$ 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 update
```

In 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](https://s-edv.com/anleitungen/wordpress-updates-wp-cli-core-plugins-themes). Welche Updates WordPress ohne Ihr Zutun installiert, legen Sie nach der Anleitung [Automatische Updates in WordPress steuern](https://s-edv.com/anleitungen/wordpress-automatische-updates-steuern-core-plugins-themes) 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.

> **Prüfen:** 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:

```bash
$ wp core verify-checksums
$ wp plugin verify-checksums --all
```

Im 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:

Ausgabe:

```plaintext
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.

```bash
$ wp plugin list --status=inactive --fields=name
$ wp theme list --status=inactive --fields=name,version
```

Anschließ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:

```bash
$ wp db check
$ wp db size --human-readable
$ wp transient delete --expired
```

`wp 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.

> **Prüfen:** 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](https://s-edv.com/anleitungen/wordpress-synology-docker-eigene-website). 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](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen).

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.

> **Prüfen:** 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=12) ü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.

> **Prüfen:** 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.

## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=12) von Marcel Schönfelder diesen Teil des Plans.

## Weiterführende Anleitungen und Quellen

- [WordPress-Core-Updates sicher einspielen](https://s-edv.com/anleitungen/wordpress-core-updates-sicher-einspielen-backup-staging-kontrolle)
- [WordPress-Updates per WP-CLI](https://s-edv.com/anleitungen/wordpress-updates-wp-cli-core-plugins-themes)
- [Automatische Updates in WordPress steuern](https://s-edv.com/anleitungen/wordpress-automatische-updates-steuern-core-plugins-themes)
- [PHP-Version für WordPress aktualisieren](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen)
- [WP-CLI-Handbuch: wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/)
- [WP-CLI-Handbuch: wp plugin verify-checksums](https://developer.wordpress.org/cli/commands/plugin/verify-checksums/)
- [WordPress-Dokumentation: Site Health Screen](https://wordpress.org/documentation/article/site-health-screen/)
- [Advanced Administration Handbook: Backups](https://developer.wordpress.org/advanced-administration/security/backup/)
- [php.net: Supported Versions](https://www.php.net/supported-versions.php)