Zu viele Weiterleitungen: ERR_TOO_MANY_REDIRECTS beheben

Was bedeutet der Fehler zu viele Weiterleitungen (ERR_TOO_MANY_REDIRECTS)?

Zu viele Weiterleitungen bedeutet, dass Ihr Browser in einer Endlosschleife steckt: Er läuft von Adresse A zu Adresse B und von dort zurück zu A. Nach einer festen Zahl von Versuchen gibt er dann auf. Chrome zeigt dann ERR_TOO_MANY_REDIRECTS. Konkret liegt die Ursache meist in den Weiterleitungseinstellungen der Website, nicht an Ihrem Gerät.

Eine Weiterleitung bedeutet, dass der Server sagt: Der gesuchte Inhalt liegt unter einer anderen Adresse. Dazu sendet er also einen 3xx Statuscode und einen Location Header. RFC 9110 definiert diese Codes daher verbindlich. Außerdem erwartet der Standard, dass Clients zyklische Weiterleitungen erkennen und eingreifen. Somit löst genau diese Schutzfunktion die Fehlerseite von Chrome aus.

Eine Schleife entsteht allerdings selten durch eine einzelne Regel. Stattdessen heben sich zwei Regeln gegenseitig auf. Zum Beispiel leitet eine Regel HTTP auf HTTPS um, während eine andere Ebene HTTPS wieder auf HTTP zurückstellt. Der Besucher pendelt dann zwischen beiden. In diesem Leitfaden zeigen wir, wie Sie die Ebene finden, die die Schleife baut, und wie Sie sie durchbrechen.

Die SEO Seite langer Ketten behandeln wir in einem eigenen Beitrag: Weiterleitungskette beheben. Dort geht es zunächst um Ketten, die lang sind, aber noch auf einer Seite enden. Hier geht es dagegen um Schleifen ohne Ende, also um Fehler, bei denen die Seite nie öffnet.

Wer muss den Fehler beheben: Besucher, Websitebetreiber oder Serveradmin?

Wer den richtigen Zuständigen benennt, spart also Zeit. Denn jede Rolle hat einen anderen Schalter in der Hand. Deshalb zeigt die folgende Tabelle, wer bei einer Weiterleitungsschleife wo suchen sollte.

In kleinen Unternehmen sind diese vier Rollen oft eine einzige Person. Trotzdem sollten Sie die Reihenfolge einhalten. Schließen Sie zunächst die Besucherseite aus, dann prüfen Sie die Ebenen von außen nach innen. Sehen auch andere Personen denselben Fehler, liegt es dann nicht an Ihrem Browser.

Wie zeigen Browser diesen Fehler an?

Der Wortlaut hängt vom Browser ab, die Bedeutung bleibt allerdings gleich. Chromium Browser wie Chrome und Edge melden, die Seite habe Sie zu oft weitergeleitet, und nennen ERR_TOO_MANY_REDIRECTS. Außerdem empfehlen sie meist, Cookies zu löschen.

Firefox dagegen meldet, die Seite leite nicht richtig weiter. Safari schreibt, die Seite lasse sich nicht öffnen, weil zu viele Weiterleitungen auftreten. Der genaue Text kann sich nämlich zwischen Versionen ändern. Achten Sie deshalb auf das Verhalten statt auf die Worte: Die Seite lädt nie, und die Adresszeile wechselt zwischen denselben Adressen.

• Leere Seite: Es erscheint nie ein Inhalt.
• Manchmal betrifft der Fehler nur eine Adresse, während einige Unterseiten noch öffnen.
• Zum Beispiel: Verschwindet der Fehler im privaten Fenster, sind Cookies oder Cache die wahrscheinliche Ursache.
• Zeigen ihn alle Browser und Geräte, liegt die Ursache beim Server oder CDN.

Daher verkürzen diese vier Hinweise die erste halbe Stunde der Diagnose. Sie erkennen also Besucherseite und Serverseite, bevor Sie einen einzigen Befehl tippen.

Was können Besucher tun, wenn ERR_TOO_MANY_REDIRECTS erscheint?

