Weiterleitungskette (Redirect Chain): Was ist das und wie beheben Sie sie?

Was ist eine Weiterleitungskette (Redirect Chain)?

Eine Weiterleitungskette ist eine Folge von Weiterleitungen, bei der eine URL über eine oder mehrere Zwischenadressen läuft, bevor sie ihr endgültiges Ziel erreicht. Leitet Seite A zum Beispiel auf B und B auf C weiter, entsteht eine Kette mit zwei Sprüngen. Jeder zusätzliche Sprung bremst Besucher und kostet Crawler Anfragen.

Seit 2012 führe ich technische SEO Audits durch, und die Weiterleitungskette gehört zu den leisen Problemen, die ich auf fast jeder älteren Website finde. Die Seite funktioniert, alles lädt, niemand sieht einen Fehler. Im Hintergrund läuft allerdings jeder Klick durch zwei, drei oder sogar fünf Serverantworten. In diesem Beitrag zeige ich, wie Ketten entstehen, worin sie sich von Schleifen unterscheiden, welches Limit Google offiziell nennt, wie sie Ladezeit und Crawling beeinflussen und wie Sie sie Schritt für Schritt beheben.

Möchten Sie Ihre eigene Adresse sofort prüfen, geben Sie sie in unseren Redirect Checker ein. Das Tool zeigt jeden Sprung der Reihe nach, zusammen mit dem Statuscode.

Wie entsteht eine Weiterleitungskette?

Eine Weiterleitungskette entsteht selten durch eine einzige falsche Entscheidung. Stattdessen wächst sie aus kleinen Änderungen, die sich über Jahre ansammeln. Jede Änderung ist für sich logisch; das Problem beginnt, wenn alte und neue Regeln aufeinandertreffen. Deshalb baut niemand eine Weiterleitungskette mit Absicht, sie sammelt sich einfach an.

Zudem wechseln Teams, und der Grund für alte Regeln gerät in Vergessenheit. Ein neuer Entwickler traut sich nicht, eine alte Regel zu löschen, und setzt eine neue darüber. So kommt jedes Jahr ein weiteres Glied hinzu.

Diese Szenarien sehe ich in Audits am häufigsten:

• Protokoll und Host: Die Adresse mit http springt zuerst auf https und danach auf die Version ohne www. Eine einzige Regel könnte beides erledigen.
• Abschließender Schrägstrich: Der Server hängt einen Schrägstrich an, danach wandelt eine weitere Regel den Pfad in Kleinbuchstaben um.
• Mehrere Relaunches: Eine Migration 2019 hat die alte URL auf B gelenkt, eine Migration 2023 dann B auf C. Die Regel für A hat niemand angepasst.
• Plugin gegen Server: Ein Plugin im CMS setzt eine Regel um, die Serverkonfiguration eine andere.
• Kurzlinks aus Kampagnen: Ein Linkkürzer zeigt auf eine alte Kampagnenseite, und diese zeigt auf die neue Seite.

Kurz gesagt: Jede Schicht fügt einen Sprung hinzu. Daher müssen Sie wissen, welche Schicht welche Regel geschrieben hat, bevor Sie die Kette auflösen.

Was unterscheidet eine Weiterleitungskette von einer Weiterleitungsschleife?

Eine Weiterleitungskette erreicht am Ende ein Ziel; der Weg ist nur länger als nötig. Eine Schleife kommt dagegen nirgends an. Seite A schickt die Anfrage zu B, B schickt sie zurück zu A, und das Spiel beginnt von vorn. Irgendwann bricht der Browser ab und zeigt eine Fehlermeldung.

Chrome meldet in diesem Fall "ERR_TOO_MANY_REDIRECTS". Das heißt, bei einer Schleife sieht der Besucher die Seite nie, während eine Kette sie immerhin verspätet ausliefert. Deshalb verlangt eine Schleife sofortiges Handeln, eine Kette dagegen eine geplante Bereinigung.

