WordPress-Sicherheit: Warum eine Login-URL-Änderung nicht ausreicht

WordPress-Besitzer suchen häufig nach Wegen, ihre Websites vor automatisierten Angriffen zu schützen. Eine der meistempfohlenen Lösungen ist die Umbenennung der Login-URL – etwa von /wp-login.php zu /mein-login. Doch diese Maßnahme allein reicht oft nicht aus, um die Sicherheit zu gewährleisten.

Viele Tools und Tutorials beantworten damit nur einen Teil der eigentlichen Frage: Wie lässt sich WordPress vollständig vor Scannern und Bots verbergen? Die Umbenennung des Login-Pfads verschleiert zwar das Standard-Zugangstor, doch es bleiben drei kritische Schwachstellen bestehen, die Angreifer nutzen können. Wer diese Lücken ignoriert, riskiert trotz getarnter Login-URL weiterhin gezielte Angriffe.

Problem 1: WordPress startet trotzdem – mit unnötigem Ressourcenverbrauch

Auch wenn eine Umbenennungs-Erweiterung wie WPS Hide Login den Zugriff auf /wp-login.php blockiert, lädt WordPress die Seite zunächst vollständig. Erst dann wird dem Besucher ein 404-Fehler angezeigt. Für den Nutzer scheint die Seite nicht zu existieren – doch im Hintergrund hat der Server bereits den gesamten WordPress-Kern initialisiert, Plugins geladen und Datenbankabfragen durchgeführt.

Auf einer kleinen Website mit wenigen Besuchern fällt dieser Overhead kaum auf. Bei Websites mit zehntausenden täglichen Scan-Versuchen summiert sich der unnötige Ressourcenverbrauch jedoch schnell. Während die Sicherheitssoftware stolz „10.000 Angriffe blockiert“ meldet, zeigt die Serverlast einen deutlichen Anstieg.

Eine effizientere Lösung besteht darin, den Zugriff auf die Standard-Login-Pfade bereits auf Server-Ebene zu unterbinden. Dies geschieht über Rewrite-Regeln in der .htaccess-Datei (Apache) oder der Server-Konfiguration (nginx), noch bevor PHP oder WordPress gestartet werden.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/(wp-login\.php|wp-admin) [NC]
  RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC]
  RewriteRule .* - [R=404,L]
</IfModule>

location ~* ^/(wp-login\.php|wp-admin) {
  if ($http_cookie !~* "wordpress_logged_in") {
    return 404;
  }
}

Der Vorteil dieser Methode: Der Server antwortet sofort mit einem 404, ohne WordPress zu starten. So spart man nicht nur CPU-Ressourcen, sondern blockiert auch potenzielle Exploits auf PHP-Ebene, bevor sie überhaupt ausgeführt werden können.

Problem 2: Plugins und Themes verraten die WordPress-Installation

Ein Angreifer, der die Standard-Login-URL nicht findet, gibt nicht auf. Stattdessen analysiert er die Website auf andere Weise – etwa durch das Auslesen der Quelltexte. Dort finden sich oft versteckte Hinweise auf die eingesetzte Software:

• /wp-content/plugins/woocommerce/
• /wp-content/themes/mein-theme/style.css?ver=2.4.1
• /wp-content/plugins/some-plugin/readme.txt (mit Versionsnummer)

Diese Pfade sind nicht durch die Login-URL geschützt, sondern liegen offen in den HTML-Quelltexten der Startseite. Laut einer Analyse von Patchstack wurden 2025 insgesamt 11.334 WordPress-Schwachstellen gemeldet – 91 % davon betrafen Plugins, nicht den Core. Ein automatisierter Scanner kann die installierten Erweiterungen innerhalb von Millisekunden identifizieren und mit bekannten Sicherheitslücken abgleichen.

Eine einfache Umbenennung der Login-URL ändert nichts an dieser Offenlegung. Wer seine Website wirklich verstecken will, muss zusätzlich die Pfade der Plugins und Themes anpassen und Versionsnummern aus den Quelltexten entfernen.

