WordPress-Website dokumentieren: Zugänge, Plugins, Lizenzen und Abhängigkeiten festhalten

Wenn die WordPress-Website ausfällt, der Webdesigner nicht erreichbar ist oder ein neuer Dienstleister übernimmt, fehlt oft das Wichtigste: Wer hat Zugang zum Hosting, welche Plugins sind lizenziert, welches Plugin hängt von welchem ab, und wo liegen die Backups? Eine Website-Dokumentation beantwortet diese Fragen, bevor sie dringend werden. Diese Anleitung zeigt, was hineingehört, wie Sie den technischen Teil mit WP-CLI und dem Werkzeug „Website-Zustand“ automatisch erfassen und warum Passwörter nicht in die Dokumentation gehören, sondern in einen Passwortmanager. Befehle und Ausgaben stammen aus einem Test mit WordPress 7.1.2.

Voraussetzungen

• WordPress: geprüft mit WordPress 7.1.2. Die Plugin-Abhängigkeiten über die Kopfzeile „Requires Plugins“ gibt es seit WordPress 6.5.
• PHP: WordPress empfiehlt derzeit mindestens PHP 7.4, getestet wurde mit PHP 8.4.
• Zugriff: Rolle Administrator im Backend. Für die automatische Erfassung SSH mit WP-CLI (getestet mit 2.12.0), ohne SSH genügt der Bericht im Website-Zustand.
• Passwortmanager: ein Passwortmanager mit Freigabe für mehrere Personen, zum Beispiel ein selbst betriebener Vaultwarden oder Passbolt, oder ein gleichwertiger Dienst.
• Ablageort: ein Ort für die Dokumentation außerhalb der Website, etwa ein Firmen-Wiki oder ein Netzlaufwerk mit Zugriff für die Verantwortlichen. Liegt die Dokumentation auf dem Webserver, ist sie genau dann weg, wenn Sie sie brauchen.
• Backup: ein aktuelles Backup der Website. Die Dokumentation beschreibt es, ersetzt es aber nicht.

Schritt 1: Aufbau der Dokumentation festlegen

Eine gute Website-Dokumentation beantwortet die Fragen, die im Notfall jemand stellt, der die Website nicht kennt. Gliedern Sie sie deshalb nach Zuständigkeit, nicht nach Technik. Bewährt hat sich diese Aufteilung:

Bereich	Inhalt	Quelle
Verträge und Zuständige	Domain-Registrar, Hoster, Vertragsnummern, Kündigungsfristen, interne und externe Ansprechpartner	Verträge, manuell
Zugänge	Liste aller Zugänge mit Verweis auf den Eintrag im Passwortmanager	manuell
Technischer Stand	WordPress-, PHP- und Datenbankversion, Plugins, Themes, Cron-Ereignisse	WP-CLI oder Website-Zustand
Lizenzen	kostenpflichtige Plugins und Themes, Konto beim Hersteller, Laufzeit	manuell
Abhängigkeiten	Plugins, die andere voraussetzen, externe Dienste, eigene Anpassungen	teils automatisch, teils manuell
Betrieb	Backup-Ort und Aufbewahrung, Update-Rhythmus, letzte Wiederherstellungsprobe	manuell

Legen Sie in Ihrem Wiki oder auf dem Netzlaufwerk für jede Website eine Seite mit diesen Abschnitten an. Ein Datum „Stand“ oben auf der Seite zeigt sofort, wie aktuell die Angaben sind.

Verifizieren: Die Dokumentationsseite existiert mit allen sechs Abschnitten und einem Stand-Datum, und mindestens zwei Personen im Unternehmen können sie öffnen.

Schritt 2: Zugänge erfassen, Passwörter getrennt ablegen

Zugangsdaten im Klartext in einem Wiki, einer Tabelle oder einer E-Mail sind ein Risiko: Jeder mit Lesezugriff auf die Dokumentation hätte damit Vollzugriff auf die Website. Legen Sie jedes Passwort deshalb als Eintrag im Passwortmanager ab, in einem gemeinsamen Ordner je Website. In der Dokumentation steht nur, welcher Zugang existiert und wie der Eintrag im Passwortmanager heißt.