Andererseits können beide Probleme dieselbe Wurzel haben. Widersprüchliche Regeln erzeugen bei manchen URLs eine Kette und bei anderen eine Schleife. Suchen Sie also nach dem einen, prüfen Sie immer auch das andere.

In der Praxis bemerke ich Schleifen meist direkt nach dem Livegang einer neuen Regel. Testen Sie daher nach jeder Regeländerung die Startseite, eine Kategorie und eine Produktseite.

Wie vielen Weiterleitungen folgt der Googlebot?

Google nennt hier eine klare Zahl. Laut Googles Dokumentation zu HTTP Statuscodes folgen die Crawler von Google standardmäßig bis zu 10 Weiterleitungssprüngen. Die Seite ergänzt, dass Crawler bestimmter Produkte andere Grenzen haben können.

Außerdem betont die Dokumentation ein Detail: Google ignoriert jeden Inhalt der weiterleitenden URL und verarbeitet nur das endgültige Ziel. Was auf den Zwischenadressen steht, spielt also keine Rolle; für Google zählt allein die letzte Station.

Sind 10 Sprünge also ein großzügiger Spielraum? Auf dem Papier ja, in der Praxis nein. Googles Leitfaden zum Umzug einer Website sagt: Auch wenn der Googlebot bis zu 10 Sprüngen folgen kann, sollten Sie direkt auf das endgültige Ziel weiterleiten. Geht das nicht, halten Sie die Kette kurz, idealerweise bei höchstens 3 und weniger als 5 Sprüngen.

Der Leitfaden nennt auch den Grund: Verkettete Weiterleitungen erhöhen die Latenz für Nutzer, und nicht alle Browser und Clients unterstützen lange Ketten. Folglich lautet Ihr Ziel nicht "unter 10", sondern null Zwischenschritte.

Ein Punkt ist mir dabei wichtig. Das Limit von 10 Sprüngen beschreibt eine technische Obergrenze, keine Komfortzone. Eine Website in der Nähe dieser Grenze zahlt längst einen Preis bei Ladezeit und Crawling.

Warum sind Weiterleitungen bei der robots.txt besonders heikel?

Für die robots.txt gelten bei Ketten eigene Regeln. Laut Googles Dokumentation zur robots.txt folgt Google bei dieser Datei mindestens fünf Weiterleitungssprüngen, stoppt dann und behandelt sie wie einen Fehler 404. Gilt die Datei als 404, geht Google davon aus, dass es keine Crawling Beschränkungen gibt.

Das bedeutet: Steht Ihre robots.txt am Ende einer langen Weiterleitungskette, greift womöglich keine Ihrer Sperrregeln. Zudem folgt Google laut derselben Dokumentation bei der robots.txt keinen logischen Weiterleitungen wie Frames, JavaScript oder Meta Refresh.

Diese Falle sehe ich am häufigsten nach einem Domainwechsel. Die robots.txt der alten Domain zeigt auf die neue Domain, und dort kommt noch ein Sprung von http auf https hinzu. Damit landet die Datei am Ende einer Kette.

Prüfen Sie deshalb die Adresse der robots.txt für jede Hauptversion: http, https, mit www und ohne www. Im Idealfall liefert die Datei auf der kanonischen Version direkt den Status 200. Wenn Sie die Datei neu aufsetzen, hilft Ihnen mein Beitrag über häufige Fehler in der robots.txt.

Wie beeinflusst eine Weiterleitungskette die Ladezeit?

Jede Weiterleitung zwingt den Browser, eine neue Anfrage zu senden und auf eine neue Antwort zu warten. Führt der Sprung auf eine andere Domain, kommen noch eine DNS Abfrage und ein neuer verschlüsselter Verbindungsaufbau hinzu. Das erste Byte der Seite kann erst kommen, wenn das letzte Glied der Kette abgeschlossen ist.

Diese Verzögerung wirkt direkt auf die Time to First Byte. Kommt das erste Byte spät, rutschen auch Kennzahlen wie der Largest Contentful Paint (LCP) nach hinten. Vor allem in Mobilfunknetzen spüren Nutzer jeden zusätzlichen Umlauf.