Problem 3: REST-API, AJAX und Meta-Tags verraten WordPress weiterhin

Selbst wenn die Login-URL geändert und die Plugin-Pfade versteckt sind, gibt WordPress weitere Hinweise preis:

<meta name="generator" content="WordPress 6.x" />
<link rel=" href=" />

Tools wie Wappalyzer oder BuiltWith erkennen WordPress nicht nur am Login-Pfad, sondern auch an der REST-API (/wp-json/) und der automatischen Generierung von Benutzernamen über /wp-json/wp/v2/users. Selbst mit einer umbenannten Login-URL bleibt die Website damit leicht als WordPress-Installation identifizierbar.

Eine umfassende Lösung erfordert daher auch die Anpassung dieser Metadaten oder die vollständige Deaktivierung der REST-API – zumindest für nicht-autorisierte Nutzer.

Direkter Vergleich: Was leisten verschiedene Tools wirklich?

| Funktion | Login-URL-Umbenennung (z. B. WPS Hide Login) | Erweiterte Sicherheit (z. B. All-in-One Security) | Vollständige Konfiguration | |----------|---------------------------------------------|--------------------------------------------------|---------------------------| | Login-Pfad geändert | ✅ | ✅ | ✅ | | Standard-Pfad vor PHP-Ladevorgang blockiert | ❌ | ✅ (teilweise) | ✅ | | Plugins/Themes-Pfade versteckt | ❌ | ❌ | ✅ | | Generator-Tags und REST-API entfernt | ❌ | ❌ | ✅ | | Benutzer-Enumeration über REST-API blockiert | ❌ | ❌ | ✅ |

Während eine einfache Login-Umbenennung mit minimalem Aufwand umsetzbar ist, erfordert eine vollständige Absicherung der Website deutlich mehr Konfiguration. Tools wie All-in-One Security bieten zwar zusätzliche Firewall-Regeln, decken jedoch nicht alle Lücken ab. Erst eine Kombination aus Server-Konfiguration, Quelltext-Anpassungen und API-Einschränkungen bietet einen echten Schutz.

So überprüfen Sie, ob Ihre Maßnahmen wirken

Ein häufiger Fehler besteht darin, die Wirksamkeit der eigenen Sicherheitsmaßnahmen im Administrator-Modus zu testen. Da der Admin-Bereich selbst WordPress-spezifische Signale aussendet, liefert eine Überprüfung mit Wappalyzer oder BuiltWith immer ein positives Ergebnis – selbst wenn die Website eigentlich sicher ist.

Testen Sie stattdessen in einem privaten Inkognito-Fenster und gehen Sie wie folgt vor:

• Prüfen Sie Meta-Tags und REST-API:

  curl -s  | grep -iE 'generator|api.w.org|/wp-json'

Falls Ausgaben erscheinen, sind diese Metadaten noch sichtbar.

• Testen Sie den alten Login-Pfad auf Ressourcenverbrauch:

  curl -s -o /dev/null -w "HTTP-Status: %{http_code}\n" 

Eine Antwort mit Code 200 (oder einem langsamen 404) deutet darauf hin, dass WordPress trotzdem geladen wird.

• Überprüfen Sie die Benutzer-Enumeration:

  curl -s 

Falls eine Liste mit Benutzernamen zurückgegeben wird, ist die REST-API noch uneingeschränkt zugänglich.

Nur wenn alle drei Tests ohne positive Ergebnisse bleiben, ist Ihre WordPress-Installation tatsächlich vor automatisierten Scannern versteckt.

Wer WordPress nicht nur vor simplen Bot-Angriffen, sondern vor gezielter Ausspähung schützen will, sollte über eine umfassende Sicherheitsstrategie nachdenken. Eine umbenannte Login-URL ist ein guter erster Schritt – doch sie allein macht Ihre Website nicht unsichtbar.