--- title: "WordPress-Website dokumentieren: Zugänge, Plugins, Lizenzen und Abhängigkeiten festhalten" date: 2026-09-30T22:13:03+02:00 modified: 2026-11-04T17:41:02+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-website-dokumentation-zugaenge-plugins-abhaengigkeiten keywords: - WordPress - Dokumentation - WP-CLI - Wartung - Plugins reading_time: 9 --- # 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. **Kurzfassung:** Trennen Sie zwei Dinge: Die Dokumentation beschreibt, was es gibt und wer zuständig ist. Die Zugangsdaten liegen in einem Passwortmanager, auf den die Dokumentation nur verweist. Den technischen Stand erfassen Sie per WP-CLI in wenigen Befehlen oder über **Werkzeuge > Website-Zustand > Bericht**. Ergänzen Sie von Hand, was keine Software weiß: Lizenzen, Abhängigkeiten, eigene Anpassungen und Ansprechpartner. Aktualisieren Sie die Dokumentation nach jeder Änderung und prüfen Sie sie mindestens einmal im Quartal. ## 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. > **Prüfen:** 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: ```bash 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](https://s-edv.com/anleitungen/wordpress-benutzerrollen-rechte-vergeben). Für Ihren Passwortmanager eignet sich zum Beispiel [Vaultwarden produktiv betreiben](https://s-edv.com/anleitungen/vaultwarden-passwortmanager-haerten-backup-fail2ban). > **Prüfen:** 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. > **Prüfen:** 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: Datei: `inventar.sh` ```bash #!/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" ``` ```bash 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](https://s-edv.com/anleitungen/wordpress-veraltete-aufgegebene-plugins-erkennen-ersetzen). 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`. > **Prüfen:** 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: ```plaintext 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. > **Prüfen:** 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](https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich). Wer Updates und Backups 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=92) ü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. > **Prüfen:** 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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=92) eine Möglichkeit. ## Weiterführende Anleitungen und Quellen - [WordPress-Wartungsplan: wöchentlich, monatlich, jährlich](https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich) - [Veraltete und aufgegebene WordPress-Plugins erkennen und ersetzen](https://s-edv.com/anleitungen/wordpress-veraltete-aufgegebene-plugins-erkennen-ersetzen) - [Benutzerrollen und Rechte in WordPress vergeben](https://s-edv.com/anleitungen/wordpress-benutzerrollen-rechte-vergeben) - [Vaultwarden produktiv betreiben](https://s-edv.com/anleitungen/vaultwarden-passwortmanager-haerten-backup-fail2ban) - [Linux-Server absichern mit UFW und Fail2ban](https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban) - [WP-CLI: wp plugin list](https://developer.wordpress.org/cli/commands/plugin/list/) - [WP-CLI: wp config list](https://developer.wordpress.org/cli/commands/config/list/) - [Make WordPress Core: Plugin Dependencies in WordPress 6.5](https://make.wordpress.org/core/2024/03/05/introducing-plugin-dependencies-in-wordpress-6-5/) - [WordPress-Dokumentation: Site Health Screen](https://wordpress.org/documentation/article/site-health-screen/)