WordPress Admin Login 2026: URL, Probleme & Sicherheit

Standard-Login-URL — /wp-admin und /wp-login.php

Jede WordPress-Installation bringt 2026 zwei feste Login-Adressen mit. https://deine-domain.de/wp-admin ist die Standard-URL, die jeder Admin im Kopf hat. Wer nicht eingeloggt ist, wird automatisch weitergeleitet zu https://deine-domain.de/wp-login.php — der tatsächlichen Login-Verarbeitung. Nach erfolgreichem Login schickt WordPress wieder zurück nach /wp-admin und öffnet das Dashboard.

Beide URLs funktionieren auf jeder WordPress-Site ab Werk identisch. Auch /login, /admin oder /dashboard leiten in den meisten Setups automatisch zur Login-Seite weiter, weil WordPress diese Aliase erkennt. Das ist bequem für den Betreiber, gleichzeitig aber das Hauptproblem: jeder Bot kennt diese Adressen und kann sie sekündlich abklopfen. 2026 ist es deshalb Pflicht, die Standard-URL zu maskieren — mehr dazu weiter unten in Kapitel 6.

Wichtig zu wissen: bei Multisite-Installationen oder bei WordPress in einem Unterverzeichnis ändert sich die URL entsprechend. Liegt WordPress unter https://deine-domain.de/blog/, lautet die Login-URL https://deine-domain.de/blog/wp-admin. Diese Unterscheidung ist wichtig, weil Tools wie Wordfence oder Limit Login Attempts den Pfad korrekt erkennen müssen, um Brute-Force zu blocken.

Login funktioniert nicht — die 8 häufigsten Ursachen

Wenn der WordPress-Login 2026 nicht klappt, liegt es fast immer an einer der folgenden acht Ursachen. Erst durchgehen, dann gezielt fixen — das spart Stunden Trial-and-Error.

1. Falsches Passwort — die häufigste Ursache. Vor jedem Fix Passwort-Reset via „Passwort vergessen“ probieren. Funktioniert die Mail nicht, hilft Reset per phpMyAdmin oder WP-CLI.

2. Cookie-Problem — der Browser akzeptiert das Login-Cookie nicht. Symptom: Login wirkt erfolgreich, leitet aber sofort zurück zur Login-Seite. Lösung in Kapitel 3.

3. Browser-Cache — alte Login-Daten im Cache überschreiben neue. Inkognito-Modus testen, dann Cache leeren.

4. Plugin-Konflikt — ein Sicherheits- oder Login-Plugin blockt den eigenen Zugriff. Häufig nach Plugin-Updates. Diagnose in Kapitel 4.

5. Defekte .htaccess — falsche Rewrite-Regeln blocken /wp-admin. Symptom: 403 Forbidden oder „too many redirects“. Fix in Kapitel 5.

6. Weiße Seite (White Screen of Death) — meist PHP-Fehler im Theme oder Plugin. Theme via FTP umbenennen, alle Plugins deaktivieren.

7. Too many redirects — Site-URL falsch in der Datenbank, HTTPS-Redirect kollidiert mit HTTP-Login. wp_options-Tabelle prüfen.

8. Lockout durch Sicherheits-Plugin — Wordfence oder Limit Login Attempts hat die eigene IP gesperrt. Via FTP Plugin-Ordner umbenennen, dann neu konfigurieren.

Cookie- und Session-Probleme lösen

Das klassische Symptom: Login-Daten eingeben, kurz lädt die Seite, dann steht der Login-Bildschirm wieder da. Keine Fehlermeldung, keine Reaktion. In 90 Prozent der Fälle ist ein Cookie-Problem schuld. WordPress setzt nach erfolgreichem Login ein Session-Cookie — wird das vom Browser oder Server nicht akzeptiert, fliegt der User sofort raus.

Erste Diagnose: Inkognito-Fenster öffnen und neu einloggen. Funktioniert es dort, ist der Browser-Cache schuld. Cache und Cookies für die Domain komplett leeren, Browser neu starten, erneut versuchen. Funktioniert auch das Inkognito-Fenster nicht, liegt das Problem tiefer.

Zweiter Schritt: anderen Browser testen. Chrome, Firefox, Safari unterscheiden sich im Cookie-Handling. Wenn der Login in einem anderen Browser klappt, ist die Cookie-Konfiguration im ersten Browser schuld — etwa restriktive Tracking-Schutz-Einstellungen oder ein aggressives Browser-Plugin.

