Sprachen

JavaScript-Weiterleitungen

Was eine JavaScript-Weiterleitung ist, wie Googles Rendering-Pipeline sie anders behandelt als eine serverseitige 301, wann sie ein akzeptabler letzter Ausweg ist und wie man eine implementiert und erkennt – plus wo Meta Refresh und die History API einzuordnen sind.

Erstveröffentlicht: 27. Juni 2026 · Zuletzt aktualisiert: 22. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Eine JavaScript-Weiterleitung sendet Nutzer und Crawler mit clientseitigem Code (window.location.replace() oder .href) an eine neue URL. Sie ist der am wenigsten zuverlässige Weiterleitungstyp, da Google sie erst nach dem Rendering sieht – was verzögert werden oder ganz fehlschlagen kann, ohne festen Zeitrahmen in beide Richtungen. Googles offizielle Präferenzreihenfolge ist serverseitig (301/302/307/308) → Meta Refresh → JavaScript, und die Dokumentation sagt klar: Verwenden Sie JS-Weiterleitungen nur, wenn Sie die anderen beiden nicht umsetzen können. Sobald Google eine erfolgreich interpretiert, wird das Ziel zu einem Kanonisierungssignal – aber das ist kein bewiesener Garant für identische PageRank- oder Ranking-Ergebnisse wie bei einer 301. Behandeln Sie JavaScript-Weiterleitungen daher als letzten Ausweg und nicht als gleichwertigen Ersatz. Nutzen Sie diesen Mechanismus auf eingeschränkten Plattformen ohne Serverzugriff, für SPA-Fehlerseiten, die auf eine echte 404 verweisen, und kaum sonst. Wenn der Einsatz unvermeidbar ist, setzen Sie window.location.replace() im <head> ein, entfernen Sie die Quell-URL aus Ihrer Sitemap und verlinken Sie intern auf das endgültige Ziel. Meta Refresh ist eine separate HTML-Ebene-Weiterleitung, und history.pushState()/replaceState() sind überhaupt keine Weiterleitungen.

TL;DR — Ein JavaScript-Redirect ist eine clientseitige Weiterleitung (window.location.replace(), .href, .assign()), die Google erst nach dem Rendering verarbeitet — Phase drei von Crawlen → Rendern → Indexieren. Ein serverseitiger 301 wird beim Crawlen erkannt; ein JS-Redirect wartet in der Render-Warteschlange, und Google gibt keinen festen Zeitrahmen für diese Wartezeit an — sie kann schnell sein oder lange dauern, und das Rendering kann komplett fehlschlagen. Die dokumentierte Präferenzreihenfolge von Google ist serverseitig → Meta-Refresh → JavaScript, und die Dokumentation besagt, JS-Redirects nur zu verwenden, wenn die anderen beiden nicht möglich sind. Sobald Google einen erfolgreich interpretiert, wird das Ziel zu einem permanenten Canonicalization-Signal — sogar Google selbst nutzte sie in ihrem eigenen Blog, als nichts anderes funktionierte — aber das ist kein dokumentierter Beweis für identische PageRank- oder Ranking-Ergebnisse wie bei einem 301, daher sind sie ein letzter Ausweg, kein Spam-Signal. Die legitimen Anwendungsfälle sind eingeschränkte Plattformen ohne Serverkonfiguration und SPA-Fehlerseiten, die auf eine echte 404 verweisen. Implementieren Sie mit window.location.replace() im <head>, entfernen Sie die Quelle aus Ihrer Sitemap, verweisen Sie interne Links um, und bestätigen Sie, dass Googlebot das JS abrufen kann. Meta-Refresh ist auf HTML-Ebene (0s = permanent, jede Verzögerung = temporär), und history.pushState()/replaceState() sind überhaupt keine Redirects.

Was als JavaScript-Redirect gilt

Skriptnavigation hängt von Rendering und Ausführung ab und ist daher nicht protokolläquivalent zu einem HTTP-Redirect. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript redirects Die Verarbeitung ist möglich, keine Garantie für exakte Zeitangaben oder Indexierung. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search

