JavaScript-Weiterleitung und Meta-Refresh im SEO

Eine Weiterleitung per JavaScript oder Meta-Refresh kann Rankings übertragen, aber sie ist der unsicherere Weg. Google kann beide Varianten verarbeiten, braucht dafür jedoch im Fall von JavaScript einen Rendering-Schritt und wertet die Signale weniger eindeutig als einen HTTP-Statuscode. Ein Meta-Refresh ohne Verzögerung gilt nach Googles Dokumentation als dauerhafte Weiterleitung, einer mit Wartezeit dagegen als vorübergehende.

Dieser Beitrag klärt die Situation, in der du keine serverseitige Lösung bekommst: ein Baukasten ohne Zugriff auf die Serverkonfiguration, ein statisches Hosting ohne Regelwerk, eine Single-Page-App oder ein Altsystem, das sich nicht anfassen lässt. Es geht nicht um die Frage, wann 301 und 302 richtig sind, sondern darum, was mit deinen Rankings passiert, wenn die Weiterleitung erst im Browser stattfindet, und wann das als Fallback vertretbar ist.

Was bei einer clientseitigen Weiterleitung technisch passiert

Bei einer serverseitigen Weiterleitung antwortet der Server auf die Anfrage mit einem Statuscode wie 301 und einem Location-Header. Der Crawler muss die Antwort nicht einmal auslesen, der Header genügt. Bei einer clientseitigen Weiterleitung sieht die Sache anders aus: Der Server liefert eine ganz normale Seite mit dem Status 200 aus, und erst der Inhalt dieser Seite schickt den Besucher weiter.

Für Google heißt das: Die alte URL antwortet erfolgreich, enthält aber die Anweisung, woanders hinzugehen. Der Bot muss die Seite also laden, das HTML auswerten und im Fall von JavaScript zusätzlich warten, bis die Seite gerendert wurde. Erst danach steht fest, dass eine Weiterleitung vorliegt. Das kostet Zeit und Crawling-Budget und führt dazu, dass die Zielseite später entdeckt und die Signale später übertragen werden.

Es gibt drei Formen, die in der Praxis vorkommen. Die erste ist das Meta-Element mit dem Attribut http-equiv=refresh im Kopfbereich der Seite. Die zweite ist ein Skript, das die Adresse des Fensters ändert, etwa mit window.location.href oder window.location.replace. Die dritte, seltener, ist ein HTTP-Header namens Refresh, den der Server mitsendet. Sie verhält sich ähnlich wie das Meta-Element, wird aber oft übersehen, weil sie in keinem Quelltext auftaucht.

Meta-Refresh mit Verzögerung 0 oder mehr

Ein Meta-Refresh besteht aus einer Zeitangabe in Sekunden und einer Ziel-URL. Die Zahl entscheidet darüber, wie Google die Weiterleitung einordnet. Nach der Dokumentation zu Weiterleitungen behandelt Google einen sofortigen Meta-Refresh, also mit der Verzögerung 0, als dauerhafte Weiterleitung. Ein Meta-Refresh mit Verzögerung wird als vorübergehende Weiterleitung gewertet.

Das ist der Kern der Antwort auf die Frage, wann Google so etwas wie eine 301 sieht: bei einem sofortigen Meta-Refresh, der im HTML steht, ohne dass ein Skript nötig ist. Weil das Element direkt im Quelltext liegt, kann Google es ohne Rendering erkennen. Das ist der Grund, warum diese Variante unter den clientseitigen Methoden die verlässlichste ist.

Bei einer Wartezeit von fünf oder zehn Sekunden sieht es anders aus. Nutzer erleben die alte Seite kurz, oft mit dem Hinweis, man werde gleich weitergeleitet. Suchmaschinen lesen das als vorübergehend, und genau so verhalten sich dann auch die Signale: Die alte URL kann im Index bleiben, und die Übertragung von Rankings verläuft zögerlicher als bei einer dauerhaften Weiterleitung. Zusätzlich gilt ein Countdown als schlechte Nutzererfahrung und fällt bei Zugänglichkeitsprüfungen auf, weil sich die Seite unerwartet verändert.