Diese Zugänge sollten Sie erfassen:

• Domain-Registrar und DNS-Verwaltung
• Kundenbereich des Hosters
• SFTP- oder SSH-Zugang, Datenbankzugang (falls separat genutzt)
• WordPress-Administratorkonten, mit Name der Person
• Konten bei Plugin- und Theme-Herstellern für Lizenzen und Downloads
• externe Dienste: Backup-Speicher, E-Mail-Versand, CDN, Statistik

Prüfen Sie dabei gleich die Administratorkonten. Jedes Konto sollte einer Person gehören, gemeinsam genutzte Konten wie „admin“ verschleiern, wer etwas geändert hat:

wp user list --role=administrator --fields=user_login,user_email,user_registered

Konten ehemaliger Mitarbeiter oder Dienstleister löschen Sie oder stufen sie herab. Wie Sie Rollen sinnvoll verteilen, beschreibt Benutzerrollen und Rechte in WordPress vergeben. Für Ihren Passwortmanager eignet sich zum Beispiel Vaultwarden produktiv betreiben.

Verifizieren: Jeder Zugang aus der Liste hat einen Eintrag im Passwortmanager, die Dokumentation enthält kein einziges Passwort, und jedes Administratorkonto ist einer namentlich bekannten Person zugeordnet.

Schritt 3: Technischen Stand ohne SSH erfassen

WordPress sammelt die wichtigsten technischen Angaben selbst. Öffnen Sie Werkzeuge > Website-Zustand und wechseln Sie auf den Tab Bericht. Dort finden Sie WordPress-Version, Theme, aktive und inaktive Plugins mit Versionen, Must-Use-Plugins, Server- und PHP-Angaben, Datenbankversion und die gesetzten WordPress-Konstanten.

Mit der Schaltfläche „Bericht in die Zwischenablage kopieren“ übernehmen Sie den Stand als Text. Fügen Sie ihn in die Dokumentation ein oder legen Sie ihn als Textdatei mit Datum ab. Der Bericht enthält Pfade und Serverangaben. Behandeln Sie ihn deshalb als intern und veröffentlichen Sie ihn nicht, etwa in öffentlichen Support-Foren, ohne ihn vorher zu kürzen.

Verifizieren: Die Dokumentation enthält einen Bericht mit Datum, und die dort genannte WordPress-Version stimmt mit der Anzeige unter Dashboard > Aktualisierungen überein.

Schritt 4: Inventar per WP-CLI automatisch schreiben

Mit SSH-Zugang erzeugen Sie ein Inventar, das Sie bei jeder Prüfung neu schreiben und mit dem vorherigen vergleichen. Das folgende Skript legt je Datum einen Ordner mit CSV- und Textdateien an. Speichern Sie es als inventar.sh außerhalb des Webroots und führen Sie es im WordPress-Verzeichnis aus:

#!/bin/sh
# WordPress-Inventar als Textdateien schreiben
set -e
ZIEL="${1:-$HOME/wp-doku}/$(date +%F)"
mkdir -p "$ZIEL"
wp core version --extra > "$ZIEL/core.txt"
wp cli info > "$ZIEL/umgebung.txt"
wp option get siteurl >> "$ZIEL/core.txt"
wp plugin list --fields=name,title,version,status,auto_update,wporg_status --format=csv > "$ZIEL/plugins.csv"
wp plugin list --status=must-use,dropin --fields=name,status --format=csv > "$ZIEL/mu-dropins.csv"
wp theme list --fields=name,title,version,status --format=csv > "$ZIEL/themes.csv"
wp user list --role=administrator --fields=user_login,user_email --format=csv > "$ZIEL/admins.csv"
wp cron event list --fields=hook,recurrence --format=csv > "$ZIEL/cron.csv"
wp config list --fields=name,type --format=csv > "$ZIEL/wp-config-namen.csv"
echo "Inventar geschrieben nach $ZIEL"

cd /var/www/html
sh ~/inventar.sh
diff ~/wp-doku/2026-09-01/plugins.csv ~/wp-doku/2026-09-30/plugins.csv