Ein JavaScript-Redirect navigiert den Browser mit clientseitigem Code zu einer neuen URL. Die gängigen Methoden und ihre Unterschiede:

  • window.location.replace("url") — navigiert und entfernt die ursprüngliche URL aus dem Verlauf der Sitzung. Dies ist die richtige Methode: Die Zurück-Taste überspringt die Redirect-Quelle, anstatt den Benutzer direkt zurückzubouncen.
  • window.location.href = "url" — navigiert, behält aber die ursprüngliche URL im Verlauf, sodass die Zurück-Taste zur weiterleitenden Seite zurückkehrt (und eine Schleife erzeugen kann). document.location.href und window.location.assign("url") verhalten sich gleich.
  • history.pushState() / history.replaceState() — keine Redirects. Sie überschreiben die Adressleiste ohne Navigation oder HTTP-Signal, daher behandeln Crawler sie nicht als Redirects. SPAs verwenden sie für In-App-URL-Änderungen; sie benötigen echte <a href>-Links (oder echte Navigationen), um crawlbar zu sein.

Die entscheidende Grenze: .replace(), .href und .assign() lösen alle eine echte Dokumentnavigation aus (der Unterschied besteht nur darin, was mit dem Sitzungsverlauf passiert), während pushState()/replaceState() nie navigieren — sie berühren nur den Verlaufszustand und die Adressleiste, sonst nichts. Keiner der vier ist ein HTTP-301; “Redirect” ist hier eine Abkürzung für clientseitige Navigation, kein Statuscode.

Meta-Refresh (<meta http-equiv="refresh" content="0;url=...">) wird oft mit JS-Redirects in einen Topf geworfen, ist aber eine HTML-Direktive, die vor der JavaScript-Ausführung geparst wird — eine separate, zuverlässigere Kategorie, die unten behandelt wird.

Wie Google einen JavaScript-Redirect verarbeitet

Das ist der Kernpunkt. Die Pipeline von Google läuft in Phasen ab, und ein JS-Redirect und ein serverseitiger Redirect werden in unterschiedlichen Phasen erfasst:

  1. Crawlen — Googlebot ruft die URL ab und liest das rohe HTML. Ein serverseitiger 301/302/307/308 wird genau hier erkannt.
  2. Render-Warteschlange — Seiten, die 200 zurückgeben, warten auf das Rendering. Die Dokumentation von Google weist darauf hin, dass die Seite “may stay on this queue for a few seconds, but it can take longer than that.” (Übersetzung) „Möglicherweise bleibt die Seite einige Sekunden in dieser Warteschlange, aber es kann auch länger dauern.“ Google veröffentlicht keinen festen Service-Level-Zeitplan darüber hinaus, behandeln Sie die Wartezeit also als unvorhersehbar — sie kann schnell sein oder sich hinziehen — anstatt eine bestimmte Anzahl von Tagen oder Wochen anzunehmen.
  3. Rendern + Indexieren — Headless-Chromium führt das JavaScript aus. Dies ist der erste Moment, in dem ein JS-Redirect existiert, soweit es Google betrifft.

Dieselbe Idee, die ich in Crawling und in JavaScript SEO darlege, gilt auch hier: Rendering ist ein separater Schritt vom Abrufen, und alles, was davon abhängt, erbt diese Verzögerung und dieses Risiko.

Und das Risiko ist real. Google: “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (Übersetzung) „Während Google versucht, jede URL zu rendern, die der Googlebot gecrawlt hat, kann das Rendering aus verschiedenen Gründen fehlschlagen. Das bedeutet: Wenn Sie eine JavaScript-Weiterleitung einrichten, könnte Google sie möglicherweise nie sehen, wenn das Rendering des Inhalts fehlgeschlagen ist.” (Google Search Central) Während des Zeitfensters, bevor die Weiterleitung verarbeitet wird – und für immer, falls das Rendering fehlschlägt – kann Google die leere Quellseite in seinem Index behalten.

Googles offizielle Präferenzreihenfolge

Die Redirects-Dokumentation legt eine Hierarchie von der zuverlässigsten zur am wenigsten zuverlässigen Methode fest:

  1. Serverseitige Weiterleitungen — 301/308 (dauerhaft), 302/307 (temporär). Am besten für alles geeignet: werden beim Crawlen erkannt, eindeutig.
  2. Meta-Refresh — auf HTML-Ebene. Ein 0-Sekunden-Meta-Refresh wird als dauerhafte Weiterleitung behandelt (wie ein 301); jeder verzögerte Meta-Refresh wird als temporär behandelt.
  3. JavaScript-Weiterleitungen — letzte Option.

