Warum sind die Header der Zwischen-Hops wichtig?

Jeder Hop ist eine eigene HTTP-Antwort, womöglich von einem anderen Server. Ein Set-Cookie, eine Cache-Regel oder ein Security-Header auf einem Redirect-Hop gilt nur für genau diese Antwort. Schaust du dir jeden Hop an, erkennst du, wo ein Redirect entsteht und ob Header an der Antwort hängen, an der sie auch wirken.

Werten Suchmaschinen den X-Robots-Tag- und den Link-Header aus?

Ja. Google unterstützt X-Robots-Tag mit denselben Anweisungen wie das Robots-Meta-Tag und akzeptiert rel="canonical" im Link-Header. Beides ist vor allem für Nicht-HTML-Dateien wie PDFs praktisch. Details findest du in der Dokumentation von Google Search Central.

Sollte der HSTS-Header auch beim Redirect von HTTP auf HTTPS gesendet werden?

Schaden tut es nicht, bringt aber nichts: Browser ignorieren Strict-Transport-Security auf Antworten, die über unverschlüsseltes HTTP kommen. Entscheidend ist, dass der Header auf den HTTPS-Antworten steht, auch auf der finalen URL. Hat ein Browser ihn einmal gesehen, ruft er beim nächsten Besuch direkt HTTPS auf und spart sich den Redirect.

HTTP Header Checker

Gib eine URL ein und sieh die Response-Header jedes Hops, inklusive Weiterleitungen.

Beispiele: github.com, http://www.wikipedia.org, apple.com/de

Ergebnis: 1 Weiterleitung(en)

301

http://github.com

Weiterleitung · 304 ms

Response-Header

Content-Length:

0

Location:

https://github.com/
200

https://github.com/

Finale URL · 709 ms

Response-Header

date:

Mon, 28 Sep 2026 23:03:01 GMT

content-type:

text/html; charset=utf-8

content-language:

en-US

vary:

X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With, X-GitHub-Client-Version, Accept-Language, Sec-Fetch-Site,Accept-Encoding, Accept, X-Requested-With

etag:

W/"6541bf4d4f9070cf9ef0524536a6d0c5"

cache-control:

max-age=0, private, must-revalidate

strict-transport-security:

max-age=31536000; includeSubdomains; preload

x-frame-options:

deny

x-content-type-options:

nosniff

x-xss-protection:

0

referrer-policy:

origin-when-cross-origin, strict-origin-when-cross-origin

content-security-policy:

default-src 'none'; base-uri 'self'; child-src github.githubassets.com github.com/assets-cdn/worker/ github.com/assets/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com *.rel.tunnels.api.visualstudio.com wss://*.rel.tunnels.api.visualstudio.com github.githubassets.com objects-origin.githubusercontent.com copilot-proxy.githubusercontent.com proxy.individual.githubcopilot.com proxy.business.githubcopilot.com proxy.enterprise.githubcopilot.com *.actions.githubusercontent.com wss://*.actions.githubusercontent.com productionresultssa0.blob.core.windows.net productionresultssa1.blob.core.windows.net productionresultssa2.blob.core.windows.net productionresultssa3.blob.core.windows.net …

server:

github.com

content-encoding:

gzip

accept-ranges:

bytes

set-cookie:

_gh_sess=WjpL4nkhbSj4BGU2lOWsRg5APkIA01uylVHSiodGUrgow%2BNO7kE3dxbcF02l7sycnRrWC3Rhj63iuNWiJ9%2B4%2B17t9lfyfr%2F8nKrF044QWtExuK1Nz4YqJr8NOZtyGrav1Zc5bwN4N7k0EgpaYwJXgA%2BqAOePXqtTyvwVDSmwSWExwgUetBTdnEBFwsnH%2BPpxjm2k7HrYT0kHAsHsq1%2FYMk9M6msZuD1%2Fh2W78AT78CFwPaioyCFwF1NArAHuFbheOpCVMQcTrqJG%2F7vJEOhbug%3D%3D--ncl1qx6VroiYG2rA--BpE5QtK2eaWo%2BAG7NTlW8A%3D%3D; path=/; HttpOnly; secure; SameSite=Lax

set-cookie:

_octo=GH1.1.498463627.1790636588; expires=Tue, 28 Sep 2027 23:03:08 GMT; domain=.github.com; path=/; secure; SameSite=Lax

set-cookie:

logged_in=no; expires=Tue, 28 Sep 2027 23:03:08 GMT; domain=.github.com; path=/; HttpOnly; secure; SameSite=Lax

x-github-request-id:

B6E4:143D47:8AEE92:8D08AC:6ABAF22C

x-github-edge-region:

fra

Sieht gut aus: Die Weiterleitungskette endet auf einer funktionierenden HTTPS-Seite.

Link zu diesem Ergebnis:

Alle Response-Header aller Hops auf einen Blick

Dein Browser zeigt dir nur die Seite am Ende einer Redirect-Kette. Was auf dem Weg dorthin passiert, steckt in den HTTP-Response-Headern. Der HTTP-Header-Checker folgt der kompletten Redirect-Kette und listet alle Response-Header jedes einzelnen Hops auf – vom ersten 301 bis zur finalen 200 oder Fehlerseite.

Das hilft dir immer dann, wenn sich ein Redirect anders verhält als gedacht: Du siehst, welcher Server oder welches CDN geantwortet hat, wohin der Location-Header zeigt, ob ein Hop gecacht wird und ob Security-Header wie HSTS an der richtigen Antwort hängen.

Die wichtigsten Header für SEO und Sicherheit

