Kein Zugriff aufs WordPress-Backend? Häufigste Ursachen im Überblick

Wenn du nicht mehr ins WordPress-Backend kommst, hilft als Erstes: einordnen, was genau passiert. „Ich komme nicht rein” hat sehr unterschiedliche Ursachen, und jede hat ihren eigenen Lösungsweg. Diese Übersicht sortiert sie nach dem, was du siehst, und schickt dich zum passenden Detailartikel.

Wichtig: Sobald du wieder Zugriff hast, lege ein Backup an, vor allem wenn du an Datenbank, wp-config.php oder Theme-Code arbeitest.

Schnellübersicht: Was siehst du?

Was du siehst	Wahrscheinliche Ursache	Weiterlesen
Login-Formular, Passwort „falsch”, Reset-Mail kommt nicht	Passwort stimmt nicht, Mailversand der Seite oder hinterlegte Adresse defekt	Passwort-Reset ohne Mail
Formular lädt nach dem Absenden neu, keine Meldung	Cookies, falsche Adresse in den Einstellungen, HTTPS-Umstellung	Login-Schleife
Login klappt, aber Menüpunkte fehlen	Administratorrolle verloren	Adminrechte verloren
„Zu viele Versuche”, Sperrhinweis	Security- oder Login-Limit-Plugin	Sperre durch Plugin
403, „Forbidden”, Browser fragt nach Benutzername und Passwort	Server, Firewall, .htaccess oder Verzeichnisschutz	Server blockt
Unbekannte Administratoren in der Benutzerliste	Möglicher Angriff	Gehackter Account
Weiße Seite	PHP-Fehler, oft Memory Limit oder Plugin	White Screen of Death
„There has been a critical error”	Fataler PHP-Fehler in Plugin oder Theme	Wiederherstellungsmodus
„Briefly unavailable for scheduled maintenance”	Hängengebliebene Wartungsdatei nach einem Update	Wartungsmodus beheben
„Error establishing a database connection”, 500er	Datenbank oder Server	WordPress-Fehler im Überblick

Passwort-Reset ohne Mail

Der Login lädt, aber dein Passwort wird nicht akzeptiert, und „Passwort vergessen” hilft auch nicht: keine Mail, oder die hinterlegte Adresse gibt es nicht mehr. Das ist einer der häufigsten Fälle, und meist steckt ein Problem beim E-Mail-Versand der Seite dahinter, nicht das Passwort selbst. Die WordPress-Dokumentation nennt für genau diese Lage mehrere Wege, je nachdem, worauf du noch Zugriff hast.

phpMyAdmin: In der Tabelle wp_users bearbeitest du deinen Benutzer, trägst bei user_pass das neue Passwort im Klartext ein und wählst in der Spalte „Funktion” vor dem Speichern MD5. Das wirkt wie eine Notlösung, ist aber ein dokumentierter Weg. WordPress prüft Hashes mit höchstens 32 Zeichen weiterhin per MD5 und ersetzt sie beim erfolgreichen Login durch einen aktuellen Hash. Dass das passiert, steht im Quellcode der Login-Funktion, nicht nur in Anleitungen. Ein Hinweis zur Tabelle: Der Präfix wp_ kann bei dir anders lauten, nachzulesen in der wp-config.php unter $table_prefix.

WP-CLI: Hast du SSH-Zugang, geht es ohne Datenbank-Oberfläche. Mit wp user list suchst du die ID, dann setzt du das Passwort:

wp user list
wp user update 1 --user_pass='ein-langes-neues-passwort'

Brauchst du einen frischen Administrator, legt ihn dieser Befehl an:

wp user create zugang zugang@example.com --role=administrator --user_pass='ein-langes-neues-passwort'

Ohne --user_pass erzeugt WP-CLI ein zufälliges Passwort und zeigt es dir an. Wirft WP-CLI selbst Fehler, weil ein Plugin die Seite zerschießt, hilft der globale Parameter --skip-plugins (Plugins im Ordner mu-plugins lädt WP-CLI trotzdem).

Nur FTP: Dann trägst du in der functions.php des aktiven Themes wp_set_password( 'neues-passwort', 1 ); ein, wobei die 1 die Benutzer-ID ist, und entfernst die Zeile nach dem ersten Aufruf sofort wieder. Sonst wird das Passwort bei jedem Seitenaufruf neu gesetzt. Die Schritt-für-Schritt-Anleitung samt Generator für SQL und functions.php steht in Ausgesperrt aus dem WP-Admin: Zugriff zurückholen.