Googles Worte: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (Übersetzung) „Verwenden Sie JavaScript-Weiterleitungen nur, wenn Sie keine serverseitigen oder Meta-Refresh-Weiterleitungen durchführen können.“ Dauerhafte Weiterleitungen geben das kanonische Signal an das Ziel weiter; temporäre behalten das Original in den Ergebnissen. (Wie das mit der Kanonisierungsauswahl zusammenspielt, erfahren Sie unter Canonicalization.)

Googles eigene Redirect-Dokumentation listet die JavaScript-Standortnavigation unter ihren permanenten Weiterleitungsmethoden auf und besagt, dass das Ziel zum Canonicalisierungssignal wird, sobald Google es interpretiert hat – die pauschale Behauptung “JS redirects don’t pass PageRank” (Übersetzung) „JS-Redirects geben keinen PageRank weiter“ ist also falsch. Was die Dokumentation nicht belegt, ist, dass das Ergebnis identisch, unmittelbar oder so zuverlässig wie ein serverseitiger 301 ist – sie beschreibt das kanonische Signal, keine Garantie für einen übereinstimmenden PageRank-Fluss, ein übereinstimmendes Ranking oder Timing. Die ehrliche Einordnung: Ein 301 gibt das Signal zum Crawl-Zeitpunkt mit nahezu absoluter Sicherheit weiter; ein JS-Redirect gibt es nur dann und nur dann weiter, wenn und sobald das Rendering gelingt, und Google verspricht nicht, dass das Ergebnis eins zu eins dem eines 301 entspricht. Diese Lücke – nicht verlorene Equity – sind die tatsächlichen Kosten der Wahl von JavaScript.

Dies ist auch der Grund, warum JS-Weiterleitungen für sich genommen keinen Strafauslöser darstellen. Sie werden erst dann zu einem Spam-Problem, wenn sie für Cloaking verwendet werden – wenn Crawlern eine Seite gezeigt wird und Nutzer auf etwas anderes weitergeleitet werden oder wenn Mobilnutzer auf eine nicht zusammenhängende Domain umgeleitet werden. Die Richtlinie von Google zu sneaky redirects bezieht sich auf diese Absicht, nicht auf die Technik selbst.

Wann ein JavaScript-Redirect das richtige Werkzeug ist

Es gibt legitime Fälle:

  • Eingeschränkte Plattformen. Einige Shared-Hosting-, CDN- oder CMS-Setups gewähren Ihnen keinen Zugriff auf serverseitige Weiterleitungsregeln. Eine JS-Weiterleitung ist ein gültiger Fallback – und bemerkenswerterweise verwendete Google JS-Weiterleitungen auf ihrem eigenen Webmaster-Blog, weil, wie Gary Illyes es ausdrückte, “that was the only thing we could use for 1:1 redirects, and it works on Google” (Übersetzung) „das war das Einzige, was wir für 1:1-Weiterleitungen verwenden konnten, und es funktioniert bei Google” (OnCrawl).
  • SPA-Fehlerbehandlung. Google befürwortet dies ausdrücklich: “Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code.” (Übersetzung) „Verwenden Sie eine JavaScript-Weiterleitung zu einer URL, für die der Server mit einem 404-HTTP-Statuscode antwortet.” (Google Search Central) Eine Single-Page-App, die eine ungültige Route auflöst, kann zu einem echten 404-Endpunkt weiterleiten, sodass Google den Fehler korrekt verarbeitet, anstatt einen Soft-404 zu indexieren.

Für dauerhafte URL-Weiterleitungen ist dies nicht das richtige Werkzeug – verwenden Sie einen 301. Denselben Punkt mache ich auch in Site-Migrationen: JavaScript-Weiterleitungen sind die letzte Option, und Google sieht sie möglicherweise nie.

Statische Site-Generatoren: Die Hugo-Aliase-Falle

