seojuice

Was ist ein Redirect? Redirects erklärt (301 vs. 302)

Vadim Kravcenko
Vadim Kravcenko
· Updated · 9 min read

TL;DR: Redirecting bedeutet, dass eine URL Besucher und Suchmaschinen automatisch an eine andere URL weiterleitet. Verwenden Sie eine 301 für eine permanente Weiterleitung und eine 302 für eine temporäre. Redirects verlieren nicht zwangsläufig PageRank, aber Chains, Loops, nicht erreichbare Ziele und irrelevante Weiterleitungen auf die Startseite können trotzdem echte SEO- und Usability-Probleme verursachen.

Redirect Bedeutung Wann verwenden Was Google in der Regel indexiert
301 Moved Permanently Eine Seite, ein Protokoll, ein Hostname oder eine Domain hat sich dauerhaft geändert Die Ziel-URL
302 Found Die ursprüngliche Seite wird zurückkommen Die ursprüngliche URL
303 See Other Eine POST-Anfrage soll über GET zu einer separaten Ergebnis-Seite führen Die ursprüngliche URL, weil die Weiterleitung temporär ist
307 Temporary Redirect Die Weiterleitung ist temporär und die HTTP-Methode muss erhalten bleiben Die ursprüngliche URL
308 Permanent Redirect Die Weiterleitung ist dauerhaft und die HTTP-Methode muss erhalten bleiben Die Ziel-URL
Redirect types: 301/308 permanent vs 302/307 temporary, and the mistakes to avoid.

Was bedeutet Redirecting?

Ein Redirect ist eine Anweisung, die sinngemäß sagt: „Diese URL ist umgezogen. Geh stattdessen zu dieser URL.“

Technisch: Ein Browser ruft eine Adresse an, und der Server kann mit einem 3xx HTTP-Statuscode plus einem Location-Header antworten, der eine andere Adresse enthält. Anschließend ruft der Browser dieses Ziel automatisch an. Auch Crawler von Suchmaschinen können dieser gleichen Anweisung folgen.

Die praktische Bedeutung von Redirecting ist einfacher: Die alte URL stellt ihren eigenen Content nicht mehr bereit; sie leitet die Anfrage an eine neue URL weiter.

Redirects werden benötigt, weil sich URLs ändern. Seiten werden umbenannt, Produkte entfernt, Websites wechseln von HTTP zu HTTPS, überlappende Artikel werden zusammengelegt, und Domains werden ersetzt. Ohne Redirect landet jemand, der die alte Adresse aufruft, in der Regel auf einem 404. Backlinks zeigen weiterhin auf eine aufgegebene URL, und Google erhält keine explizite Routing-Anweisung, die die alte Seite mit ihrem Ersatz verknüpft.

Das haben wir direkt gelöst, als Lida und ich im Januar 2026 SEOJuice von seojuice.io auf seojuice.com migriert haben. Eine Domainmigration macht den Zweck von Redirects ungewöhnlich klar: Jeder alte Pfad braucht ein bewusstes Ziel – nicht nur eine Regel, die die Domain irgendwohin schickt, was „ungefähr sinnvoll“ wirkt. Als Zwei-Personen-Team gab es keinen Spielraum, die Begründung zu delegieren; die Redirect-Map musste als Teil der Migration selbst behandelt werden (nicht als die administrative Aufgabe danach).

Dieser Unterschied zählt. Einen alten Artikel auf sein Äquivalent in der neuen Domain weiterzuleiten, erhält den Pfad. Jede alte Adresse auf die neue Startseite umzuleiten, überdeckt nur die fehlenden Routen.

301 vs. 302: Die echte Entscheidung ist „permanent“

Der Unterschied zwischen einer 301 und einer 302 ist nicht, dass die eine „SEO-freundlich“ ist und die andere schlecht. Jeder Code signalisiert eine andere Erwartung darüber, was als Nächstes passiert.

