Blog
Umleitungsfehler in der Google Search Console beheben
Google kam beim Folgen einer Weiterleitung nicht bei deiner Seite an. So verfolgst du die Kette mit curl oder im Browser, findest die Ursache und behebst sie.
Im Bericht zur Seitenindexierung steht bei einer Adresse «Umleitungsfehler». Die Meldung bedeutet: Google hat beim Abruf dieser Adresse eine Weiterleitung erhalten und ist auf dem Weg zum Ziel gescheitert. Über diese Adresse gelangt Google deshalb nicht zu der Seite, auf die sie zeigen soll, und die Adresse selbst wird nicht indexiert.
In der deutschen Google-Hilfe zum Seitenindexierungsbericht heisst derselbe Grund «Weiterleitungsfehler». Google nennt dort vier Möglichkeiten: «Eine zu lange Weiterleitungskette», «Eine Weiterleitungsschleife», «Eine Weiterleitungs-URL, die die maximale URL-Länge überschritten hat» und «Eine ungültige oder leere URL in der Weiterleitungskette». Welche davon zutrifft, steht nicht im Bericht. Du siehst es, wenn du die Weiterleitungen der betroffenen Adresse Station für Station verfolgst.
Zeigt dir Firefox beim Aufruf einer Website «Fehler: Umleitungsfehler», ist das eine Meldung des Browsers, nicht der Search Console. Wie du dann in drei Schritten klärst, ob es an der Website oder an deinem Browser liegt, steht im Abschnitt «Fehler: Umleitungsfehler» im Firefox.
Das tust du jetzt: Verfolge die Beispieladresse aus dem Bericht mit curl oder den Entwicklertools deines Browsers bis zum Ende. Endet die Kette bei der passenden Seite mit Status 200, funktioniert dieser Abruf. Kürze überflüssige Zwischenschritte und prüfe das Ziel zusätzlich mit Googles Live-Test. Ein erfolgreicher Browserabruf allein schliesst eine zeitweise Störung oder eine abweichende Antwort für Google nicht aus. Endet die Kette nicht, suchst du die Regel, die den Fehler erzeugt, und korrigierst sie. Anschliessend startest du im Bericht «Fehlerbehebung überprüfen». Am Schluss zeige ich den Fall aus meiner eigenen Search Console: eine Adresse, die Google zuletzt im Mai auf meiner früheren Website abgerufen hat.
Was «Umleitungsfehler» bedeutet
Eine Weiterleitung schickt jeden, der eine Adresse aufruft, zu einer anderen Adresse. Der Server liefert dann keine Seite, sondern einen Statuscode wie 301 oder 308 und die neue Adresse. Leitet auch diese weiter, entsteht eine Kette. Jede Station nennt Google einen «Weiterleitungs-Hop». In seiner Übersicht zu HTTP-Statuscodes schreibt Google: «Der Googlebot folgt beim Crawlen allgemeiner Webinhalte in der Regel bis zu 10 Weiterleitungs-Hops». Wie die Prüftools der Search Console mit Weiterleitungen umgehen, beschreibt Google nicht einheitlich; darauf geht Schritt 4 der Prüfung ein.
Ein Umleitungsfehler entsteht, wenn diese Kette nicht bei einer Seite endet: weil sie mehr als zehn Stationen hat, im Kreis führt, eine immer längere Adresse erzeugt oder auf eine leere oder ungültige Adresse zeigt. «Umleitungsfehler» im Bericht und «Weiterleitungsfehler» in der Hilfe bezeichnen denselben Grund; Oberfläche und Hilfe sind unterschiedlich übersetzt.
Wichtig für die Einordnung: Der Bericht zeigt das Ergebnis des letzten Abrufs. In der Spalte «Zuletzt gecrawlt» steht, wann Google die Adresse zuletzt versucht hat. Liegt dieses Datum vor einer Umstellung deiner Website, etwa vor einem Relaunch oder dem Wechsel auf https, beschreibt die Meldung den damaligen Zustand. Ob er heute noch besteht, prüfst du selbst.
Nicht verwechseln: ähnliche Meldungen
- «Seite mit Weiterleitung»: Google ist der Weiterleitung gefolgt und angekommen. Die Hilfe beschreibt diesen Grund so: «Dies ist eine nicht kanonische URL, die zu einer anderen Seite weiterleitet. Daher wird diese URL nicht indexiert.» Bei einer bewusst umgezogenen Seite ist das der gewünschte Zustand. Steht dort aber eine Seite, die gar nicht weiterleiten soll, entfernst du die Weiterleitung und beantragst in der URL-Prüfung die Indexierung. So war es bei meiner Preisseite
/preise: Google hat sie am 17. September 2026 abgerufen, als sie auf/leistungenweiterleitete. Seit dem 24. September ist sie wieder eine eigene Seite, und am 25. September habe ich die Indexierung beantragt. - «Nicht gefunden (404)»: Die Adresse liefert keine Seite und leitet auch nicht weiter. Gibt es für eine alte Adresse eine passende neue Seite, richtest du eine Weiterleitung ein. Die Übersicht im Beitrag Warum Google deine Website nicht findet ordnet diesen Fall ein.
- «Konnte nicht abgerufen werden» im Sitemaps-Bericht: Diese Meldung betrifft die Sitemap-Datei, nicht eine einzelne Seite. Leitet die Adresse deiner Sitemap weiter, prüfst du das Ziel, wie es der Beitrag zur Sitemap-Meldung «Konnte nicht abgerufen werden» beschreibt.
«Fehler: Umleitungsfehler» im Firefox
Diese Meldung stammt nicht aus der Search Console, sondern vom Browser. Firefox schreibt darunter: «Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann. Dieses Problem kann manchmal auftreten, wenn Cookies deaktiviert oder abgelehnt werden.» Chrome und Edge melden denselben Zustand mit dem Code ERR_TOO_MANY_REDIRECTS. Ob der Fehler an der Website oder an deinem Browser liegt, klärst du so:
- Cookies dieser Website löschen. Klicke links neben der Adresse auf das Schloss-Symbol und lösche die Cookies und Website-Daten dieser Website, wie es die Firefox-Hilfe beschreibt. Hast du Cookies für diese Website blockiert, erlaube sie probeweise. Lädt die Seite danach, lag es an den gespeicherten Daten oder Einstellungen deines Browsers.
- Die Adresse in einem privaten Fenster oder einem anderen Browser öffnen. Dort fehlen die Cookies und gespeicherten Weiterleitungen deines gewohnten Fensters. Lädt die Seite dort, liegt es an diesen gespeicherten Daten. Das kommt auch nach einer Korrektur auf deiner eigenen Website vor: Browser speichern dauerhafte Weiterleitungen und können dir im gewohnten Fenster noch die alte Schleife zeigen, obwohl die Website sie nicht mehr liefert.
- Scheitert der Aufruf überall, liegt der Fehler an der Website. Ist es deine eigene, erreichen auch deine Besucher die Seite nicht. Dann prüfst du sofort, wie bei Ursache 2 beschrieben. Bei einer fremden Website kann nur deren Betreiber den Fehler beheben.
Die Weiterleitungskette sichtbar machen
Im Browser siehst du nur die Adresse, bei der du am Ende landest. Die Stationen dazwischen zeigen dir zwei Werkzeuge. Google selbst verweist in der Hilfe allgemein auf ein Web-Debugging-Tool wie Lighthouse; für die Kette genügen curl und die Entwicklertools des Browsers.
Mit curl: Das Programm ist auf aktuellen Windows-Versionen und auf dem Mac bereits installiert. Öffne unter Windows die PowerShell, auf dem Mac das Terminal, und gib die Adresse aus dem Bericht genau so ein, wie sie dort steht, zum Beispiel curl.exe -sIL https://www.beispiel.ch/alte-seite/. Auf dem Mac schreibst du curl statt curl.exe; unter Windows ist die Endung nötig, weil curl in der vorinstallierten PowerShell einen anderen Befehl aufruft. -I holt nur die Kopfzeilen der Antworten, -L folgt den Weiterleitungen, -s blendet die Fortschrittsanzeige aus.
Für jede Station erscheint ein Block mit einer Statuszeile, bei Weiterleitungen zusätzlich eine Zeile location mit dem nächsten Ziel. So liest du das Ergebnis:
- Die letzte Statuszeile zeigt 200: Die Kette endet bei einer Seite. Die Statuszeilen mit 301, 302, 307 oder 308 davor sind die Weiterleitungen; ihre Zahl ist die Länge der Kette. Sind es mehr als zehn, liegt Ursache 1 vor.
- Dieselben Adressen wiederholen sich: Die Kette führt im Kreis, siehe Ursache 2.
- Die Adresse wird von Station zu Station länger: siehe Ursache 3.
- Die
location-Zeile fehlt, ist leer oder ergibt ein ungültiges Ziel: siehe Ursache 4. Ein relativer Pfad wie/neue-seiteist dagegen zulässig. - Am Ende steht 404 oder ein Status ab 500: Die Weiterleitung führt zu einer Seite, die nicht existiert oder einen Serverfehler liefert. Auch dann korrigierst du das Ziel der Regel.
Antwortet der Server auf diese Kurzabfrage mit einem Fehler wie 405, obwohl die Seite im Browser funktioniert, verwendest du stattdessen die Entwicklertools.
Mit den Entwicklertools des Browsers: In Chrome oder Edge öffnest du mit F12 die Entwicklertools und wechselst zum Tab «Netzwerk». Setze die Häkchen bei «Protokoll beibehalten», damit die Liste bei einer Weiterleitung nicht geleert wird, und bei «Cache deaktivieren», denn Browser speichern dauerhafte Weiterleitungen und zeigen dir sonst nach einer Korrektur noch den alten Weg. Rufe dann die Adresse aus dem Bericht auf. Jede Station steht als eigene Zeile mit ihrem Status; das Ziel liest du nach einem Klick auf die Zeile unter «Header» bei location ab.
Prüfe zuerst genau die Schreibweise aus dem Bericht, danach die Varianten mit http://, ohne www und mit oder ohne Schrägstrich am Ende. Für Google sind /seite und /seite/ zwei Adressen, und eine davon kann über einen Umweg führen, während die andere direkt ankommt. In meinem Fall stand nur die Schreibweise mit Schrägstrich im Bericht.
Viele Adressen auf einmal prüfen
Stehen nach einem Relaunch mehrere Adressen unter der Meldung, prüfst du sie in einem Durchgang. Klicke in der Detailansicht von «Umleitungsfehler» oben rechts auf «Exportieren», kopiere die Spalte mit den Adressen in eine Textdatei, eine Adresse pro Zeile, und speichere sie als adressen.txt in deinem Benutzerordner, in dem PowerShell und Terminal starten. Füge auch die Schreibweisen mit http:// und ohne www hinzu, die du prüfen willst. Dann gibst du unter Windows in der PowerShell ein: Get-Content adressen.txt | ForEach-Object { curl.exe -s -o NUL -L --max-redirs 10 -w "%{http_code} %{num_redirects} $_ -> %{url_effective}\n" $_ }. Auf dem Mac im Terminal lautet der Befehl: while read -r u; do curl -s -o /dev/null -L --max-redirs 10 -w "%{http_code} %{num_redirects} $u -> %{url_effective}\n" "$u"; done < adressen.txt.
Befehl für Windows und Mac anzeigen
Für jede Adresse erscheint eine Zeile mit dem Status an der letzten Station, der Zahl der Weiterleitungen, der Adresse aus deiner Liste und der Adresse, bei der curl aufgehört hat. --max-redirs 10 begrenzt diesen Test auf zehn Weiterleitungen. Das orientiert sich an Googles dokumentiertem Regelfall, bildet aber nicht alle Bedingungen eines Googlebot-Abrufs nach. So liest du die Zeilen:
- 200 vorne: Die Kette endet bei diesem Abruf bei einer Seite. Prüfe zusätzlich, ob das Ziel den gesuchten Inhalt enthält und für Google abrufbar ist. Braucht eine alte Adresse in der Hauptschreibweise deiner Website, etwa mit
https://www., mehr als eine Weiterleitung, führt sie über einen Umweg, den du nach Ursache 1 kürzt. Für die Adresse aus meinem Beispiel lautete die Zeile am 26. September 2026200 1 https://www.simon-haenel.com/blog/5-wege-msp-qualifizierte-leads/ -> https://www.simon-haenel.com/blog/leadgenerierung-im-b2b. Dieselbe Adresse mithttp://und ohnewwwkam mit der Zahl 3 an, weil mein Hosting zuerst https undwwwdurchsetzt; das liegt deutlich unter Googles Grenze. - Ein Code aus der 300er-Reihe und die Zahl 10: curl hat die eingestellte Grenze erreicht. Die Kette ist zu lang (Ursache 1), führt im Kreis (Ursache 2) oder verlängert die Adresse bei jedem Schritt (Ursache 3); den dritten Fall erkennst du schon an der langen Adresse am Zeilenende. Welcher Fall vorliegt, zeigt der Einzelaufruf dieser Adresse mit
curl.exe -sILwie oben. - Ein Code aus der 300er-Reihe und eine Zahl unter 10: curl kam an einer Station nicht weiter, weil die nächste Adresse fehlt, ungültig ist oder nicht erreichbar ist. Das entspricht Ursache 4.
- 404 oder ein Status ab 500 vorne: Die Kette endet bei einer Seite, die nicht existiert oder einen Fehler liefert. Du korrigierst das Ziel der Regel.
Zeigen viele Zeilen dasselbe Muster, etwa denselben Zwischenschritt oder denselben Abbruch, kann eine einzige allgemeine Regel dahinterstehen. Dann korrigierst du zuerst diese Regel und lässt den Befehl erneut laufen.
Die vier Ursachen prüfen und beheben
Jede der vier Ursachen aus Googles Liste zeigt sich in der Ausgabe von curl oder in den Entwicklertools auf eigene Weise. Zu jeder steht hier, woran du sie erkennst, wie sie entsteht und was du änderst.
Ursache 1: Die Weiterleitungskette ist zu lang
Eine lange Kette entsteht, wenn Regeln aus verschiedenen Jahren zusammenkommen: Die Website wurde auf https umgestellt, später auf die Schreibweise mit www, eine Seite ist bei einem Relaunch umgezogen und beim nächsten noch einmal. Jede Regel ist für sich richtig, aber eine alte Adresse durchläuft sie nacheinander. So sieht das Muster aus; Domain und Seiten sind ein Beispiel:
Tabelle seitlich verschieben
| Station | Adresse | Grund der Weiterleitung |
|---|---|---|
| Aufruf | http://beispiel.ch/umbau/ | alter Link auf einer anderen Website |
| 1 | https://beispiel.ch/umbau/ | Umstellung auf https |
| 2 | https://www.beispiel.ch/umbau/ | Schreibweise mit www |
| 3 | https://www.beispiel.ch/umbau | Schrägstrich am Ende entfernt |
| 4 | https://www.beispiel.ch/leistungen/umbau | erster Relaunch |
| 5 | https://www.beispiel.ch/renovation | zweiter Relaunch, Status 200 |
Fünf Weiterleitungen liegen noch unter Googles Grenze von zehn. Mit jeder weiteren Umstellung rückt die Grenze näher, und jede Station ist eine Regel, die bei der nächsten Änderung brechen kann.
Prüfen: Zähle in curl die Weiterleitungen bis zum Status 200. Prüfe die Adresse auch mit http:// und ohne www, denn Links von anderen Websites und alte Lesezeichen können diese Schreibweisen enthalten.
Beheben: Richte für jede alte Adresse eine Regel ein, die direkt auf die endgültige Seite zeigt. Zieht eine Seite erneut um, änderst du auch die Ziele der älteren Regeln, statt eine neue Regel anzuhängen. Achte auf die Reihenfolge: Eine allgemeine Regel, die den Schrägstrich am Ende entfernt oder ergänzt, darf nicht vor den Regeln für einzelne alte Adressen greifen, sonst läuft jede alte Adresse mit Schrägstrich über einen zusätzlichen Schritt. Genau das war auf meiner Website bis zum 7. September 2026 der Fall, wie das Beispiel unten zeigt.
Ursache 2: Die Weiterleitungen führen im Kreis
Eine Schleife entsteht, wenn Regeln einander widersprechen, zum Beispiel so:
- Das Hosting leitet auf die Adresse mit
wwwweiter, das CMS auf die Adresse ohnewww. In WordPress stehen die massgeblichen Adressen unter «Einstellungen → Allgemein» bei «WordPress-Adresse (URL)» und «Website-Adresse (URL)». Kommst du wegen der Schleife nicht mehr in die WordPress-Verwaltung, öffnest du über den Dateimanager deines Hostings oder per FTP die Dateiwp-config.phpim Hauptverzeichnis der Installation und legst dort vor der Kommentarzeile mit «stop editing» beide Adressen fest, bei einer üblichen Installation mit derselben Adresse:define( 'WP_HOME', 'https://www.beispiel.ch' );unddefine( 'WP_SITEURL', 'https://www.beispiel.ch' );. Laut WordPress-Handbuch überschreiben diese Einträge die gespeicherten Werte; die Adresse beginnt mithttps://und endet ohne Schrägstrich. - Der Server ergänzt den Schrägstrich am Ende, eine Regel im CMS oder in einem Plugin entfernt ihn wieder.
- Ein vorgeschalteter Dienst ruft deinen Server per http ab, während dein Server jede http-Anfrage auf https umleitet. Cloudflare beschreibt diese Schleife für den Verschlüsselungsmodus «Flexible» in seiner Anleitung zu ERR_TOO_MANY_REDIRECTS.
- Zwei Einträge in einer Weiterleitungsliste zeigen aufeinander, etwa wenn eine Seite an ihre alte Adresse zurückkehrt, eine neue Regel dorthin zurückführt und die alte Regel in die Gegenrichtung stehen bleibt.
Prüfen: In der Ausgabe von curl wiederholen sich dieselben Adressen immer wieder. Im Browser erscheint die Fehlermeldung aus dem Abschnitt oben. Eine Schleife betrifft deshalb nicht nur Google, sondern auch deine Besucher.
Beheben: Lege eine einzige Schreibweise fest: https, mit oder ohne www, mit oder ohne Schrägstrich am Ende. Jede dieser Entscheidungen setzt genau eine Stelle durch. An allen anderen Stellen entfernst du die entsprechende Regel oder stellst sie auf dieselbe Schreibweise ein. Für den Fall mit Cloudflare nennt die Anleitung zwei Wege: die https-Weiterleitung auf deinem Server entfernen oder den Verschlüsselungsmodus «Full» oder höher wählen, wofür dein Server ein eigenes SSL-Zertifikat braucht.
Ursache 3: Die Weiterleitungs-URL wird zu lang
Dieser Fall entsteht, wenn das Ziel einer Regel wieder auf dieselbe Regel passt und bei jedem Durchgang etwas an die Adresse angehängt wird. Zwei Muster als Beispiel: Eine Regel soll alle Seiten unter /de/ einordnen und leitet /seite auf /de/seite weiter. Erfasst sie auch Adressen, die schon mit /de/ beginnen, entstehen /de/de/seite, dann /de/de/de/seite und so weiter. Oder eine Anmeldeseite hängt die aufgerufene Adresse als Parameter an, etwa ?ziel=, und leitet dabei auf sich selbst weiter; mit jedem Durchgang steckt die ganze bisherige Adresse im Parameter.
Prüfen: In curl wächst die Adresse in der location-Zeile von Station zu Station.
Beheben: Grenze die Regel so ein, dass sie nicht auf ihr eigenes Ziel passt, etwa indem sie nur Adressen ohne /de/ erfasst oder nur genau die eine alte Adresse umleitet. Leitet eine Anmeldeseite im Kreis, prüfst du zusätzlich, ob die aufgerufene Seite überhaupt eine Anmeldung verlangen soll: Seiten, die in der Suche erscheinen sollen, müssen ohne Anmeldung erreichbar sein.
Ursache 4: Eine Weiterleitung zeigt ins Leere
Google nennt als vierte Möglichkeit «eine ungültige oder leere URL in der Weiterleitungskette». Das kann ein Eintrag in einem Weiterleitungs-Plugin sein, bei dem das Zielfeld leer geblieben ist, oder ein Ziel, das nur aus https:// ohne Domain besteht.
Prüfen: In curl fehlt nach einer Weiterleitung die location-Zeile, sie ist leer, oder ihr Wert lässt sich nicht zu einer gültigen Zieladresse auflösen. Ein Pfad wie /neue-seite ist kein Fehler: Der Browser ergänzt die Domain der aufgerufenen Adresse. Solche relativen Ziele sind im HTTP-Standard ausdrücklich vorgesehen. Prüfe, bei welcher vollständigen Adresse curl tatsächlich ankommt.
Beheben: Trage in der Weiterleitungsregel die vollständige Zieladresse ein. Gibt es für die alte Adresse keine passende neue Seite, löschst du die Regel. Die Adresse liefert dann üblicherweise den Status 404, und Google führt sie nach dem nächsten Abruf unter «Nicht gefunden (404)». Für eine bewusst entfernte Seite ohne Nachfolger ist das richtig.
Wo die verantwortliche Regel steckt
Weiterleitungen können an mehreren Stellen eingerichtet sein. Prüfe diese Stellen der Reihe nach:
- Domain und Hosting: Die Umstellung auf https und die Schreibweise mit oder ohne
wwwstellst du in der Verwaltung deines Hostings oder deiner Domain ein, sofern dein CMS das nicht selbst übernimmt. - Serverkonfiguration: Bei Hostings mit Apache-Server können Weiterleitungen in der Datei
.htaccessim Hauptverzeichnis der Website stehen. - CMS-Einstellungen: Die Adresse der Website und die Form der Seitenadressen, bei WordPress unter «Einstellungen → Allgemein» und «Einstellungen → Permalinks».
- Plugins und Baukasten: SEO- und Weiterleitungs-Plugins sowie der Umleitungsmanager eines Website-Baukastens führen eigene Listen.
- Vorgeschaltete Dienste: Ein CDN oder Proxy wie Cloudflare kann eigene Weiterleitungsregeln und SSL-Einstellungen haben.
Die curl-Ausgabe hilft bei der Zuordnung. Eine Station, die für alle Adressen https, www oder den Schrägstrich ändert, deutet auf Hosting, Server oder CDN. Eine Weiterleitung für einen einzelnen Pfad steht eher in einer Weiterleitungsliste von CMS oder Plugin. WordPress schreibt bei seinen Weiterleitungen die Zeile x-redirect-by in die Antwort, mit dem Wert WordPress oder, je nach Plugin, mit dessen Namen. Die Zeile server kann verraten, welcher Dienst geantwortet hat, etwa cloudflare.
Die Meldung Schritt für Schritt prüfen
- Bericht öffnen. In der Search Console klickst du unter «Indexierung → Seiten» in der Tabelle «Warum Seiten nicht indexiert werden» auf «Umleitungsfehler». Lies die Beispieladressen und das Datum bei «Zuletzt gecrawlt». Liegt es vor einer Umstellung deiner Website, weisst du, dass der Eintrag einen früheren Zustand beschreibt.
- Adresse einordnen. Ist es eine alte Adresse, die auf eine neue Seite führen soll, oder eine aktuelle Seite, die gar nicht weiterleiten soll? Im zweiten Fall ist die Weiterleitung selbst der Fehler: Dann entfernst du die Regel, statt die Kette zu kürzen.
- Kette verfolgen. Rufe die Adresse mit curl oder den Entwicklertools auf, wie oben beschrieben, zuerst in der Schreibweise aus dem Bericht, dann in den Varianten. Bei mehreren Adressen nimmst du den Befehl für die ganze Liste.
- URL-Prüfung ausführen. Gib die Beispieladresse oben in der Search Console in die URL-Prüfung ein und klappe «Seitenindexierung» auf. Dort liest du ab, welchen Stand Google gespeichert hat und wann die Adresse zuletzt gecrawlt wurde. Den Weg bis zum Ziel zeigt dir die URL-Prüfung nicht. Ob ihr Live-Test einer Weiterleitung folgt, beschreibt Google zudem widersprüchlich: Laut der Hilfe zum Seitenindexierungsbericht folgt er ihr und testet die finale Adresse, laut der Übersicht zu HTTP-Statuscodes folgen die Prüftools keinen Weiterleitungen.
- Live-Test mit der Endadresse. Gib deshalb die Adresse selbst ein, bei der die Kette endet, und klicke auf «Live-URL testen»; dann weisst du, welche Seite du testest. Stehen bei «Seitenabruf» «Erfolgreich» und bei «Indexierung zulässig?» «Ja», kann Google das Ziel abrufen. Scheitert der Test, besteht an der Zielseite ein weiteres Problem, das du zuerst behebst.
- Sitemap und interne Links durchsuchen. Suche die alte Adresse in deiner Sitemap und in den Links deiner Seiten. Jeder Treffer schickt Google und Besucher unnötig über die Weiterleitung.
Was du jetzt änderst
- Eine alte Adresse, ein Schritt. Jede alte Adresse leitet direkt auf die endgültige Seite, in beiden Schreibweisen mit und ohne Schrägstrich am Ende.
- Eine Stelle pro Regel. https,
wwwund der Schrägstrich werden jeweils an genau einer Stelle durchgesetzt. Widersprechende Regeln an anderen Stellen entfernst du. - Allgemeine Regeln zuletzt. Eine allgemeine Regel für den Schrägstrich greift erst nach den Regeln für einzelne alte Adressen, oder diese Regeln akzeptieren beide Schreibweisen.
- Dauerhafte Weiterleitung auf dem Server. Für umgezogene Seiten verwendest du 301 oder 308. Google schreibt in der Anleitung zu Weiterleitungen: «Verwende JavaScript-Weiterleitungen nur, wenn keine serverseitigen oder meta refresh-Weiterleitungen möglich sind.»
- Sitemap und interne Links auf Endadressen. Ersetze jeden Treffer aus Schritt 6 durch die Endadresse. Google empfiehlt in der Hilfe zum Sitemaps-Bericht, weiterleitende Adressen in der Sitemap durch die Adressen zu ersetzen, die gecrawlt werden sollen.
- Mit curl nachprüfen. Nach jeder Korrektur rufst du die Beispieladresse und ihre Varianten erneut auf. curl speichert keine Weiterleitungen, der Browser schon.
- Die Überprüfung starten. Öffne im Bericht den Grund «Umleitungsfehler» und klicke auf «Fehlerbehebung überprüfen». Prüfe vorher alle Beispieladressen, denn laut Google-Hilfe gilt: «Falls Sie eine Instanz übersehen haben und Google sie findet, wird die Überprüfung beendet.» Laut derselben Hilfe dauert die Überprüfung «in der Regel etwa zwei Wochen, manchmal aber auch um einiges länger».
Ein aktuelles Beispiel aus meiner Search Console
Am 25. September 2026 stand in meinem Bericht zur Seitenindexierung genau eine Adresse unter «Umleitungsfehler». Diese Werte habe ich an diesem Tag in der Search Console abgelesen und mit curl nachgeprüft:
Tabelle seitlich verschieben
| Prüfung | Befund |
|---|---|
| Grund «Umleitungsfehler» | 1 Adresse: /blog/5-wege-msp-qualifizierte-leads/ mit Schrägstrich am Ende, zuletzt gecrawlt am 10.05.2026. Validierung: «Nicht gestartet». |
| Stand der Website am 10.05.2026 | Damals lief meine frühere Website. Die heutige ist seit Juli 2026 online. |
Weiterleitung heute mit https://www. | Ein Schritt: Status 308 auf /blog/leadgenerierung-im-b2b, dort Status 200. |
Dieselbe Adresse mit http:// und ohne www | Drei Schritte: auf https, auf die Schreibweise mit www, auf die Zielseite. Ende mit Status 200. |
| Grund «Seite mit Weiterleitung» | 8 Adressen, darunter alte Blogadressen wie /blog/it-leads-kaufen-vs-organisch (zuletzt gecrawlt am 29.07.2026) und die Preisseite aus dem Abschnitt Nicht verwechseln. |
| Sitemap und interne Links | Alle 44 Adressen der Sitemap und alle 47 internen Linkziele auf diesen Seiten antworten direkt mit Status 200, ohne Weiterleitung. |
Was ich daraus ablese: Der Eintrag beschreibt einen Abruf auf meiner früheren Website. Was Google am 10. Mai beim Abruf dieser Adresse erhalten hat, kann ich heute nicht mehr nachstellen, weil diese Website nicht mehr online ist. Nachprüfen lässt sich der heutige Zustand: Die Adresse kommt in einem Schritt bei einer Seite an. Mein heutiger Abruf zeigt keine fehlerhafte Kette; der nächste Schritt ist «Fehlerbehebung überprüfen». Findet Google beim erneuten Abruf die funktionierende Weiterleitung, gilt das Problem für diese Adresse als behoben. Ich erwarte, dass sie danach wie meine anderen alten Blogadressen unter «Seite mit Weiterleitung» steht.
Dass die Adresse heute in einem Schritt ankommt, war auf der neuen Website nicht von Anfang an so. Bis zum 7. September 2026 lief jede alte Adresse mit Schrägstrich am Ende über mindestens zwei Schritte: Zuerst entfernte eine allgemeine Einstellung meines Hostings den Schrägstrich, danach leitete die Regel für die alte Adresse auf die neue Seite. Die allgemeine Einstellung griff vor den einzelnen Regeln. Seit dem 7. September akzeptiert jede Regel für eine alte Adresse beide Schreibweisen, und die allgemeine Regel für den Schrägstrich steht als letzte. Einen Umleitungsfehler verursachte der zusätzliche Schritt nicht, denn Google folgt bis zu zehn Weiterleitungen. Mit http:// und ohne www wären es für dieselbe Adresse aber vier Schritte gewesen, und jede weitere Umstellung hätte die Kette verlängern können.
Wenn du die Weiterleitungen nicht selbst entwirren möchtest
Mit curl und dem Bericht stellst du fest, welchen Weg eine Adresse bei deinem heutigen Abruf nimmt. Bei einer einzelnen falschen Regel in einem Plugin ist die Korrektur überschaubar, sobald das richtige Ziel feststeht. Aufwendiger wird es, wenn Hosting, CMS, Plugin und ein vorgeschalteter Dienst je eigene Regeln führen oder wenn nach einem Relaunch Dutzende alte Adressen auf neue Seiten zeigen sollen. Dann musst du herausfinden, welche Stelle welchen Schritt erzeugt, und jede Änderung so vornehmen, dass keine andere Adresse neu ins Leere läuft.
Für deine Anfragen zählen dabei vor allem die alten Adressen deiner Leistungsseiten. Auf sie können noch Links von anderen Websites, Einträge in Branchenverzeichnissen oder Lesezeichen früherer Kunden zeigen. Führt eine solche Adresse im Kreis oder ins Leere, sieht ein Interessent, der etwa über ein Verzeichnis kommt, statt deiner Leistung eine Fehlermeldung des Browsers, und Google gelangt über diese Adresse nicht zur heutigen Seite.
Die Bereinigung dieser Weiterleitungen übernehme ich als Einzelauftrag; den Festpreis vereinbaren wir vorab in einer Offerte. Ich verfolge die Adressen aus deinem Bericht und ihre Schreibweisen mit http:// und ohne www, ordne jeden Schritt der Stelle zu, die ihn erzeugt, und richte für jede alte Adresse eine Regel ein, die direkt auf die passende heutige Seite führt. Widersprechende Regeln entferne ich, allgemeine Regeln setze ich ans Ende. Zum Schluss prüfe ich jede Adresse erneut mit curl und starte im Bericht «Fehlerbehebung überprüfen», wenn du mir Zugriff auf die Search Console gibst. So führt jede alte Adresse, für die es einen Nachfolger gibt, in einem Schritt auf die Seite, die heute dieselbe Leistung erklärt. Von dir brauche ich die Zugänge zu Hosting und CMS und deine Bestätigung, welche alte Adresse zu welcher heutigen Seite führen soll.
Beim Zuordnen kann sich eine zweite Lücke zeigen: Für eine alte Leistungsseite gibt es keine heutige Seite mehr, die dieselbe Leistung erklärt, etwa weil der Relaunch mehrere Leistungen auf einer Übersicht zusammengefasst hat. Die Weiterleitung auf diese Übersicht kann Google als Soft 404 werten. Soll die Leistung weiterhin Anfragen bringen, braucht sie wieder eine eigene Seite. Dafür gibt es SEO-Start: Für bis zu drei Leistungen recherchiere ich, wonach Interessenten suchen, lege die Seiten in deinem bestehenden Layout neu an oder überarbeite sie und setze Seitentitel, Beschreibung und interne Links. Du erklärst mir die Leistungen und prüfst die fachlichen Angaben. Der Festpreis beträgt CHF 1’900. Brauchst du beides, stehen die Bereinigung und SEO-Start in derselben Offerte.
Wann Google die alten Adressen erneut abruft und ob es die Seiten aufnimmt oder weiter vorne zeigt, kann ich nicht zusagen; zugesagt sind die vereinbarten Änderungen an deiner Website. Schick mir für das kostenlose Erstgespräch die Adressen aus dem Bericht, die Ausgabe deiner curl-Prüfung und, falls deine Website umgebaut wurde, ungefähr wann.