Wichtig ist auch, was nicht passiert: Ein Meta-Refresh ersetzt keinen sauberen Statuscode, und er erzeugt keinen Header. Tools, die nur HTTP-Antworten prüfen, zeigen für die alte URL weiterhin ein 200. Wer mit einem Crawler eine Migration kontrolliert, sieht diese Fälle deshalb nur, wenn er HTML und Rendering mit auswertet.

• Verzögerung 0 im Meta-Refresh: wird von Google als dauerhafte Weiterleitung behandelt und braucht kein Rendering.
• Verzögerung größer als 0: wird als vorübergehend eingeordnet und ist zudem ein Nutzbarkeitsproblem.
• Die alte URL liefert in beiden Fällen den Status 200, nicht 301 oder 302.

JavaScript-Weiterleitung mit window.location

Eine JavaScript-Weiterleitung setzt voraus, dass Google das Skript ausführt. Die Dokumentation nennt sie als mögliche Methode, rät aber ausdrücklich dazu, serverseitige Weiterleitungen zu bevorzugen, sobald sie möglich sind. Der Ablauf bei Google ist zweistufig: Zuerst wird das HTML geladen, dann kommt die Seite in die Rendering-Warteschlange. Erst nach dem Rendern sieht Google, dass window.location gesetzt wurde, und folgt der neuen Adresse.

Daraus folgen mehrere Konsequenzen. Erstens dauert es länger, bis die Weiterleitung greift. Zweitens hängt alles daran, dass das Skript für den Bot erreichbar ist: Wenn die JavaScript-Datei in der robots.txt gesperrt ist, sieht Google die Weiterleitung nie und indexiert die alte Seite mit ihrem dünnen Inhalt. Drittens lässt sich aus dem Code nicht ablesen, ob die Weiterleitung dauerhaft gemeint ist. Es gibt keinen Statuscode, der das ausdrücken würde, und Google muss aus dem Kontext schließen.

Auch bei der Schreibweise gibt es Unterschiede. Mit window.location.replace ersetzt die neue Adresse den Eintrag im Browserverlauf, sodass der Zurück-Button nicht in eine Schleife führt. Mit window.location.href bleibt die alte Seite im Verlauf, und wer zurückgeht, landet sofort wieder beim Skript. Für Suchmaschinen ist das unerheblich, für Besucher ein spürbarer Unterschied.

Ein weiterer Fallstrick sind Weiterleitungen, die erst nach einem Ereignis feuern, etwa nach einem Klick, nach dem Laden einer Bibliothek oder nach einer Verzögerung per setTimeout. Der Renderer wartet nicht beliebig lange. Was erst nach Sekunden oder nach einer Interaktion geschieht, kann Google verpassen.

Was mit Rankings, Linkkraft und Index passiert

Kurz gefasst: Die Signale können übertragen werden, aber zuverlässig und schnell geschieht das nur bei einem sofortigen Meta-Refresh und mit Einschränkungen bei JavaScript. Eine konkrete Prozentzahl für den Verlust gibt es nicht, und du solltest jedem Wert misstrauen, der dir eine nennt. Was sich beschreiben lässt, sind die Mechanismen.

Beim Index ist der erste Effekt eine Verzögerung. Solange Google die Weiterleitung nicht verarbeitet hat, bleibt die alte URL mit ihrem Inhalt sichtbar, und die neue wird erst später als Ersatz erkannt. Bei einer Migration vieler Seiten kann sich das über einen deutlich längeren Zeitraum ziehen als bei Statuscodes, weil jede Seite erst gerendert werden muss.