Dritter Schritt für hartnäckige Fälle: in der wp-config.php die COOKIE_DOMAIN explizit setzen. In den meisten Setups löst folgender Eintrag das Problem dauerhaft:

define('COOKIE_DOMAIN', '.deine-domain.de');

Mit dem führenden Punkt erlaubt der Cookie alle Subdomains und vermeidet Konflikte bei Multi-Subdomain-Setups. Vorsicht: die Domain muss exakt mit dem WordPress-Site-URL übereinstimmen — sonst klappt der Login gar nicht mehr.

Plugin-Konflikt diagnostizieren

Wenn der Login bis gestern lief und heute nicht mehr, war meist ein Plugin-Update schuld. Diagnose-Standard 2026: alle Plugins deaktivieren, dann einzeln aktivieren bis der Fehler wiederkommt.

Schritt 1 — FTP-Zugang öffnen. FileZilla, Cyberduck oder das Hoster-Webinterface starten und mit der Live-Site verbinden. Pfad zu /wp-content/plugins/ öffnen.

Schritt 2 — Plugins-Ordner umbenennen. Den kompletten Ordner plugins umbenennen zu plugins-old. WordPress findet die Plugins nicht mehr und deaktiviert sie automatisch beim nächsten Login-Versuch.

Schritt 3 — Login testen. Browser öffnen, /wp-admin aufrufen, einloggen. Klappt der Login, ist sicher ein Plugin schuld. Klappt der Login nicht, weiter zu Kapitel 5 (.htaccess).

Schritt 4 — Plugins einzeln zurückspielen. Per FTP den Ordner zurück umbenennen zu plugins. Im WP-Admin unter Plugins alle als „inaktiv“ sehen. Eins nach dem anderen aktivieren, nach jedem Aktivieren neu einloggen testen. Das schuldige Plugin findet sich so in 10 bis 20 Minuten.

Schritt 5 — Schuldiges Plugin entfernen oder ersetzen. Beim Hersteller nach Update-Status fragen oder eine Alternative finden. Sicherheits-Plugins wie Wordfence, Sucuri oder Loginizer sind 2026 die häufigsten Login-Blocker nach fehlerhaften Updates.

.htaccess reparieren

Eine kaputte .htaccess-Datei im WordPress-Root blockt häufig den Zugriff auf /wp-admin. Symptome: 403 Forbidden, 500 Internal Server Error, „too many redirects“ oder eine weiße Seite. Reparatur dauert zwei Minuten.

Schritt 1. Per FTP in den WordPress-Root navigieren. Die .htaccess umbenennen zu .htaccess.alt (Punkt-Dateien können je nach FTP-Client versteckt sein — versteckte Dateien einblenden).

Schritt 2. Neue, leere .htaccess erstellen mit folgendem Standard-WordPress-Inhalt:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Schritt 3. Login testen. Klappt der Login wieder, ist das Problem gelöst. Im WP-Admin unter Einstellungen → Permalinks einmal „Speichern“ klicken, ohne etwas zu ändern — WordPress schreibt damit die .htaccess sauber neu, falls weitere Rewrite-Regeln durch Plugins gebraucht werden.

Schritt 4. Bei Multisite-Setups oder bei WordPress in Unterverzeichnis ist der .htaccess-Code anders. WordPress liefert den korrekten Code unter Einstellungen → Permalinks am Seitenende.

Login-URL ändern für mehr Sicherheit

Brute-Force-Bots scannen 2026 stündlich Millionen Domains nach /wp-admin und /wp-login.php. Wer diese URLs auf eine eigene, geheime Adresse umlegt, blockt 99 Prozent aller automatisierten Angriffe ohne weiteren Aufwand. Standard-Plugin 2026: WPS Hide Login.

Setup in 3 Minuten:

• WPS Hide Login im WordPress-Repo installieren und aktivieren
• Unter Einstellungen → WPS Hide Login eine neue Login-URL eintragen, z. B. mein-geheimer-login-2026
• Redirect-URL für ungültige Versuche setzen (Standard: 404-Seite)
• Speichern, ausloggen, neue URL testen

Nach der Aktivierung leitet jeder Aufruf von /wp-admin oder /wp-login.php auf die definierte Redirect-URL (meist 404). Nur wer die neue, geheime URL kennt, sieht das Login-Formular. Für 99 Prozent der Bots ist die Site damit unsichtbar.

