Ist eine Meta-Refresh-Weiterleitung schlecht für SEO?

Nicht unbedingt. Google behandelt einen sofortigen Meta Refresh wie eine permanente Weiterleitung. Trotzdem ist er langsamer als ein 301 und wird nicht von jedem Bot verstanden. Nutz ihn nur, wenn du keine serverseitige Weiterleitung einrichten kannst.

Welche Verzögerung sollte ein Meta Refresh haben?

Null. Google wertet einen sofortigen Meta Refresh als permanent, einen verzögerten als temporär. Eine Verzögerung lässt Nutzer außerdem warten und ist ein Barrierefreiheitsproblem. Willst du vorher eine Nachricht anzeigen, ist ein sichtbarer Link die bessere Lösung.

Folgt Google JavaScript-Weiterleitungen?

Ja, sobald die Seite gerendert wird. Das kann später als das Crawlen passieren und auch fehlschlagen, deshalb empfiehlt Google JavaScript-Weiterleitungen nur als letzten Ausweg. Viele andere Crawler und Tools führen überhaupt kein JavaScript aus.

Kann ich einen Meta Refresh mit einem 301 kombinieren?

Das ist unnötig. Eine 301-Antwort wird nicht als Seite dargestellt, der Browser bekommt ein Meta-Tag darin also nie zu sehen. Wenn du einen 301 schicken kannst, tu das und entfern den Meta Refresh – sonst entsteht womöglich ein zusätzlicher Hop.

Meta-Refresh- und JavaScript-Weiterleitung: SEO-Ratgeber

Nicht jede Weiterleitung passiert auf dem Server. Auch ein Meta-Refresh-Tag oder eine Zeile JavaScript kann Besucher auf eine andere URL schicken. Hier erfährst du, wie diese clientseitigen Weiterleitungen funktionieren, wie Google mit ihnen umgeht und warum sie nur die Notlösung sein sollten.

Serverseitige vs. clientseitige Weiterleitung

Bei einer normalen serverseitigen Weiterleitung (301, 302, 307, 308) beantwortet der Server die Anfrage mit einem 3xx-Statuscode und einem Location-Header. Es wird kein Inhalt ausgeliefert, der Browser ruft sofort die neue URL auf.

Bei einer clientseitigen Weiterleitung antwortet der Server mit 200 OK und einer ganz normalen HTML-Seite. Erst wenn der Browser diese Seite geladen und verarbeitet hat, löst eine Anweisung darin die Weiterleitung aus. Dafür gibt es zwei Varianten: das Meta-Refresh-Tag und JavaScript.

Klingt nach einem technischen Detail, hat aber Folgen – für die Ladezeit, für Suchmaschinen und für jedes Tool, das sich nicht wie ein vollwertiger Browser verhält.

So funktioniert eine Meta-Refresh-Weiterleitung

Ein Meta Refresh ist ein meta-Element im head der Seite:

<meta http-equiv="refresh" content="0; url=https://example.com/neue-seite/">

Das content-Attribut besteht aus zwei Teilen: der Verzögerung in Sekunden und, nach einem Semikolon, der Ziel-URL. 0 heißt „sofort weiterleiten“, 5 heißt „diese Seite fünf Sekunden lang zeigen, dann weiterleiten“. Fehlt der url=-Teil, lädt das Tag einfach die aktuelle Seite neu – das ist ein anderer Anwendungsfall.

Dieselbe Anweisung lässt sich statt im HTML auch als HTTP-Header schicken:

HTTP/1.1 200 OK
Refresh: 0; url=https://example.com/neue-seite/

Der Refresh-Header gehört nicht zur HTTP-Spezifikation, ist aber im HTML-Standard beschrieben und wird von Browsern unterstützt. Da er ebenfalls mit einem 200 kommt, hat er dieselben Nachteile wie das Meta-Tag.

So funktioniert eine JavaScript-Weiterleitung

Eine JavaScript-Weiterleitung ändert window.location:

<script>
  window.location.replace('https://example.com/neue-seite/');
</script>

Nimm lieber location.replace() als location.href = .... Mit href bleibt die weiterleitende Seite im Browserverlauf. Klickt der Besucher auf „Zurück“, landet er wieder auf der Weiterleitungsseite – und wird sofort wieder nach vorn geschickt. Die klassische Zurück-Button-Falle. replace() ersetzt den Eintrag im Verlauf, der Zurück-Button funktioniert also wie erwartet.

JavaScript-Weiterleitungen findest du vor allem in Single-Page-Anwendungen, auf Seiten, bei denen das Ziel von etwas abhängt, das nur der Browser kennt (etwa ein clientseitig gespeicherter Login-Status), und in Tracking- oder Affiliate-Skripten.

Wie Google Meta-Refresh- und JavaScript-Weiterleitungen behandelt

Laut Google Search Central gilt:

Ein sofortiger Meta Refresh (Verzögerung 0) wird wie eine permanente Weiterleitung behandelt, ähnlich einem 301.
Ein verzögerter Meta Refresh wird wie eine temporäre Weiterleitung behandelt, ähnlich einem 302. Die ursprüngliche URL bleibt dann eher im Index.
JavaScript-Weiterleitungen folgt Google ebenfalls, allerdings erst, wenn die Seite gerendert wird. Das Rendern kann später als das Crawlen stattfinden und auch scheitern, etwa wenn Skripte blockiert sind oder zu lange brauchen. Google empfiehlt JavaScript-Weiterleitungen deshalb nur, wenn weder eine serverseitige Weiterleitung noch ein Meta Refresh möglich ist.