Zwei Details sind bewusst gewählt. Erstens schreibt wp config list nur Namen und Typ der Konstanten, nicht die Werte. So landen Datenbankpasswort und Salts nicht in der Dokumentation. Zweitens zeigt die Spalte wporg_status, ob ein Plugin im Verzeichnis auf wordpress.org noch geführt wird. Im Test stand bei „Hello Dolly“ der Wert closed. Ein geschlossenes Plugin erhält dort keine Updates mehr und gehört auf die Liste der Kandidaten zum Ersetzen, siehe veraltete und aufgegebene Plugins erkennen. Bei kostenpflichtigen Plugins, die nicht auf wordpress.org liegen, bleibt die Spalte leer.

Must-Use-Plugins aus wp-content/mu-plugins tauchen unter Plugins > Installierte Plugins nur im Bereich „Must-Use“ auf und werden leicht übersehen. Im Test erschien eine dort abgelegte Datei firma-anpassungen.php in mu-dropins.csv als firma-anpassungen,must-use.

Verifizieren: Das Skript endet mit „Inventar geschrieben nach …“, der Ordner enthält die Dateien core.txt, umgebung.txt, plugins.csv, mu-dropins.csv, themes.csv, admins.csv, cron.csv und wp-config-namen.csv, und keine Datei enthält ein Passwort.

Schritt 5: Lizenzen und Abhängigkeiten ergänzen

Was keine Software weiß, tragen Sie von Hand ein. Ergänzen Sie in der Plugin-Liste je Zeile vier Spalten: Zweck, Lizenz (kostenlos oder kostenpflichtig mit Laufzeit und Konto), abhängige Funktionen und eine verantwortliche Person. Die Spalte „Zweck“ ist die wichtigste: Ein Plugin, dessen Zweck niemand mehr kennt, ist ein Kandidat zum Entfernen.

Seit WordPress 6.5 können Plugins in ihrer Kopfzeile mit „Requires Plugins“ angeben, welche anderen Plugins sie brauchen. WordPress verhindert dann die Aktivierung ohne die Abhängigkeit. Im Test mit einem eigenen Plugin, das den Classic Editor voraussetzt, meldete WP-CLI beim Aktivieren:

Warning: Failed to activate plugin. Fehler: Firmen-Erweiterung erfordert, dass 1 Plugin installiert und aktiviert ist: Classic Editor. .
Error: No plugins activated.

Verlassen Sie sich darauf nicht allein. Im selben Test ließ sich das vorausgesetzte Plugin per WP-CLI anschließend deaktivieren, während das abhängige Plugin aktiv blieb. Viele ältere Plugins nutzen die Kopfzeile außerdem gar nicht, etwa Erweiterungen für Shop- oder Formular-Plugins. Notieren Sie Abhängigkeiten deshalb ausdrücklich, auch zu externen Diensten wie Zahlungsanbietern, Newsletter-Diensten oder Schnittstellen zu Warenwirtschaft und CRM.

Eigene Anpassungen gehören ebenfalls hinein: Code in einem Child-Theme, Must-Use-Plugins, Einträge in wp-config.php und Regeln in .htaccess oder der Nginx-Konfiguration. Beschreiben Sie je Anpassung kurz, was sie tut und warum es sie gibt.

Verifizieren: Jedes aktive Plugin und jedes Must-Use-Plugin hat einen eingetragenen Zweck, jede kostenpflichtige Lizenz eine Laufzeit und ein Herstellerkonto mit Verweis auf den Passwortmanager.

Schritt 6: Dokumentation aktuell halten

Eine veraltete Dokumentation ist gefährlich, weil sie Sicherheit vortäuscht. Legen Sie zwei Auslöser fest: Nach jeder Änderung (neues Plugin, neuer Zugang, Wechsel des Dienstleisters) aktualisiert die ausführende Person die Seite sofort. Zusätzlich prüft eine verantwortliche Person im Quartal den Gesamtstand, schreibt das Inventar aus Schritt 4 neu und vergleicht es mit dem letzten.