Ein 301-Redirect bedeutet: Die Änderung ist dauerhaft. Ein 302-Redirect bedeutet: Die Änderung ist temporär und die ursprüngliche URL wird voraussichtlich zurückkommen. Google folgt beiden, interpretiert deren kanonische Signale jedoch nicht auf dieselbe Weise.

„Googlebot folgt dem Redirect, und die Indexierungs-Pipeline nutzt die Weiterleitung als Signal dafür, dass das Redirect-Ziel kanonisch sein soll.“

Für temporäre Redirects: „Googlebot folgt dem Redirect, aber die Indexierungs-Pipeline nutzt den Redirect nicht als Signal dafür, dass das Redirect-Ziel kanonisch sein soll.“

Das sind die eigenen Formulierungen von Google Search Central in der Dokumentation Redirects and Google Search.

Übersetzt in praktisches SEO heißt das: Eine permanente Weiterleitung bittet Google, die alte URL im Index durch das Ziel zu ersetzen. Eine temporäre Weiterleitung schickt Nutzer zum Ziel, lässt normalerweise aber die ursprüngliche URL als kanonisch stehen. Wenn der kanonisierende Teil verwirrend ist: Unser Guide zu how Google indexing works erklärt, wie Crawling, Kanonical Selection und Indexierung zusammenpassen.

Verwenden Sie eine 301 für permanente URL-Änderungen

Eine 301 ist die Standardwahl für eine normale Content-URL, die dauerhaft umgezogen ist. Typische Fälle sind:

  • Eine Seite umbenennen oder ihren URL-Slug ändern
  • Von HTTP zu HTTPS wechseln
  • Auf www oder non-www standardisieren
  • In eine andere Domain wechseln
  • Doppelte oder überlappende Seiten zusammenführen
  • Eine alte Seite durch einen wirklich gleichwertigen Nachfolger ersetzen

Google empfiehlt, wann immer möglich eine permanente serverseitige Weiterleitung zu verwenden, sobald eine URL in den Suchergebnissen geändert werden muss. Das nennt Google den besten Weg sicherzustellen, dass sowohl Nutzer als auch die Google-Suche die korrekte Seite erreichen.

Das Wort gleichwertig (equivalent) ist hier entscheidend. Ein gelöschtes Produkt wird nicht automatisch mit Ihrer Startseite gleichwertig, nur weil beide URLs zu demselben Unternehmen gehören.

Verwenden Sie eine 302, wenn die ursprüngliche URL wiederkommt

Eine 302 passt zu einer temporären Wartungsseite, einem Experiment, einer kurzfristigen saisonalen Übernahme oder zu einem Routing, das Sie später wieder zurückdrehen wollen. Sie signalisiert Google, dass das Ziel nicht als dauerhafter Ersatz gedacht ist.

Wenn eine Seite zwar dauerhaft umgezogen ist, aber hinter einer 302 bleibt, kann Google weiterhin die alte Adresse indexieren. Die Weiterleitung kann im Browser völlig „funktionieren“, während sie gleichzeitig die falsche Indexierungsabsicht kommuniziert (ein nützlicher Hinweis: „Es lädt“ ist kein vollständiger Redirect-Test).

Wählen Sie danach, ob Sie die Änderung rückgängig machen möchten. Permanent bedeutet 301; temporär bedeutet 302. Unser gesonderter Vergleich von 301 vs 302 redirects deckt die weniger offensichtlichen Migrations- und Kanonisierungsszenarien ab.

Was ist mit 303-, 307- und 308-Redirects?

Die meisten Redaktions- und Marketingseiten können über Jahre mit 301- und 302-Redirects arbeiten, ohne die anderen Codes zu brauchen. Die Unterschiede werden wichtig rund um Formulare, APIs und andere Anfragen, die nicht GET verwenden.

Wie in den guide to HTTP redirections von MDN Web Docs dokumentiert: 301 und 302 tragen historisch eine gewisse Unklarheit bezüglich der Request-Methoden. Einige Clients können dabei eine POST-Anfrage in eine GET-Anfrage umwandeln, während sie den Redirect verfolgen.

Dieses Verhalten ist bei einer normalen Seitenansicht oft harmlos. Es ist nicht harmlos, wenn ein Endpunkt einen Request-Body erwartet.