Kommt die Reset-Mail grundsätzlich nicht an, prüfe den Mailversand der Seite, sobald du wieder drin bist.

Die Login-Seite lädt immer wieder neu

Du gibst Benutzername und Passwort ein, drückst den Button, und die Login-Seite erscheint wieder. Keine Fehlermeldung, kein „Passwort falsch”. Das heißt meist: Die Zugangsdaten stimmen, aber WordPress kann dich danach nicht halten oder leitet dich im Kreis. Prüfe in dieser Reihenfolge.

1. Browser. Öffne den Login in einem privaten Fenster oder einem anderen Browser. Klappt es dort, lag es an Cookies oder Cache. Manchmal blendet WordPress auch eine Meldung ein: „Cookies are blocked or not supported by your browser” heißt, dass der Browser keine Cookies annimmt. „Cookies are blocked due to unexpected output” dagegen heißt, dass schon vor dem Login irgendetwas Text ausgegeben hat. Meist sind das Leerzeichen oder eine BOM-Markierung vor dem <?php in der wp-config.php oder in einer Plugin-Datei. Die Fehlermeldung „headers already sent” nennt die Datei und die Zeile, an der die Ausgabe beginnt.

2. Adresse in den Einstellungen. In der Tabelle wp_options stehen die Zeilen siteurl (WordPress-Adresse) und home (Website-Adresse). Weichen sie von der Adresse ab, unter der du dich einloggst, etwa weil du von http auf https oder von www auf ohne www umgestellt hast, kann das Cookie nicht passen. Korrigiere beide Werte in phpMyAdmin oder per WP-CLI:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Kommst du an die Datenbank nicht ran, kannst du die Adressen in der wp-config.php fest vorgeben:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Diese Konstanten überschreiben die Datenbankwerte, ändern sie aber nicht. Entfernst du sie später, gilt wieder der Datenbankwert.

3. HTTPS und FORCE_SSL_ADMIN. Hier steckt ein Detail, das viele nicht auf dem Schirm haben: Steht in siteurl ein https, schaltet WordPress FORCE_SSL_ADMIN in aktuellen Versionen laut Quellcode von selbst ein, sofern die Konstante nicht definiert ist. Der Login leitet dann auf die HTTPS-Variante um, wenn WordPress die Anfrage nicht als HTTPS erkennt. Steht vor deiner Seite ein Reverse Proxy, ein Load Balancer oder ein CDN, das HTTPS beendet und intern per HTTP weiterreicht, erkennt WordPress das nicht, und du drehst dich im Kreis. Die WordPress-Entwicklerdoku beschreibt dafür eine Lösung in der wp-config.php, die den Header HTTP_X_FORWARDED_PROTO auswertet:

define( 'FORCE_SSL_ADMIN', true );
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Das setzt voraus, dass der Proxy den Header tatsächlich mitschickt. Ob und wie, klärst du mit dem Hoster oder in der Proxy-Konfiguration.

4. Plugins, Theme, .htaccess. Hilft nichts davon, benenne /wp-content/plugins/ testweise in plugins.hold um. WordPress deaktiviert dann alle Plugins, du kannst dich einloggen, benennst den Ordner zurück und aktivierst die Plugins einzeln wieder. Beschädigte Weiterleitungsregeln in der .htaccess kommen als Ursache ebenfalls vor: Benenne die Datei um und speichere im Backend unter Einstellungen > Permalinks neu, WordPress schreibt dann seinen Standardblock zurück.

Wie du den Login langfristig robuster machst, steht in WordPress-Login absichern.

Du hast deine Administratorrechte verloren

Du kommst zwar rein, aber Menüpunkte fehlen oder du bist plötzlich nur noch Abonnent. Das passiert nach fehlgeschlagenen Migrationen, durch ein fehlerhaftes Plugin oder als Folge eines Angriffs, der deine Rechte heruntergestuft hat.

WordPress speichert die Rolle in der Tabelle wp_usermeta. Der Schlüssel heißt wp_capabilities, mit dem Tabellenpräfix deiner Installation: Heißt dein Präfix abc_, suchst du abc_capabilities. Die Korrektur: Findest du für deine User-ID den Eintrag, setzt du den Wert auf

a:1:{s:13:"administrator";b:1;}