Diese Prüfung fällt am leichtesten zusammen mit der übrigen Pflege. Ein Rahmen dafür steht im WordPress-Wartungsplan. Wer Updates und Backups 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 und wöchentliche Backups auf externen Speicher. Auch dann gehört die Dokumentation in Ihre Hand, denn sie ist Ihre Grundlage für jeden Dienstleister.

Verifizieren: Im Kalender steht ein wiederkehrender Termin für die Quartalsprüfung mit verantwortlicher Person, und das Stand-Datum der Dokumentation ist nicht älter als drei Monate.

Typische Fehler

• Passwörter in der Dokumentation. Wer die Dokumentation lesen darf, hat damit alle Zugänge. Passwörter in den Passwortmanager verschieben und danach ändern.
• Bericht aus dem Website-Zustand öffentlich geteilt. Er enthält Pfade und Serverangaben. Vor dem Teilen kürzen.
• wp config list ohne --fields=name,type. Die Standardausgabe zeigt auch die Werte, also Datenbankpasswort und Salts. Immer mit Feldauswahl aufrufen.
• Error: 'site-health' is not a registered wp command. WP-CLI 2.12.0 bringt keinen Befehl für den Website-Zustand mit. Den Bericht im Backend nutzen.
• Must-Use-Plugins fehlen in der Liste. wp plugin list ohne Statusfilter zeigt sie zwar, aber leicht übersehen. Separat mit --status=must-use,dropin erfassen.
• Dokumentation liegt nur auf dem Webserver. Bei einem Ausfall oder Hack ist sie nicht erreichbar oder manipuliert. Außerhalb der Website ablegen.

Häufige Fragen

Reicht eine Tabellenkalkulation?

Für eine einzelne Website ja, solange sie keine Passwörter enthält und an einem gesicherten Ort liegt. Bei mehreren Websites oder mehreren Bearbeitern ist ein Wiki mit Versionsverlauf übersichtlicher, weil Sie Änderungen nachvollziehen können.

Wer sollte Zugriff auf die Dokumentation haben?

Mindestens zwei Personen im Unternehmen, damit Urlaub oder Krankheit keinen Engpass erzeugen. Externe Dienstleister erhalten Zugriff auf das, was sie für ihren Auftrag brauchen.

Gehört der Quellcode eigener Anpassungen in die Dokumentation?

Nein, der Code gehört in eine Versionsverwaltung oder in das Backup. Die Dokumentation beschreibt, was die Anpassung tut und wo sie liegt.

Testumfang

Getestet in einer Laborinstanz mit WordPress 7.1.2, PHP 8.4 und WP-CLI 2.12.0: Inventar-Skript mit allen Befehlen, Felder von wp plugin list einschließlich wporg_status, Erfassung eines Must-Use-Plugins, Aktivierungssperre über „Requires Plugins“ und Deaktivieren der Abhängigkeit per WP-CLI, Benennung von Tab und Schaltfläche im Website-Zustand anhand der deutschen Sprachdatei. Nicht getestet: Passwortmanager-Anbindung, Multisite und kostenpflichtige Plugins.

Fazit

Eine Website-Dokumentation kostet einen halben Tag und spart im Notfall Stunden. Trennen Sie Beschreibung und Passwörter strikt, lassen Sie den technischen Stand von WP-CLI oder dem Website-Zustand erfassen und ergänzen Sie Lizenzen, Abhängigkeiten und Zuständigkeiten von Hand. Mit einem festen Prüftermin bleibt sie aktuell. Wenn Sie die laufenden Updates und Backups auslagern möchten, ist die betreute WordPress-Wartung eine Möglichkeit.

Weiterführende Anleitungen und Quellen

• WordPress-Wartungsplan: wöchentlich, monatlich, jährlich
• Veraltete und aufgegebene WordPress-Plugins erkennen und ersetzen
• Benutzerrollen und Rechte in WordPress vergeben
• Vaultwarden produktiv betreiben
• WP-CLI: wp plugin list
• WP-CLI: wp config list
• Make WordPress Core: Plugin Dependencies in WordPress 6.5
• WordPress-Dokumentation: Site Health Screen