Aktivitätsprotokoll in WordPress: Änderungen von Benutzern nachvollziehen

Wer hat die Preisliste gelöscht, wer hat das Kontaktformular-Plugin deaktiviert, und seit wann hat die Praktikantin Administratorrechte? Arbeiten mehrere Personen oder eine Agentur an einer WordPress-Website, lassen sich solche Fragen ohne Protokoll kaum beantworten. WordPress selbst speichert zwar Revisionen von Beiträgen, aber keine Änderungen an Plugins, Benutzerrollen oder Einstellungen. Diese Anleitung zeigt, wie Sie mit dem Plugin Simple History ein Aktivitätsprotokoll einrichten, sinnvoll konfigurieren und datenschutzgerecht betreiben. Alle Schritte wurden mit WordPress 7.1.2 und Simple History 5.34.0 getestet.

Voraussetzungen

• WordPress ab 6.3, getestet mit 7.1.2; PHP ab 7.4 laut Plugin-Seite, getestet mit PHP 8.4
• Benutzerkonto mit der Rolle Administrator
• Für die Anpassungen in Schritt 4: Zugriff per SFTP oder SSH auf wp-content/mu-plugins
• Optional: WP-CLI (getestet mit 2.12.0), um das Protokoll auf der Kommandozeile zu lesen
• Ein aktuelles Backup, bevor Sie ein neues Plugin installieren
• Ein Verzeichnis der Verarbeitungstätigkeiten, in das Sie das Protokoll aufnehmen

Schritt 1: Werkzeug auswählen

Im Plugin-Verzeichnis von wordpress.org gibt es mehrere verbreitete Protokoll-Plugins. Stand 30.09.2026 laut Plugin-Seiten:

Diese Anleitung verwendet Simple History, weil es in der kostenlosen Fassung die typischen Fragen kleiner Teams abdeckt, eine WP-CLI-Schnittstelle mitbringt und IP-Adressen ohne Zusatzeinstellung kürzt. Alle drei Plugins speichern ihre Daten in der WordPress-Datenbank. Wer Protokolle zentral und manipulationssicher außerhalb der Website ablegen muss, braucht zusätzlich eine Weiterleitung an einen externen Log-Dienst; das bieten die Hersteller teils in kostenpflichtigen Versionen an.

Verifizieren: Das gewählte Plugin ist laut Plugin-Seite mit Ihrer WordPress- und PHP-Version getestet und wurde in den letzten Monaten aktualisiert.

Schritt 2: Simple History installieren

Im Backend installieren Sie das Plugin unter Plugins → Plugin hinzufügen über die Suche nach „Simple History“ und aktivieren es anschließend. Per WP-CLI:

wp plugin install simple-history --activate
wp language plugin install simple-history de_DE

Der zweite Befehl lädt die deutsche Übersetzung, falls WordPress sie nicht automatisch geholt hat. Danach erscheint im Backend ein eigener Menüpunkt „Simple History“ mit den Unterpunkten „Ereignisprotokoll“, „Einstellungen“ und „Export & Werkzeuge“. Zusätzlich zeigt das Dashboard ein Widget mit den letzten Einträgen.

Beim ersten Aufruf befüllt Simple History das Protokoll nachträglich mit vorhandenen Beiträgen und Benutzern. Im Test lautete der Eintrag: „Das Protokoll wurde mit 3 Beiträgen und 1 Benutzern aus den letzten 30 Tagen nachträglich befüllt“. Änderungen vor der Installation, etwa an Plugins oder Einstellungen, kann kein Plugin rekonstruieren.

Verifizieren: wp plugin list --name=simple-history --fields=name,status,version zeigt active, und unter Simple History → Ereignisprotokoll steht als erster Eintrag die Aktivierung des Plugins.

Schritt 3: Protokollierte Ereignisse prüfen

Lösen Sie einige typische Änderungen aus und kontrollieren Sie, ob sie erscheinen. Im Labor wurden per WP-CLI ein Redakteur angelegt, ein Beitrag veröffentlicht, ein Plugin aktiviert, der Website-Titel geändert und der Redakteur zum Administrator befördert. Anschließend folgte ein fehlgeschlagener Login im Browser-Formular. Das Protokoll auf der Kommandozeile:

wp simple-history list --count=10