Ein konkretes Beispiel: Alte URLs in Anzeigen und E-Mail Kampagnen tragen oft die längsten Ketten. Der Nutzer klickt auf die Anzeige und erreicht die Seite erst nach zwei oder drei Sprüngen, und manche springen unterwegs ab. Verliert die Weiterleitung außerdem die UTM Parameter, stimmt auch Ihre Kampagnenmessung nicht mehr.

Öffnen Sie für einen eigenen Test die Entwicklertools des Browsers und schauen Sie im Tab Netzwerk auf die ersten Anfragen. Jede Zeile mit einem Statuscode 3xx zeigt Zeit, die vergeht, bevor die Seite überhaupt lädt. So sehen Sie die Kosten der Kette in Millisekunden.

Wie verschwenden Weiterleitungsketten Crawl Budget?

Der Googlebot behandelt jeden Sprung einer Weiterleitungskette als eigene Anfrage. Eine Kette mit drei Sprüngen bedeutet also vier Anfragen für eine einzige Seite. Auf einer kleinen Website wirkt der Unterschied gering. In einem Onlineshop mit zehntausenden URLs sieht das allerdings anders aus.

Geraten zum Beispiel Filter URLs, alte Kategoriepfade und Produktvarianten in Ketten, fließt ein großer Teil der Crawling Kapazität in Zwischenschritte. Folglich entdeckt Google neue Produkte und aktualisierte Seiten langsamer. Antwortet Ihr Server ohnehin träge, drosselt Google das Crawling bereits; Ketten verstärken diesen Druck.

Zudem zählt jede Zwischenadresse für Google als eigene URL. Google behält diese Adressen in seiner Warteschlange und ruft sie in Abständen erneut ab. Daher taucht jede alte Regel, die Sie stehen lassen, noch lange in Ihren Crawling Daten auf.

Wenn Sie einen Rückgang der Crawling Rate genauer untersuchen möchten, lesen Sie meinen Beitrag darüber, warum der Googlebot weniger crawlt. Dort zeige ich Schritt für Schritt, wie Sie den Bericht zu den Crawling Statistiken lesen.

Kurz gesagt: Auf kleinen Websites ist eine Kette vor allem ein Thema der Ladezeit. Auf großen Websites betrifft sie zusätzlich die Auffindbarkeit, also richten Sie Ihre Prioritäten nach der Größe der Website aus.

Wie verändern die Codes 301, 302, 307 und 308 eine Kette?

Der Statuscode jedes Glieds beeinflusst, welche URL Google als kanonisch auswählt. Laut Googles Dokumentation zu Weiterleitungen gelten dauerhafte Weiterleitungen als Signal, dass das Ziel kanonisch sein sollte. Bei temporären Weiterleitungen folgt der Googlebot zwar dem Ziel, die Indexierung nutzt die Weiterleitung aber nicht als kanonisches Signal.

Gemischte Weiterleitungsketten sorgen für die meiste Verwirrung. Ein Pfad aus 301, dann 302 und dann wieder 301 sendet Google zum Beispiel widersprüchliche Signale. Prüfen Sie daher beim Kürzen einer Kette auch den Code: Ist der Inhalt dauerhaft umgezogen, genügt eine einzige Weiterleitung mit 301 oder 308.

Noch ein Hinweis: Google behandelt 303 und 307 wie 302 und 308 wie 301. Dennoch betont die Dokumentation, dass diese Codes eine unterschiedliche Bedeutung haben, und empfiehlt den passenden Code für andere Clients. Gleiche Behandlung durch Google heißt also nicht, dass Sie beliebig wählen können.

Warum sind Meta Refresh und JavaScript Weiterleitungen riskant?