Header	Wofür er da ist	Worauf du achten solltest
`Location`	Das Ziel eines Redirects. Nur zusammen mit einem 3xx-Statuscode relevant.	Er sollte direkt auf die finale URL zeigen, mit richtigem Protokoll und Host – nicht auf einen weiteren Redirect.
`Cache-Control`	Legt fest, wie lange Browser und Proxys die Antwort cachen dürfen.	Browser cachen `301`- und `308`-Redirects sehr hartnäckig. Ein langes `max-age` auf einem Redirect, den du später vielleicht ändern willst, macht Korrekturen mühsam.
`Strict-Transport-Security`	HSTS weist den Browser an, diesen Host künftig nur noch per HTTPS aufzurufen.	Setz ihn auf HTTPS-Antworten, etwa mit `max-age=31536000`. Auf reinen HTTP-Antworten ignorieren Browser ihn.
`Content-Type`	Medientyp und Zeichensatz des Antwortinhalts.	HTML-Seiten sollten `text/html; charset=utf-8` senden. Ein falscher Typ kann Darstellung oder Indexierung stören.
`Set-Cookie`	Setzt Cookies im Browser.	Prüf `Secure`, `HttpOnly` und `SameSite`. Cookies, die ein Redirect-Hop für den falschen Host setzt, fehlen nach der Umleitung.
`X-Robots-Tag`	Robots-Anweisungen wie `noindex` oder `nofollow` als HTTP-Header.	Ein versehentliches `noindex` auf der finalen URL wirft die Seite aus dem Google-Index – auch wenn im HTML kein Robots-Meta-Tag steht.
`Link` mit `rel="canonical"`	Canonical-URL als HTTP-Header, üblich bei PDFs und anderen Nicht-HTML-Dateien.	Er sollte die finale, bevorzugte URL nennen und weder dem Redirect noch dem Canonical-Tag im HTML widersprechen.
`Server`, `Via`, `X-Cache`	Verraten, welche Software, welcher Proxy oder welches CDN die Antwort erzeugt hat.	So findest du heraus, ob ein Redirect von deinem Webserver, deinem CMS oder einem CDN wie Cloudflare kommt.

So nutzt du den Header-Checker

Gib eine Domain oder URL ein und wähl einen User-Agent. Lässt du das Schema weg, wird http:// ergänzt – so prüfst du den Schritt von HTTP auf HTTPS gleich mit. Im Ergebnis siehst du jeden Hop mit seinem Statuscode und darunter die vollständige Liste der Response-Header.

Typische Befunde:

HSTS fehlt auf der finalen URL: Ergänz Strict-Transport-Security in deinen HTTPS-Antworten. Mehr dazu im Ratgeber HTTP auf HTTPS umleiten.
Anderer Server-Header beim ersten Hop: Der Redirect passiert in einem CDN oder Load Balancer, nicht in deiner Webserver-Konfiguration. Genau dort musst du ihn auch ändern.
Location-Header zeigt auf einen weiteren Redirect: Pass die Regel an, damit sie direkt auf die finale URL zeigt.
X-Robots-Tag: noindex auf einer Seite, die ranken soll: Prüf deine Serverkonfiguration oder dein SEO-Plugin.

Brauchst du nur Statuscodes und finale URL, bekommst du mit dem Redirect-Checker eine kompaktere Ansicht. Was die einzelnen Codes bedeuten, steht in der Übersicht der HTTP-Statuscodes.

Häufige Fragen

Warum sind die Header der Zwischen-Hops wichtig?: Jeder Hop ist eine eigene HTTP-Antwort, womöglich von einem anderen Server. Ein Set-Cookie, eine Cache-Regel oder ein Security-Header auf einem Redirect-Hop gilt nur für genau diese Antwort. Schaust du dir jeden Hop an, erkennst du, wo ein Redirect entsteht und ob Header an der Antwort hängen, an der sie auch wirken.
Werten Suchmaschinen den X-Robots-Tag- und den Link-Header aus?: Ja. Google unterstützt X-Robots-Tag mit denselben Anweisungen wie das Robots-Meta-Tag und akzeptiert rel="canonical" im Link-Header. Beides ist vor allem für Nicht-HTML-Dateien wie PDFs praktisch. Details findest du in der Dokumentation von Google Search Central.
Sollte der HSTS-Header auch beim Redirect von HTTP auf HTTPS gesendet werden?: Schaden tut es nicht, bringt aber nichts: Browser ignorieren Strict-Transport-Security auf Antworten, die über unverschlüsseltes HTTP kommen. Entscheidend ist, dass der Header auf den HTTPS-Antworten steht, auch auf der finalen URL. Hat ein Browser ihn einmal gesehen, ruft er beim nächsten Besuch direkt HTTPS auf und spart sich den Redirect.

Weitere kostenlose Tools

Bulk-Checker

Prüfe bis zu 20 URLs auf einmal, z. B. deine Redirect-Map nach einem Domain-Umzug. Mit CSV-Export.
.htaccess-Redirect-Generator

Erzeuge .htaccess-Regeln für einzelne Seiten, HTTPS- und www-Weiterleitungen.
nginx-Redirect-Generator

Erzeuge nginx-Server-Blöcke und return-Regeln für deine Weiterleitungen.
HTTP-Statuscodes

Alle HTTP-Statuscodes erklärt, mit Hinweisen, wie Google sie behandelt.
JSON-API

Prüfe Weiterleitungen aus Skripten und CI-Pipelines mit einer einfachen JSON-API.

HTTP Header Checker

Ergebnis: 1 Weiterleitung(en)

Alle Response-Header aller Hops auf einen Blick

Die wichtigsten Header für SEO und Sicherheit

So nutzt du den Header-Checker

Häufige Fragen

Weitere kostenlose Tools

Bulk-Checker

.htaccess-Redirect-Generator

nginx-Redirect-Generator

HTTP-Statuscodes

JSON-API