Treffen Sie den Fehler auf einer fremden Website, sind Ihre Möglichkeiten dagegen begrenzt. Ein Versuch lohnt sich dennoch. Öffnen Sie die Seite zunächst in einem privaten Fenster. Ein privates Fenster ignoriert Ihre aktuellen Cookies, daher kann ein defektes Sitzungscookie die Schleife nicht mehr auslösen.

1. Öffnen Sie die Adresse im privaten Fenster und notieren Sie das Ergebnis.
2. Löschen Sie nur die Cookies dieser Website, nicht den gesamten Verlauf.
3. Leeren Sie den Cache, denn Browser speichern manche Weiterleitungen.
4. Probieren Sie einen anderen Browser oder Ihr Handy mit mobilen Daten.
5. Schalten Sie Browsererweiterungen aus, vor allem Datenschutz und Weiterleitungstools.

Bleibt der Fehler danach bestehen, liegt das Problem sehr wahrscheinlich bei der Website selbst. Dann teilen Sie dem Betreiber mit, welche Adresse, welchen Browser und welche Uhrzeit Sie hatten. Eine solche Notiz verkürzt die Diagnose also deutlich.

Wie verfolgen Sie die Weiterleitungskette mit curl -I?

Browser verbergen Weiterleitungen vor Ihnen, deshalb müssen Sie die Kette sehen. Um zu viele Weiterleitungen zu verstehen, müssen Sie die Kette sehen, und curl zeigt jeden Schritt. Zunächst folgt der Befehl unten der Adresse und gibt Statuszeile und Location Header jeder Antwort aus. Mit --max-redirs begrenzen wir die Schritte, damit der Befehl nicht ewig läuft.

curl -sIL --max-redirs 8 https://example.com/ | grep -iE '^(HTTP|location)'

Listet die Ausgabe immer wieder dieselben zwei Adressen auf, haben Sie die Schleife gefunden. Notieren Sie dann, welche Adresse auf welche zeigt. Danach testen Sie die HTTP und die HTTPS Version sowie die Varianten mit und ohne www einzeln.

curl -sI http://example.com/ | grep -iE '^(HTTP|location)'
curl -sI https://www.example.com/ | grep -iE '^(HTTP|location)'
curl -sL -o /dev/null --max-redirs 8 -w '%{num_redirects} %{url_effective}\n' https://example.com/

Der dritte Befehl gibt nur die Zahl der Weiterleitungen und die Endadresse aus. In einer Schleife bricht curl daher mit einem Fehler ab, sobald es das Limit erreicht. Die Befehle sind Beispiele, tauschen Sie also die Domain gegen Ihre eigene. Die Kommandozeile hat zudem einen Vorteil: Cookies und Cache stören nicht.

Möchten Sie kein Terminal nutzen, zeigt unser Redirect Checker dieselbe Kette Schritt für Schritt im Browser.

Wie sehen Sie eine Weiterleitungsschleife in den Entwicklertools?

Bevorzugen Sie den Browser gegenüber der Kommandozeile, helfen stattdessen die Entwicklertools. Zunächst öffnen Sie in Chrome mit F12 den Tab Network. Aktivieren Sie danach vor dem Neuladen die Option Preserve log. Sonst löscht der Browser bei jeder Weiterleitung das Protokoll, und Sie sehen die Kette nicht.

1. Öffnen Sie den Tab Network und aktivieren Sie Preserve log.
2. Laden Sie die Adresse im privaten Fenster neu.
3. Prüfen Sie, ob sich dieselben zwei Adressen mit 3xx Codes in der Statusspalte wiederholen.
4. Klicken Sie auf eine Zeile und lesen Sie unter Response Headers den Location Header.

Der Location Header zeigt konkret, wohin der Server Sie in diesem Schritt schickt. Zwei Zeilen mit demselben Header zeigen also das ganze Bild der Weiterleitungsschleife. Steht dort zum Beispiel HTTP, fehlt eine HTTPS Regel. Sehen Sie einen Unterschied bei www, ist die kanonische Adresse uneinheitlich. Außerdem können Sie dem Support einen Screenshot dieser Ansicht schicken.

In welcher Reihenfolge finden Sie die Ebene, die die Schleife auslöst?

