Bringt ein Verzeichnisschutz vor wp-admin wirklich etwas?

Ja – er verlagert die Abwehr vor WordPress. Automatisierte Login-Angriffe treffen auf das Server-Passwort, bevor wp-login.php überhaupt ausgeführt wird: kein PHP-Aufruf, keine Datenbank-Last, keine Chance für Schwachstellen im Login-Prozess. Er ersetzt weder starke Passwörter noch Zwei-Faktor-Authentifizierung, ist aber eine der wirksamsten Zusatzschichten, die WordPress kennt.

Warum sollte ich wp-login.php schützen statt des wp-admin-Ordners?

Weil die Login-Datei gar nicht im wp-admin-Ordner liegt: wp-login.php liegt im WordPress-Hauptverzeichnis. Wer nur den Ordner schützt, lässt die eigentliche Angriffsfläche offen. Der Schutz der einzelnen Datei per Files-Regel deckt den Login ab, ohne admin-ajax.php zu blockieren – und umgeht damit auch das häufigste Problem mit Plugins, die diese Datei vom Frontend aus aufrufen.

Funktioniert der wp-admin-Verzeichnisschutz mit WooCommerce?

Mit der Datei-Variante (nur wp-login.php schützen): ja, in der Regel problemlos. Den kompletten wp-admin-Ordner zu schützen ist bei WooCommerce dagegen riskant: Frontend-Funktionen vieler Shops und Plugins rufen /wp-admin/admin-ajax.php auf – steht davor ein Server-Passwort, brechen Warenkorb-Updates, Filter oder Formulare für normale Besucher. Wenn Ordner-Schutz, dann nur mit Ausnahme für admin-ajax.php.

Können sich Kunden und Redakteure dann noch einloggen?

Ja, sie brauchen nur einen Schritt mehr: erst das Server-Passwort (das für alle gleich ist und z. B. im Team geteilt wird), dann den normalen WordPress-Login. Für Shops mit Kunden-Logins ist wichtig: Das WooCommerce-Kundenkonto läuft über /mein-konto/ im Frontend und berührt wp-login.php normalerweise nicht – Kunden merken vom Schutz nichts. Vorsicht nur bei Setups, die Kunden aktiv über wp-login.php schicken.

wp-admin mit Verzeichnisschutz absichern – wann es geht, wann nicht

Der WordPress-Login ist das meistattackierte Stück deiner Website: Bots probieren rund um die Uhr Passwörter durch, an guten Tagen im Sekundentakt. Ein Verzeichnisschutz stellt eine zweite Tür davor – auf Server-Ebene, bevor WordPress überhaupt lädt. Das ist einer der wirksamsten Schutzwälle, die es gibt. Und einer, der falsch eingerichtet einen Shop lahmlegen kann.

Dieser Artikel zeigt beides: die Variante, die fast immer funktioniert, und die Fälle, in denen der Schutz bricht. Die Grundlagen – wie .htaccess und .htpasswd zusammenspielen – stehen im allgemeinen Verzeichnisschutz-Artikel; hier geht es um den WordPress-Spezialfall.

Warum die zweite Tür so wirksam ist

Der übliche Login-Schutz – Limit für Fehlversuche, Zwei-Faktor – arbeitet in WordPress: Jeder Bot-Versuch startet PHP, lädt WordPress, fragt die Datenbank. Der Verzeichnisschutz arbeitet vor WordPress: Der Server verlangt Benutzername und Passwort, bevor er wp-login.php überhaupt ausführt.

Das hat zwei Effekte. Erstens Sicherheit: Auch eine unbekannte Lücke im Login-Prozess ist unerreichbar, solange die Server-Tür zu ist. Zweitens Last: Tausende Bot-Versuche pro Tag kosten keine PHP-Prozesse und keine Datenbank-Abfragen mehr – auf schwächerem Hosting ein spürbarer Unterschied.

Der entscheidende Irrtum: wp-login.php liegt nicht in wp-admin

Wer „wp-admin schützen” hört, schützt naheliegenderweise den Ordner /wp-admin/. Zwei Probleme:

Die Login-Datei liegt woanders. wp-login.php liegt im WordPress-Hauptverzeichnis, nicht im Ordner. Der Ordner-Schutz lässt die eigentliche Angriffsfläche offen.
Im Ordner liegt admin-ajax.php. Diese Datei ist trotz ihres Namens auch fürs Frontend da: Unzählige Plugins rufen sie für normale Besucher auf – Warenkorb-Updates, Produktfilter, Formulare, Live-Suchen. Steht ein Server-Passwort davor, bekommen Besucher Fehler, die aussehen wie Plugin-Bugs und sich als solche kaum finden lassen.

Deshalb die Regel: Schütze die Datei, nicht den Ordner.

Die empfohlene Variante: nur wp-login.php schützen