Alternative Plugins 2026: Loginizer (auch mit Brute-Force-Schutz und 2FA in einem), iThemes Security (jetzt Solid Security, größeres Paket), oder die Custom-URL-Funktion in Wordfence Premium. Für reines URL-Verstecken ist WPS Hide Login die kleinste und schnellste Lösung — 0,9 MB Plugin-Größe, keine Performance-Kosten.

Nachteil bedenken: die neue URL muss man sich merken und Team-Mitgliedern sicher kommunizieren. Bookmark im Browser ist Standard. Bei Mitarbeiter-Wechsel die URL ändern — sonst behält der Ex-Mitarbeiter Zugang zum Login-Formular (er kommt zwar ohne Passwort nicht rein, könnte aber Brute-Force versuchen, weil er die URL kennt).

2-Faktor-Authentifizierung einrichten

2FA ist 2026 für jede produktive WordPress-Site Pflicht. Selbst wenn das Passwort geleakt wird, kommt ohne den zweiten Faktor niemand rein. Empfohlene Plugins 2026: WP 2FA (von Melapress) oder Two Factor (von der WordPress-Core-Team-Community).

Setup mit WP 2FA:

• Plugin installieren, aktivieren, Setup-Wizard durchlaufen
• Methode wählen: TOTP-App (Google Authenticator, Authy, 1Password) oder E-Mail-Code
• QR-Code in der App scannen, generierten 6-stelligen Code einmal eingeben
• Backup-Codes generieren und sicher speichern (Passwort-Manager)
• 2FA für alle Admins und Editoren als Pflicht setzen

TOTP über App (Google Authenticator, Authy) ist sicherer als E-Mail-Codes, weil E-Mails abgefangen werden können. Für Premium-Konten empfiehlt sich zusätzlich ein Hardware-Token (YubiKey) — den unterstützen WP 2FA Premium und Two Factor.

Pflicht 2026: 2FA für alle Benutzer mit Admin- oder Editor-Rolle. Subscriber und Customer-Konten können optional 2FA nutzen. Bei WooCommerce-Shops ist 2FA für alle Shop-Manager Pflicht, weil sonst Order-Daten und Kunden-Daten gefährdet sind.

Backup-Codes nicht vergessen: jedes 2FA-Plugin generiert 8 bis 10 Einmal-Codes als Fallback. Diese gehören in den Passwort-Manager (1Password, Bitwarden) oder ausgedruckt in den Tresor. Wer 2FA-App und Backup-Codes verliert, kommt nur über phpMyAdmin oder Hoster-Support wieder rein.

Brute-Force-Schutz

Bots probieren 2026 bis zu 10.000 Passwort-Kombinationen pro Stunde auf einer ungeschützten WordPress-Site. Ohne Brute-Force-Schutz ist jede Site mit schwachem Passwort innerhalb von Tagen kompromittiert. Drei Schutz-Ebenen sind 2026 Standard.

Ebene 1 — Limit Login Attempts Reloaded (kostenlos, 2 Mio. Installationen): sperrt eine IP nach 4 falschen Login-Versuchen für 20 Minuten. Nach mehrfacher Wiederholung wird die Sperre länger. Konfiguration in 2 Minuten, kein spürbarer Performance-Verbrauch.

Ebene 2 — Wordfence Security (Free oder Premium): kombiniert Login-Limit, Web Application Firewall, Malware-Scanner und Country-Block in einem Paket. Free-Version ausreichend für KMU-Sites. Premium (149 USD/Jahr) bringt Realtime-Threat-Feed und Premium-Support. 2026 das meistgenutzte Security-Plugin mit über 5 Mio. aktiven Installationen.

Ebene 3 — Cloudflare Rate Limiting (Free Plan ausreichend): blockt verdächtige Requests bereits auf Cloudflare-Ebene, bevor sie den eigenen Server erreichen. Regel: pro IP maximal 5 POST-Requests auf /wp-login.php innerhalb 10 Minuten, danach 1 Stunde Block. Setup in 5 Minuten im Cloudflare-Dashboard, spart massiv Server-Ressourcen bei großen Brute-Force-Wellen.