9  Anonymous web user  Failed to login with username "admin" (incorrect password entered)  warning
8  WP-CLI              Changed role for user "redakteur" to "administrator" from "editor"   notice
7  WP-CLI              Updated setting "Site Title" on the General Settings Page            info
6  WP-CLI              Activated plugin "Akismet Anti-spam: Spam Protection"               info
5  WP-CLI              Created beitrag "Preisliste"                                          info
4  WP-CLI              Created user redakteur (r@example.test) with role editor             info

Die Ausgabe ist gekürzt; Datum und Uhrzeit stehen in einer eigenen Spalte. Nach Installation der Übersetzung erscheinen die Beschreibungen auf Deutsch, etwa „Der Benutzer redaktion2 (r2@example.test) mit der Rolle editor wurde erstellt“. Wichtig für die Praxis: Änderungen per WP-CLI werden mit dem Auslöser „WP-CLI“ erfasst, nicht mit einem Benutzernamen. Wer auf dem Server arbeitet, ist so nur über die Server-Protokolle zuzuordnen.

Die Stufe warning bei fehlgeschlagenen Logins und notice bei Rollenänderungen hilft beim Filtern: Eine Beförderung zum Administrator sollten Sie immer nachvollziehen können. Für JSON-Ausgaben, etwa zur Weiterverarbeitung, ergänzen Sie --format=json.

Verifizieren: Jede Ihrer Teständerungen erscheint im Ereignisprotokoll mit Zeitpunkt, Auslöser und Beschreibung.

Schritt 4: Aufbewahrung und Leserechte festlegen

Zwei Standardwerte sollten Sie bewusst prüfen. Erstens die Aufbewahrung: Neue Installationen löschen Einträge nach 30 Tagen, im Test stand die Option simple_history_retention_days auf 30. Laut Quelltext gelten für ältere Installationen ohne diese Option 60 Tage. Zweitens die Leserechte: Das Protokoll sehen standardmäßig alle Benutzer mit der Berechtigung edit_pages, also auch Redakteure. Das Protokoll enthält aber Anmeldenamen, E-Mail-Adressen und fehlgeschlagene Logins anderer Personen.

Beides ändern Sie mit Filtern, die das Plugin dokumentiert. Legen Sie dafür ein Must-Use-Plugin an, zum Beispiel wp-content/mu-plugins/simple-history-anpassungen.php:

<?php
/* Plugin Name: Simple History Anpassungen */

// Einträge 90 statt 30 Tage aufbewahren
add_filter( 'simple_history/db_purge_days_interval', function () {
	return 90;
} );

// Protokoll nur für Administratoren sichtbar (Standard: edit_pages)
add_filter( 'simple_history/view_history_capability', function () {
	return 'manage_options';
} );

Prüfen Sie die Datei vor dem Hochladen mit php -l, denn ein Syntaxfehler in einem Must-Use-Plugin legt die gesamte Website lahm. Im Test gab Simple History danach 90 Tage als Aufbewahrung und manage_options als nötige Berechtigung zurück; ein Redakteur hatte keinen Zugriff mehr.

Wie lange Sie Einträge aufbewahren, ist eine Abwägung. Für die Aufklärung von Bedienfehlern reichen wenige Wochen. Um einen Angriff nachträglich zu rekonstruieren, sind längere Zeiträume hilfreich, denn Einbrüche fallen oft erst nach Wochen auf. Mehr als nötig sollten Sie wegen der personenbezogenen Daten aber nicht speichern. Legen Sie den Zeitraum fest und begründen Sie ihn in Ihrer Dokumentation.

Verifizieren: wp plugin list --status=must-use zeigt die neue Datei, und ein Konto mit der Rolle Redakteur sieht den Menüpunkt „Simple History“ nicht mehr.

Schritt 5: Datenschutz berücksichtigen

Ein Aktivitätsprotokoll verarbeitet personenbezogene Daten: Benutzernamen, E-Mail-Adressen, Zeitpunkte, bei fehlgeschlagenen Logins auch den eingegebenen Namen und den Browser. Im Test speicherte Simple History zu einem fehlgeschlagenen Login unter anderem login, login_email, server_http_user_agent und die IP-Adresse in gekürzter Form 127.0.0.x. Die Kürzung ist Standard und lässt sich per Filter abschalten; tun Sie das nur mit Begründung.