Bei der Linkkraft gilt dasselbe: Externe Verweise zeigen auf die alte Adresse, und die Übertragung hängt davon ab, dass Google die Beziehung zwischen beiden Adressen versteht. Eine verzögerte oder als vorübergehend gelesene Weiterleitung schwächt dieses Verständnis. Hinzu kommt, dass andere Suchmaschinen und Crawler, etwa die von Social-Media-Plattformen und Vorschau-Diensten, JavaScript oft gar nicht ausführen. Für sie existiert die Weiterleitung nicht, und sie zeigen die Inhalte der alten Seite an.

Ein häufiger Irrtum ist, die Zielseite lasse sich durch ein Canonical-Tag auf der alten Seite ersetzen. Ein Canonical ist ein Hinweis und keine Weiterleitung, und es löst das Problem der Besucher nicht. Kombiniert mit einem sofortigen Meta-Refresh und identischen Zielangaben kann es die Absicht allerdings unterstützen, solange beide Signale dieselbe Adresse nennen.

Wann die Notlösung vertretbar ist

Es gibt Fälle, in denen eine clientseitige Weiterleitung die einzige praktikable Möglichkeit ist, und dann ist sie besser als gar keine. Sie ist vertretbar, wenn du wirklich keinen Zugriff auf Serverkonfiguration, Hosting-Regeln oder eine Weiterleitungsfunktion der Plattform hast und wenn die Zahl der betroffenen Seiten überschaubar ist.

Typische Beispiele sind einfache Baukasten-Systeme, die nur Weiterleitungen auf Seitenebene über ein Feld im Kopfbereich erlauben, statische Seiten auf einem Speicherdienst ohne Regelwerk und Altseiten auf Fremdsystemen, bei denen du nur den Inhalt, nicht die Konfiguration kontrollierst. In solchen Fällen ist der sofortige Meta-Refresh die erste Wahl, weil er ohne Skript funktioniert und von Google als dauerhaft verstanden wird.

Nicht vertretbar ist die Notlösung bei größeren Migrationen, bei Domainumzügen, bei einem Wechsel von HTTP auf HTTPS oder bei Seiten mit vielen externen Verlinkungen. Dort lohnt es sich, zuerst zu klären, ob ein Wechsel des Hostings oder ein vorgeschalteter Dienst die saubere Lösung ermöglicht. Die Kosten einer verzögerten Übertragung stehen in keinem Verhältnis zum Aufwand einer richtigen Konfiguration.

• Geeignet: einzelne Seiten, fehlender Serverzugriff, kurzfristige Überbrückung, sofortiger Meta-Refresh.
• Ungeeignet: Domainumzug, Protokollwechsel, Massenmigration, stark verlinkte Seiten.
• Zeitlich begrenzen: Die Notlösung sollte ein Ablaufdatum haben und später durch einen Statuscode ersetzt werden.

So setzt du die Fallback-Lösung sauber um

Wenn es nicht anders geht, halte dich an eine feste Reihenfolge. Beginne mit dem sofortigen Meta-Refresh im Kopfbereich der alten Seite, mit der Zeit 0 und der vollständigen Ziel-URL. Ergänze einen Canonical-Link auf dieselbe Zielseite und einen sichtbaren Textlink, damit Nutzer und Bots auch dann weiterkommen, wenn die automatische Weiterleitung blockiert wird. Nutze eine einzige Methode pro Seite: Wer Meta-Refresh und Skript mischt, riskiert doppelte Sprünge und Schleifen.

Verwende eine JavaScript-Weiterleitung nur, wenn das Meta-Element nicht möglich ist, etwa weil die Weiterleitung von einer Bedingung abhängt. Dann gilt: Skript ohne Verzögerung beim Laden ausführen, nicht hinter einem Ereignis verstecken, in der robots.txt nicht sperren und window.location.replace statt href einsetzen. Das Ziel muss eine absolute URL sein, die selbst mit dem Status 200 antwortet und nicht ihrerseits weiterleitet.

