Was ist Redirect 301?

Die Zahl ist kein technisches Detail ohne Bedeutung: 301 heißt "dauerhaft umgezogen", 302 heißt "vorübergehend umgezogen", und Google behandelt beide unterschiedlich. Bei einem 301 wird die Ziel-URL zur kanonischen Version und ist die, die Google in den Suchergebnissen zeigt. Bei einem 302 zeigt Google weiter die Ausgangs-URL in den Ergebnissen, solange die Weiterleitung besteht, weil davon ausgegangen wird, dass die alte Adresse jederzeit wieder aktiv werden kann.

Der teuerste Fehler ist ein 302 bei einer Änderung, die eigentlich endgültig ist. Das passiert häufig bei Domain-Migrationen: Das neue CMS oder die neue Plattform setzt standardmäßig einen 302, niemand kontrolliert das nach, und wochenlang zeigt Google in den Ergebnissen weiter die alte Domain, statt den Wert auf der neuen zu bündeln. Die neue Domain übernimmt Crawling- und Klickverlauf langsamer, weil die Weiterleitung für Google jederzeit rückgängig gemacht werden könnte.

Die Faustregel ist einfach: Besteht die Möglichkeit, dass die alte URL wieder aktiv wird, gehört ein 302 hin. Besteht diese Möglichkeit nicht, gehört ein 301 hin.

Den tatsächlichen Code prüft man am schnellsten über die Kommandozeile, unabhängig davon, was das CMS oder Plugin behauptet:

curl -I https://beispiel.de/alte-seite

HTTP/1.1 301 Moved Permanently
Location: https://beispiel.de/neue-seite

Auch Protokoll- oder Subdomain-Wechsel zählen als 301, auch wenn sie oft nicht als "Migration" wahrgenommen werden: Der Wechsel von http zu https, oder von einer Version ohne www zu einer mit www (oder umgekehrt), bündelt dauerhaft auf eine einzige Adresse und sollte immer diesen Code tragen, keinen temporären 302 und erst recht nicht beide Versionen ohne jede Weiterleitung stehenlassen.

In der Praxis liegt der Fehler selten an einer bewussten Entscheidung für 302, sondern an der Standardeinstellung der Software. Viele Weiterleitungs-Plugins und Reverse-Proxy-Konfigurationen setzen ohne Rückfrage einen 302, weil das der sicherere Default ist: Eine falsch als dauerhaft markierte Weiterleitung lässt sich schwerer rückgängig machen als eine falsch als temporär markierte. Wer nach einer Migration nicht aktiv nachprüft, behält also oft monatelang den falschen Code, ohne es zu merken, weil die Seite für Besucher weiterhin normal funktioniert. Nur die Suchmaschine sieht den Unterschied.

Ein Canonical-Tag und ein Redirect 301 lösen dasselbe Grundproblem, doppelten oder auf mehrere URLs verteilten Inhalt, auf entgegengesetzte Weise. Das Canonical lässt beide URLs erreichbar: Wer die alte Adresse aufruft, sieht sie weiterhin, es wird Google nur mitgeteilt, welche Version bevorzugt indexiert werden soll. Der Redirect 301 dagegen sorgt dafür, dass die alte URL nicht mehr selbst antwortet: Wer sie aufruft, ob Mensch oder Crawler, landet automatisch auf der neuen Adresse, ohne die Möglichkeit, auf der alten zu bleiben.

Dieser Unterschied entscheidet, welches Werkzeug passt. Müssen beide Versionen bestehen bleiben, etwa eine Produktseite mit und ohne Farbparameter, reicht ein Canonical völlig aus: Eine Weiterleitung würde dort die Navigation für alle kaputt machen, die genau diese Variante sehen wollen. Hat die alte URL dagegen keinen Grund mehr, erreichbar zu sein, etwa bei einem Domain-Umzug, einer neuen Kategoriestruktur oder einer Zusammenlegung zweier Seiten, ist der Redirect 301 das richtige Werkzeug, und Canonical greift zu kurz: Es würde eine URL weiter erreichbar lassen, die eigentlich verschwinden sollte.

Der typische Fehler geht in beide Richtungen. Nur ein Canonical zu setzen, wenn die alte URL eigentlich gelöscht gehört, hält sie ohne Grund am Leben und erzeugt minderwertige Duplikate, die ein Crawler weiter unnötig besucht. Einen Redirect 301 zu setzen, obwohl beide Versionen nebeneinander bestehen müssen, kappt den Zugang zu einer davon: Wer genau diese Variante sucht, kommt nicht mehr eigenständig dorthin.