Zunächst läuft eine Anfrage durch Browser, DNS, CDN oder Proxy, Webserver und Anwendung. Eine dieser Ebenen baut die Schleife, daher müssen Sie sie der Reihe nach ausschließen. Wahllos Einstellungen zu ändern, erschwert dagegen die Suche, wenn zu viele Weiterleitungen auftreten.

1. Schließen Sie die Browserebene mit einem privaten Fenster und einem zweiten Gerät aus.
2. Nutzen Sie ein CDN oder einen Proxy, schalten Sie ihn kurz auf reines DNS und vergleichen Sie das Ergebnis.
3. Fragen Sie den Server direkt: Mit curl und --resolve umgehen Sie das CDN.
4. Prüfen Sie dann die Regeln des Webservers, also .htaccess oder die Nginx Konfiguration.
5. Prüfen Sie zuletzt die Anwendung, zum Beispiel WordPress Adressen, Plugins und Cache.

Dann zwingt der Befehl in Schritt drei die Domain auf eine bestimmte Serveradresse. Die Beispieladresse stammt aus einem Dokumentationsblock, ersetzen Sie sie also durch die Adresse Ihres Servers.

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | grep -iE '^(HTTP|location)'

Verschwindet die Schleife bei der direkten Anfrage, fügt die CDN Ebene sie hinzu. Bleibt sie dennoch bestehen, suchen Sie die Regel auf dem Server oder in der Anwendung. Welche Adresse Ihre Domain nutzt, prüfen Sie mit unserer DNS Abfrage.

Warum verursacht ein Konflikt zwischen HTTP und HTTPS eine Weiterleitungsschleife?

Die häufigste Ursache ist einfach: Zwei Ebenen wissen Unterschiedliches über HTTPS. Ein CDN oder Load Balancer spricht zum Beispiel mit dem Besucher HTTPS, mit Ihrem Server aber vielleicht unverschlüsseltes HTTP. Der Server sieht eine HTTP Anfrage und sagt: Gehen Sie zu HTTPS. Dann fragt das CDN wieder per HTTP, und die Schleife schließt sich.

In der Praxis beschreibt die Apache Dokumentation diesen Fall klar. Konkret fragt die Variable %{HTTPS} direkt mod_ssl ab. Beendet ein Load Balancer oder Reverse Proxy die SSL Verbindung, meldet sie off, obwohl der Client HTTPS nutzte. Daher prüfen Sie stattdessen den Header X-Forwarded-Proto, den der Proxy hinzufügt.

• Schaut der Server also nur auf seine eigene Verbindung, versteckt der Proxy davor die Wahrheit.
• Vertrauen Sie dem Proxy Header nur, wenn der Proxy ihn bei jeder Anfrage selbst überschreibt.
• Hat auch der Server ein Zertifikat, können Sie am CDN volle Verschlüsselung nutzen und die Serverweiterleitung behalten.

Deshalb rät die Apache Dokumentation, diesem Header nur zu vertrauen, wenn Sie den vorgelagerten Proxy kontrollieren. Sonst könnte ein Angreifer den Server direkt ansprechen und den Header fälschen. Die Grundlagen zu Zertifikaten erklären wir in Was ist ein SSL Zertifikat, deshalb wiederholen wir sie hier nicht.

Was ändern die Weiterleitungscodes 301, 302, 307 und 308 in einer Schleife?

Zunächst teilt RFC 9110 die Weiterleitungscodes in zwei Familien. Die Codes 301 und 308 melden einen dauerhaften Umzug, 302 und 307 einen vorübergehenden. Sowohl 307 als auch 308 behalten die Anfragemethode. Dagegen erlauben 301 und 302, dass sich die Methode ändert. Außerdem steht bei allen vier die neue Adresse im Location Header.

Die Art des Codes zählt, ebenso die Reihenfolge. Sehen Sie eine Schleife, die mit einer 301 beginnt und mit derselben 301 endet, müssen Sie eine dauerhafte Regel finden. Diese Regel steht allerdings meist auf Server oder CDN Ebene.

Wie baut ein Konflikt zwischen www und ohne www eine Schleife?