Das Problem wächst, wenn ein Glied der Kette nicht auf dem Server, sondern in der Seite selbst läuft. Googles Reihenfolge ist klar: zuerst serverseitige Weiterleitungen, dann Meta Refresh und JavaScript nur als letzte Möglichkeit. Laut Dokumentation sollten Sie JavaScript nur nutzen, wenn beides andere nicht möglich ist.

Der Grund ist einfach. Um eine Weiterleitung per JavaScript zu sehen, muss Google die Seite rendern, und scheitert das Rendern, bleibt die Weiterleitung womöglich unbemerkt. Einen verzögerten Meta Refresh liest Google zudem als temporäre Weiterleitung, einen sofortigen Meta Refresh eher als dauerhafte.

Die gemischte Kette, die mir in Audits am häufigsten begegnet, sieht so aus: Der Server leitet per 301 auf die neue URL, dann schickt ein altes Theme dort per JavaScript auf eine weitere Seite. Im Browser wirkt alles in Ordnung. Für den Crawler bleibt das letzte Glied jedoch unsicher.

Verlagern Sie also jedes Glied der Kette auf den Server und reduzieren Sie es nach Möglichkeit auf einen einzigen Sprung. Weiterleitungen in der Seite sind nur eine Notlösung, falls Sie keinen Zugriff auf den Server haben.

Gehostete Plattformen schränken den Serverzugriff oft ein. Nutzen Sie dann die Weiterleitungsverwaltung der Plattform und entfernen Sie alte Skripte zur Weiterleitung aus dem Theme.

Wo zeigt die Search Console Weiterleitungsfehler an?

Die Search Console meldet Ihnen direkt, wenn eine Kette das Limit sprengt. Im Bericht zur Seitenindexierung stehen dabei die URLs mit dem Grund "Weiterleitungsfehler" ganz oben. Laut Googles Beschreibung des Berichts umfasst dieser Grund einen der folgenden Fälle:

• Eine zu lange Weiterleitungskette
• Eine Weiterleitungsschleife
• Eine Weiterleitungs URL, die schließlich die maximale URL Länge überschreitet
• Eine fehlerhafte oder leere URL in der Kette

Im selben Bericht finden Sie auch den Grund "Seite mit Weiterleitung". Das ist kein Fehler; Google sagt nur, dass die weiterleitende URL nicht kanonisch ist und daher nicht in den Index kommt. Stehen in dieser Liste allerdings URLs, auf die Ihre internen Links oder Ihre Sitemap noch zeigen, haben Sie den Anfang einer Kette gefunden.

Für eine einzelne Adresse nutzen Sie das Prüftool für URLs in der Search Console. Es zeigt die von Google gewählte kanonische URL und den aktuellen Status der Seite. Sind Sie neu im Tool, starten Sie mit meiner Anleitung zur Google Search Console.

Wie finden Sie eine Weiterleitungskette auf Ihrer Website?

Die Search Console meldet nur Fälle über dem Limit; Ketten mit zwei oder drei Sprüngen finden Sie nur mit einem eigenen Crawl. Ich gehe dabei immer in derselben Reihenfolge vor:

1. Einzelne URL prüfen: Testen Sie die verdächtige Adresse mit dem Redirect Checker. Notieren Sie Code und Ziel jedes Sprungs.
2. Hauptversionen testen: Probieren Sie alle vier Versionen Ihrer Domain aus (http, https, mit www, ohne www). Jede sollte in einem Sprung die kanonische Version erreichen.
3. Website crawlen: Folgen Sie allen internen Links mit einem Crawler und listen Sie jede URL mit einem Statuscode 3xx auf. Prüfen Sie, ob das Tool Ketten in einem eigenen Bericht zeigt.
4. Defekte Links prüfen: Manchmal endet die Kette in einem 404. Ein Broken Link Checker findet diese Fälle.
5. Externe Quellen: Nehmen Sie Zielseiten von Anzeigen, Vorlagen für Newsletter und Links aus Social Profilen in die Liste auf.

Arbeiten Sie gern auf der Kommandozeile, liefert curl ebenfalls einen schnellen Test. So sehen Sie jeden Antwortheader und seinen Location Wert der Reihe nach. Für größere Mengen ist ein Crawler allerdings deutlich praktischer.