Eine häufige Überraschung: Hugos aliases:-Frontmatter hat historisch gesehen Meta-Refresh-HTML-Seiten generiert, keine serverseitigen 301er – und andere statische Generatoren haben ähnliche Dinge standardmäßig getan. Die Generator-Standardeinstellungen ändern sich zwischen Versionen, also überprüfen Sie die tatsächliche Ausgabe Ihrer aktuell bereitgestellten Version, anstatt Annahmen zu treffen; wenn aliases: Ihnen keine 301er liefert, benötigen Sie Redirect-Regeln auf Plattformebene (Netlify _redirects, Cloudflare Workers, Vercel vercel.json) plus (bei Hugo) disableAliases: true. Ich behandle dies detailliert in Hugo SEO.

Best Practices für die Implementierung

Wenn ein JavaScript-Redirect wirklich Ihre einzige Option ist:

  • Verwenden Sie window.location.replace(), nicht .href. Wie Search Engine Journal es ausdrückt, JS-Redirects “typically use window.location.replace() function rather than window.location.href to avoid UX redirect loops” (Übersetzung) „verwenden typischerweise die Funktion window.location.replace() anstelle von window.location.href, um UX-Redirect-Schleifen zu vermeiden“ (SEJ).
  • Platzieren Sie es im <head>, nicht im <body>. Browser parsen HTML sequenziell und führen Skripte aus, sobald sie darauf stoßen, daher “position JavaScript redirects in the <head> tag rather than <body> to minimize delay” (Übersetzung) „platzieren Sie JavaScript-Redirects im <head>-Tag anstelle von <body>, um Verzögerungen zu minimieren“ (OnCrawl).
  • Leiten Sie in einem Sprung zum endgültigen Ziel weiter. Ein JS-Redirect auf eine Seite, die selbst anderswohin 301t, erzeugt eine Kette; Ketten verschwenden Crawl-Budget und können in der GSC als Redirect-Fehler auftauchen.
  • Entfernen Sie die Quell-URL aus Ihrer XML-Sitemap. Sitemaps sollten kanonische, indexierbare URLs auflisten – keine weiterleitenden.
  • Richten Sie interne Links auf das Ziel aus, damit sie den Redirect gar nicht erst durchlaufen.
  • Stellen Sie sicher, dass Googlebot das JS abrufen kann. Wenn der Redirect in einem externen Skript lebt, das durch robots.txt blockiert wird, kann Google es nicht rendern und den Redirect nicht sehen.

So erkennen Sie JavaScript-Redirects

Sie kündigen sich nicht wie ein 301 in einem Header an, also müssen Sie rendern:

  • Ein Crawler mit aktiviertem JS-Rendering. OnCrawl empfiehlt, mit “JavaScript rendering enabled (5-second timeout minimum)” zu crawlen; (Übersetzung) „JavaScript-Rendering aktiviert (mindestens 5 Sekunden Timeout)“; Screaming Frog und Ahrefs Site Audit können beide rendern. Ohne Rendering sieht eine Seite mit JS-Redirect einfach wie ein normaler 200 aus.
  • Chrome DevTools. Der Netzwerk-Tab (mit „Protokoll beibehalten“) zeigt die clientseitige Navigation; die Redirect Path-Erweiterung kennzeichnet sie ebenfalls.
  • In der Search Console erscheint ein erfolgreich verarbeiteter JS-Redirect unter Seite mit Redirect – derselbe Status wie bei jeder weitergeleiteten URL, was für nicht-kanonische Quellen normal ist. Diese Bezeichnung ist bei einer bestimmten Prüfung jedoch nicht garantiert: Sie spiegelt wider, was Google zu dem Stichprobenzeitpunkt abgerufen, gerendert, interpretiert und kanonisiert hat, sodass eine URL zwischen Prüfungen einen anderen Status (oder noch keinen Redirect-Status) zeigen kann, ohne dass dies ein Fehler auf Ihrer Seite ist.

Was ich tatsächlich tun würde

Serverseitig zuerst, jedes Mal. Meta-Refresh (0 Sekunden), wenn Sie HTML bearbeiten können, aber keine Serverkonfiguration. JavaScript nur, wenn beides nicht in Frage kommt – und dann mit window.location.replace() im <head>, einer sauberen Sitemap und einer Überprüfung, dass der Redirect für Googlebot tatsächlich rendert. Für alles Dauerhafte oder Hochwertige ist die zusätzliche Zuverlässigkeit eines 301 fast jede Mühe wert.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.