Eine Website kann nicht zwei kanonische Adressen haben, daher wählen Sie eine und leiten die andere dorthin um. Eine Schleife entsteht also, wenn zwei Ebenen verschiedene Adressen wählen. Das Hosting Panel sagt: Gehen Sie zur Adresse ohne www. Die Einstellung der Anwendung sagt: Gehen Sie zur Adresse mit www. Beide Seiten begegnen sich dann endlos.

Ein typisches Szenario sieht zum Beispiel so aus. Sie haben die Domain zu einem neuen Hostingkonto umgezogen. Dann behielt das Panel eine Weiterleitungsregel mit der alten Präferenz. WordPress dagegen wurde mit der neuen Präferenz eingerichtet. Die erste Regel entfernt www, die zweite fügt es wieder an.

Die Lösung: Wählen Sie genau eine kanonische Adresse und erzwingen Sie sie nur an einer Stelle. Für Hostnamen empfiehlt die Apache Dokumentation die Direktive Redirect in einem Virtual Host statt mod_rewrite. Die Grundlagen zur Adresse selbst lesen Sie in Was ist www.

Wie beheben Sie zu viele Weiterleitungen in WordPress?

In WordPress sind zunächst die ersten Verdächtigen die Felder WordPress Adresse und Websiteadresse auf der Seite Allgemein. Steht in einem Feld HTTP und im anderen HTTPS, oder unterscheidet sich www, leitet WordPress sich selbst immer wieder um. Beide Felder müssen also übereinstimmen und stimmen.

Können Sie sich nicht anmelden, tragen Sie die Werte in wp-config.php ein. Die offizielle WordPress Dokumentation zeigt dafür die Konstanten WP_HOME und WP_SITEURL. Sie warnt allerdings, dass dieser Weg die Werte nur fest einträgt und die Felder unter Allgemein sperrt.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Haben Sie Zugriff auf WP-CLI, prüfen Sie dasselbe per Befehl. Die ersten beiden Befehle lesen die Werte, die letzten beiden aktualisieren sie. Machen Sie vorher ein Backup.

wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Bei WordPress hinter einem Reverse Proxy oder CDN kommt ein Detail hinzu. Die offizielle HTTPS Dokumentation warnt, manche SSL Optionen führten zunächst in eine Endlosschleife, wenn ein Proxy SSL liefert und WordPress selbst ohne SSL läuft. Ein kleiner Codeabschnitt bringt WordPress dann bei, den Header X-Forwarded-Proto zu lesen. Sichern Sie vorher alles; dazu lesen Sie unsere Website Backup Strategie.

Was tun, wenn nur das Admin Dashboard in die Schleife läuft?

Manchmal öffnet die Startseite, aber der Admin Login läuft dennoch in die Schleife. In WordPress ist die typische Ursache daher erzwungenes HTTPS für das Dashboard. Die offizielle Dokumentation beschreibt dazu die Konstante FORCE_SSL_ADMIN. Sie warnt, dass sie hinter einem Proxy mit SSL eine Endlosschleife auslösen kann, bis Sie WordPress den Proxy Header beibringen.

Zunächst klären Sie, ob die Verbindung als HTTP beim Server ankommt. Mit CDN oder Load Balancer sieht der Server nämlich vielleicht HTTP. Dann entscheidet WordPress, das Dashboard müsse HTTPS nutzen, und leitet um. Danach reicht der Proxy wieder per HTTP weiter. Die Lösung: Erkennen Sie HTTPS anhand des Headers X-Forwarded-Proto.

Die Cookie Domain ist außerdem der zweite Verdächtige. Läuft das Dashboard auf der Adresse mit www, das Cookie steht aber auf der Adresse ohne www, verschwindet die Sitzung immer wieder. Die Anmeldeseite schickt Sie dann zurück zur Anmeldeseite. Machen Sie deshalb zuerst Ihre WordPress Adressen einheitlich und löschen Sie danach Ihre Cookies.

Wie finden und beheben Sie Regelkonflikte in der .htaccess?