Die <Files>-Regel legt das Server-Passwort exakt vor die Login-Datei – admin-ajax.php und alles andere bleibt unberührt. Der Generator steht auf dieser Seite gleich im richtigen Modus:

Verzeichnisschutz-Generator

.htaccess & .htpasswd erzeugen

Benutzer anlegen, Dateien kopieren, fertig. Das Passwort wird lokal gehasht und verlässt deinen Browser nicht.

Was möchtest du schützen?

Titel des Login-Fensters (AuthName)

Absoluter Server-Pfad zur .htpasswd

Den echten Pfad verrät dir dein Hosting-Panel – oder eine PHP-Datei mit <?php echo __DIR__;

Benutzer

Benutzername und Passwort verlassen den Browser nicht – der Hash (APR1-MD5, htpasswd-kompatibel) wird lokal per JavaScript erzeugt.

Die erzeugte .htaccess-Regel gehört in die bestehende .htaccess im WordPress-Hauptverzeichnis – oben ergänzt, ohne den WordPress-Block (# BEGIN WordPress …) anzufassen. Die .htpasswd speicherst du unter dem Pfad aus AuthUserFile, idealerweise außerhalb des Web-Roots. Schritt-für-Schritt-Anleitung inklusive Pfad-Ermittlung: im Grundlagen-Artikel.

Zwei praktische Hinweise:

Ein gemeinsames Server-Passwort reicht. Es ist die Tür vor der Tür – die eigentliche Anmeldung bleibt der WordPress-Login mit persönlichen Konten. Das Server-Passwort darf also im Team geteilt werden.
Ausgesperrt? Regel aus der .htaccess entfernen (per FTP oder Hosting-Dateimanager), und alles ist wie vorher. Der Schutz ist vollständig umkehrbar – falls doch mehr klemmt.

Wann es nicht (so einfach) geht

WooCommerce und andere Shops. Die Datei-Variante funktioniert auch hier – das Kundenkonto läuft über /mein-konto/ im Frontend und berührt wp-login.php normalerweise nicht. Aber: Manche Setups schicken Kunden aktiv über wp-login.php (Redirect-Plugins, individuelle Login-Flows, manche Membership-Plugins). Dann stünde das Server-Passwort plötzlich vor zahlenden Kunden. Vorher prüfen: Wo landen Kunden beim Klick auf „Anmelden”?

Ordner-Schutz nur mit Ausnahme. Wer trotzdem den kompletten /wp-admin/-Ordner schützen will (legitim bei reinen Firmen-Sites ohne Frontend-Ajax), braucht die Ausnahme für admin-ajax.php – eine eigene .htaccess im wp-admin-Ordner:

AuthType Basic
AuthName "Geschützter Bereich"
AuthUserFile /pfad/zu/deinem/webspace/.htpasswd
Require valid-user

<Files "admin-ajax.php">
  Require all granted
</Files>

Und selbst dann gilt: Nach dem Einrichten das Frontend gründlich durchklicken – Formulare, Filter, Suche. Bricht etwas, ist ein Plugin im Spiel, das mehr aus wp-admin lädt als nur Ajax.

Häufig eingeloggte Nutzer-Gruppen. Bei Sites, auf denen sich täglich viele Redakteure, Mitglieder oder Kursteilnehmer über wp-login.php anmelden, wird das geteilte Server-Passwort schnell zur Reibung. Hier ist der klassische Login-Schutz mit 2FA und Fehlversuch-Limit der bessere Hauptweg.

nginx-Hosting. Ohne .htaccess-Unterstützung führt der Weg über die Server-Konfiguration des Hosters – Details im Grundlagen-Artikel.

Was der Schutz nicht ersetzt

Die zweite Tür ist eine Schicht, kein Gesamtkonzept: Starke Passwörter und Zwei-Faktor im WordPress-Login bleiben Pflicht – das Server-Passwort ist geteilt und schützt nicht vor einem kompromittierten Redakteurs-Konto. Und gegen Angriffe über verwundbare Plugins hilft er gar nicht; dort wirken Updates und virtuelles Patching. Wie die Schichten zusammenspielen, zeigt der Sicherheits-Überblick.

Ehrliches Fazit

Für die typische Unternehmens-Site mit einer Handvoll Redakteuren ist der Schutz von wp-login.php per <Files>-Regel einer der besten Sicherheits-Handgriffe überhaupt: zehn Minuten Aufwand, Bot-Angriffe prallen am Server ab, vollständig umkehrbar. Beim Shop mit Kunden-Login und bei Frontend-Ajax braucht es den prüfenden Blick vorher – und wer den kompletten Ordner schützt, ohne an admin-ajax.php zu denken, debuggt hinterher Plugin-Fehler, die keine sind.

Du willst deine WordPress-Site absichern lassen, statt selbst an der .htaccess zu arbeiten? Login-Härtung gehört bei uns zur WordPress-Wartung – zusammen mit Updates, getesteten Backups und virtuellem Patching. Schreib uns kurz.