Ist eine 308-Weiterleitung gut für SEO?

Ja. Google behandelt einen 308 wie einen 301: Er gibt PageRank weiter und ist ein starkes Signal, dass die Ziel-URL statt der alten indexiert werden soll. Du kannst 308 überall einsetzen, wo du sonst einen 301 nehmen würdest.

Warum zeigt Chrome „307 Internal Redirect“ an?

Meist wegen HSTS. Der Browser weiß, dass die Seite nur per HTTPS geladen werden darf, und stuft die URL selbst hoch, ohne überhaupt eine HTTP-Anfrage zu senden. Der Header Non-Authoritative-Reason: HSTS bestätigt das. Dein Server hat diesen 307 nicht geschickt, und Crawler bekommen ihn nie zu sehen.

Was ist der Unterschied zwischen 302 und 307?

Beides sind vorübergehende Weiterleitungen. Bei einem 302 dürfen Browser aus einem POST ein GET machen und den Body verwerfen. Bei einem 307 müssen Methode und Body exakt gleich bleiben. Für GET-Anfragen verhalten sich beide identisch.

Unterstützen alle Browser den Statuscode 308?

Alle aktuellen Browser tun das, ebenso die Crawler der Suchmaschinen und gängige HTTP-Clients. Probleme mit 308 hatte nur sehr alte Software wie veraltete Internet-Explorer-Versionen auf älteren Windows-Systemen. Musst du solche Clients unterstützen, nimm für reine Seitenweiterleitungen einen 301.

307 vs. 308 Weiterleitung: Unterschiede erklärt

307 und 308 sind die strengen Geschwister von 302 und 301: Sie garantieren, dass ein POST ein POST bleibt. Hier erfährst du, was das in der Praxis bedeutet, warum du oft einen 307 siehst, den dein Server nie geschickt hat, und wann ein 308 die bessere permanente Weiterleitung ist.

Die Kurzfassung

307 Temporary Redirect ist eine vorübergehende Weiterleitung wie 302 – nur muss der Client die Anfrage mit derselben Methode und demselben Body wiederholen.
308 Permanent Redirect ist eine dauerhafte Weiterleitung wie 301, mit derselben Garantie: Methode und Body bleiben erhalten.

Die Zuordnung ist also einfach: 302 → 307 und 301 → 308. Anders ist nur der Umgang mit Anfragen, die kein GET sind. Für Suchmaschinen verhält sich 308 wie 301 und 307 wie 302.

Warum es 307 und 308 überhaupt gibt

Eigentlich sollten schon 301 und 302 die Anfragemethode beibehalten. Die Browser haben es aber anders umgesetzt: Folgten sie nach einem POST einem 301 oder 302, schickten sie ein GET an die neue URL und ließen den Body weg. Das hat sich so weit verbreitet, dass RFC 9110 es heute ausdrücklich erlaubt, bei 301 und 302 aus POST ein GET zu machen.

Um wieder eindeutige Codes zu haben, führte HTTP/1.1 den 307 (vorübergehend, Methode bleibt) und den 303 See Other (immer Wechsel zu GET) ein. Das dauerhafte Gegenstück 308 kam später mit RFC 7538 dazu und ist inzwischen Teil von RFC 9110. Zusammen ergibt das ein vollständiges Raster:

	Methode darf zu GET werden	Methode bleibt immer erhalten	Immer GET
Dauerhaft	301	308	–
Vorübergehend	302	307	303

Was „Methode bleibt erhalten“ konkret heißt

Angenommen, ein Formular schickt seine Daten per POST an /anmelden, und du verlegst diesen Endpunkt nach /newsletter/anmelden. Bei einem 301 folgt der Browser mit einem GET – ohne Formulardaten. Der Nutzer sieht ein leeres Formular oder eine Fehlermeldung, die Anmeldung ist weg. Bei einem 308 schickt der Browser denselben POST mit demselben Body an die neue URL, und alles funktioniert weiter.

POST /anmelden HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

email=jana%40example.com

HTTP/1.1 308 Permanent Redirect
Location: https://example.com/newsletter/anmelden

POST /newsletter/anmelden HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

email=jana%40example.com

Dasselbe gilt für PUT, PATCH und DELETE in REST-APIs. Ziehst du eine API um, ist ein 307 oder 308 fast immer die richtige Wahl, weil API-Clients sich darauf verlassen, dass die Methode unverändert ankommt. Beachte aber, dass HTTP-Bibliotheken Weiterleitungen unterschiedlich behandeln: Manche folgen bei Nicht-GET-Anfragen gar nicht automatisch, solange du es nicht einschaltest. Teste also mit den Clients, die deine Nutzer tatsächlich einsetzen.

Bei normalen Seitenweiterleitungen spielt das alles keine Rolle. Links, Lesezeichen und Crawler nutzen GET, und GET bleibt bei jedem 3xx-Code ein GET.

Der 307, den du nie geschickt hast: HSTS und interne Weiterleitungen

Eine sehr häufige Frage: „Mein Server leitet mit 301 von HTTP auf HTTPS weiter, aber Chrome zeigt einen 307. Warum?“ Die Antwort lautet fast immer HSTS (HTTP Strict Transport Security).

Hat ein Browser von deiner Seite einmal per HTTPS einen Strict-Transport-Security-Header bekommen oder steht deine Domain auf der HSTS-Preload-Liste, weiß er: Diese Seite darf nur per HTTPS geladen werden. Tippst oder klickst du dann eine http://-URL an, nimmt der Browser gar keinen Kontakt per HTTP zum Server auf. Er schreibt die URL intern auf https:// um, und die Chrome-Entwicklertools zeigen das so an:

Status Code: 307 Internal Redirect
Non-Authoritative-Reason: HSTS

Das Wichtigste zu diesem „falschen“ 307:

Er stammt vom Browser, nicht von deinem Server. Eine Netzwerkanfrage an die HTTP-URL findet gar nicht statt.
Er ist kein Fehler und muss nicht behoben werden. Im Gegenteil: Das ist die sicherste Variante, weil keine unverschlüsselte Anfrage den Browser verlässt.
Crawler von Suchmaschinen und serverseitige Tools sehen ihn nicht. Sie sehen, was dein Server wirklich schickt – typischerweise einen 301 oder 308.
Neuere Browser stufen HTTP teilweise auch ohne HSTS selbstständig auf HTTPS hoch, was ebenfalls als interne Weiterleitung auftauchen kann.

Willst du wissen, was dein Server tatsächlich antwortet, teste außerhalb des Browsers. Der Redirect-Checker schickt eine frische Anfrage ohne HSTS-Gedächtnis, du siehst also den echten ersten Hop, etwa http://example.com/ mit 301. Prüf bei der Gelegenheit auch, ob deine HTTPS-Antworten den gewünschten Strict-Transport-Security-Header mitschicken, zum Beispiel mit dem HTTP-Header-Checker. Mehr Hintergrund findest du im Ratgeber HTTP auf HTTPS weiterleiten.

307, 308, 301 und 302 im Vergleich

Code	Dauerhaft?	Methode und Body	Standardmäßig gecacht	Kanonisierungssignal bei Google	Typischer Einsatz
301	Ja	POST kann zu GET werden	Ja	Stark	Seiten- und Domainumzüge
302	Nein	POST kann zu GET werden	Nein	Schwach	Vorübergehende Seitenweiterleitungen
307	Nein	Bleiben erhalten	Nein	Schwach	Vorübergehende API- oder Formular-Weiterleitungen, HSTS im Browser
308	Ja	Bleiben erhalten	Ja	Stark	Dauerhafte API-Umzüge, HTTPS-Weiterleitungen

Laut Google Search Central geben alle diese Codes PageRank weiter. Einen 308 behandelt Google wie einen 301, also als starkes Signal, dass das Ziel die kanonische URL werden soll. Einen 307 behandelt Google wie einen 302. Wie ein 301 ist auch ein 308 standardmäßig cachebar – Browser merken ihn sich unter Umständen sehr lange. Bist du dir noch nicht sicher, teste zuerst mit einem 307 oder 302.

Wann 307, wann 308?

Nimm einen 308, wenn

ein API-Endpunkt oder Formular-Handler dauerhaft umzieht,
du HTTP auf HTTPS weiterleitest und POST-Anfragen an alte HTTP-URLs unbeschadet ankommen sollen (Next.js und Vercel etwa nutzen 308 für ihre permanenten Weiterleitungen),
du eine dauerhafte Weiterleitung mit eindeutiger Bedeutung für alle Methoden willst.

Nimm einen 307, wenn

ein Endpunkt vorübergehend woanders bereitgestellt wird, etwa während einer Wartung oder bei einem Failover,
eine Anfrage an einem anderen Host wiederholt werden muss, ohne dass sich die Methode ändert.

Bleib bei 301/302, wenn du nur normale Seiten weiterleitest und maximale Kompatibilität mit sehr alten Clients brauchst. Aktuelle Browser und Suchmaschinen verstehen 307 und 308 problemlos, manche Altsoftware aber nicht – alte Internet-Explorer-Versionen auf älteren Windows-Versionen kamen zum Beispiel mit 308 nicht klar.

Und wenn sich die Methode ändern soll, etwa nach dem Absenden eines Formulars, damit ein Neuladen nicht doppelt abschickt (Post/Redirect/Get), ist 303 See Other der richtige Code.

So schickst du einen 307 oder 308

Apache (.htaccess oder VirtualHost), mit mod_alias oder mod_rewrite:

Redirect 308 /api/v1/ https://example.com/api/v2/

RewriteEngine On
RewriteRule ^anmelden$ /newsletter/anmelden [R=308,L]

nginx:

location ~ ^/api/v1/(.*)$ {
    return 308 https://example.com/api/v2/$1$is_args$args;
}

location = /anmelden {
    return 308 https://example.com/newsletter/anmelden;
}

Achtung: rewrite ... permanent schickt in nginx immer einen 301, redirect einen 302. Für 307 oder 308 brauchst du return 307 bzw. return 308.

PHP:

header('Location: https://example.com/newsletter/anmelden', true, 308);
exit;

Weitere Beispiele findest du in den Ratgebern zu .htaccess und nginx. Regeln zusammenklicken kannst du dir mit dem .htaccess-Generator und dem nginx-Generator.

307- und 308-Weiterleitungen testen

Für GET-Anfragen gibst du die URL einfach in den Redirect-Checker ein. Du siehst jeden Hop mit Statuscode und kannst so prüfen, ob der Server wirklich 308 statt 301 schickt und ob sich keine Kette aus mehreren Weiterleitungen gebildet hat.

Ob die Methode erhalten bleibt, prüfst du mit einem echten POST auf der Kommandozeile:

curl -i -L --data "email=test@example.com" https://example.com/anmelden

-L lässt curl den Weiterleitungen folgen. Mit --data (ohne -X POST) verhält sich curl wie ein Browser: Nach einem 301, 302 oder 303 wechselt es zu GET, nach einem 307 oder 308 bleibt es beim POST. In der Ausgabe siehst du also direkt, ob dein Endpunkt die Daten noch bekommt. Wie Browser die einzelnen Codes behandeln, beschreibt der MDN-Artikel zu Weiterleitungen ausführlich.