Auf Apache Seiten stehen Weiterleitungsregeln meist in der Datei .htaccess, denn sie braucht keinen Serverzugriff. Das Hosting Panel, ein Sicherheits Plugin, ein Cache Plugin und WordPress selbst können dort Regeln anlegen. Zwei Regeln mit demselben Zweck oder mit gegensätzlichem Zweck erzeugen somit eine Schleife.

Sichern Sie zunächst die Datei, dann vereinfachen Sie sie. Der Standardblock von WordPress sieht wie unten aus und enthält keine Weiterleitung. Deaktivieren Sie jede Regel außerhalb dieses Blocks einzeln und testen Sie die Website nach jeder Änderung.

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Müssen Sie HTTPS erzwingen, folgen Sie dem Rezept der Apache Dokumentation. Haben Sie dagegen nur Zugriff auf .htaccess, ist mod_rewrite das richtige Werkzeug. Können Sie die Serverkonfiguration bearbeiten, ist ein Redirect in einem eigenen HTTP Virtual Host sauberer.

RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

Hinter einem Load Balancer oder CDN stellen Sie die Bedingung auf den Header X-Forwarded-Proto um. Sonst ist die Bedingung immer wahr, und die Schleife beginnt. Außerdem aktivieren Sie dieselbe HTTPS Regel nie ein zweites Mal in einem Plugin, Panel oder CDN. Kurz gesagt erleichtert eine Regel an einer Stelle die Fehlersuche.

Wie entsteht eine Weiterleitungsschleife in Nginx?

Die Logik ist in Nginx dieselbe: Zwei Blöcke oder ein Block und die Anwendung leiten sich gegenseitig entgegengesetzt um. In der Praxis ist am saubersten ein eigener Server Block auf Port 80 für die dauerhafte Weiterleitung. Im 443 Block steht dann keine Weiterleitung zurück auf HTTP.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

In diesem Beispiel gehen alle HTTP Anfragen an eine kanonische HTTPS Adresse. Im HTTPS Block braucht es eventuell eine Regel, die die Adresse mit www auf die kanonische Adresse umlegt. Schickt der HTTPS Block Besucher zurück auf HTTP, ist somit eine Schleife unvermeidbar.

Ein weiterer Fehler lässt sich allerdings leicht verwechseln. Nginx hat einen eigenen internen Rewrite Zyklus, der keine Weiterleitung an den Browser sendet. Dann sehen Sie im Log die Meldung "rewrite or internal redirection cycle", und der Server antwortet mit einem 500 Fehler. Das ist nicht ERR_TOO_MANY_REDIRECTS, aber das Log bleibt trotzdem die erste Anlaufstelle.

Nach jeder Änderung an der Nginx Konfiguration testen Sie zuerst die Syntax und laden dann neu. Möchten Sie nicht auf einem Produktionsserver experimentieren, überlassen Sie diese Arbeit Ihrem Serveradmin.

Warum verursacht Cloudflare Flexible SSL zu viele Weiterleitungen?

Die bekannteste Ursache hinter Cloudflare ist daher der Modus Flexible SSL. Laut Cloudflare Dokumentation entsteht die Schleife, wenn Ihr Ursprungsserver HTTP auf HTTPS umleitet, während Cloudflare unverschlüsselte Anfragen an ihn sendet. Zunächst fragt Cloudflare per HTTP, der Server antwortet mit einer HTTPS Weiterleitung, und der Kreis beginnt von vorn.

Die Dokumentation nennt zwei Lösungen. Entweder entfernen Sie die HTTPS Weiterleitung am Ursprungsserver, oder Sie installieren dort ein Zertifikat und wechseln zu Full. Die zweite Variante ist sicherer, denn im Modus Flexible bleibt die Verbindung zwischen Cloudflare und Ihrem Server unverschlüsselt.

Cloudflare weist außerdem darauf hin, dass HSTS Probleme macht, wenn der Verschlüsselungsmodus Off ist oder der Server HTTPS auf HTTP zurückstellt. Ihr Zertifikat und die Kette prüfen Sie mit unserem SSL Check.

Wie finden Sie Konflikte durch Plugins, CDN und Cache?

