Technisches SEORatgeber

Weiterleitungen und SEO: 301, 302 und 410 richtig einsetzen

Eine 301- oder 308-Weiterleitung zeigt Google, dass eine Seite dauerhaft umgezogen ist; Google wertet das als Signal, das Ziel als kanonische Adresse zu zeigen. Bei 302 und 307 bleibt in der Regel die alte Adresse in den Ergebnissen. Für Seiten, die ersatzlos wegfallen, passen 404 oder 410, die Google gleich behandelt.

Eine schmale Kopfsteinpflastergasse in einer Kleinstadt, eine Holzabsperrung lenkt Fußgänger in eine Seitengasse
Bild: KI-generiert

Adressen ändern sich bei jedem Relaunch, beim Wechsel auf HTTPS oder wenn du Kategorien neu ordnest. Mit einer Weiterleitung schickst du Besucher und Suchmaschinen von der alten auf die neue Adresse. Für die Google Suche entscheidet der Typ der Weiterleitung, welche der beiden Adressen in den Ergebnissen erscheint. Wie du Weiterleitungen in der .htaccess eines Apache-Servers einrichtest, erklärt domain-root.de unter Die .htaccess-Datei: Weiterleitungen und Regeln. Hier geht es um die Wirkung auf die Suche.

Was die Statuscodes bedeuten

Die Bedeutung der Codes legt RFC 9110 "HTTP Semantics" aus dem Juni 2022 fest [4]. Der Code 301 "Moved Permanently" sagt, dass die Ressource dauerhaft eine neue Adresse hat und künftige Verweise eine der neuen Adressen nutzen sollen [4]. 302 "Found" heißt, dass die Ressource vorübergehend unter einer anderen Adresse liegt; der Client soll weiter die ursprüngliche Adresse verwenden [4]. Mit 303 "See Other" schickt der Server den Client auf eine andere Ressource, die in der Location-Angabe steht; laut RFC dient das vor allem dazu, das Ergebnis einer POST-Anfrage als eigene Ressource bereitzustellen, die sich zum Beispiel als Lesezeichen speichern lässt [4]. Aus historischen Gründen dürfen Programme bei 301 und 302 eine POST-Anfrage als GET wiederholen. Wer das nicht will, nimmt laut RFC 308 "Permanent Redirect" statt 301 und 307 "Temporary Redirect" statt 302; bei diesen beiden darf sich die Methode nicht ändern [4]. Antworten mit 301 und 308 sind laut RFC heuristisch cachebar, Browser und Zwischenspeicher dürfen sie also ohne ausdrückliche Cache-Angabe speichern [4]. Eine falsch gesetzte dauerhafte Weiterleitung kann deshalb bei Besuchern noch wirken, wenn du sie auf dem Server längst korrigiert hast.

Google teilt die Weiterleitungen in zwei Gruppen ein [1]:

WeiterleitungEinordnung bei Google
HTTP 301 und 308dauerhaft
HTTP 302, 303 und 307vorübergehend
Meta-Refresh oder HTTP-Refresh nach 0 Sekundendauerhaft
Meta-Refresh oder HTTP-Refresh nach mehr als 0 Sekundenvorübergehend
JavaScript (location)dauerhaft
Crypto-Weiterleitung (Link mit Hinweis auf den Umzug)dauerhaft

Wie Google Weiterleitungen auswertet

Besucher merken von der Art der Weiterleitung meist nichts, sie landen in jedem Fall auf der neuen Adresse [1]. Für Google ist der Typ dagegen ein Signal. Bei einer dauerhaften Weiterleitung versteht die Indexierungspipeline von Google die Weiterleitung als Signal dafür, dass das Ziel kanonisch sein soll. In den Ergebnissen erscheint dann die neue Adresse [1]. Bei einer vorübergehenden Weiterleitung nutzt Google sie nicht als Signal für die Kanonisierung, und die alte Adresse bleibt in den Ergebnissen [1]. Google beschreibt 301 und 308 als starkes Signal, dass das Ziel verarbeitet werden soll, 302 und 307 als schwaches Signal [2].