Tragen Sie jede gefundene Weiterleitungskette in eine Tabelle ein: Start URL, Zwischenschritte, endgültiges Ziel und Code jedes Glieds. Diese Tabelle bildet dann die Grundlage für die Korrektur.

Was verraten Serverlogs über Weiterleitungsketten?

Crawling Tools laufen so durch Ihre Website, wie Sie sie sehen. Serverlogs zeigen dagegen, was der Googlebot tatsächlich anfragt. Dieser Unterschied ist wichtig, denn Google ruft alte URLs, die es vor Jahren entdeckt hat, weiterhin regelmäßig ab.

Filtern Sie die Logdatei nach Anfragen des Googlebots und übertragen Sie die Antworten mit 301, 302, 307 und 308 in eine eigene Tabelle. Sortieren Sie dann die weiterleitenden URLs nach Anzahl der Anfragen. Die Adressen ganz oben sind die Zwischenschritte, die am meisten Crawling Kapazität verbrauchen.

Sehen Sie außerdem, dass der Googlebot dieselbe Kette in kurzen Abständen immer wieder durchläuft, hat diese Regel hohe Priorität. Statt die Datei von Hand zu lesen, können Sie unsere Logfile Analyse nutzen; sie gruppiert Bot Anfragen und Statuscodes.

Schließlich sollten Sie die Loganalyse nicht nur einmal durchführen. Wiederholen Sie sie nach großen Änderungen, vor allem in den Wochen nach einer Migration oder einem Relaunch. So entdecken Sie neue Ketten früh.

Auf kleinen Websites ist der Zugriff auf Logs nicht immer einfach. Dann ist der Bericht zu den Crawling Statistiken in der Search Console eine gute Alternative, denn auch er schlüsselt Anfragen nach Antwortcode auf.

Wie beheben Sie eine Weiterleitungskette?

Das Grundprinzip bei einer Weiterleitungskette ist einfach: Jede alte URL sollte ihr endgültiges Ziel in einem einzigen Sprung erreichen. Ich gehe dabei so vor:

1. Karte erstellen: Schreiben Sie jede weiterleitende URL und ihr endgültiges Ziel in eine Tabelle.
2. Regeln abflachen: Schreiben Sie A→B→C um in A→C und B→C. Löschen Sie die Regel für B nicht, denn manche Links zeigen noch auf B.
3. Richtigen Code wählen: Nutzen Sie für dauerhafte Umzüge 301 oder 308.
4. Ziel prüfen: Stellen Sie sicher, dass die Ziel URL den Status 200 liefert, kein noindex trägt und ein Canonical auf sich selbst hat.
5. Interne Links anpassen: Richten Sie Links in Menü, Inhalt und Footer direkt auf die endgültige URL aus.
6. Erneut testen: Crawlen Sie dieselbe Liste nach der Änderung noch einmal.

Fällt es Ihnen schwer, Ziele für alte URLs zu finden, hilft unser Tool Weiterleitungen zuordnen. Es ordnet alte und neue URL Listen nach Ähnlichkeit zu. Prüfen Sie dennoch jeden Vorschlag von Hand, denn eine automatische Zuordnung schlägt manchmal eine unpassende Seite vor.

Vor allem sollten Sie alte Produkte nicht einfach auf die Startseite schicken. Google kann Weiterleitungen auf unpassende Ziele als Soft 404 einstufen. Die nächstgelegene Kategorie oder das Nachfolgeprodukt ist für Nutzer und Crawler das bessere Ziel.

Welche Fehler in Serverregeln erzeugen Ketten?

Die meisten Ketten stammen aus Serverregeln, die jemand ohne Kenntnis der anderen Regeln geschrieben hat. Unter Apache ist das die .htaccess, unter Nginx sind es die Serverblöcke, im CMS die Plugins, und alle greifen zu unterschiedlichen Zeitpunkten auf dieselbe URL zu. Achten Sie besonders auf diese Fehler:

• Reihenfolge der Regeln: Läuft die allgemeine Regel (http auf https) vor der speziellen, fügt die spezielle Regel einen zweiten Sprung hinzu.
• Relative Ziele: Ein Ziel ohne Protokoll oder Host lässt den Server zuerst über die Standardversion laufen.
• Aufgeteilte Normalisierung: Drei getrennte Regeln für https, www und den abschließenden Schrägstrich erzeugen drei getrennte Sprünge.
• Doppelte Schichten: Dieselbe Weiterleitung existiert womöglich im CDN, auf dem Server und im CMS.
• Verlorene Parameter: Eine Regel ohne Query String schickt eine URL mit Parametern womöglich auf das falsche Ziel.

Deshalb empfehle ich, Regeln zur Normalisierung an einer Stelle zu bündeln und das Ziel immer als vollständige URL zu schreiben. So erreicht eine Anfrage mit http und www die kanonische Version in einem Sprung. Sichern Sie die Regeldatei vor jeder Änderung; eine einzige falsche Regel kann die ganze Website in eine Schleife schicken.

Warum sollten interne Links und Sitemap auf die finale URL zeigen?

Die Kette auf dem Server zu kürzen, ist nur die halbe Arbeit. Die andere Hälfte besteht darin, dass die Website selbst nicht mehr auf weiterleitende URLs verlinkt. Denn jeder interne Link sagt dem Googlebot, dass sich ein Crawl dieser Adresse lohnt.

Stehen alte URLs noch im Menü, im Inhalt oder auf Produktkarten, bleibt mindestens ein Sprung bestehen, egal wie sauber Ihre Serverregeln sind. Zudem wiederholt sich dieser Sprung bei jedem Seitenaufruf. Für Nutzer ist das eine kleine Verzögerung, für Crawler eine ständige Verschwendung.

Für die Sitemap gilt eine noch klarere Regel: Sie sollte nur kanonische URLs mit dem Status 200 enthalten. Eine weiterleitende URL in der Sitemap sendet Google ein widersprüchliches Signal. Wenn Sie die Datei neu erstellen müssen, liefert der XML Sitemap Generator eine saubere Liste.

Prüfen Sie außerdem Ihre Canonical Tags. Zeigt ein Canonical auf eine weiterleitende URL, senden Sie Google gleichzeitig zwei verschiedene Botschaften. Interne Links, Sitemap und Canonical sollten sich also alle bei derselben finalen URL treffen.

Auf großen Websites ist die Anpassung von Hand mühsam. Deshalb ist Suchen und Ersetzen direkt in der Datenbank oft der schnellste Weg. Legen Sie vorher unbedingt eine Sicherung an.

Wie verhindern Sie Weiterleitungsketten bei einem Relaunch?

Die längsten Ketten entstehen durch Migrationen, die aufeinander folgen. Eine Website, die zuerst auf HTTPS umgestellt, dann die Domain gewechselt und zuletzt die Plattform getauscht hat, schickt alte URLs zum Beispiel durch drei Generationen von Regeln. Planen Sie eine neue Migration, erfassen Sie daher nicht nur die heutigen URLs, sondern auch alle früher umgeleiteten Adressen. Sonst hängen Sie ein neues Glied an eine alte Kette.

Mein Vorgehen sieht so aus. Vor der Migration exportiere ich alle bestehenden Weiterleitungsregeln. Danach lege ich für jede alte URL einzeln das endgültige Ziel auf der neuen Website fest. Dadurch erreicht selbst eine jahrealte Adresse die neue Seite in einem Sprung.

Zudem crawle ich die Liste der Weiterleitungen vor dem Livegang in einer Testumgebung. Finde ich eine Schleife oder eine Kette mit drei Sprüngen, behebe ich sie vor dem Start. Nach dem Livegang beobachte ich Logs und Search Console in den ersten zwei Wochen täglich.