Erledigen mehrere Ebenen dieselbe Aufgabe, steigt das Konfliktrisiko. Zum Beispiel können ein SSL Plugin, ein Cache Plugin, die .htaccess und das CDN gleichzeitig HTTPS erzwingen. Jedes funktioniert allein. Zusammen leiten sie die Ergebnisse der anderen erneut um.

1. Benennen Sie den Ordner plugins in wp-content vorübergehend um, damit alle Plugins ausfallen.
2. Verschwindet der Fehler, benennen Sie den Ordner zurück und aktivieren die Plugins einzeln.
3. Beginnen Sie mit Weiterleitungs, SSL, Sicherheits und Cache Plugins.
4. Leeren Sie den CDN Cache und rufen Sie die Seite erneut auf.

Mit WP-CLI erledigt der Befehl wp plugin deactivate --all dasselbe sauberer. Er schaltet allerdings jedes Plugin einer Live Seite ab. Fällt ein Shop oder Formular aus, merken Besucher das sofort. Probieren Sie ihn deshalb in einem Wartungsfenster.

Seien Sie auch beim Cache vorsichtig. Ein Cache Plugin kann eine defekte Weiterleitungsantwort speichern und weiter ausliefern. Leeren Sie nach der Korrektur den Plugin Cache und den CDN Cache. Sonst glauben Sie, das Problem bestehe noch.

Warum merkt sich der Browser die alte Weiterleitung auch nach der Korrektur?

RFC 9110 behandelt eine 301 Antwort standardmäßig als zwischenspeicherbar. Ein Browser kann also eine dauerhafte Weiterleitung speichern und das alte Ziel ansteuern, ohne den Server zu fragen. Selbst nach der Korrektur zeigt Ihr eigener Browser den Fehler dann weiter.

Prüfen Sie daher mit curl und nicht mit dem Browser. Im Browser nutzen Sie ein privates Fenster oder leeren Cache und Cookies dieser Website. Beim Testen hinterlässt eine vorübergehende Weiterleitung (302 oder 307) keine dauerhafte Spur einer falschen Regel. Steht die richtige Regel fest, wechseln Sie zu 301 oder 308.

HSTS ist eine eigene zwischengespeicherte Regel. Hat eine Website HSTS gesendet, stellt der Browser für diese Domain eine Zeit lang HTTP auf HTTPS um. Schickt Ihr Server HTTPS zurück auf HTTP, endet die Schleife erst, wenn Sie die Serverregel korrigieren. Bevor Sie HSTS aktivieren, sollten Sie sicherstellen, dass HTTPS auf jeder Subdomain funktioniert.

Schaden zu viele Weiterleitungen dem SEO und dem Ranking?

Ja, das ist möglich. Eine Adresse in einer Schleife liefert nie Inhalt. Auch ein Suchmaschinen Bot folgt nicht endlos. In der Crawling Dokumentation schreibt Google, seine Crawler folgten standardmäßig bis zu 10 Weiterleitungsschritten. Eine Schleife erreicht dieses Limit, und der Inhalt bleibt unerreichbar.

Folglich kann Google Seiten, die zu viele Weiterleitungen auslösen, nicht crawlen. Beheben Sie den Fehler schnell, erwarten Sie normalerweise keinen bleibenden Schaden. Eine Schleife über mehrere Tage kann allerdings Aktualisierungen und die Entdeckung neuer Inhalte verzögern. Das ist eine logische Folge, keine Garantie und keine Zahlenschätzung.

• Search Console: Suchen Sie in den Berichten zu Crawling und Seitenindexierung nach Weiterleitungsfehlern.
• Listen Sie die betroffenen Adressen auf, denn oft ist eine Vorlage oder ein Ordner betroffen.
• Prüfen Sie nach der Korrektur Beispieladressen erneut mit curl.

Zu Crawl Budget und Tempo lesen Sie weiter bei Wie beeinflusst die Ladezeit SEO. Einheitliche Weiterleitungen stehen bei uns immer auf der Liste des technischen SEO Audits, schauen Sie also auf unsere SEO Beratung.

Warum entstehen Schleifen nach einem Website Umzug?