307 bewahrt die Anfrage temporär

Ein 307 Temporary Redirect drückt die gleiche temporäre Absicht wie eine 302 aus, garantiert aber, dass HTTP-Methode und Body erhalten bleiben. Ein POST bleibt nach dem Redirect ein POST.

308 bewahrt die Anfrage dauerhaft

Ein 308 Permanent Redirect ist das methodenerhaltende Gegenstück zu einer 301. MDN erklärt: „308 wurde erstellt, um die Unklarheit im Verhalten zu entfernen, wenn Nicht-GET-Methoden verwendet werden.“

Bei einer normalen Content-Seite, die per GET angefragt wird, sehen Nutzer kaum einen praktischen Unterschied zwischen 301 und 308. Dasselbe gilt für 302 und 307. Method Preservation wird vor allem relevant für POST- und PUT-Requests, Formulare und APIs (in dem Fall würde ich die Person ins Boot holen, die den Backend-Teil verantwortet, statt einen Status aus einem SEO-Report zu wählen).

303 ändert die Anfrage bewusst zu GET

Ein 303 See Other-Redirect ist temporär und macht die folgende Anfrage bewusst zu einem GET. Ein gängiger Anwendungsfall: Sie schicken jemanden von einem abgeschickten Formular auf eine separate Bestätigungs- oder Ergebnis-Seite – damit wird verhindert, dass ein Refresh das ursprüngliche POST erneut absendet.

Das ist zuerst HTTP-Verhalten und erst danach SEO-Verhalten. Mach normale Seitenredirects nicht exotischer als nötig.

Server-seitige Redirects schlagen Browser-Workarounds

HTTP-Statusredirects passieren serverseitig. Zwei weitere clientseitige Alternativen gibt es ebenfalls: HTML Meta Refresh und JavaScript-Redirects.

Ein Meta Refresh läuft erst, nachdem ein HTML-Dokument mit dem Laden beginnt. MDN empfiehlt, die Verzögerung für die Barrierefreiheit auf null zu setzen, und warnt davor, dass HTTP- und HTML-Redirect-Regeln, die nicht synchron sind, eine Endlosschleife oder „andere Albträume“ erzeugen können. Die Formulierung bleibt im Kopf, weil die Gefahr real ist: Zwei getrennt verwaltete Routing-Ebenen können nach einer ansonsten routinemäßigen CMS-Änderung anfangen, sich zu widersprechen.

Ein JavaScript-Redirect hängt davon ab, dass der Client JavaScript ausführt. Google Search Central schreibt: „Nutzen Sie JavaScript-Redirects nur, wenn serverseitige oder Meta-Refresh-Redirects nicht möglich sind. Obwohl Google versucht, jedes von Googlebot gecrawlte URL zu rendern, kann das aus verschiedenen Gründen fehlschlagen.“

Meine Reihenfolge der Präferenz ist:

  1. Ein serverseitiger HTTP-Redirect mit dem korrekten permanenten oder temporären Status
  2. Ein Meta Refresh mit 0 Sekunden, falls die Serverkonfiguration nicht verfügbar ist
  3. Ein JavaScript-Redirect nur, wenn keine der Optionen oben möglich ist

Einige statische Hosting-Setups und eingeschränkte CMS-Plattformen machen es unmöglich, die ideale Server-Ebene bereitzustellen. Diese Einschränkung ist real. Trotzdem ist es nicht dasselbe, wenn ein Browser irgendwann das Ziel erreicht, wie ein sauberer Redirect, den jeder Client konsistent interpretieren kann.

Verlieren Redirects PageRank?

Eine alte SEO-Regel behauptete, dass jeder Redirect einen festen Prozentsatz von „Link Juice“ verliert. Die Prozentwerte kursieren zwar noch, sollten aber keine Implementierungsentscheidungen treiben. Sie werden in Googles aktueller Position nicht unterstützt.

„30x-Redirects verlieren nicht mehr PageRank.“