Heißt übersetzt: Google kommt mit clientseitigen Weiterleitungen zurecht, aber sie sind ein schwächeres und langsameres Signal als eine echte 3xx-Antwort. Und Google ist nicht der einzige Client. Andere Suchmaschinen, Linkvorschauen in sozialen Netzwerken, SEO-Crawler, Feedreader und viele HTTP-Bibliotheken führen kein JavaScript aus, manche ignorieren auch Meta Refresh. Für sie antwortet die alte Seite schlicht mit 200 OK – die Weiterleitung existiert gar nicht.

Warum serverseitige Weiterleitungen besser sind

	301/308 (Server)	Meta Refresh (0 s)	Meta Refresh (verzögert)	JavaScript
Statuscode der alten URL	301/308	200	200	200
Interpretation durch Google	Permanent	Permanent	Temporär	Nach dem Rendern gefolgt
Funktioniert ohne JavaScript	Ja	Ja	Ja	Nein
Funktioniert für PDFs, Bilder, APIs	Ja	Nein	Nein	Nein
Geschwindigkeit	Am schnellsten	Alte Seite muss erst laden	Absichtlich langsam	Seite und Skript müssen erst laden
Wird von einfachen Bots und Tools erkannt	Ja	Teilweise	Teilweise	Selten

Die wichtigsten Gründe im Einzelnen:

Ladezeit: Bei einem 3xx bekommt der Browser eine winzige Antwort und macht direkt weiter. Bei einer clientseitigen Weiterleitung lädt und parst er erst eine HTML-Seite, lädt womöglich Skripte und startet erst dann die eigentliche Anfrage. Im Mobilfunknetz merkt man das deutlich.
Eindeutige Bedeutung: Ein 301 sagt unmissverständlich „dauerhaft umgezogen“, und zwar jedem Client. Ein 200 mit eingebauter Weiterleitung ist Auslegungssache.
Funktioniert für jede Ressource: Ein Meta-Tag kannst du in HTML unterbringen, aber nicht in einem PDF, einem Bild oder einer JSON-Antwort. Serverseitige Weiterleitungen funktionieren für alles.
Barrierefreiheit: Zeitgesteuerte Weiterleitungen, die Nutzer ohne Vorwarnung wegschicken, sind ein bekanntes Barrierefreiheitsproblem. Die MDN-Dokumentation zum meta-Element weist darauf hin, dass verzögerte Refreshes besonders für Screenreader-Nutzer verwirrend sein können.
Sicherheit: JavaScript-Weiterleitungen, die ihr Ziel ungeprüft aus der URL lesen (etwa ?next=...), sind eine häufige Quelle für Open Redirects, die Angreifer für Phishing missbrauchen.

Wann eine clientseitige Weiterleitung vertretbar ist

Manchmal hast du schlicht keinen Zugriff auf die Serverkonfiguration, etwa bei einem statischen Hoster ohne Redirect-Regeln oder einer gehosteten Plattform mit wenigen Einstellungen. Dann ist ein Meta Refresh die zweitbeste Lösung, danach kommt JavaScript. Bau sie so robust wie möglich:

<!doctype html>
<html lang="de">
<head>
  <meta charset="utf-8">
  <title>Diese Seite ist umgezogen</title>
  <link rel="canonical" href="https://example.com/neue-seite/">
  <meta http-equiv="refresh" content="0; url=https://example.com/neue-seite/">
</head>
<body>
  <p>Diese Seite ist umgezogen: <a href="https://example.com/neue-seite/">example.com/neue-seite/</a></p>
</body>
</html>

Setz die Verzögerung auf 0, damit Google die Weiterleitung als permanent wertet und niemand warten muss.
Ergänze ein rel="canonical" auf das Ziel als zusätzliches Signal.
Bau einen sichtbaren Link ein für Clients, die dem Refresh nicht folgen.
Platzier das Meta-Tag weit oben im head, damit es auch Tools finden, die nur den Anfang des Dokuments lesen.

Bevor du dich mit einem Meta Refresh zufriedengibst, prüf, ob deine Plattform nicht doch echte Weiterleitungen kann. Viele können das, oft versteckt in einer Konfigurationsdatei: Sieh dir die Ratgeber zu Vercel und Netlify, Cloudflare (das vor jedem beliebigen Server weiterleiten kann) und WordPress an. Läuft bei dir Apache oder nginx, ist ein 301 eine einzige Zeile – wie, zeigt der Ratgeber zur 301-Weiterleitung.

So findest du Meta-Refresh- und JavaScript-Weiterleitungen

Clientseitige Weiterleitungen übersieht man leicht, weil sie im Browser wie jede andere Weiterleitung aussehen. Unser Redirect-Checker liest den Anfang jeder HTML-Antwort. Findet er ein Meta-Refresh-Tag, folgt er ihm, zeigt es als eigenen Hop an und gibt einen Hinweis, dass eine serverseitige Weiterleitung besser wäre. So siehst du auf einen Blick, ob deine „Weiterleitung“ ein echter 301 ist oder eine 200-Seite mit Meta-Tag.

Bei JavaScript-Weiterleitungen ist das anders: Der Checker führt – wie die meisten Crawler und HTTP-Tools – kein JavaScript aus. Zeigt er für eine URL 200 OK, dein Browser landet aber woanders, steckt sehr wahrscheinlich eine JavaScript-Weiterleitung dahinter. Was Google daraus macht, siehst du mit dem URL-Prüftool in der Google Search Console, das die gerenderte Seite anzeigt.

Wenn du clientseitige Weiterleitungen durch serverseitige ersetzt, teste danach erneut: Am Ende sollte ein einziger 301- oder 308-Hop direkt auf eine 200-Seite stehen, ohne dass ein übrig gebliebener Meta Refresh eine Redirect-Kette erzeugt.