WordPress Login URL ändern (/wp-login.php)

Öffne das Access Log einer beliebigen WordPress Seite, die seit mehr als ein paar Tagen online ist, und such nach wp-login.php. Du findest hunderte, oft tausende Einträge von IP Adressen, von denen du noch nie gehört hast, alle versuchen sie gängige Benutzername Passwort Kombinationen. WordPress Login ist einer der am häufigsten angegriffenen Endpunkte im öffentlichen Web, schlicht weil die URL universell ist. Jede WordPress Seite weltweit liefert das Login Formular unter /wp-login.php und /wp-admin aus. Das macht es Botnets trivial, in der Breite anzugreifen.

Die Login URL auf etwas Eigenes zu verschieben löst das Grundproblem nicht (wer wirklich an deiner spezifischen Seite Interesse hat, findet die neue URL trotzdem), aber es nimmt die Seite aus den Millionen automatisierter Listen heraus, die den Default Endpunkt scrapen und beklopfen. In der Praxis sinkt der Login Traffic dadurch um 95% oder mehr, was alleine wegen der Server Last schon einen spürbaren Gewinn bedeutet. Diese Anleitung erklärt, was die Änderung tatsächlich bringt, welche Wege zur Umsetzung es gibt und welche Stolpersteine du kennen solltest.

Was das Ändern der Login URL leistet und was nicht

Hier lohnt sich Präzision, weil das Thema in beide Richtungen verzerrt dargestellt wird. Manche Anleitungen verkaufen es als Komplettlösung, andere winken es als Security Theater ab. Die ehrliche Position liegt dazwischen.

Was es gut leistet:

• Es stoppt automatisierte Botnets, die direkt /wp-login.php ansteuern. Die große Mehrheit des Brute Force Verkehrs sind stumpfe Skripte, die Wortlisten durchgehen. Nach der neuen URL suchen sie nicht, das würde einen echten Besuch und HTML Parsing erfordern.
• Es nimmt dich aus den "WordPress Login vorhanden" Filterlisten, die Scanner aufbauen, um Ziele schnell zu finden.
• Es reduziert Server Last und Log Rauschen drastisch. Auf Seiten mit Traffic ist das alleine schon Argument genug.
• Es senkt unbeabsichtigte Admin Sichtbarkeit. Die Login Seite verrät schon durch ihre bloße Existenz einiges: Fehlermeldungen, das Favicon, das WordPress Logo, die Version des Login Templates. Wenn die URL versteckt ist, ist das alles weg.

Was es nicht leistet:

• Einen entschlossenen Angreifer aufhalten, der gezielt deine Seite ins Visier nimmt. Der findet die neue URL über mehrere Wege: den Logout Redirect, die Password Reset Mail mit dem Link auf die neue URL, den Cookie Pfad, einen geleakten Link irgendwo im CMS oder schlicht durch das Erraten gängiger Slugs.
• Starke Passwörter oder Zwei Faktor Authentifizierung ersetzen. Die Login URL ist eine Schicht vor der eigentlichen Authentifizierung. Die echte Verteidigung findet immer noch auf dem Formular statt, nicht beim Pfad zum Formular.
• Vor Schwachstellen auf Anwendungsebene schützen. Wenn ein Plugin eine Remote Code Execution Lücke hat, ist die Login URL irrelevant.

Pragmatischer Rahmen: die Login URL zu ändern ist eine Maßnahme mit hohem Nutzen bei geringem Aufwand, die genau eine Klasse von Angriffen adressiert (ungezieltes automatisiertes Brute Forcen). Sie ergänzt sich gut mit starken Passwörtern, 2FA und einem Rate Limiter, ersetzt aber keines davon.

Empfohlener Weg: WPS Hide Login (oder Äquivalent)

Für 95% der Seiten ist die sauberste Lösung das kostenlose Plugin WPS Hide Login. Es ist klein (unter 100KB), wird seit Jahren aktiv gepflegt, hat über eine Million aktive Installationen und macht genau eine Sache: den Login URL Slug ändern. Keine Upsells, kein Einstellungs Panel voll mit Funktionen, die nichts mit dem Thema zu tun haben.

Einrichtung dauert eine Minute:

1. WPS Hide Login aus dem Plugin Verzeichnis installieren.
2. Aktivieren.
3. Zu Einstellungen, WPS Hide Login gehen.
4. Im Feld "Login URL" den neuen Slug eintragen. Beispiele: geheimer-zugang, backstage, access-2347. Offensichtliches wie admin, geheim, login, oder den Domainnamen mit einer Nummer dahinter vermeiden.
5. Optional eine "Redirection URL" für Aufrufe der alten /wp-login.php setzen. Das Standardverhalten gibt ein 404 zurück, was gegenüber Scannern genau richtig ist. Eine eigene Weiterleitung auf die Startseite ist aber auch in Ordnung.
6. Speichern.