Prüfe danach mit der URL-Prüfung in der Search Console, was Google sieht. Das Werkzeug zeigt im gerenderten HTML, ob die Seite als weitergeleitet erkannt wurde, und nennt die Google-ausgewählte Canonical-URL. Lass die Seiten außerdem mit einem Crawler laufen, der JavaScript rendert, und vergleiche das Ergebnis mit einem Lauf ohne Rendering. Unterschiede zeigen dir, welche Weiterleitungen nur mit Skript funktionieren.

Schließlich gehören die Links dazu: Aktualisiere interne Verweise, Sitemaps und Navigation auf die neue Adresse, damit die Weiterleitung nur noch für externe Zugriffe gebraucht wird. Jede interne Verlinkung, die weiterhin die alte URL nennt, erzeugt unnötige Umwege und verlängert die Ladezeit.

Ein Beispiel aus der Praxis: Umzug einer Handvoll Seiten

Angenommen, ein kleiner Verein betreibt seine Seite mit einem Baukasten, der keine serverseitigen Weiterleitungen anbietet. Fünf Ratgeberseiten sollen unter neuen Adressen erscheinen, weil die Verzeichnisstruktur aufgeräumt wird. Die alten Seiten bleiben bestehen und enthalten nur noch den Meta-Refresh mit der Zeit 0, einen Canonical-Link auf die neue Adresse und einen kurzen Satz mit Textlink. Alle internen Links und die Sitemap zeigen sofort auf die neuen URLs.

In diesem Szenario ist das Risiko klein: wenige Seiten, sofortiger Meta-Refresh, eindeutige Ziele. Nach einigen Wochen kontrolliert der Betreiber in der Search Console, ob die neuen Adressen indexiert sind und die alten aus den Ergebnissen verschwinden. Würde derselbe Verein dagegen zweihundert Seiten verschieben, sollte er vorher klären, ob ein Anbieterwechsel oder ein vorgeschalteter Dienst serverseitige Regeln erlaubt.

Ein ähnlicher Fall ist eine Single-Page-App, in der das Routing im Browser erfolgt. Dort erzeugt eine Weiterleitung im Router zwar einen Seitenwechsel, aber keinen Statuscode. Wer entfernte Seiten sauber behandeln will, muss dafür sorgen, dass der Server beim ersten Abruf die richtige Antwort sendet, und darf sich nicht allein auf das Skript verlassen.

Typische Fehler bei clientseitigen Weiterleitungen

Der häufigste Fehler ist eine Weiterleitung auf die Startseite. Wer alte Seiten per Skript pauschal auf die Startseite schickt, erzeugt aus Sicht von Google eine Art Soft-404: Der Inhalt der alten Seite hat keine Entsprechung, und die Signale verpuffen. Die Zielseite sollte thematisch zur alten Seite passen.

Ein zweiter Fehler sind Ketten. Eine clientseitige Weiterleitung, die auf eine serverseitige zeigt, die wiederum auf eine weitere Adresse führt, verlängert den Weg und verzögert die Verarbeitung. Der Renderer folgt nicht unbegrenzt vielen Sprüngen. Die beste Lösung ist immer der direkte Weg vom Ursprung zum Ziel.

Drittens wird vergessen, dass Weiterleitungen nach Nutzerverhalten, etwa nach Land, Sprache oder Gerät, per Skript für Bots anders aussehen können. Wenn ein Crawler ohne Standort oder Cookies eine andere Seite zu sehen bekommt als ein Besucher, entstehen Missverständnisse, die im schlimmsten Fall als Cloaking wirken. Eine Weiterleitung, die nur Besucher betrifft und dem Bot etwas anderes zeigt, sollte deshalb vermieden werden.

Viertens bleiben Überbleibsel stehen. Oft wird eine Notlösung eingerichtet und nie ersetzt. Plane deshalb im Redaktions- oder Entwicklungsablauf eine Wiedervorlage ein, damit aus dem Provisorium nicht dauerhaft die Standardlösung wird.