Eine vollständige Liste für den ganzen Umzug finden Sie in meiner SEO Checkliste für die Website Migration. Dort gehe ich Domainwechsel, Umstellung auf HTTPS, Plattformwechsel und neue URL Strukturen einzeln durch.

Wie lange sollten Sie alte Weiterleitungen behalten?

Beim Kürzen einer Kette liegt es nahe, alte Regeln zu löschen. Allerdings empfiehlt Google im Leitfaden zum Umzug, Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr. In dieser Zeit kann Google die neuen URLs erneut crawlen und Links anderer Websites den neuen Adressen zuordnen.

Die Lösung heißt also abflachen, nicht löschen. Entfernen Sie in einer Kette A→B→C die Regel für B, sehen Websites mit Links auf B einen Fehler 404. Leiten Sie stattdessen A und B direkt auf C.

In der Praxis behalte ich Weiterleitungen für URLs mit externen Backlinks deutlich länger. Ein alter Presselink auf eine wertvolle Seite kann noch Jahre später Besucher bringen. Zwischenadressen ohne Links und ohne Traffic nach einem Jahr zu bereinigen, ist dagegen meist unkritisch.

Schauen Sie für diese Entscheidung in die Logs und in die Backlink Daten. So beruht sie auf Daten statt auf Vermutungen.

Notieren Sie außerdem das Datum jeder gelöschten Regel in einem Änderungsprotokoll. Steigt die Zahl der Fehler 404 einige Wochen später, finden Sie die Ursache sofort.

Eine kurze Checkliste für regelmäßige Redirect Audits

Weiterleitungsketten räumen Sie nicht einmal auf und sind dann für immer fertig; jede neue Kampagne, jede neue Kategorie und jedes Update eines Plugins kann eine neue erzeugen. Daher empfehle ich diese Prüfungen einmal im Quartal:

• Erreichen alle vier Hauptversionen der Domain die kanonische URL in einem Sprung?
• Liefern robots.txt und Sitemap direkt den Status 200?
• Zeigt ein Crawl der Website URLs mit zwei oder mehr Sprüngen?
• Ist die Zahl der Weiterleitungsfehler in der Search Console gestiegen?
• Welche weiterleitenden URLs fragt der Googlebot laut Logs am häufigsten an?
• Führen Zielseiten von Anzeigen und Newslettern direkt zur finalen Seite?
• Zeigen Canonical Tags und interne Links auf die finale URL?

Ich trage diese Prüfungen in eine Tabelle ein und vergleiche sie jedes Quartal. So sehen Sie auf einen Blick, ob das Problem wächst. Weitere technische Themen finden Sie in meinen Tipps zum technischen SEO.

Wie gehe ich mit meinem Team bei der Bereinigung vor?

In technischen SEO Projekten gehört die Bereinigung von Weiterleitungen zu den Aufgaben mit schnellen, messbaren Ergebnissen. Mit meinem Team beginne ich immer mit Daten: Crawl der Website, Loganalyse und Bericht aus der Search Console. Danach sammeln wir alle Regeln in einer einzigen Karte und flachen die Ketten ab.

Der aufwendigste Teil ist selten die technische Korrektur. Vielmehr geht es darum zu verstehen, warum jemand eine alte Regel überhaupt geschrieben hat. Deshalb bewerten wir vor jeder Löschung gemeinsam Traffic, Backlinks und geschäftliche Bedeutung der Regel.

Änderungen testen wir zuerst in einer Testumgebung und bringen sie dann live. Danach beobachten wir Logs und Indexierungsbericht über mehrere Wochen. Die Verantwortung für Strategie und Ergebnis liegt bei mir, die Umsetzung übernehmen erfahrene Spezialisten aus meinem Team.

Wünschen Sie ein ähnliches Audit für Ihre Website, erreichen Sie uns über unsere Seite zur SEO Beratung. Möchten Sie lieber selbst loslegen, bieten Ihnen die Schritte in diesem Beitrag und unsere kostenlosen Tools einen soliden Start.