2021 wurde ich herangezogen, um eine 400-Seiten-E-Commerce-Website zu überprüfen, die sich sechs Monate zuvor migriert hatte. Der Traffic war um 38 % gesunken und der Client konnte nicht herausfinden, warum. Der Entwickler, der die Migration durchgeführt hatte, hatte durchgehend 302 Redirects verwendet, auf jede einzelne alte URL, weil er das „schon mal funktionieren gesehen hatte". Die Domain Authority der Website war intakt. Die Backlinks waren noch da. Aber Googlebot behandelte die alten Seiten als vorübergehend verschoben, hielt die Link Equity in der Schwebe, wartete darauf, ob die ursprünglichen URLs möglicherweise zurückkommen könnten. Sechs Monate lang. Es ist eine schmerzhafte Lektion, jemandem beim Lernen zuzusehen.
Das ist das Ding mit Redirect-Typen: Für einen Nutzer, der auf einen Link klickt, sehen sie identisch aus. Der Browser bringt dich in beiden Fällen von A nach B. Aber für Suchmaschinen ist der Unterschied signifikant genug, um eine Migration zu ruinieren, wenn du es falsch machst.
Was diese beiden Redirect-Codes wirklich bedeuten
Auf der HTTP-Protokoll-Ebene teilt ein 301 dem Client (Browser, Googlebot, Bingbot, was auch immer) mit, dass die Ressource permanent an einen neuen Ort verschoben wurde. Ein 302 sagt, dass sie vorübergehend verschoben wurde. Das ist es. Das ist der ganze Unterschied auf Spezifikationsebene.
Aber die SEO-Implikationen downstream sind, wo es interessant wird.
Mit einer 301 konsolidiert Google die Signale (Backlinks, Seitenautorität, Crawl-Priorität) von der alten URL auf die neue. Mit einer 302 soll Google die ursprüngliche URL indexiert halten, da der Umzug temporär ist. In der Praxis ist Google über die Jahre hinweg intelligenter geworden, und Googles eigene Dokumentation räumt ein, dass Googlebot "möglicherweise" auch Signale von 302s transferiert, letztendlich. Aber "möglicherweise" und "letztendlich" sind keine Worte, auf die ich die Einnahmen eines Kunden setzen möchte.
Die Link-Equity-Frage
Der Link-Equity-Transfer von 301s ist auch nicht sofort. Es dauert normalerweise mehrere Crawl-Zyklen, was je nach Crawl-Budget und Domain-Größe Tage oder Wochen sein kann. Für eine brandneue Ziel-URL ohne bestehende Autorität ist diese Konsolidierung enorm wichtig. Ich habe Seiten gesehen, die ihre Traffic-Level vor der Migration innerhalb von 6-8 Wochen wiedererlangt haben, nachdem falsche 302s zu 301s korrigiert wurden, nur durch das Ausführen einer korrigierten .htaccess-Datei und das Erzwingen eines erneuten Crawl über Google Search Console.
Wann man eine 301-Umleitung verwendet
Verwende eine 301 immer dann, wenn der Umzug wirklich dauerhaft ist. Einige konkrete Szenarien:
- Du migrierst von HTTP zu HTTPS (jede einzelne Umleitung hier sollte eine 301 sein)
- Eine Seite wurde gelöscht und du leitest die URL auf ihren nächstgelegenen relevanten Ersatz weiter
- Du hast deine Permalink-Struktur in WordPress geändert (das trifft viele Leute)
- Du konsolidierst zwei Domains in einer nach einer Fusion oder einem Rebrand
- Ein Produkt wird eingestellt und du leitest auf die Kategorieseite weiter
Bei einer WooCommerce-Migration, die ich Ende 2022 für einen Fashion-Retailer durchgeführt habe, gab es etwa 800 alte Produkt-URLs, die auf die neue URL-Struktur umgeleitet werden mussten. Jede einzelne bekam einen 301 über das Redirection Plugin mit Regex-Matching für das Muster. Das hat etwa zwei Stunden dauert, um es sauber einzurichten. Die Alternative – es manuell zu machen oder 302er zu nutzen, „nur zum Testen" – hätte ihnen Monate Recovery-Zeit gekostet.
Die HTTPS-Migrations-Falle
Genau diese hier. Ich sehe immer noch Entwickler, die HTTP-zu-HTTPS-Migrationen machen und 302er verwenden, weil sie „erst das SSL testen" möchten. Das nicht. Wenn das Zertifikat installiert und funktionsfähig ist, gehen Sie direkt zu 301ern. Der 302-Ansatz bei HTTPS-Migrationen ist einer der häufigsten Gründe für die gefürchteten „Duplicate Content"-Flags in Google Search Console, weil Googlebot beide Versionen zeitweise indexieren kann.
Wann man einen 302 Redirect nutzt
Deutlich weniger Fälle als die meisten Leute denken. Ein 302 ist angebracht, wenn:
- Sie A/B-Tests auf einer Seite laufen lassen und die Original-URL ihre Ranking-Signale während des Tests behalten soll
- Sie eine temporäre Werbekampagne laufen lassen (eine kurzfristige Landing Page, die für Black Friday beispielsweise Ihre Homepage ersetzt)
- Sie Wartungsarbeiten durchführen und Nutzer für ein paar Stunden auf eine Status-Seite leiten
- Sie Nutzer geo-spezifisch zu lokalisierten Versionen einer Seite umleiten müssen, ohne das permanent zu machen
Das Letzte verdient ein längeres Verweilen. Wenn Sie UK-Besucher zu /en-gb/ und US-Besucher zu /en-us/ umleiten, sollten das 302er sein, weil keine einzelne Nutzergruppe die kanonische URL „besitzt". Google behandelt Geo-Targeting ohnehin separat durch hreflang, aber der 302 signalisiert, dass die Original-URL immer noch das kanonische Ziel ist.
Seahawk hatte letztes Jahr einen SaaS-Kunden mit einer 30-Tage-Gratis-Test-Promotion. Die Startseite wurde vorübergehend auf eine /free-trial/-Landingpage umgeleitet. Sie wählten 302. Das war richtig. Nach der Kampagne sollte die Startseite ihre Rankings sofort zurückbekommen. Mit einer 301 wäre das problematisch geworden: Die Signals hätten sich auf /free-trial/ konzentriert, einer Seite, die danach komplett gelöscht wurde.
Der Mythos „Google behandelt 302er wie 301er"
Das hast du wahrscheinlich irgendwo gelesen. Und es steckt ein Körnchen Wahrheit darin. Google kann in bestimmten Situationen eine lange bestehende 302 ähnlich wie eine 301 behandeln, besonders wenn die Ziel-URL über einen langen Zeitraum konsistent gleich bleibt. John Mueller hat das in verschiedenen Google Search Central Office-Hours-Sessions erwähnt.
Aber hier ist der Punkt: Das ist Google, das Entwickler-Fehler verzeiht, keine Funktion, die du einplanen solltest. Bing verhält sich nicht auf die gleiche Weise. Und dich auf Googles Großzügigkeit bei etwas so Wichtigem wie einer Domain-Migration zu verlassen ist einfach nur schlampige Arbeit. Nutze das richtige Werkzeug.
So prüfst du, welche Art von Umleitung du hast
Falls du nicht sicher bist, was auf einer Website gerade live ist, gibt es ein paar schnelle Möglichkeiten, das zu prüfen.
Am schnellsten: Öffne dein Terminal und führe curl -I https://example.com/old-page aus. Achte auf HTTP/1.1 301 oder HTTP/1.1 302 in den Response-Headern. Dauert fünf Sekunden.
Für größere Audits nutze ich Screaming Frog SEO Spider. Exportiere dein Crawl, filtere nach Response-Code 3xx, und du siehst jede Umleitung auf der Website. Was für einen Typ es ist, auch. Das mache ich standardmäßig bei jedem Site-Audit bei Seahawk, bevor wir etwas ändern. Die kostenlose Version handhabt bis zu 500 URLs — für viele kleinere Websites völlig ausreichend.
Speziell für WordPress hat das Redirection-Plugin ein integriertes Log, das dir jede Umleitung in Echtzeit anzeigt, einschließlich des Response-Codes. Wirklich nützlich, um nach einer Migration etwas Merkwürdiges zu erwischen.
Umleitungsketten: Das Problem, über das niemand genug spricht
Eine 301 auf eine andere 301, die auf die finale URL zeigt. Das ist eine Redirect-Kette, und sie passiert ständig auf Sites, die mehrere Migrationen oder CMS-Wechsel durchgemacht haben. Jeder Hop in der Kette schwächt die Weitergabe der Link-Equity leicht ab und kostet Crawl-Budget.
Die Regel, die ich befolge: Wenn Screaming Frog eine Kette mit mehr als einer Weiterleitung anzeigt, behebe ich das. Weise die erste URL direkt auf das endgültige Ziel. Das gilt für 301- und 302-Ketten.
Redirects korrekt implementieren
Hängt von deinem Stack ab, aber die häufigsten Szenarien sind:
Apache (.htaccess): `` Redirect 301 /old-page https://www.example.com/new-page ``
Nginx: `` return 301 https://www.example.com/new-page; ``
WordPress (via Redirection-Plugin): Stelle das HTTP-Code-Feld explizit auf 301. Das Plugin standardmäßig auf 301, aber ich habe schon gesehen, dass es durch andere Plugins oder Importe geändert wird, also überprüfe es immer nochmals.
Cloudflare Page Rules: Du kannst Weiterleitungsregeln auf der CDN-Ebene mit expliziten 301- oder 302-Statuscodes setzen. Nützlich für siteweite Redirects, bevor die Anfrage deinen Server überhaupt erreicht.
Ein Punkt noch: Nach der Implementierung eines Redirects mit curl oder dem HTTP Status Checker Tool verifizieren. Klick nicht einfach im Browser auf den Link. Browser cachen Redirects aggressiv, und du wirst denken, es funktioniert, während der Server für First-Time-Visitor tatsächlich etwas anderes zurückgibt.
Was mit Backlinks passiert, die auf Weitergeleitete URLs zeigen
Kurze Antwort: Ein 301 wird im Laufe der Zeit den Linkwert zur Ziel-URL konsolidieren. Aber die Backlinks selbst verschwinden nicht und werden nicht automatisch aktualisiert. Sie zeigen immer noch auf die alte URL. Der Redirect teilt Google mit, dass es den Wert dieser Links mit dem neuen Ziel verknüpfen soll.
Deshalb ist es katastrophal, deine Permalink-Struktur zu ändern, ohne 301s einzurichten. Jeder Backlink, den du je für /blog/post-name/ erworben hast, wird wertlos, wenn diese URL jetzt statt zu /articles/post-name/ umzuleiten mit einem 404 antwortet.
Ich habe 2020 eine Content-Website überprüft, die das WordPress-Theme gewechselt hatte, und das neue Theme hatte eine andere URL-Struktur eingebaut. Es waren keine Redirects eingerichtet worden. Sie hatten Linkequity bei etwa 200 Artikeln über Nacht verloren. Laut Ahrefs-Daten behält auch ein gut umgesetzter 301-Redirect irgendwo zwischen 90–99 % der Linkequity, wobei Google keine offizielle Zahl veröffentlicht hat. Das Wichtigste ist: Selbst ein unvollkommener 301 schlägt einen 404 um ein Vielfaches.
FAQ
Gibt ein 301-Redirect 100 % der Linkequity weiter?
Nein, und das hat er wahrscheinlich noch nie getan. Google hat historisch gesehen vorgeschlagen, dass es durch einen Redirect einen kleinen PageRank-Verlust gibt. Die alte genannte Zahl war etwa 15 % Verlust, aber Google hat das inzwischen etwas relativiert. Ahrefs und Moz schätzen beide, dass der Verlust bei einem sauberen einzelnen 301 minimal ist. Was dich schadet, sind Ketten, Schleifen oder die Verwendung eines völlig falschen Redirect-Typs.
Kann ich einen 301-Redirect später so ändern, dass er woanders hinweist?
Ja. Ein 301 ist eine serverseitige Anweisung, nicht etwas, das dauerhaft in Googles Index eingebettet ist. Du kannst das Ziel jederzeit aktualisieren. Google übernimmt das neue Ziel bei seinem nächsten Crawl. Das „Permanent" im 301 bedeutet permanente Absicht zum damaligen Zeitpunkt, nicht dass es technisch unveränderbar ist.
Wie lange braucht Google, um einen 301-Redirect zu verarbeiten?
Bei hochautoritativen Websites mit häufigem Crawling manchmal innerhalb von ein oder zwei Tagen. Bei kleineren Websites kann es mehrere Wochen dauern. Das Einreichen der neuen URLs über das URL-Inspektionstool in Google Search Console und die Anforderung der Indexierung beschleunigt dies erheblich. Das mache ich standardmäßig bei jeder Migration.
Sollte ich jede alte URL umleiten oder nur die wichtigen?
Jede URL, die Backlinks, indexierten Traffic oder interne Links hat, sollte eine ordnungsgemäße 301-Umleitung bekommen. Für Seiten ohne Links und ohne indexierten Traffic ist eine 404 tatsächlich in Ordnung. Erstelle keine Umleitungs-Bloat, indem du wirklich tote URLs umleitest, die nie einen Wert hatten.
Wie sieht es mit JavaScript-Umleitungen aus? Werden diese gleich behandelt?
Nein. JavaScript-Umleitungen (mit window.location) werden von Googlebot viel langsamer verarbeitet, da sie JavaScript-Rendering erfordern. Sie sind auch inkonsistent bei anderen Crawlern. Für alles, das SEO-relevant ist, nutze serverseitige Umleitungen. Immer.
---
Der Umleitungstyp ist eine dieser Sachen, die trivial aussieht, bis sie es nicht mehr ist. Ich habe Stunden in Gesprächen damit verbracht, Clients zu erklären, warum ihr Traffic sechs Monate nach einer Migration gesunken ist, und bin auf die Entscheidung eines Entwicklers zurückgestoßen, 302s zu nutzen, weil es „sicherer" sei. Das ist nicht sicherer. Wähle den richtigen Typ, halte die Ketten kurz und verifiziere mit etwas anderem als deinem Browser.