Daneben pflegt WordPress einen veralteten Eintrag wp_user_level mit dem Wert 10 für Administratoren. Fehlt der Eintrag nach einer Migration, lege ihn dazu. Nach einem Umzug mit geändertem Tabellenpräfix kann die Rolle scheinbar „verschwinden”: Die Daten stehen dann noch unter dem alten Präfix im Schlüssel, während die Seite nach dem neuen sucht.

Mit Shell-Zugang geht es deutlich einfacher:

wp user set-role 1 administrator

Der schnellste Weg ohne beides ist weiterhin ein frischer Admin-Benutzer per Datenbank oder Code, wie in Ausgesperrt aus dem WP-Admin beschrieben. Kam der Rechteverlust überraschend, lohnt anschließend ein Blick, ob die Seite kompromittiert wurde.

Gesperrt durch ein Security-Plugin

Ein Security- oder Login-Limit-Plugin hat dich oder deine IP ausgesperrt, etwa nach zu vielen Fehlversuchen oder nach einem Update, das die Regeln verändert hat. Meist siehst du dann einen Sperrhinweis des Plugins, manchmal auch „This has been disabled” oder eine eigene Fehlerseite.

Der schnellste Weg: das Plugin per FTP stilllegen. Benenne den Ordner des Plugins unter /wp-content/plugins/ um, logge dich ein und benenne ihn danach zurück. Lockere dann die Einstellung gezielt, statt das Plugin dauerhaft auszuschalten. Alternativ wartest du ab, bis die Sperre ausläuft, aber der FTP-Weg ist verlässlicher.

Zwei Stolperfallen: Manche Sicherheitslösungen liegen im Ordner wp-content/mu-plugins/. Must-Use-Plugins lädt WordPress automatisch, und sie lassen sich im Backend nicht abschalten. Umbenennen im Plugin-Ordner reicht dann nicht, du musst die Datei in mu-plugins verschieben. Hosts nutzen diesen Ordner gern für eigene Funktionen. Außerdem können Regeln zusätzlich in der .htaccess stehen. Bleibt die Sperre trotz deaktiviertem Plugin, schau dort nach.

403 oder Passwortabfrage vor dem Login

Zwei Erscheinungsformen, die leicht verwechselt werden.

Der Browser fragt nach Benutzername und Passwort, bevor das WordPress-Formular überhaupt erscheint. Dann liegt vor wp-login.php oder wp-admin ein Server-Passwortschutz, den jemand eingerichtet hat, etwa dein Hoster, eine Agentur oder du selbst. Diese Zugangsdaten sind andere als deine WordPress-Zugangsdaten. Wie so ein Schutz funktioniert und wo er bricht, steht in wp-admin mit Verzeichnisschutz absichern.

Eine 403-Seite („Forbidden”) kommt vom Server oder einer Firewall, nicht von WordPress. Typische Auslöser sind Regeln in der .htaccess, die den Zugriff auf wp-login.php oder wp-admin auf bestimmte IP-Adressen beschränken (deine hat sich geändert), eine Web Application Firewall deines Hosters oder eines vorgeschalteten Dienstes oder ein Plugin, das solche Regeln schreibt. Erkennbar ist das daran, dass die Fehlerseite nicht wie deine Website aussieht. Prüfe:

1. Funktioniert der Login aus einem anderen Netz, zum Beispiel per Mobilfunk? Dann ist es eine IP-Beschränkung.
2. Steht in der .htaccess eine Regel für wp-login.php oder wp-admin?
3. Nennt das Fehlerprotokoll deines Hostings, welche Regel gegriffen hat?

Ist es eine Firewall des Hosters, kommst du nur über den Support weiter. An deiner Seite kannst du dann nichts reparieren. Bei einem 500er statt 403 hilft 500 Internal Server Error in WordPress beheben.

Unbekannte Administratoren oder geänderte Zugangsdaten

Siehst du in der Benutzerliste Administratoren, die du nicht angelegt hast, oder hat sich deine E-Mail-Adresse im Profil geändert, ist das kein Zugriffsproblem mehr, sondern ein Sicherheitsvorfall. Das gilt auch, wenn du dich gar nicht mehr einloggen kannst, weil dein Konto verschwunden ist. In phpMyAdmin zeigt dir eine Abfrage, wer Administrator ist:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Ersetze wp_ durch deinen Präfix. Ein Konto mit unbekanntem Namen und auffälligem Anmeldedatum ist verdächtig, aber lösche es nicht blind. Sichere zuerst den Zustand und folge dann dem Ablauf in WordPress gehackt? Malware erkennen und bereinigen. Ein neuer Zugang ohne behobene Ursache lässt die Tür offen.

