Die benutzerdefinierte Login-Adresse funktioniert direkt am Origin-Server, über das CDN sehen Nutzer jedoch eine alte 404-Seite oder werden zur Startseite umgeleitet. Dann ist meist nicht die WordPress-Zuordnung defekt: Eine vorgelagerte Cache-Regel behandelt den persönlichen Authentifizierungsweg wie eine öffentliche Seite.
Warum Login-Seiten nicht gemeinsam gecacht werden dürfen
Login, Logout und Passwort-Reset hängen von Cookies, Nonces, persönlichen Parametern und aktuellen Redirects ab. Eine gemeinsam gespeicherte Antwort kann diesen Zustand entfernen oder einem anderen Besucher ausliefern. Deshalb müssen Authentifizierungswege dynamisch bleiben und passende no-store– beziehungsweise Bypass-Regeln erhalten.
Ein CDN-Konflikt kann außerdem durch URL-Normalisierung, eine Edge-Funktion oder einen Cache-Key entstehen, der Host, Pfad oder Query-Parameter nicht ausreichend berücksichtigt. Entscheidend ist der Vergleich derselben Anfrage am öffentlichen Endpoint und am autorisierten Origin.
Ein realistisches WordPress-Beispiel
Eine anonyme Anfrage an den neuen Login-Slug traf während einer kurzen Fehlkonfiguration auf eine 404-Seite. Das CDN speicherte diese Antwort unter einer breit gefassten Cache-all-Regel. Obwohl WordPress den Pfad inzwischen korrekt auflöst, erhalten Besucher weiterhin das alte Objekt aus dem Edge-Cache.
Die Reparatur erfolgt in der richtigen Reihenfolge: Zuerst wird die Cache-Regel so eingegrenzt, dass Login-Pfad und zugehörige Cookies nie gemeinsam gecacht werden. Erst danach wird das gespeicherte 404-Objekt gezielt entfernt. Ein kalter Erstaufruf und mehrere Wiederholungen bestätigen, dass die Richtlinie dauerhaft greift.
Warum Löschen allein keine Lösung ist
Eine Purge-Aktion leert lediglich den aktuellen Cache. Bleibt die fehlerhafte Regel bestehen, wird die nächste 404-Seite oder Weiterleitung erneut gespeichert. Umgekehrt erschwert eine pauschale Leerung aller Website-Caches die Ursachenanalyse und belastet den Origin unnötig.
Die richtige Abnahme prüft daher Richtlinie und Inhalt getrennt: Die öffentliche Antwort muss dynamisch vom vorgesehenen WordPress-Pfad stammen, während normale öffentliche Seiten weiterhin vom CDN profitieren dürfen.
Der einfache Weg für Einsteiger
- Halten Sie eine Administratorsitzung und den dokumentierten Notfallzugang offen.
- Vergleichen Sie Status, Redirect-Ziel und Cache-Header der öffentlichen URL mit der Antwort des Origin-Servers.
- Erfassen Sie alle zugehörigen Wege: eigener Login,
wp-admin, Logout, Passwort-Reset, Registrierung und Sprachvarianten. - Definieren Sie genaue Bypass-Regeln für diese Pfade und die relevanten Login-Cookies.
- Entfernen Sie erst danach die betroffenen 404- oder Redirect-Objekte.
- Testen Sie anonym und angemeldet, mit falschem Kennwort, Logout, Reset sowie in einer zweiten Region oder Verbindung.
Der technische Weg
Zeichnen Sie für Origin und öffentlichen Endpoint Statuscode, Location, Cache-Control, Set-Cookie, Age, Cache-Status, Host und Pfad auf. Vergleichen Sie zudem den Cache-Key und die Priorität aller CDN-Regeln. Ein Redirect darf nicht ohne den Cookie-Zustand gespeichert werden, der ihn ausgelöst hat.
Testen Sie nach der Korrektur einen kalten Cache-Miss und mehrere warme Aufrufe. Bei globalen CDNs sollten mindestens zwei Regionen geprüft werden, weil einzelne Points of Presence noch alte Objekte oder eine verzögert verteilte Konfiguration halten können. Eine absichtlich nicht vorhandene Nachbar-URL bleibt dabei die 404-Kontrolle.
Risiken, häufige Fehler, Backup und Rollback
Zu breite Ausnahmen können die gesamte Website aus dem CDN nehmen; zu enge Regeln lassen dagegen Reset- oder Sprachvarianten ungeschützt. Sichern Sie die aktuelle Regelreihenfolge und dokumentieren Sie die betroffenen Cache-Keys und URLs vor jeder Änderung.
Werden private Antworten gespeichert, berechtigte Nutzer umgeleitet oder andere Login-Wege unterbrochen, nehmen Sie genau die neue Edge-Regel zurück. Stellen Sie anschließend den zuletzt akzeptierten dynamischen Zustand wieder her, bevor Sie eine engere Variante entwerfen.
So unterstützt AIOWS:
AIOWS Login Manager
AIOWS Login Manager verwaltet unterstützte Einstellungen für den WordPress-Login und eigene Zugangswege. Bei einem Cache- oder CDN-Konflikt liefert die dort sichtbare Konfiguration den maßgeblichen WordPress-Pfad, der öffentlich dynamisch erreichbar sein muss. Damit lässt sich die AIOWS-Seite der Diagnose klar von CDN- und Webserverregeln trennen.
Prüfen Sie zunächst direkt am Origin, ob Login Manager den erwarteten Pfad auf das Anmeldeformular führt. Funktioniert er dort, sollte die AIOWS-Einstellung während der weiteren Analyse unverändert bleiben. Die Abweichung liegt dann zwischen öffentlichem Endpoint und Origin. Status-, Redirect- und Cache-Header zeigen, welche vorgelagerte Regel eingreift.
Nach der CDN-Korrektur wird der vollständige Ablauf über den öffentlichen Host getestet: korrekte und falsche Anmeldung, wp-admin, Logout und Passwort-Reset. Die funktionierende Administratorsitzung bleibt offen, bis sowohl ein kalter Aufruf als auch wiederholte Anfragen das erwartete dynamische Verhalten zeigen.
Login Manager kann keinen CDN-Cache leeren, keine externe Cache-Regel umordnen und keine regionale Konvergenz erzwingen. Verursacht dagegen eine AIOWS-Pfadänderung den Konflikt, setzen Sie ausschließlich diese Einstellung über den vorbereiteten Zugang zurück. Dokumentieren Sie Login-Pfad, CDN-Ausnahme und Testergebnisse gemeinsam, damit die Grenze zwischen WordPress und Edge nachvollziehbar bleibt.
Passende AIOWS-Artikel
- WordPress-Login-URL ändern: vollständiger Sicherheitsleitfaden
- Benutzerdefinierte WordPress-Login-URL zeigt 404
- Browser-Caching für WordPress konfigurieren
Fazit und empfohlener Weg
Vergleichen Sie Origin und öffentlichen Endpoint, korrigieren Sie zuerst die Cache-Richtlinie und löschen Sie erst danach alte Objekte. Login, Logout und Passwort-Reset bleiben privat und dynamisch; normale öffentliche Seiten können weiterhin im CDN gecacht werden.