Optimal 2026: alle drei Ebenen kombinieren. Cloudflare blockt 80 Prozent aller Bots vor dem Server, Wordfence fängt die restlichen 15 Prozent, Limit Login Attempts ist der letzte Backup. Wer 70 €/h für eine professionelle Einrichtung investiert, hat die Konfiguration in zwei Stunden wasserdicht.

Admin-Benutzer absichern

Die wichtigste Einzelmaßnahme 2026: kein Benutzer mit dem Username „admin“. Bots probieren genau diesen Namen als erstes, weil er bis WordPress 3.0 (2010) der Standard war. Auch „administrator“, „root“, „wp_admin“ oder der Domain-Name als Username sind gefährlich.

Sicherer Username: ein nicht erratbarer Name, idealerweise nicht der echte Personenname. Beispiel: mlu-wp-edit statt maximo-luppert. Den Klarnamen optional als „Display Name“ hinterlegen — dieser wird in Beiträgen und Kommentaren angezeigt, aber nicht für den Login verwendet.

Username nachträglich ändern: WordPress erlaubt das nicht im UI. Workaround: neuen Admin-Benutzer mit sicherem Namen anlegen, alle Inhalte des alten Users zuweisen, alten User löschen. Oder per WP-CLI: wp user update 1 --user_login=neuer-name.

Starkes Passwort: mindestens 16 Zeichen, Mix aus Groß-/Kleinbuchstaben, Zahlen, Sonderzeichen. Generieren via 1Password oder Bitwarden, niemals merken oder aufschreiben. WordPress zeigt im Profil eine Passwort-Stärke-Anzeige — alles unter „stark“ ist 2026 nicht akzeptabel.

Application Passwords statt Standard-Login bei API-Zugriff: WordPress unterstützt seit Version 5.6 sogenannte Application Passwords. Diese sind separate Passwörter pro App oder Service (z. B. für ein mobiles CMS, einen externen Webhook, eine Backup-Software). Vorteil: jede App hat eigenen Zugang, der jederzeit einzeln widerrufen werden kann, ohne das Haupt-Passwort zu ändern.

Login-Probleme nach Migration oder Update

Nach einer Site-Migration oder einem größeren WordPress-Update streikt der Login häufig. Drei typische Ursachen, drei klare Fixes.

Problem 1: Site-URL falsch in der Datenbank. Wenn die Site umgezogen wurde, aber die wp_options-Tabelle noch die alte URL enthält, scheitert der Login mit „too many redirects“. Fix in phpMyAdmin: Tabelle wp_options öffnen, Einträge siteurl und home auf die neue Domain setzen. Per WP-CLI noch schneller: wp search-replace 'alte-domain.de' 'neue-domain.de'.

Problem 2: User-Capabilities-Tabelle defekt. Manchmal verliert ein User durch eine fehlerhafte Migration seine Admin-Rolle. Symptom: Login klappt, aber das Dashboard ist leer oder zeigt nur eine Subscriber-Ansicht. Fix in phpMyAdmin: Tabelle wp_usermeta öffnen, beim entsprechenden User den Eintrag wp_capabilities setzen auf a:1:{s:13:"administrator";b:1;}. Beim Tabellen-Präfix aufpassen — wenn es nicht wp_ ist, anpassen.

Problem 3: HTTPS-Redirect-Schleife nach SSL-Umstellung. Nach SSL-Aktivierung kommt der Login in eine Schleife zwischen http://-Login und https://-Dashboard. Fix: in der wp-config.php diesen Code ergänzen:

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

Problem 4: PHP-Version inkompatibel. Nach Hosting-Wechsel auf PHP 8.3 funktionieren manche älteren Sicherheits-Plugins nicht mehr. Lösung: PHP-Version im Hoster-Panel temporär auf 8.1 zurücksetzen, dann Plugin-Updates suchen oder Plugin austauschen.

Problem 5: wp-config.php-Salts veraltet. WordPress nutzt 8 sogenannte „Secret Keys“ (Salts) zur Sicherheitsverschlüsselung. Bei einem Migrations-Backup können diese inkonsistent werden — alle aktiven Sessions werden ungültig, der nächste Login klappt nicht. Neue Salts generieren auf api.wordpress.org/secret-key/1.1/salt/, in wp-config.php austauschen, alle User werden ausgeloggt und müssen neu einloggen.

Häufige Fragen 2026

Kostenloses Angebot
☎ Jetzt anrufen