Gary Illyes von Google hat das 2016 so gesagt, wie von Search Engine Land berichtet. Die sinnvolle Schlussfolgerung ist eng, aber wichtig: Das bloße Vorhandensein einer 301, 302 oder eines anderen 30x-Redirects führt nicht automatisch zu einer PageRank-Strafe.

Aber: Daraus folgt nicht, dass 301 und 302 austauschbar sind.

Eine 301 sagt Google, dass das Ziel als permanente kanonische Ersetzung behandelt werden soll. Eine 302 lässt die ursprüngliche URL in der Regel kanonisch, weil die Weiterleitung temporär ist. PageRank-Handling und kanonische Intention hängen zusammen, sind aber nicht dieselbe Frage.

Ich würde auch nicht versprechen, dass eine Domainmigration jedes Ranking ohne Schwankungen bewahrt. Redirects tragen ein wichtiges Signal – Google muss aber URLs weiterhin neu crawlen, Canonicals verarbeiten und seinen Index aktualisieren. Sauberes Routing entfernt eine große Quelle für Unklarheit; es friert Suchergebnisse nicht ein.

Die Redirect-Fehler, die echten Schaden anrichten

Redirect Chains

Eine Redirect Chain leitet eine Anfrage über mehrere URLs weiter:

URL A → URL B → URL C → URL D

Der sauberere Weg ist, dass URL A direkt zu URL D führt. Wenn B und C weiterhin intern verlinkt sind, aktualisieren Sie diese Links ebenfalls auf D.

Jeder „Hop“ bedeutet zusätzliche Requests, verbraucht Crawler-Ressourcen und erzeugt eine weitere Regel, die fehlschlagen kann. Lange Chains erhöhen außerdem das Risiko, dass das finale Ziel in einem bestimmten Crawl nicht erreicht wird. Wiederholt über tausende Seiten wird daraus ein echtes Crawl-Budget-Problem – statt nur ein kosmetisches Audit-Warnsignal.

Es gibt keinen Grund, an jeden Hop erfundene PageRank-Verlustprozente zu hängen. Mehr Requests, langsameres Routing, verschwendetes Crawling und zusätzliche Fehlerpunkte reichen als Begründung, die Chain zu verkürzen.

Redirect Loops

Eine Schleife schickt die Anfrage im Kreis, z. B. A → B → A. Browser stoppen irgendwann und zeigen einen Fehler wie „too many redirects“. Der Content ist dann sowohl für Nutzer als auch für Crawler nicht erreichbar.

Loopen entstehen häufig durch widersprüchliche Regeln: Eine HTTPS-Regel kämpft gegen eine Hostname-Regel, eine Slash-End-Regel dreht eine andere Weiterleitung um, oder ein Meta Refresh widerspricht dem Server. Der finale Browser-Fehler verschleiert den Pfad – prüfen Sie deshalb jede Antwort, statt die Seite wiederholt neu zu laden (oder, häufiger als mir lieb ist, Caches zu leeren und zu hoffen).

Jede gelöschte URL auf die Startseite weiterleiten

Das ist keine Strategie für „Aufräumen“. Sie ersetzt eine klare Antwort „Seite fehlt“ durch ein irrelevantes Ziel.

Googles Soft-404-Guidance erklärt, dass Weiterleitungen auf irrelevante Seiten als Soft 404 interpretiert werden können. Leiten Sie eine alte URL nur dann weiter, wenn es eine wirklich relevante Ersetzung gibt. Wenn keine Ersetzung existiert: Geben Sie eine korrekte 404 oder 410 zurück.

Ein eingestelltes Produkt kann sinnvoll auf seinen direkten Nachfolger umgeleitet werden – oder in manchen Fällen auf eine eng verwandte Kategorie. Es sollte Nutzer nicht automatisch zu einer generischen Startseite schicken, die die Anfrage nicht beantwortet.

Gemischte Protokoll- und Hostname-Varianten