Ein weiterer praktischer Unterschied betrifft die Nutzererfahrung. Ein Canonical ist für Besucher unsichtbar, sie merken nichts von seiner Existenz, während ein Redirect 301 aktiv in die Navigation eingreift: Ein gespeichertes Lesezeichen oder ein alter Screenshot mit der ursprünglichen URL führt automatisch woanders hin. Das ist im Fall eines echten Umzugs gewollt, wäre bei einer bloßen Parameter-Variante aber ein unnötiger Bruch in der Erwartung der Nutzer.

Ein Fehler 404 sagt "hier gibt es nichts". Ein Redirect 301 sagt "das ist umgezogen, hier ist das Neue". Der Unterschied klingt eindeutig, bis konkret entschieden werden muss, was mit einer bestimmten URL passiert, die weggefallen ist, und genau dort passiert der häufigste Fehler.

Gibt es für den Inhalt eine echte Entsprechung an anderer Stelle, ist der Redirect 301 fast immer die richtige Wahl: Er nimmt sowohl Besucher, die über einen alten Link oder ein gespeichertes Lesezeichen kommen, als auch die auf dieser Adresse gesammelten Rankingsignale mit. Bei einem 404 bleiben in diesem Fall beide auf der Strecke, ohne Notwendigkeit.

Der 404 bleibt die richtige Antwort, wenn es keine passende Entsprechung gibt. Eine Weiterleitung auf eine Seite ohne echten inhaltlichen Bezug zu erzwingen, allen voran die Startseite als Auffangbecken, löst das Problem nicht: Es verwirrt, wer gezielt etwas Bestimmtes gesucht hat, und schwächt das Vertrauen in den Rest der Seite, während Google die Weiterleitung als wenig relevant für die ursprüngliche Suchanfrage einstufen kann. In diesem Fall ist ein sauber gestalteter 404 mit eigener Navigation und Suche ehrlicher und nützlicher als eine erzwungene Weiterleitung.

Wer bewusst Inhalt entfernt und sicher weiß, dass kein Ersatz kommt, kann statt eines 404 den weniger gebräuchlichen Code 410 einsetzen: Er kommuniziert "absichtlich und endgültig gelöscht" statt des offeneren "hier ist nichts", das ein 404 auch für versehentlich kaputte Links liefert. In der Praxis behandelt Google beide ähnlich, der Unterschied liegt vor allem in der Klarheit für Menschen, die den Server-Log auswerten.

• Redirect-Ketten vermeiden: Zeigt URL A auf B, muss B bereits die finale Version sein, kein weiterer Sprung zu C. Jeder zusätzliche Sprung kostet Crawl-Budget und verzögert die Signalübertragung.
• Immer auf eine inhaltlich passende Seite weiterleiten, nie standardmäßig auf die Startseite.
• 301 für jede Änderung nutzen, die als endgültig gilt, auch bei Restzweifeln im Moment der Umsetzung: Ein 301 lässt sich leichter korrigieren als ein 302, der monatelang die Signalübertragung ausgebremst hat, bevor jemand es bemerkt.
• Interne Links, die auf die alte URL zeigten, direkt auf die neue Adresse umstellen, statt sie über die Weiterleitung laufen zu lassen.
• Vor jeder Domain- oder Strukturmigration eine vollständige URL-für-URL-Redirect-Map erstellen; improvisierte Weiterleitungen sind der häufigste Grund für pauschale Redirects auf die Startseite.
• Mit einem Kommandozeilen-Tool (curl -I genügt) prüfen, ob die Weiterleitung wirklich 301 zurückgibt und nicht ein vom CMS standardmäßig gesetzter 302.
• In Search Console und Analytics den Traffic der neuen URL in den Wochen nach der Migration beobachten; ein anhaltender Einbruch deutet meist auf falsch gemappte Redirects hin, nicht auf ein Problem des 301 selbst.

• Einen 302 bei einer dauerhaften Änderung stehenlassen, weil das CMS ihn standardmäßig setzt und niemand ihn kontrolliert.
• Alle alten URLs einer Migration pauschal auf die Startseite statt auf ihre echte Entsprechung weiterleiten.
• Redirect-Ketten mit mehreren Sprüngen anlegen, die niemand prüft, bis auffällt, dass das Crawling langsamer läuft als erwartet.
• Interne Links nach dem Einrichten der Weiterleitung weiter auf die alte URL zeigen lassen, statt sie auf die neue Adresse zu aktualisieren.
• Widersprüchliche Signale mischen: eine URL mit einem Canonical auf ein Ziel, während die interne Verlinkung sie auf ein anderes weiterleitet.
• Einen Redirect 301 nutzen, um problematischen Inhalt zu "verstecken", statt ihn zu überarbeiten oder gezielt zu entfernen.