wp-login.php ist die meistangegriffene URL jeder WordPress-Website. Nicht weil sie schwach wäre, sondern weil sie auf Millionen von Websites an derselben bekannten Adresse liegt, was automatisierte, ununterbrochene Angriffe lohnend macht. Die meisten Betreiberinnen und Betreiber erfahren davon aus einer Logdatei und nicht aus einem Einbruch.
Diese Anleitungen behandeln die Abwehrmaßnahmen, grob nach ihrer Wirkung geordnet. Die Login-URL zu verlegen entzieht die Website den einfachsten Scans. Versuche zu begrenzen stoppt die geduldigen. Eigene Adressen freizugeben und die auffälligsten zu sperren engt es weiter ein. Ein Captcha unterbindet die meisten automatisierten Übermittlungen, und die Zwei-Faktor-Authentifizierung ist diejenige Maßnahme, die auch dann noch schützt, wenn ein Passwort bereits abgeflossen ist.
Jede davon hat eine Kehrseite, und auch die wird behandelt. Eine eigene Login-URL, die ein Cache der falschen Person ausliefert oder die nach einer Permalink-Änderung 404 liefert. Eine URL, die verlegt und dann vergessen wurde. Versuche, die nach dem Verlegen weiterlaufen, weil etwas die alte Datei weiterhin direkt erreicht.
Eine Gruppe behandelt das Ausgesperrtsein, also das Risiko, das mit dem Härten eines Logins übernommen wird. Das Telefon mit der Authenticator-App geht verloren, nach korrektem Passwort entsteht eine Weiterleitungsschleife, Sitzungen enden nach Minuten, Cookies werden vom Browser nicht gesetzt.
Wer heute eine Website härtet, liest die Wiederherstellungsartikel vor den Härtungsartikeln. Den Weg zurück zu kennen ist das, was alles Übrige gefahrlos macht.
Wenn WooCommerce-Nutzer nach dem Login als Gast erscheinen oder Mein Konto leer bleibt, sind oft Seitenzuordnung, Endpoints, Cookies oder Cache-Regeln falsch. So prüfen Sie den vollständigen Kundenweg.
Funktioniert die eigene Login-URL am Origin, aber nicht über das CDN, werden oft 404-Seiten oder Redirects zwischengespeichert. So halten Sie Authentifizierungswege privat und dynamisch.
Eine eigene WordPress-Login-URL reduziert automatisierte Anfragen nicht automatisch. Bots können das neue Formular oder andere Anmeldewege finden. So ordnen und schützen Sie die tatsächlichen Angriffsflächen.
Wiederholte WordPress-Abmeldungen entstehen häufig durch abweichende Hosts, Cookie-Einstellungen, Sicherheitsschlüssel oder Serverknoten. So verfolgen Sie eine Sitzung bis zur Ursache.
Die WordPress-Meldung zu blockierten Cookies entsteht oft durch falsche Host-, HTTPS- oder Cookie-Attribute und nicht durch eine Browser-Sperre. So finden Sie die Unterbrechung im Login-Ablauf.
Wenn ein WordPress-Link zum Zurücksetzen des Passworts ständig weiterleitet, gehen meist Host, HTTPS-Protokoll oder Reset-Parameter unterwegs verloren. So verfolgen und reparieren Sie die Weiterleitung sicher.
Zeigt eine eigene WordPress-Login-URL nur noch eine 404-Seite, liegt der Fehler meist bei Rewrite-Regeln, Slug-Konflikten oder einem zwischengespeicherten Fehler. So finden Sie die zuständige Ebene, ohne sich auszusperren.
Login-Protokolle werden erst mit Zeitkontext, verlässlicher Client-IP und weiteren Kontoereignissen aussagekräftig. So unterscheiden Sie Fehlalarm und Sicherheitsvorfall.
Eine IP-Sperre kann akute Login-Angriffe bremsen. Sie sollte auf belastbaren Protokollen beruhen, eng begrenzt sein und automatisch auslaufen.
Eine IP-Allowlist kann kontrollierte Netze beim WordPress-Login ausnehmen. Voraussetzung sind korrekte Client-IPs, enger Umfang, klare Zuständigkeit und ein Ablaufdatum.