Google erfasst Quelle und Ziel einer Weiterleitung. Eine Adresse gilt als kanonisch, die andere als alternativer Name [1]. Nach einem Domainwechsel kann die alte Adresse deshalb noch eine Zeit lang gelegentlich in den Ergebnissen auftauchen; das verschwindet laut Google von selbst [1]. Dauerhafte Weiterleitungen solltest du laut Google verwenden, wenn du dir sicher bist, dass die Weiterleitung nicht rückgängig gemacht wird [1].

Ketten aus mehreren Weiterleitungen verfolgt Google nur begrenzt. Standardmäßig folgen die Crawler von Google bis zu zehn Weiterleitungs-Hops [2]. Für Umzüge empfiehlt Google, verkettete Weiterleitungen zu vermeiden und direkt auf das endgültige Ziel zu leiten [3].

Serverseitig, Meta-Refresh oder JavaScript

Am zuverlässigsten wertet Google serverseitige Weiterleitungen aus, also eine Antwort des Servers mit Statuscode 3xx und Zieladresse [1]. Wie du sie einrichtest, hängt vom Server ab: Bei Apache geht es über die .htaccess, bei anderen Servern über deren Konfiguration, und viele Redaktionssysteme haben eigene Funktionen dafür. Für dauerhafte Umzüge nennt Google 301 oder 308 [1].

Google zeigt in seiner Dokumentation Beispiele für verbreitete Umgebungen [1]:

Umgebungdauerhaftvorübergehend
PHPheader('HTTP/1.1 301 Moved Permanently'); mit anschließendem Location-Headerheader('HTTP/1.1 302 Found'); mit Location-Header
Apache, mod_aliasRedirect permanent "/old" "https://example.com/new"Redirect temp "/two-old" "https://example.com/two-new"
Apache, mod_rewriteRewriteRule mit dem Zusatz [R=301]RewriteRule mit dem Zusatz [R]
NGINXreturn 301 mit der Zieladressereturn 302 mit der Zieladresse

Bei PHP müssen die Header vor jeder Ausgabe gesetzt werden [1]. Plattformen wie Blogger oder Shopify bringen laut Google teils eigene Lösungen für Weiterleitungen mit; bei anderen Servern hilft der Hostinganbieter [1].

Kannst du keine serverseitige Weiterleitung einrichten, ist ein Meta-Refresh die Alternative. Er steht im <head> der Seite, etwa als <meta http-equiv="refresh" content="0; url=https://example.com/newlocation">, oder als HTTP-Header Refresh [1]. Die Zahl vor der Adresse ist die Wartezeit in Sekunden. Mit 0 wertet Google die Weiterleitung als dauerhaft, mit einer längeren Wartezeit als vorübergehend [1]. JavaScript-Weiterleitungen soll man laut Google nur nutzen, wenn weder eine serverseitige Weiterleitung noch ein Meta-Refresh möglich ist. Google kann den Code möglicherweise nicht sehen, wenn das Rendering scheitert [1]. Die Crypto-Weiterleitung, also ein einfacher Link auf der alten Seite mit Hinweis auf den Umzug, ist nach Google nur für den Notfall gedacht; vorher soll man beim Hostinganbieter nachfragen, ob eine echte Weiterleitung möglich ist [1].

404 oder 410 für gelöschte Seiten

Nicht jede alte Adresse braucht ein Ziel. Fällt ein Inhalt ersatzlos weg, antwortet der Server mit einem Fehlercode. Nach RFC 9110 sagt 404 "Not Found" nicht, ob der Zustand vorübergehend oder dauerhaft ist. 410 "Gone" bedeutet, dass die Ressource nicht mehr verfügbar ist und das voraussichtlich so bleibt [4]. Der Betreiber muss laut RFC nicht alle dauerhaft entfernten Ressourcen als "gone" markieren und die Markierung auch nicht für eine bestimmte Zeit behalten [4].

