Zum Inhalt springen 
Ich erkläre knapp und klar, wie du einen Redirect Loop WordPress erkennst, sauber analysierst und zuverlässig beendest. Ich zeige dir sofort umsetzbare Lösungen für SSL-Konflikte, fehlerhafte .htaccess-Regeln, falsche Site-URLs, Caching/Cookies, Plugin-Probleme und Server-Settings – inklusive Tests und Vorbeugung.
Zentrale Punkte
Die folgende Liste fasst die wichtigsten Handgriffe zusammen, bevor ich die Schritte detailliert erkläre.
- Ursache schnell eingrenzen: SSL, .htaccess, URLs, Plugins, Cache
- Standard-Regeln prüfen: .htaccess und wp-config.php
- HTTPS korrekt setzen: Zertifikat, Mixed Content, HSTS
- Plugins testweise abschalten: per Dashboard oder FTP
- Prävention etablieren: Backups, Doku, Monitoring
Was bedeutet ein Redirect Loop konkret?
Eine Weiterleitungsschleife entsteht, wenn URL A zu URL B springt und B wieder zurück zu A – oder wenn mehrere Sprünge am Ende wieder zur Startadresse führen. Der Browser bricht dann mit ERR_TOO_MANY_REDIRECTS ab und blockiert den Aufruf. Ich erkenne die Schleife oft daran, dass der Login nach korrekter Eingabe erneut das Login-Formular lädt. Für Besucher wirkt das wie eine unendliche Runde, für Suchmaschinen wie ein technischer Fehler. Das kostet Vertrauen, verhindert Logins ins Backend und frisst wertvolle Crawl-Budgets.
Hauptursachen für Schleifen in WordPress
Die häufigsten Auslöser finde ich in falschen WordPress-URLs, aggressiven .htaccess-Regeln, doppelten SSL-Erzwingungen oder chaotischen Plugin-Redirects. Auch alte Cookies und harter Browsercache schicken Anfragen in die Irre. Nach Domainwechseln oder HTTPS-Umstellung häufen sich Fehler, weil http und https gemischt auftreten. Bei Themes mit eigenen Umleitungen oder Security-Plugins können sich Regeln gegenseitig blockieren. In seltenen Fällen setzt Malware gezielt Redirects, um Admins auszusperren.
Schnelltests im Browser: Cookies und Cache
Ich starte mit einem Client-Check, weil er in Minuten Klarheit bringt. Ich lösche Cookies und den kompletten Cache für die betroffene Domain. Ein privates Fenster hilft, alte Sitzungen auszuschließen. Falls der Login dann funktioniert, lag es an lokalen Daten und nicht am Server. Tritt der Fehler weiter auf, gehe ich an die Server- und WordPress-Ebene.
.htaccess prüfen und auf Standard zurücksetzen
Ich sichere die .htaccess und stelle sie testweise auf den WordPress-Standard zurück. So entferne ich kollidierende Umleitungen aus früheren Experimenten oder SEO-Regeln.
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Wenn danach alles läuft, ergänze ich zusätzliche Weiterleitungen Schritt für Schritt. Für saubere Bedingungen verweise ich auf htaccess-Weiterleitungen mit praxistauglichen Beispielen. Wichtig: Niemals http→https doppelt erzwingen – einmal auf Serverebene reicht.
WordPress-URLs in Einstellungen und wp-config.php angleichen
Abweichungen zwischen WP_HOME und WP_SITEURL lösen häufig Endlosschleifen aus, vor allem nach Domainumzügen. Ich prüfe zuerst Einstellungen > Allgemein. Wenn das Backend nicht erreichbar ist, setze ich die Werte kurz in der wp-config.php fest:
define( 'WP_HOME', 'https://deinedomain.de' );
define( 'WP_SITEURL', 'https://deinedomain.de' );
Bei Admin-SSL-Problemen entsperre ich den Zugang temporär mit:
define('FORCE_SSL_ADMIN', false);
Sobald ich im Dashboard bin, stelle ich korrekte URLs ein und entferne die Konstanten wieder. Einheitliche Adressen verhindern erneute Schleifen.
HTTPS/SSL-Konflikte sauber beheben
Konflikte entstehen, wenn SSL serverseitig erzwungen wird und zusätzlich ein Plugin Redirects setzt. Ich teste erst, ob das Zertifikat gültig ist, und ob HSTS oder Proxy-Header die Erkennung stören. Dann sorge ich für eine eindeutige Stelle, die https erzwingt – bevorzugt auf Serverebene. Mixed-Content-Fehler und falsche Weiterleitungsketten beseitige ich konsequent. Für die konkrete Umstellung hilft mir diese Anleitung zur HTTPS-Umstellung in WordPress.
Plugins und Themes als Fehlerquelle eingrenzen
Ich schalte verdächtige Plugins ab, besonders Redirect-, SEO- und Security-Tools. Wenn ich nicht ins Backend komme, benenne ich per FTP den Ordner wp-content/plugins in plugins.old um. Danach aktiviere ich im Dashboard jedes Plugin einzeln, bis der Fehler wieder auftaucht. Auch ein Wechsel auf ein Standard-Theme wie Twenty Twenty-Four zeigt, ob das Theme Regeln beisteuert. So finde ich schnell die Ursache und stelle eine konfliktfreie Konfiguration her.
Login-Schleifen beenden: Cookies, Sessions, Security
Wenn der Login trotz korrekter Daten wieder zurückspringt, prüfe ich Cookie-Domain, Pfad und https-Flag. Ich leere Caches auf allen Ebenen: Browser, WordPress-Cache, Object-Cache, CDN. Bei Security-Plugins kontrolliere ich Regeln, die Admin-URLs umleiten oder Logins einschränken. Ich setze zur Diagnose temporär klare Defaults und baue Sicherheit anschließend wieder Stück für Stück auf. Ziel: Eine stabile Session ohne doppelten Redirect.
Reverse Proxy, CDN und Server-Header richtig setzen
Hinter einem Proxy verwechseln Anwendungen leicht http und https, wenn der Forwarded- oder X-Forwarded-Proto-Header fehlt oder falsch ankommt. Ich prüfe Nginx/Apache-Configs, Load-Balancer-Settings und CDN-Weiterleitungen. Wichtig ist, dass WordPress die tatsächliche Client-URL korrekt erkennt. Für Setups mit vorgeschaltetem Proxy hilft mir diese Anleitung zu Reverse Proxy einrichten. So verhindere ich widersprüchliche Regeln zwischen Server, CDN und Plugin.
Malware als letzte Verdachtsquelle
Lässt sich die Schleife trotz aller Korrekturen nicht auflösen, scanne ich die Installation auf Schadcode. Ich vergleiche Kern-Dateien mit Originalen, überprüfe neuere Admins und Cron-Jobs. Redirects in Headern, Template-Dateien oder via JavaScript entlarve ich durch Suche nach window.location, meta refresh oder obskuren Base64-Strings. Nach der Bereinigung setze ich Passwörter neu und ziehe ein frisches Backup. Sicherheit vor Wiederbefall spart später viel Zeit.
Prophylaxe und Monitoring im Alltag
Ich verhindere Schleifen, indem ich Änderungen dokumentiere, Redirects zentral verwalte und vor Live-Deployments in einer Staging-Umgebung teste. Backups lege ich automatisiert an und halte Plugins sowie Themes aktuell. Nach Domainwechseln kontrolliere ich die Site-URLs, SSL und Weiterleitungsketten. Ein kleines Monitoring meldet mir Statuscode-Sprünge frühzeitig. Die folgende Tabelle hilft bei der schnellen Diagnose im Betrieb.
| Symptom | Mögliche Ursache | Direkte Maßnahme | Prüfwerkzeug |
|---|---|---|---|
| ERR_TOO_MANY_REDIRECTS | Doppelte https-Erzwingung | Nur eine Stelle für Redirects nutzen | HTTP-Header-Check, Curl |
| Login springt zurück | Cookie/Session Konflikt | Cookies löschen, Cache leeren | Privates Fenster, DevTools |
| Startseite lädt nicht | .htaccess-Loop | Standard .htaccess aktivieren | Server-Logs, Diff |
| Nur unter Proxy fehlerhaft | Falscher Proto-Header | X-Forwarded-Proto korrekt setzen | Proxy-Config, Header-Trace |
| Plötzlich ab Ranking | Redirect-Ketten | Ketten reduzieren, 301 korrekt | Crawler, Screaming Frog |
Redirects präzise nachverfolgen: Header-Trace und Curl
Bevor ich an Konfigurationen drehe, zeichne ich die exakte Kette nach. In den DevTools (Netzwerk-Tab) siehst du jeden Hop mit Statuscode und Location-Header. Auf der Shell genügt oft:
curl -IL https://deinedomain.de
# oder ausführlich mit Anzeige jeder Umleitung
curl -IL --max-redirs 20 https://deinedomain.de
Ich achte auf Muster wie http→https→http (Hin-und-her) oder www↔non-www. Ein 302, der auf einen 301 folgt, ist ebenfalls verdächtig. Wenn schon der erste Request auf /wp-login.php umleitet, liegt die Ursache meist in Plugin/Theme oder Cookies; passiert es global, ist es oft .htaccess oder Server.
Server- und WordPress-Logs gezielt nutzen
Logs sparen Stunden. Ich aktiviere in der wp-config.php das Debug-Log, ohne es Besuchern anzuzeigen:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Dann prüfe ich /wp-content/debug.log auf Hinweise (z. B. „Cannot modify header information“ vor einem Redirect). Parallel schaue ich in die Webserver-Logs. Bei Apache: access.log und error.log, bei Nginx: access.log mit Status 301/302. Ein Blick in den User-Agent hilft, ob nur Bots oder alle Nutzer betroffen sind.
WP-CLI: schnelle Rettung per Konsole
Wenn das Dashboard nicht erreichbar ist, löse ich vieles per WP-CLI:
# URLs prüfen und setzen
wp option get home
wp option get siteurl
wp option update home 'https://deinedomain.de'
wp option update siteurl 'https://deinedomain.de'
# Permalinks einmal „durchspeichern“
wp rewrite flush --hard
# Caches leeren
wp cache flush
wp transient delete --all
# Plugins massenhaft deaktivieren / gezielt testen
wp plugin deactivate --all
wp plugin activate classic-editor
So komme ich ohne Risiko wieder ans System, finde Übeltäter und aktiviere nur, was wirklich gebraucht wird.
www, Slash und Kanonisierung ohne Loop
Häufig entstehen Schleifen aus kleinen Inkonsistenzen: www vs. non-www, fehlender/zusätzlicher Slash oder Mixed-Proto. Ich entscheide mich für eine Variante und setze nur eine Regelkette. Beispiel non-www→www in Apache (ohne doppeltes https-Erzwingen):
RewriteEngine On
# Nur weiterleiten, wenn Host nicht bereits www ist
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
Bei Nginx setze ich eine klare Server-Block-Weiterleitung und vermeide Mischregeln in PHP/Plugins. Wichtig: Erst die Kanonisierung (www/Slash), dann https – und nur an einer Stelle.
Sauber hinter Proxy/CDN: HTTPS korrekt erkennen
Steht WordPress hinter einem Load-Balancer oder CDN, kommt am Backend oft nur http an, obwohl der Client https nutzt. Dann erkennt WordPress is_ssl() falsch und erzeugt Loops. Ich korrigiere die Server-Variablen früh in der wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Zusätzlich setze ich auf dem Proxy die Header X-Forwarded-Proto bzw. Forwarded sauber. Mit HSTS gehe ich sparsam um: Ist HSTS aktiv, darf es keinen http-Pfad geben, sonst hängt der Browser fest. Preload nutze ich erst, wenn alle Subdomains stabil auf https laufen.
Login- und Cookie-Fallen entschärfen
Eine häufige Quelle sind falsch gesetzte Cookies. Ich setze in der Regel keine COOKIE_DOMAIN. Falls sie einmal definiert wurde, stelle ich testweise um:
define('COOKIE_DOMAIN', false);
Außerdem prüfe ich, ob das Admin-Cookie-Flag „Secure“ unter https gesetzt ist und der Pfad auf „/“ steht. Bei hartnäckigen Problemen lösche ich serverseitige Sessions (z. B. php-fpm neu starten) und leere Object-Cache/Redis, damit alte Nonces nicht mehr greifen.
Besonderheiten bei Multisite und Domain-Mapping
In Multisite-Setups führen abweichende Mappings schnell zum Loop: Subdomain- vs. Verzeichnis-Modus, unterschiedliche Protokolle oder ein altes Domain-Mapping-Plugin mit eigenen Redirects. Ich prüfe die blog- und site-Tabellen, gleiche Protokolle und Hosts ab und deaktiviere kurz Auto-Redirects der Sprachumschaltung. Ein „Super Admin“-Login im Hauptblog hilft, Netzwerk-Weiterleitungen zentral zu sehen. Wichtig: Nur eine Instanz entscheidet über die kanonische Domain.
WooCommerce, Mehrsprachigkeit und „Hide Login“
Shops und mehrsprachige Sites besitzen zusätzliche Redirect-Logiken: erzwungene SSL-Seiten (Kasse/Konto), Sprachumleitung nach Accept-Language oder „Hide Login“-Funktionen in Security-Plugins. Für die Diagnose deaktiviere ich die automatische Sprachweiterleitung und erlaube /wp-login.php temporär ohne Umweg. In WooCommerce stelle ich „Nur diese Seiten auf SSL“ entweder sauber serverseitig sicher oder komplett systemweit, damit keine Mischzustände entstehen.
Object-Cache, Opcode und Edge-Cache koordinieren
Mehrere Caching-Schichten können sich gegenseitig verstärken: PHP-Opcode (OPcache), Object-Cache (Redis/Memcached), Seiten-Cache von Plugins und CDN-Edge. Ich leere sie in geordneter Reihenfolge, damit kein Layer alte Redirects zurückliefert. Nach Regeländerungen invalidiere ich Edge-Cache vollständig. Erst danach ist ein Test aussagekräftig.
Typische Nginx-Fallen
Bei Nginx entstehen Loops, wenn location-Blöcke doppelt umschreiben oder /index.php intern und extern wohnen. Ich nutze eine einzige saubere Konfiguration: erst die Server-Block-Weiterleitung (www/https), dann ein klarer try_files auf /index.php. Mischungen aus add_header Refresh und 301/302 meide ich konsequent.
Checkliste: in 10 Minuten zur Ursache
- Cookies/Cache lokal löschen, im Inkognito testen
- curl -IL laufen lassen und die Kette ansehen
- .htaccess/Nginx auf Standardpfad zurücksetzen
- WP_HOME/WP_SITEURL abgleichen (ggf. via WP-CLI)
- Nur eine Instanz erzwingt https (Server bevorzugt)
- Plugins/Theme deaktivieren, schrittweise aktivieren
- Proxy-Header korrekt setzen, is_ssl() prüfen
- Object-/Page-/Edge-Cache leeren
- Logs checken: debug.log, access/error.log
- Besonderheiten: Multisite, Woo, Sprachen, Hide-Login
Fehlerbilder jenseits klassischer Loops
Nicht jeder 301/302 ist ein echter Loop – aber Fehlleitungen kosten ebenfalls. Ein 301 auf 404 signalisiert Suchmaschinen „diese Ressource ist für immer hier“, liefert aber Leere aus. Oder ein 302 statt 301 verhindert die dauerhafte Konsolidierung von Signalen. Ich halte die Kette maximal ein- bis zweistufig, setze 301 für permanente, 302 für temporäre Fälle und vermeide Query-String-Verluste, indem ich QSA-Flags bzw. args korrekt übergebe.
Stabile Deployments und Dokumentation
Damit Loops gar nicht erst entstehen, dokumentiere ich jede Regel: Wer leitet was wohin – und warum? Ich nutze eine Staging-Umgebung, spiele Regeländerungen dort durch, protokolliere Header und Zeiten und verteile anschließend identische Server- und Plugin-Settings in Produktion. Ein kurzer Post-Deployment-Check (Startseite, Login, Kasse, Sprache) verhindert Ausfälle.
Abschluss in Kürze
Ich löse eine Weiterleitungsschleife systematisch: Cookies prüfen, .htaccess auf Standard zurückfahren, WP-URLs angleichen, SSL sauber setzen, Plugins/Theme isolieren und Server-Header korrekt ausliefern. Mit diesen Schritten endet der Loop meist in kurzer Zeit. Danach sichere ich die Installation, dokumentiere Redirects und halte Updates aktuell. So bleibt das Login erreichbar, Besucher landen auf den richtigen Seiten und Suchmaschinen crawlen ohne Zeitverlust. Wer strukturiert vorgeht, vermeidet Wiederholungen – und spart Nerven.
