Redirect-Handling für KI-Crawler: 301, 302 und Ketten richtig nutzen

Ein Redirect gilt vielen als technisches Detail, das nach dem Relaunch niemand mehr anschaut. Für die KI-Suche ist genau diese Haltung riskant.

Definition: Redirect-Handling für KI-Crawler bezeichnet den kontrollierten Einsatz von 301-, 302- und Meta-Refresh-Weiterleitungen, damit GPTBot, PerplexityBot, ClaudeBot und Googlebot eine Seite unter der richtigen URL erreichen, verstehen und der passenden Entität zuordnen. Dazu gehört auch, Redirect-Ketten kurz zu halten und veraltete Weiterleitungen rechtzeitig zu bereinigen.

Redirect-Handling ist im Kern technisches SEO, betrifft aber direkt die KI-Sichtbarkeit: Wenn ein Crawler eine Kette nicht zu Ende verfolgt oder das falsche Signal liest, fehlt die Seite im Index, egal wie gut der Inhalt ist. Wo genau die Grenze zwischen klassischem SEO und der KI-spezifischen Optimierung (in der Branche oft AIO oder GAIO genannt) verläuft, ist uneinheitlich definiert. Für Redirects sollte das kaum eine Rolle spielen: Die technischen Grundregeln dürften für Google, GPTBot und Co. weitgehend ähnlich sein, auch wenn das für die einzelnen KI-Crawler öffentlich nicht dokumentiert ist.

Was Googles Dokumentation zu 301-Redirects wirklich bedeutet