Wiederherstellungsmodus bei kritischem Fehler

Seit WordPress 5.2 gibt es den Wiederherstellungsmodus (Recovery Mode). Löst ein Plugin oder Theme einen fatalen PHP-Fehler aus, zeigt WordPress „There has been a critical error on this website” und schickt eine E-Mail an die Administrator-Adresse, die in den allgemeinen Einstellungen steht. Alternativ nutzt es die Adresse, die per WP_RECOVERY_MODE_EMAIL gesetzt ist. In der Mail steht ein geheimer Link. Er führt dich zu wp-login.php, setzt ein Cookie, und nach dem Login siehst du im Backend, welches Plugin oder Theme den Fehler verursacht. WordPress pausiert es dann für deine Sitzung.

Zwei Dinge zu wissen:

• Die Mail wird standardmäßig höchstens einmal pro Tag verschickt, und der Link ist laut Quellcode mindestens so lange gültig. Kam die Mail also schon gestern und ist verloren gegangen, kann es dauern, bis eine neue kommt.
• Dein Login bleibt nötig. Der Modus ersetzt ihn nicht, er umgeht nur die Fehlerquelle.

Kommt die Mail nicht an, bleibt der Weg über FTP: das verdächtige Plugin oder Theme umbenennen. Eine ausführliche Anleitung steht in „There has been a critical error”: Recovery Mode richtig nutzen.

Statt Login kommt eine weiße Seite oder ein Fehler

Dann ist nicht der Zugang das Problem, sondern die Seite selbst wirft einen Fehler:

• Weiße Seite, besonders im Backend: oft ein zu niedriges Memory Limit, siehe WordPress Memory Limit erhöhen. Andere Ursachen und die Diagnose per Debug-Log findest du in White Screen of Death beheben.
• „critical error”, Datenbankfehler, 500er oder Parse-Error: ordne ihn über den Überblick zu WordPress-Fehlern ein.

Application Passwords sind kein Ersatz für den Login

Manchmal taucht der Gedanke auf, ein Anwendungspasswort aus dem Profil könne als Hintertür dienen. Das funktioniert nicht. Application Passwords sind für Programme gedacht, die per REST-API oder XML-RPC auf WordPress zugreifen, und laut WordPress-Entwicklerteam ausdrücklich nicht für die interaktive Anmeldung durch Menschen. Auf wp-login.php kannst du sie nicht verwenden. Wenn du dich ausgesperrt hast, brauchst du einen der oben beschriebenen Wege.

Du kommst gar nicht auf den Server

Weder Backend noch FTP noch Hosting-Login? Dann beginnt die Lösung eine Ebene tiefer: (s)FTP-Zugang über das Hosting-Paket neu setzen oder die „Passwort vergessen”-Funktion deines Hosters nutzen. Hast du den Hosting-Zugang wieder, stehen dir alle weiteren Wege offen. Für den Fall, dass so etwas wieder passiert: Ein aktuelles Backup mit getestetem Restore macht aus einem Ausfall ein Ärgernis.

Wann es Zeit für Hilfe ist

Manches löst du selbst. Spätestens hier lohnt es sich, nicht weiter an der Datenbank zu schrauben:

• Du hast keinen Zugang zu Hosting, FTP oder Datenbank und der Hoster kommt nicht weiter.
• Es gibt Administratoren, die du nicht kennst, oder die Seite verhält sich auffällig.
• Mehrere Ursachen überlagern sich, zum Beispiel eine Login-Schleife nach einem Umzug mit geändertem Tabellenpräfix.
• Es ist ein Shop oder eine Seite, die Umsatz bringt, und du willst nicht raten.

Für akute Fälle haben wir eine eigene WordPress-Notfall-Seite. Wir sind in der Regel zu unseren Servicezeiten (Montag bis Freitag, 8 bis 18 Uhr) erreichbar, eine feste Reaktionszeit sagen wir ohne Wartungsvertrag nicht zu. Den Aufwand schätzen wir vorab ein.

---

Unklar, welcher Fall bei dir vorliegt, oder keine Lust auf Datenbank und FTP? Schreib uns kurz, wir holen dich zurück ins Backend. Und wenn sich dauerhaft jemand kümmern soll: Ein WordPress-Wartungsvertrag deckt Updates, Backups und Sicherheits-Monitoring laufend ab.