Ein Domain oder Hosting Wechsel ist der Moment, in dem Schleifen am häufigsten auftreten. Die Regeln der alten Umgebung wandern in die neue, aber die Standardwerte der neuen Umgebung unterscheiden sich. Zum Beispiel hatte der alte Server ein Zertifikat, der neue noch nicht. Oder das alte Setup hatte kein CDN, das neue schon.

Bereiten Sie vor dem Umzug eine Checkliste vor. Stellen Sie sicher, dass die Werte home und siteurl in der Datenbank auf die neue Adresse zeigen. Kopieren Sie nicht die alte .htaccess unverändert, sondern übernehmen Sie nur die nötigen Regeln. Bestätigen Sie, dass das Zertifikat in der neuen Umgebung aktiv ist, und stellen Sie erst danach DNS um.

• Vergleichen Sie vor dem Umzug den SSL Status der alten und der neuen Umgebung.
• Stellen Sie sicher, dass in der Datenbank keine alte Domain übrig bleibt.
• Testen Sie zuerst auf einer temporären Adresse, dann gehen Sie live.
• Sammeln Sie am Umzugstag alle Weiterleitungsregeln an einer Stelle.

Gehört die Serverkonfiguration nicht Ihnen, gehen Sie diese Schritte gemeinsam mit Ihrem Hostinganbieter durch. So kündigt der Anbieter seine eigenen Weiterleitungen vorher an.

Wie verhindern Sie, dass die Weiterleitungsschleife wiederkommt?

Eine Weiterleitungsschleife tritt meist direkt nach einer Änderung auf: Domainumzug, SSL Installation, neues CDN oder ein Update von Theme oder Plugin. Zu viele Weiterleitungen lassen sich also vermeiden, und zwar mit einer kleinen Checkliste vor und nach jeder Änderung.

1. Wählen Sie eine kanonische Adresse: HTTPS und entweder mit www oder ohne www.
2. Erzwingen Sie diese Wahl nur an einer Stelle und schalten Sie sie in den anderen Ebenen aus.
3. Sichern Sie vor einer Änderung .htaccess oder die Nginx Datei, wp-config.php und die Datenbank.
4. Testen Sie nach einer Änderung alle vier Adressen mit curl: HTTP, HTTPS, mit www und ohne www.
5. Stimmen Sie den SSL Modus des CDN auf den echten Zustand Ihres Servers ab.

Auch eine vorab gezeichnete Weiterleitungskarte hilft. Schreiben Sie beim Start einer neuen Website die alten und neuen Adressen in eine Tabelle. Dann sehen Sie, welche Regel welche Adresse wohin führt. Zur Prüfung von Domaindaten ist eine WHOIS Abfrage ebenfalls praktisch.

Was Sie beim ersten Einrichten von einem Anbieter erfragen sollten, erklären wir in Webhosting auswählen.

Wann sollten Sie das nicht selbst tun, sondern Ihrem Hostinganbieter überlassen?

Ehrlich gesagt sind wir kein Hostingunternehmen. Wir sind ein Team für digitales Marketing und Webentwicklung, und dieser Leitfaden stützt sich auf offizielle Dokumentation und Standards. Wo ein Schritt riskant wirkt, verweisen wir Sie deshalb an Ihren Hostinganbieter.

• Bei Shared Hosting ohne SSH und Zugriff auf die Serverkonfiguration sollte der Support des Anbieters die Regeln korrigieren.
• Haben Sie kein Backup, ändern Sie weder .htaccess noch wp-config.php noch die Datenbank. Sichern Sie zuerst.
• Bei Managed Hosting leitet der Anbieter eventuell auf seiner eigenen Ebene um, und Ihre Regel kollidiert damit.
• Verliert ein Live Shop jede Stunde Umsatz, fordern Sie vom Anbieter prioritären Support statt Versuch und Irrtum.
• Machen Sie keine Änderung allein, die DNS Einträge oder E-Mail Einstellungen zerstören könnte.

Wenn Sie Ihren Anbieter kontaktieren, helfen die curl Ausgabe und der Zeitpunkt des Fehlerbeginns am meisten. Damit findet der Support die Schleife oft schon in der ersten Antwort. Möchten Sie Weiterleitungen bei einem Relaunch oder Umzug von Anfang an planen, deckt unser Webdesign auch diesen Plan ab.