Ab jetzt liefert https://deinedomain.de/wp-login.php für Außenstehende ein 404, und du loggst dich stattdessen über https://deinedomain.de/geheimer-zugang ein. Die neue URL sofort als Lesezeichen speichern. Das Plugin legt den Slug nirgends sichtbar von außen ab, falls du die URL also vergisst und keinen FTP Zugriff hast, hast du ein Problem (es gibt aber den weiter unten beschriebenen Recovery Weg).

Alternative: eigener Slug ohne Plugin

Wenn du kein zusätzliches Plugin installieren willst, kannst du denselben Effekt per Code umsetzen. Lege folgendes als Must Use Plugin unter wp-content/mu-plugins/custom-login-url.php an:

<?php
/**
 * Plugin Name: Eigene Login URL
 * Description: Versteckt /wp-login.php hinter einem eigenen Slug.
 */

if (!defined('ABSPATH')) {
    exit;
}

const CUSTOM_LOGIN_SLUG = 'geheimer-zugang';

add_action('init', function () {
    $requestUri = isset($_SERVER['REQUEST_URI']) ? (string) $_SERVER['REQUEST_URI'] : ';
    $path = parse_url($requestUri, PHP_URL_PATH) ?? ';
    $path = trim($path, '/');

    // Zugriff über den eigenen Slug erlauben, indem wp-login.php geladen wird
    if ($path === CUSTOM_LOGIN_SLUG) {
        require_once ABSPATH . 'wp-login.php';
        exit;
    }

    // Direkten Zugriff auf die Standard Login URL blockieren
    if (preg_match('#(^|/)wp-login\.php$#', $path)) {
        status_header(404);
        nocache_headers();
        include get_404_template();
        exit;
    }
});

// URL in Mails und Login Redirects umschreiben
add_filter('site_url', function ($url, $path) {
    if (str_contains((string) $path, 'wp-login.php')) {
        return str_replace('wp-login.php', CUSTOM_LOGIN_SLUG, $url);
    }
    return $url;
}, 10, 2);

add_filter('wp_redirect', function ($location) {
    return str_replace('wp-login.php', CUSTOM_LOGIN_SLUG, $location);
});

Vorteil dieses Wegs: volle Kontrolle und keine Plugin Abhängigkeit. Nachteil: du pflegst es selbst, und Sonderfälle (Multisite, eigene Registrierungs Flows, manche Page Builder, die das Login Formular wiederverwenden) brauchen zusätzliche Behandlung. Für die meisten Seiten ist WPS Hide Login ehrlich gesagt die praktischere Antwort.

Einen guten Slug wählen

Der Slug muss nicht kryptografisch geheim sein, nur nicht offensichtlich. Ein paar Daumenregeln:

• Nahe Varianten von "login", "admin" oder "wp" vermeiden. Scanner, die über /wp-login.php hinaus suchen, haben in der Regel eine Liste: /login, /admin, /secure-login, /wp-secret, /backend, /dashboard. Such etwas, das nicht auf dieser Liste steht.
• Etwas wählen, das du dir merken kannst, statt rein zufällig. Ein Slug, den du aus dem Kopf tippen kannst, reicht völlig. katze-tofu ist deutlich besser als k7Hg2P, weil du letzteres im Passwort Manager ablegst und ersteres einfach nicht vergisst.
• Domain oder Firmenname raushalten. beispiel-login auf beispiel.de ist das Erste, was ein gezielter Angreifer probiert.
• Kleinbuchstaben, keine Sonderzeichen. URLs sind technisch case sensitive, aber echte Nutzer vertippen Groß und Kleinschreibung ständig. Ein klein geschriebener Slug spart eine ganze Klasse "Ich kann mich nicht einloggen" Tickets.

Häufige Stolpersteine und Sonderfälle

Eine Handvoll Dinge brechen oder verhalten sich unerwartet, wenn man die Login URL verschiebt. Lohnt sich, das vorab zu wissen.