Wenn sowohl HTTP, HTTPS, www als auch non-www dieselben Inhalte ausliefern, konkurrieren mehrere Adressen darum, dieselbe Seite zu repräsentieren. Wählen Sie genau einen kanonischen Host und ein Protokoll und leiten Sie dauerhaft jede alternative Variante direkt auf diesen einen Wert um.

Testen Sie jede Kombination. Eine HTTP-Regel kann allein korrekt funktionieren, aber zusammen mit der Hostname-Regel eine zweite Hop erzeugen oder eine Schleife auslösen.

Redirects, die auf einen Fehler enden

Eine Weiterleitung ist nicht erfolgreich nur weil ihre erste Antwort eine 301 ist. Das finale Ziel muss eine funktionierende Antwort zurückgeben.

Eine 301, die zu einer 404 führt, bleibt für die Person kaputt, die ihr gefolgt ist. Ein Redirect, der auf eine Antwort aus dem 500er-Bereich endet, ist nicht besser. Deshalb reicht es nicht, nur den initialen Statuscode zu prüfen – ein großer Teil der Route bleibt sonst verborgen.

Wie Sie Redirect-Probleme finden und beheben

Starten Sie mit einem Crawler wie Screaming Frog, Ahrefs Site Audit oder dem Audit von SEOJuice. Crawl'en Sie die Quell-URLs und folgen Sie jeder Route bis zur finalen Antwort. Achten Sie auf:

  • Redirect Chains mit mehreren Hops
  • Redirect Loops
  • Redirects, die in eine 4xx- oder 5xx-Antwort enden
  • Interne Links, die weiterhin auf Redirect-URLs zeigen
  • Perma-Moves, die mit temporären Redirects umgesetzt wurden

Was wir bei SEOJuice über viele Sites hinweg sehen: Interne Links, die auf bereits umgeleitete URLs zeigen, verdienen mehr Aufmerksamkeit als sie bekommen. Die Weiterleitung kann funktionieren, daher wirkt das Problem harmlos. Aber Ihre Site schickt trotzdem jeden Nutzer und jeden Crawler durch eine unnötige Anfrage – und zukünftige Redirect-Änderungen können diesen alten internen Link wieder Teil einer Chain machen.

Das wurde besonders relevant während unserer .io-zu-.com Migration. Domainweite Regeln können die Site so aussehen lassen, als sei alles migriert, während alte absolute Links weiterhin in Seiten, Templates oder strukturierten Content „vergraben“ sind. Ein funktionierender globaler Redirect maskiert diese Links; ein Crawl deckt sie auf.

Google Search Console zeigt Googles Sicht auf das Ergebnis. Der Bericht „Page indexing“ kann Status wie „Page with redirect“ und „Redirect error“ anzeigen. „URL Inspection“ zeigt den von Ihnen angegebenen sowie den von Google ausgewählten kanonischen Wert – das hilft, wenn Google das erwartete Ziel nicht akzeptiert hat.

Bei einer einzelnen verdächtigen URL nutzen Sie im Browser die Network-Ansicht in den DevTools. Prüfen Sie jede Status- und Location-Antwort, bis die finale Seite geladen ist oder die Route fehlschlägt. Das ist schneller als ein Full Crawl, wenn Sie gerade nur eine Regel debuggen.

Priorisieren Sie Fixes in dieser Reihenfolge:

  1. Loopen entfernen, weil sie Seiten unerreichbar machen.
  2. Redirects reparieren, die in 4xx- oder 5xx-Antworten enden.
  3. Chains reduzieren, sodass alte URLs direkt auf finale Ziele zeigen.
  4. Irrelevante Redirects durch relevante Ziele oder echte 404/410-Antworten ersetzen.
  5. Interne Links aktualisieren, um Redirects zu umgehen.
  6. Bestätigen, dass permanente Moves auch mit permanentem Status umgesetzt sind.

Der SEO audit von SEOJuice macht Redirect Chains, kaputte Redirects und interne Links sichtbar, die auf Redirect-URLs zeigen – und liefert Ihnen damit eine praktische Liste zum Abarbeiten. Er schreibt nicht selbst Ihre nginx-, .htaccess-, CDN- oder CMS-Redirect-Regeln um; diese Änderungen gehören weiterhin in die Infrastruktur, die die Response steuert.