Laut der Dokumentation von Google Search Central interpretiert Google einen sofortigen, also nach 0 Sekunden ausgeführten Meta-Refresh wie einen permanenten Redirect, während ein verzögerter Meta-Refresh als temporärer Redirect gewertet wird. Von JavaScript-basierten Weiterleitungen rät die Dokumentation ausdrücklich ab, weil das Rendering fehlschlagen kann (https://developers.google.com/search/docs/crawling-indexing/301-redirects).

Das bedeutet nicht, dass Meta-Refresh eine gleichwertige Alternative zum Server-Redirect ist. Es bedeutet nur, dass Google im Zweifel überhaupt eine Einordnung vornimmt, statt die Seite komplett zu ignorieren. Für die Praxis folgt daraus: Ein serverseitiger 301-Redirect bleibt der Standardfall, Meta-Refresh ist eine Notlösung für Systeme, die keinen echten Server-Redirect erlauben.

Aus unserer Sicht ist ein serverseitiger 301-Redirect auch für andere KI-Crawler das robustere Signal: Er kommt, anders als eine JavaScript-Weiterleitung, ohne das Rendering aus, das laut der oben zitierten Google-Dokumentation fehlschlagen kann. Als belegte Tatsache für jeden einzelnen KI-Crawler können wir das aber nicht ausgeben.

Redirect-Ketten: Warum 10 Hops nicht das Ziel sind

Laut der Dokumentation von Google Search Central zum Website-Umzug mit URL-Änderungen folgt Googlebot einer Redirect-Kette maximal 10 Hops weit, empfiehlt aber, direkt zum Ziel weiterzuleiten und eine Kette auf idealerweise nicht mehr als 3 und weniger als 5 Weiterleitungen zu begrenzen (https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes).

Rechenbeispiel: Angenommen, eine Kette hat 5 Redirects und jeder Hop benötigt rund 200 Millisekunden Serverantwortzeit: Dann ergäbe das in diesem Modell rund 1.000 Millisekunden zusätzliche Wartezeit, bevor ein Crawler die endgültige Seite erreicht, verglichen mit einer einzelnen direkten Weiterleitung.

Laut Ahrefs (Autor: Patrick Stox, 2025) belasten liegengebliebene interne Links auf weitergeleitete Seiten das Crawl-Budget unnötig, ihre Bereinigung hat einen kleinen, aber messbaren positiven Effekt (https://ahrefs.com/blog/crawl-budget/). Wie viel Crawl-Budget eine Website insgesamt zur Verfügung hat und wie Serverantwortzeit dabei hineinspielt, haben wir im Beitrag Crawl-Budget für KI-Bots: Server-Response-Zeit richtig optimieren eingeordnet.

301 vs. 302: Welches Signal Google und KI-Systeme lesen

Laut der Crawling-Infrastruktur-Dokumentation von Google behandelt Google einen 301-Statuscode als starkes Signal dafür, welche URL kanonisch werden soll, während ein 302 nur als schwaches Signal gilt. Ein 308 wird dabei wie ein 301 gewertet, ein 307 wie ein 302 (https://developers.google.com/crawling/docs/troubleshooting/http-status-codes).

Redirect-Typ	Signalwirkung laut Google	Einsatzbereich
301 (permanent)	starkes Signal für die kanonische URL	dauerhafte URL-Änderungen, Domain-Umzüge
302 (temporär)	schwaches Signal, alte URL bleibt bevorzugt	kurzfristige Umleitungen, Wartungsseiten
308 (permanent, Methode erhalten)	wie 301 gewertet	permanente Umleitungen mit erhaltener HTTP-Methode
307 (temporär, Methode erhalten)	wie 302 gewertet	temporäre Umleitungen mit erhaltener HTTP-Methode
Meta-Refresh, 0 Sekunden	wie permanenter Redirect gewertet	Notlösung ohne Zugriff auf den Server
Meta-Refresh, verzögert	wie temporärer Redirect gewertet	Notlösung, nicht empfohlen

Ein 302 statt 301 bei einer dauerhaften Änderung ist einer der Fehler, die eine Seite technisch online lassen und trotzdem aus dem Index verschwinden lassen, weil das Kanonisierungssignal fehlt. Wie ein Canonical-Tag dieses Signal ergänzt und wo die beiden sich widersprechen können, steht im Beitrag Canonical Tags für generative Suche: KI-Duplikate gezielt vermeiden.

Meta-Refresh und JavaScript-Redirects: Risiko für KI-Crawler

Wenn schon Googlebot beim Rendern von JavaScript-Redirects scheitern kann, wie die Google-Dokumentation oben festhält, liegt die Vermutung nahe, dass Crawler mit geringeren oder öffentlich nicht dokumentierten Rendering-Fähigkeiten wie GPTBot oder PerplexityBot ähnliche oder größere Probleme haben. Belegt ist das für diese Systeme öffentlich nicht, wir kennzeichnen den Punkt deshalb ausdrücklich als Vermutung und nicht als gesicherten Fakt.

Praktisch heißt das: Wo ein Redirect wichtig ist, gehört er in den Server oder ins CMS-Redirect-Modul, nicht in ein Script, das erst nach dem Laden der Seite feuert.

Bevor du aufräumst: 301-Redirects lange genug aktiv lassen

Laut John Mueller von Google, zitiert von Search Engine Journal (Autor: Matt G. Southern, 2021), sollte ein 301-Redirect mindestens ein Jahr lang aktiv bleiben, weil Google die Änderung mehrfach sehen muss, um sie dauerhaft zu übernehmen (https://www.searchenginejournal.com/google-keep-301-redirects-in-place-for-a-year/428998/).

Aus unserer Sicht ist die konservative Ableitung aus dieser Google-Frist auch für KI-Suchsysteme sinnvoll: Wer einen Redirect nach wenigen Wochen entfernt, riskiert, dass die alte URL wieder zitiert oder verlinkt auftaucht, obwohl sie längst nicht mehr existiert. Eine geplante Migration oder ein Relaunch verdient deshalb eine eigene Checkliste statt Bauchgefühl, dazu mehr im Beitrag Website-Migration KI-Sichtbarkeit: Checkliste ohne Traffic-Verlust.

Redirect-Hygiene und die geaio-Regelliste

Die vollständige geaio-Regelliste mit Gewichtung und Aufwand je Regel ist für registrierte Nutzer kostenlos auf geaio.de/erklaert einsehbar.

Redirect-Handling ist selten das einzige Problem einer Seite, aber oft das unauffälligste: Eine Kette aus drei oder vier Weiterleitungen liefert am Ende noch einen 200er-Statuscode und sieht im Browser unauffällig aus. Für einen Crawler mit begrenztem Budget pro Domain macht das trotzdem den Unterschied, ob eine Seite überhaupt vollständig erfasst wird.

Häufig gestellte Fragen

Wie viele Redirects darf eine Kette maximal haben, bevor Googlebot abbricht? Laut Google Search Central folgt Googlebot einer Kette maximal 10 Hops weit. Google empfiehlt aber ausdrücklich, deutlich darunter zu bleiben und idealerweise nicht mehr als 3 bis 5 Weiterleitungen aneinanderzuhängen.

Ist ein 301-Redirect für KI-Crawler dasselbe wie für Google? Dokumentiert ist das Verhalten von 301 und 302 nur für Google, wo 301 als starkes und 302 als schwaches Kanonisierungssignal gilt. Wie GPTBot, PerplexityBot oder ClaudeBot diese Statuscodes im Detail gewichten, ist öffentlich nicht bekannt.

Wie lange muss ich einen 301-Redirect aktiv lassen? John Mueller von Google empfiehlt laut Search Engine Journal mindestens ein Jahr, weil Google die Weiterleitung mehrfach sehen muss, um die Änderung dauerhaft zu übernehmen. Für andere KI-Systeme gibt es keine vergleichbare öffentliche Angabe, weshalb dieselbe Frist als konservative Richtgröße sinnvoll ist.

Sollte ich Meta-Refresh statt eines Server-Redirects nutzen? Nur wenn kein Zugriff auf Serverkonfiguration oder CMS-Redirect-Funktion besteht. Google wertet einen sofortigen Meta-Refresh zwar wie einen permanenten und einen verzögerten wie einen temporären Redirect, rät aber grundsätzlich zum serverseitigen 301, weil er kein Rendering voraussetzt.

Wichtig: Die beiden beanstandeten Sätze standen bereits mit Reichweitenbegrenzung (“in den von uns geprüften Quellen …”) da, sind aber ohne geladenen Prüfanker trotzdem als unbelegt durchgefallen. Ich habe sie gestrichen und die direkt anschließenden Vermutungssätze zu klar gekennzeichneten eigenen Einschätzungen (“Aus unserer Sicht”) umformuliert, gestützt auf bereits im Text vorhandene, belegte Fakten (Google-Rendering-Hinweis, John-Mueller-Zitat). Keine neuen Quellen oder Zahlen ergänzt.

Offen: Die FAQ enthält an zwei Stellen wortähnliche, nicht vom Gate beanstandete Aussagen (“ist öffentlich nicht bekannt”, “gibt es keine vergleichbare öffentliche Angabe”) mit demselben Fehlermuster. Ich habe sie laut Vorgabe unangetastet gelassen, weil nur die zwei markierten Stellen zu bearbeiten waren — sie könnten im nächsten Prüflauf denselben Befund auslösen.