Benutzerrollen in WordPress sauber vergeben: Rechte prüfen und einschränken
Welche WordPress-Rolle wofür gedacht ist, wie Sie Administratorkonten reduzieren, Rollen per Backend und WP-CLI anpassen, ehemalige Konten ohne Inhaltsverlust löschen und den Datei-Editor sperren.
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
In vielen kleinen Unternehmen haben auf der WordPress-Website alle Beteiligten die Rolle Administrator: die Geschäftsführung, die Agentur, die Aushilfe für die News und der Dienstleister, der vor drei Jahren das Theme angepasst hat. Das ist bequem und gefährlich. Jedes Administratorkonto kann Plugins installieren, Benutzer anlegen und damit die gesamte Website übernehmen. Wird eines davon kompromittiert, ist alles betroffen. Diese Anleitung zeigt, welche Rolle in WordPress wofür gedacht ist, wie Sie die Konten Ihrer Website prüfen, Rechte sinnvoll zuschneiden und ehemalige Mitarbeitende sauber entfernen, ohne Inhalte zu verlieren.
Voraussetzungen
- WordPress: geprüft mit WordPress 7.1.2 in deutscher Sprache. Rollen und Rechte sind seit vielen Versionen unverändert.
- PHP: mindestens 7.4.
- Zugriff: ein Konto mit der Rolle Administrator. Für Schritt 5 Zugriff auf die
wp-config.phpper FTP, SFTP oder Dateimanager des Hosters, optional SSH mit WP-CLI. - Überblick über die Personen: eine Liste, wer an der Website arbeitet und was er dort tut, zum Beispiel Beiträge schreiben, Seiten pflegen, Updates einspielen.
- Backup: eine aktuelle Sicherung der Datenbank, bevor Sie Konten löschen. Gelöschte Benutzer und mitgelöschte Inhalte lassen sich nur aus dem Backup zurückholen.
Schritt 1: Die Rollen verstehen
Laut WordPress-Dokumentation beschreiben Rollen Verantwortungen, keine Hierarchie. Jede Rolle ist ein Bündel einzelner Berechtigungen (Capabilities) wie publish_posts oder install_plugins. Die deutschen Bezeichnungen im Backend weichen teils vom englischen Original ab, deshalb hier beide:
| Rolle (Slug) | Darf | Typischer Einsatz |
|---|---|---|
Administrator (administrator) | alles: Plugins, Themes, Updates, Benutzer, Einstellungen | Inhaber, technisch Verantwortliche |
Redakteur (editor) | alle Beiträge und Seiten veröffentlichen und bearbeiten, auch fremde, Kommentare moderieren, Kategorien verwalten | Marketing, Redaktionsleitung |
Autor (author) | eigene Beiträge schreiben, veröffentlichen und löschen, Dateien hochladen | regelmäßige Verfasser von News |
Mitarbeiter (contributor) | eigene Beiträge schreiben, aber nicht veröffentlichen, keine Uploads | Gastautoren, Praktikanten |
Abonnent (subscriber) | nur das eigene Profil pflegen | registrierte Leser, Standard für neue Konten |
Die Rolle „Mitarbeiter“ ist kein Mitarbeiterkonto im Sinne der Firma, sondern die eingeschränkteste Schreibrolle. Seiten bearbeiten können nur Redakteure und Administratoren. Eine Rolle, die ausschließlich Seiten pflegt, gibt es in WordPress nicht. Auf einer Multisite-Installation kommt der Super-Admin hinzu. Plugins wie WooCommerce bringen eigene Rollen mit, etwa „Shop-Manager“.
Ein Detail, das oft übersehen wird: Redakteure haben auf Einzel-Websites die Berechtigung unfiltered_html. Sie dürfen also beliebiges HTML und JavaScript in Inhalte schreiben. Ein kompromittiertes Redakteurskonto kann damit Schadcode in Seiten einbauen. Auch Redakteurskonten brauchen daher starke Passwörter.
Verifizieren: wp role list zeigt die fünf Standardrollen. wp cap list author zeigt die Berechtigungen einer Rolle, im Labor unter anderem upload_files, edit_posts, publish_posts und delete_published_posts.
Schritt 2: Bestand prüfen
Öffnen Sie „Benutzer“ › „Alle Benutzer“. Über der Liste zeigt WordPress die Anzahl je Rolle, etwa „Alle (3) | Administrator (1) | Autor (1) | Mitarbeiter (1)“. Klicken Sie auf „Administrator“, um nur diese Konten zu sehen. Mit SSH liefert WP-CLI dieselbe Übersicht samt E-Mail-Adresse und Registrierungsdatum:
wp user list --fields=ID,user_login,user_email,roles,user_registered
wp user list --role=administrator --fields=ID,user_login,user_emailGehen Sie jedes Konto durch und beantworten Sie drei Fragen: Kennen Sie die Person? Arbeitet sie noch an der Website? Braucht sie diese Rolle für ihre Aufgabe? Achten Sie besonders auf Administratorkonten mit unbekannten Namen oder fremden E-Mail-Domains. Ein Konto, das niemand zuordnen kann, ist ein Warnsignal für einen früheren Einbruch und sollte nicht einfach gelöscht, sondern zuerst untersucht werden.
Prüfen Sie zusätzlich unter „Einstellungen“ › „Allgemein“ den Bereich „Mitgliedschaft“. Ist „Jeder kann sich registrieren“ aktiv, legt jeder Besucher selbst ein Konto an, und zwar mit der „Standardrolle eines neuen Benutzers“. Diese muss „Abonnent“ sein. Steht dort eine höhere Rolle, kann sich jeder Besucher Schreibrechte verschaffen. Im Labor waren die Voreinstellungen korrekt: Registrierung aus, Standardrolle Abonnent.
wp option get users_can_register
wp option get default_roleVerifizieren: Sie haben eine Liste aller Konten mit Soll-Rolle. users_can_register ist 0, oder bei gewollter Registrierung ist default_role gleich subscriber.
Schritt 3: Rollen anpassen
Stufen Sie Konten auf die kleinste passende Rolle herab. Im Backend geht das in „Benutzer“ › „Alle Benutzer“: Haken beim Konto setzen, oben in der Auswahl „Rolle ändern in …“ die neue Rolle wählen und auf „Wechseln“ klicken. Alternativ öffnen Sie das Konto mit „Bearbeiten“ und ändern das Feld „Rolle“.
Per WP-CLI:
wp user set-role chef editor
wp user list-caps chefIm Labor wurde ein zweites Administratorkonto so zum Redakteur. wp user list-caps zeigte danach keine Berechtigungen wie install_plugins oder manage_options mehr. Stufen Sie Ihr eigenes Konto nicht versehentlich herab: WP-CLI führte das im Labor ohne Rückfrage auch beim einzigen Administrator aus. Wer so den letzten Administrator entfernt, kommt nur noch per WP-CLI oder Datenbank an die Einstellungen.
Wie viele Administratoren sind sinnvoll? Zwei: eines für Sie und eines als Reserve, falls Sie ausfallen oder sich aussperren. Eine Agentur oder ein Dienstleister, der Updates einspielt, braucht ebenfalls Administratorrechte, dann aber mit eigenem, persönlichem Konto statt eines geteilten Zugangs. So sehen Sie später, wer was geändert hat, und können einen Zugang gezielt entfernen.
Verifizieren: wp user list --role=administrator zeigt nur noch die gewünschten Konten. In der Benutzerliste stimmen die Zahlen je Rolle mit Ihrer Soll-Liste überein.
Schritt 4: Ehemalige Konten löschen, ohne Inhalte zu verlieren
Konten von Personen, die nicht mehr an der Website arbeiten, gehören gelöscht. Deaktivieren sieht WordPress nicht vor, ein ruhendes Konto mit bekanntem Passwort bleibt ein Einfallstor. Beim Löschen fragt WordPress: „Was soll mit den Inhalten dieses Benutzers geschehen?“ Zur Wahl stehen „Den gesamten Inhalt löschen.“ und „Alle Inhalte einem anderen Benutzer zuordnen.“. Wählen Sie fast immer die zweite Option und einen aktiven Benutzer, sonst verschwinden alle Beiträge und Seiten dieses Kontos.
- „Benutzer“ › „Alle Benutzer“, mit der Maus über das Konto fahren und „Löschen“ anklicken.
- „Alle Inhalte einem anderen Benutzer zuordnen.“ auswählen und in der Liste den neuen Eigentümer wählen.
- Mit „Löschen bestätigen“ abschließen.
Bei WP-CLI ist Vorsicht geboten. Ohne --reassign fragt der Befehl im Labor nur: --reassign parameter not passed. All associated posts will be deleted. Proceed? [y/n]. Mit --yes fällt selbst diese Rückfrage weg. Geben Sie deshalb immer die ID des neuen Eigentümers an:
wp post list --author=3 --fields=ID,post_title
wp user delete 3 --reassign=1Im Labor gehörte der Beitrag „Test“ vor dem Löschen Benutzer 3, danach Benutzer 1. Die Ausgabe lautete Success: Removed user 3 from http://127.0.0.1:21773.
Benutzerverwaltung ist keine einmalige Aufgabe. Jeder Personalwechsel, jede beendete Zusammenarbeit mit einer Agentur und jedes neue Plugin mit eigenen Rollen verändert den Bestand. Wer diese laufende Pflege zusammen mit Updates und Backups nicht selbst im Kalender halten möchte, kann sie teilweise abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher und die Firewall, dazu eine einmalige Analyse der Homepage.
Verifizieren: Das Konto fehlt in der Benutzerliste, und wp post list --author=NEUE_ID zeigt die übernommenen Beiträge.
Schritt 5: Zusätzliche Schutzmaßnahmen
Selbst mit sauberen Rollen bleibt das Administratorkonto mächtig. Zwei Einstellungen in der wp-config.php begrenzen den Schaden, falls es übernommen wird. Sichern Sie die Datei vorher und fügen Sie die Zeilen oberhalb von /* That's all, stop editing! */ ein:
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_UNFILTERED_HTML', true );DISALLOW_FILE_EDIT entfernt laut WordPress-Dokumentation die Berechtigungen edit_themes, edit_plugins und edit_files für alle Benutzer. Damit verschwinden „Theme-Datei-Editor“ und „Plugin-Datei-Editor“ aus dem Backend, über die sich sonst direkt PHP-Code einschleusen lässt. Im Labor hatte der Administrator danach kein edit_plugins mehr, install_plugins blieb erhalten. Die Dokumentation weist selbst darauf hin, dass das Hochladen schädlicher Dateien damit nicht verhindert wird.
DISALLOW_UNFILTERED_HTML nimmt allen Rollen, auch Administratoren, das Recht auf ungefiltertes HTML. Im Labor lieferte user_can() danach für Redakteur und Administrator false. Der Nachteil: Eingebettete Skripte, etwa für Karten oder Buchungs-Widgets, lassen sich im Editor dann nicht mehr einfügen. Testen Sie die Einstellung auf einer Kopie der Website, wenn Sie solche Einbettungen nutzen.
Sichern Sie außerdem alle Konten mit erweiterten Rechten mit einem zweiten Faktor ab, siehe WordPress-Login mit Zwei-Faktor-Authentifizierung absichern. Verlässt jemand das Unternehmen, meldet wp user session destroy BENUTZER --all alle aktiven Sitzungen ab, bevor Sie das Konto löschen.
Verifizieren: Unter „Werkzeuge“ bzw. „Design“ erscheint kein Datei-Editor mehr. wp eval 'var_dump( user_can( 1, "edit_plugins" ) );' gibt bool(false) aus.
Typische Fehler
- Beiträge nach dem Löschen eines Kontos verschwunden: Beim Löschen wurde „Den gesamten Inhalt löschen.“ gewählt oder
wp user deleteohne--reassignbestätigt. Die Inhalte lassen sich nur aus dem Datenbank-Backup zurückholen. Error: No such 'manage_options' cap for editor-test (2).Sie wollten eine Berechtigung entfernen, die das Konto nicht einzeln besitzt.wp user remove-capentfernt nur zusätzlich vergebene Einzelrechte, nicht die Rechte der Rolle. Ändern Sie in diesem Fall die Rolle.- Letzter Administrator herabgestuft: Niemand kommt mehr an Plugins und Einstellungen. Mit SSH hilft
wp user set-role admin administrator, ohne SSH ein Eingriff in die Datenbank über das Werkzeug des Hosters. - Redakteur sieht Menüpunkte eines Plugins nicht: Viele Plugins prüfen auf
manage_options, das nur Administratoren haben. Prüfen Sie zuerst, ob das Plugin eigene Rechte-Einstellungen hat, bevor Sie die Rolle anheben. - Einzelrechte vergeben und vergessen:
wp user add-capgibt einem Konto dauerhaft ein zusätzliches Recht, das in der Rollenübersicht nicht auffällt. Im Labor meldete der BefehlSuccess: Added 'edit_theme_options' capability for editor-test (2).Dokumentieren Sie solche Ausnahmen und entfernen Sie sie mitwp user remove-cap, wenn sie nicht mehr gebraucht werden.
Häufige Fragen
Brauche ich ein Plugin für eigene Rollen?
Für die meisten kleinen Websites nicht. Die fünf Standardrollen decken die üblichen Aufgaben ab. Eigene Rollen lohnen sich erst, wenn Sie zum Beispiel jemanden nur Seiten, aber keine Beiträge bearbeiten lassen wollen. Dann ist ein Rollen-Editor-Plugin der übliche Weg, dessen Einstellungen Sie wie jede Rechteänderung dokumentieren sollten.
Darf meine Agentur ein gemeinsames Konto nutzen?
Technisch ja, sinnvoll ist es nicht. Persönliche Konten zeigen, wer eine Änderung vorgenommen hat, und lassen sich beim Personalwechsel der Agentur einzeln löschen. Bei geteilten Zugängen müssten Sie jedes Mal das Passwort ändern.
Wie oft sollte ich die Benutzer prüfen?
Mindestens vierteljährlich und bei jedem Personalwechsel. Der Blick auf „Benutzer“ › „Alle Benutzer“ dauert wenige Minuten.
Was ist mit Kundenkonten im Shop?
Shop-Plugins legen Kunden meist mit einer eigenen Rolle ohne Rechte im Backend an. Diese Konten gehören nicht in die Rechteprüfung, wohl aber in das Löschkonzept nach DSGVO.
Testumfang
Wir haben Rollen und Berechtigungen am 30.09.2026 in einer Testinstanz mit WordPress 7.1.2 durchgespielt, im Backend ebenso wie per WP-CLI. Dazu gehörte auch das Löschen von Benutzern mit und ohne --reassign.
Multisite, Rollen von Shop-Plugins und Rollen-Editor-Plugins haben wir nicht getestet. Wenn Sie so etwas einsetzen, probieren Sie die Schritte bitte zuerst auf einer Kopie Ihrer Seite aus.
Fazit
Saubere Rollen kosten einmal eine halbe Stunde und senken das Risiko deutlich: Jedes Konto, das kein Administrator ist, kann im Fall eines gestohlenen Passworts deutlich weniger Schaden anrichten. Wichtig sind die kleinste passende Rolle, höchstens zwei Administratoren, persönliche Konten für Dienstleister und das Zuordnen von Inhalten beim Löschen. Updates, Backups und Firewall rund um diese Konten übernimmt auf Wunsch die WordPress-Wartung von Marcel Schönfelder.