• WooCommerce "Mein Konto" Seite. Der Kunden Login auf /mein-konto/ ist ein eigener Flow und von der Änderung nicht betroffen. Nur der Admin Login wird versteckt. WooCommerce Kunden loggen sich weiter ganz normal ein.
• Zwei Faktor Authentifizierungs Plugins. Die meisten gängigen 2FA Plugins (Wordfence, WP 2FA, miniOrange usw.) funktionieren problemlos mit WPS Hide Login. Sie hängen sich an den Login Prozess unterhalb der URL Ebene und sind unabhängig davon, wo das Formular liegt. Nach der Aktivierung einmal testen.
• REST API und XML RPC. Die Login URL Änderung betrifft /wp-json/ oder /xmlrpc.php nicht. Anwendungen, die sich gegen diese authentifizieren, laufen wie zuvor. Wenn du XML RPC aktiv nicht nutzt, ist das ein guter Anlass, es komplett abzuschalten (eigene Anleitung in unserer Knowledge Base).
• Caching Plugins. Manche aggressive Page Caches (LiteSpeed Cache mit Edge Caching, Cloudflare APO) cachen die neue Login URL oder, schlimmer, cachen die eingeloggte Admin Antwort und liefern sie an ausgeloggte Besucher. Nach der Änderung die neue URL in einem privaten Browserfenster aufrufen. Wenn dort eine eingeloggte Admin Ansicht erscheint, ist der Cache kaputt; leeren und den Slug auf die Cache Ausschlussliste setzen.
• Passwort Reset Mails. Sowohl WPS Hide Login als auch das obige Snippet schreiben die Reset URL automatisch um, aber eigene Mail Plugins oder transaktionale Mail Integrationen kodieren manchmal wp-login.php hart in ihre Templates. Nach der Änderung einmal einen Passwort Reset an dich selbst schicken.
• Unterordner Installationen und Multisite. Beides funktioniert, aber Achtung, dass der Slug nicht an die falsche Basis URL angehängt wird. Liegt WordPress in /blog/, ist die neue URL https://deinedomain.de/blog/geheimer-zugang, nicht https://deinedomain.de/geheimer-zugang.

Recovery: was tun, wenn du dich aussperrst

Passiert. Du richtest den Slug ein, loggst dich aus, schließt den Tab, und eine Woche später weißt du nicht mehr, ob du Bindestriche, Unterstriche oder welches dritte Wort du benutzt hast. Du steckst nicht fest, der Recovery Weg hängt aber von der Methode ab.

Wenn du WPS Hide Login benutzt hast: das Plugin per SFTP deaktivieren. Entweder den Ordner wp-content/plugins/wps-hide-login in wps-hide-login.disabled umbenennen oder ganz löschen. Die Standard /wp-login.php URL kommt sofort zurück. Einloggen, in den Plugin Einstellungen den Slug nachschlagen, dann das Plugin wieder aktivieren. Alternativ direkt in der WordPress Datenbank nachsehen: der Slug liegt in der Tabelle wp_options unter dem Schlüssel whl_page.

Wenn du das Code Snippet benutzt hast: per SFTP in wp-content/mu-plugins/, Datei öffnen, den Slug aus der CUSTOM_LOGIN_SLUG Konstanten ablesen. Oder die Datei kurz umbenennen, einloggen, dann zurückbenennen.

In beiden Fällen die URL beim Einrichten irgendwo dauerhaft notieren. Passwort Manager, Projektdokumentation, irgendetwas, das einen verloren gegangenen Browser Bookmark überlebt.

So prüfst du, ob die Änderung greift

1. https://deinedomain.de/wp-login.php in einem privaten Browserfenster öffnen. Erwartetes Ergebnis: eine 404 Seite.
2. Selbe Prüfung für https://deinedomain.de/wp-admin/. Sollte ebenfalls auf das 404 weiterleiten, nicht auf das Login Formular.
3. Die neue URL https://deinedomain.de/geheimer-zugang öffnen. Sollte das Standard WordPress Login Formular zeigen.
4. Normal einloggen, ausloggen, auf den "Abmelden" Link klicken. Der Redirect sollte auf der neuen URL landen, nicht auf /wp-login.php.
5. Einen Passwort Reset für dich selbst auslösen. Der Link in der Mail sollte auf die neue URL zeigen.
6. Einen frischen InspectWP Scan starten. Die Login URL bezogenen Checks sollten den neuen Stand widerspiegeln.

Nach der Verifikation besteht die einzige laufende Pflege darin, dass das Plugin (oder dein eigener Code) durch WordPress Core Updates weiter funktioniert, was es sollte. Sollte ein Major Update tatsächlich mal den Login Flow intern umbauen, ist WPS Hide Login eines der ersten Plugins, das einen Patch ausliefert, in der Regel innerhalb weniger Tage.

Die ganze Änderung ist eine halbe Stunde Arbeit für eine dauerhafte Reduktion der Angriffsfläche und einen spürbaren Rückgang der Server Last. Es gibt keinen guten Grund, den WordPress Login auf einer Produktivseite an seiner Standard Position zu belassen.