Für Unternehmen im DACH-Raum heißt das: Nehmen Sie das Protokoll mit Zweck, Datenkategorien, Speicherdauer und Zugriffsberechtigten in das Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO auf. Als Rechtsgrundlage kommt in der Regel das berechtigte Interesse an der Sicherheit der Website nach Art. 6 Abs. 1 lit. f DSGVO in Betracht; die Grundsätze der Datenminimierung und Speicherbegrenzung aus Art. 5 DSGVO sprechen für kurze Fristen und gekürzte IP-Adressen. Gibt es einen Betriebsrat, klären Sie vorab, ob das Protokoll zur Leistungs- oder Verhaltenskontrolle geeignet ist und damit mitbestimmungspflichtig sein kann. Die rechtliche Bewertung im Einzelfall gehört zu Ihrer Datenschutzberatung.

Verifizieren: Das Protokoll steht mit Speicherdauer und Zugriffsberechtigten in Ihrem Verarbeitungsverzeichnis, und die im Protokoll gespeicherten IP-Adressen enden auf .x.

Schritt 6: Protokoll regelmäßig auswerten

Ein Protokoll, das niemand liest, schützt nicht. Planen Sie eine kurze Durchsicht ein, etwa wöchentlich. Achten Sie besonders auf:

• neue Benutzer und Rollenänderungen, vor allem zu Administrator
• aktivierte oder neu installierte Plugins und Themes
• gehäufte fehlgeschlagene Logins, die auf Angriffe hindeuten
• Änderungen an Einstellungen wie Website-Adresse oder Registrierung

Auf der Kommandozeile gelingt die Durchsicht schnell mit wp simple-history list --count=50. Finden Sie einen unbekannten Administrator oder ein fremdes Plugin, gehen Sie vor wie in Gehackte WordPress-Seite erkennen beschrieben. Gegen gehäufte Login-Versuche hilft die Zwei-Faktor-Anmeldung.

Die wöchentliche Durchsicht reiht sich ein in Updates, Backups und die Kontrolle der Plugins. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung der Firewall.

Verifizieren: Ein wiederkehrender Termin für die Durchsicht steht im Kalender, und eine Person ist dafür zuständig.

Typische Fehler

Häufige Fragen

Kann ein Administrator das Protokoll löschen?

Ja. Wer die Einstellungen von Simple History öffnen darf, kann das Protokoll leeren, und wer Zugriff auf die Datenbank hat, kann Einträge direkt ändern. Ein Protokoll in der WordPress-Datenbank ist deshalb ein Werkzeug für den Alltag, kein Nachweis gegenüber einem Angreifer mit Administratorrechten.

Bremst das Protokoll die Website?

Simple History schreibt bei Änderungen und Anmeldungen Einträge in zwei eigene Tabellen, wp_simple_history und wp_simple_history_contexts. Normale Seitenaufrufe von Besuchern erzeugen keine Einträge. Die automatische Löschung hält die Tabellen klein.

Ersetzt das Protokoll Revisionen?

Nein. Revisionen speichern den Inhalt eines Beitrags zu verschiedenen Zeitpunkten und erlauben die Wiederherstellung. Das Protokoll zeigt, wer wann etwas geändert hat. Beides ergänzt sich, und für den Ernstfall bleibt ein Backup unverzichtbar, siehe WordPress-Backup per Cronjob und Shell-Skript.

Testumfang

Wir haben Simple History unter WordPress 7.1.2 in einer lokalen Testumgebung ausprobiert. Alle getesteten Ereignisse vom fehlgeschlagenen Login bis zur Rollenänderung landeten im Protokoll und ließen sich auch mit wp simple-history list abrufen. Auffällig war, dass IP-Adressen nur gekürzt gespeichert werden.

Den Export und die kostenpflichtigen Erweiterungen haben wir nicht geprüft, testen Sie diese daher zuerst auf einer Kopie Ihrer Seite.

Fazit

Mit Simple History und zwei Filtern haben Sie in einer halben Stunde ein Aktivitätsprotokoll, das die häufigsten Fragen im Team beantwortet und mit gekürzten IP-Adressen datenschutzfreundlich startet. Entscheidend sind drei Punkte: Leserechte auf Administratoren beschränken, Aufbewahrung bewusst festlegen und das Protokoll regelmäßig lesen. Wenn Sie Updates, Backups und Sicherheit Ihrer Website abgeben möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Gehackte WordPress-Seite erkennen: Anzeichen prüfen und erste Schritte
• WordPress-Login mit Zwei-Faktor-Authentifizierung absichern
• DSGVO-Löschpflichten bei Backups und Logfiles
• Simple History im Plugin-Verzeichnis von wordpress.org
• WP Activity Log im Plugin-Verzeichnis
• DSGVO (Verordnung (EU) 2016/679), Art. 5, 6 und 30