Eine Redirect-Checkliste für Site-Migrationen

Check Erwartetes Ergebnis
Jede wertvolle alte URL ist gemappt Jede URL verweist auf eine wirklich relevante Ersetzung
Perma-Moves verwenden 301 oder 308 Das Ziel erhält ein permanentes kanonisches Signal
Temporäre Moves verwenden 302 oder 307 Die ursprüngliche URL bleibt erwarteterweise kanonisch
Redirects nutzen nur einen Hop Die alte URL verweist direkt auf die finale URL
Protokoll- und Hostname-Varianten sind getestet Jede Variante löst zu genau einer kanonischen Version ohne Loops auf
Finale Ziele sind geprüft Kein Redirect endet auf einer 4xx- oder 5xx-Antwort
Interne Links sind aktualisiert Links zeigen direkt auf finale URLs
Gelöschte Seiten ohne Treffer werden klar behandelt Sie liefern 404 oder 410 statt eines irrelevanten Redirect

Behandeln Sie Redirects als Routing-Regeln – nicht als SEO-Zauberei. Wählen Sie ein relevantes Ziel, halten Sie fest, ob die Änderung permanent ist, und entfernen Sie vermeidbare Hops. Die meisten Redirect-Entscheidungen werden deutlich, sobald diese drei Punkte explizit geklärt sind.

Häufig gestellte Fragen

Was bedeutet „Redirecting“?

Redirecting bedeutet: Eine URL stellt nicht mehr ihren eigenen Content bereit und leitet stattdessen Besucher und Suchmaschinen an eine andere URL weiter. Ein serverseitiger Redirect gibt normalerweise einen 3xx-HTTP-Status plus die Zieladresse zurück, die der Browser automatisch anfordert.

Was ist der Unterschied zwischen einem 301- und einem 302-Redirect?

Eine 301 sagt: Die Änderung ist permanent – so kann Google das Ziel als kanonisch behandeln. Eine 302 sagt: Die Änderung ist temporär – dadurch bleibt Googles in der Regel die ursprüngliche URL im Index. Verwenden Sie eine 301, wenn die alte Seite nicht mehr zurückkommt, und eine 302, wenn sie zurückkommt.

Schaden Redirects dem SEO?

Richtig umgesetzte Redirects schaden dem SEO nicht zwangsläufig. Google empfiehlt serverseitige permanente Redirects für permanente Moves, und Gary Illyes hat gesagt, dass 30x-Redirects kein PageRank verlieren. SEO-Probleme entstehen durch Chains, Loops, kaputte Ziele, irrelevante Redirects sowie Statuscodes, die die falsche Absicht signalisieren.

Was ist eine Redirect Chain?

Eine Redirect Chain entsteht, wenn URL A zu URL B weiterleitet und URL B noch einmal zu URL C weiterleitet. Das erzeugt unnötige Requests und zusätzlicher Crawler-Aufwand. Beheben Sie das, indem Sie URL A direkt auf URL C zeigen lassen und interne Links auf die finale Adresse aktualisieren.

Was führt zu einem „too many redirects“-Fehler?

Eine Redirect Loop verursacht diesen Fehler. Zwei oder mehr Regeln schicken die Anfrage in einem Kreis weiter – oft weil HTTPS-, www-, Trailing-Slash-, serverseitige oder Meta-Refresh-Regeln miteinander im Konflikt stehen. Der Browser stoppt die Weiterleitung irgendwann innerhalb des Zyklus.

Wann sollte ich einen 307- oder 308-Redirect verwenden?

Verwenden Sie 307 für einen temporären Move und 308 für einen permanenten Move, wenn die ursprüngliche HTTP-Methode und der Request-Body erhalten bleiben müssen. Das ist besonders relevant für Formulare und API-Requests, die Methoden wie POST oder PUT nutzen. Für normale Content-Seiten, die per GET angefragt werden, bleiben 301 und 302 die üblichen Standardentscheidungen.