Für Google macht der Unterschied keinen: 404 und 410 behandelt Google gleich, wie alle 4xx-Codes außer 429 [2]. Bereits indexierte Adressen entfernt Google aus dem Index, neu gefundene 404-Adressen verarbeitet Google nicht, und die Crawling-Frequenz für solche Adressen sinkt allmählich [2]. Ob du 404 oder 410 wählst, ist also eine Frage der Klarheit für andere Clients. Welche Codes es sonst gibt, steht auf domain-root.de unter HTTP-Statuscodes von 200 bis 503.

Weniger gut ist die bequeme Lösung, alle gelöschten Seiten auf die Startseite zu leiten. Google rät davon ab, eine größere Zahl alter Adressen auf eine einzelne Zieladresse ohne Bezug zum alten Inhalt zu leiten, zum Beispiel auf die Startseite der neuen Website. Das kann Nutzer verwirren und als Soft 404 gewertet werden [3].

Weiterleitungen beim Umzug planen

Bei einem Relaunch mit neuen Adressen beginnt Google mit einer Zuordnung: Für jede alte Adresse legst du fest, auf welche neue sie zeigt [3]. Die Liste der alten Adressen kannst du laut Google aus Sitemaps, Serverprotokollen und der Analysesoftware zusammenstellen [3]. Danach empfiehlt Google [3]:

  • serverseitige dauerhafte Weiterleitungen, am besten 301 oder 308,
  • direkte Weiterleitungen auf das endgültige Ziel ohne Ketten,
  • interne Links auf die neuen Adressen umzustellen,
  • die Canonical-Angaben der neuen Seiten auf die neuen Adressen zeigen zu lassen,
  • die neue Sitemap in der Search Console einzureichen.

Die Weiterleitungen sollen bleiben: "Behalte die Weiterleitungen möglichst lange bei, generell mindestens für ein Jahr" [3]. Während der Umstellung kann die Sichtbarkeit schwanken. Bei mittelgroßen Websites dauert es laut Google im Allgemeinen einige Wochen oder länger, bis Google nach und nach die neuen Adressen anstelle der alten anzeigt [3]. Wechselst du die Domain, reichst du zusätzlich in der Search Console eine Adressänderung für die alte Website ein; für eine Umstellung auf HTTPS oder geänderte Pfade auf derselben Domain ist sie nicht nötig [3]. Den ganzen Ablauf beschreibt Website-Relaunch ohne Rankingverlust.

Weiterleitungen und Canonical-Tag ergänzen sich. Die Weiterleitung passt, wenn die alte Adresse ganz wegfallen soll; bleiben beide Varianten für Besucher erreichbar, ist der Canonical-Tag das passende Mittel.

Fehler in der Search Console finden

Der Bericht zur Seitenindexierung führt Adressen mit Weiterleitung unter "Seite mit Weiterleitung". Die Adresse ist dann nicht kanonisch und wird nicht indexiert; das Ziel kann je nach Bewertung durch Google indexiert werden [5]. Ein Problem zeigt die Meldung "Weiterleitungsfehler": Dahinter steckt eine zu lange Kette, eine Schleife, eine zu lange oder eine ungültige Zieladresse; zur Analyse nennt die Hilfe ein Web-Debugging-Tool wie Lighthouse [5]. Unter "Nicht gefunden (404)" findest du Adressen, die ins Leere laufen. Bei dauerhaft entfernten Seiten ist das in Ordnung, bei umgezogenen Seiten empfiehlt die Hilfe eine 301-Weiterleitung [5]. Was die übrigen Meldungen bedeuten, erklärt Seite wird nicht indexiert: Ursachen finden.

  1. Organisation Weiterleitungen und die Google Suche. Google Search Central. Stand 20.04.2026. abgerufen am 29.10.2026
  2. Organisation Auswirkungen von HTTP-Statuscodes auf die Crawler von Google. Google for Developers. Stand 06.03.2026. abgerufen am 29.10.2026
  3. Organisation Website migrieren. Google Search Central. Stand 09.09.2026. abgerufen am 29.10.2026
  4. Gesetz RFC 9110: HTTP Semantics (R. Fielding, M. Nottingham, J. Reschke). IETF / RFC Editor. Stand 06.2022. abgerufen am 29.10.2026
  5. Organisation Bericht zur Seitenindexierung. Search Console-Hilfe, Google. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.