Netztools24

HTTP-Header Analyse: Response-Headers online prüfen

Werfen Sie einen Blick hinter die Kulissen einer Webseite: Statuscode, Cache-Einstellungen und Security-Header wie HSTS, CSP oder X-Frame-Options auf einen Blick. Praktisch für SEO-Checks, Security-Audits und die Fehlersuche bei Redirects.

Zuletzt aktualisiert: 04. März 2026

Der erste Blick in die Ergebnisliste

Sie geben eine URL ein, klicken auf Analysieren, und Sekundenbruchteile später steht dort eine Liste mit zwanzig, dreißig Zeilen. Ganz oben der Statuscode, darunter Server, Content-Type, dann eine ganze Reihe Header, deren Namen man nicht jeden Tag liest. Wer das Tool zum ersten Mal benutzt, fragt sich meistens zuerst: Was davon ist überhaupt relevant für mich?

Die kurze Antwort: kommt auf Ihr Anliegen an. Ein SEO-Verantwortlicher schaut zuerst auf Statuscode und Redirect-Kette, ein Entwickler auf Caching und CORS, jemand aus der IT-Sicherheit auf die Security-Header. Die folgenden Abschnitte gehen genau in dieser Reihenfolge durch, was in der Ergebnisliste steckt und wie Sie es lesen.

Statuscode zuerst

Ganz oben in der Ausgabe steht immer der HTTP-Statuscode. Er verrät in einer Zahl, wie die Anfrage gelaufen ist.

  • 2xx, Erfolg: 200 OK ist der Normalfall, daneben gibt es 204 No Content und 206 Partial Content für Teilantworten.
  • 3xx, Umleitung: 301 steht für eine dauerhafte Weiterleitung und ist SEO-relevant, 302 ist nur temporär, 304 bedeutet, der Browser darf seine gecachte Version weiterverwenden.
  • 4xx, Fehler beim Client: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests.
  • 5xx, Fehler beim Server: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.

Die Security-Header in der Liste

Direkt darunter finden Sie normalerweise die sicherheitsrelevanten Header, sofern die Seite sie überhaupt setzt. Fehlt einer davon komplett, ist das kein Beinbruch, aber ein Hinweis, dass an dieser Stelle noch Spielraum ist.

  • Strict-Transport-Security (HSTS): erzwingt HTTPS bei wiederkehrenden Besuchern. Als Zielwert hat sich max-age=63072000; includeSubDomains; preload etabliert.
  • Content-Security-Policy (CSP): definiert, aus welchen Quellen Skripte, Styles und Bilder geladen werden dürfen. Wirksamer Schutz gegen XSS, deutlich mächtiger als das veraltete X-XSS-Protection.
  • X-Content-Type-Options: nosniff: unterbindet MIME-Type-Sniffing, damit der Browser eine JSON-Antwort nicht versehentlich als HTML interpretiert.
  • X-Frame-Options / frame-ancestors: verhindert, dass Ihre Seite in einem fremden iFrame für Clickjacking missbraucht wird.
  • Referrer-Policy: steuert, wie viel Referrer-Information beim Verlassen der Seite mitgeschickt wird. strict-origin-when-cross-origin gilt als solide Vorgabe.
  • Permissions-Policy: schaltet Browser-APIs wie Kamera, Mikrofon oder Standort für Kontexte ab, die sie nicht brauchen.
  • Cross-Origin-Opener-Policy und Cross-Origin-Embedder-Policy: ermöglichen die Isolation, die etwa für SharedArrayBuffer nötig ist.

Was die Caching-Header aussagen

Weiter unten in der Liste taucht meistens Cache-Control auf, oft zusammen mit ETag und Vary. Ein paar Muster, die sich in der Praxis bewährt haben:

  • Cache-Control: public, max-age=31536000, immutable für Assets, deren Dateiname einen Hash trägt und die sich damit nie unbemerkt ändern.
  • Cache-Control: no-cache zusammen mit ETag für HTML, das bei jedem Aufruf neu validiert werden soll.
  • Cache-Control: private für Inhalte, die an einen einzelnen Nutzer gebunden sind und nie auf einem Proxy landen dürfen.
  • Vary: Accept-Encoding, User-Agent, damit CDNs verschiedene Varianten derselben URL sauber auseinanderhalten.

Der Rest der Liste

  • Content-Type: MIME-Typ und Zeichensatz, etwa text/html; charset=utf-8.
  • Content-Encoding: gzip, br oder zstd als Kompressionsverfahren für die Übertragung.
  • Server: verrät die eingesetzte Webserver-Software. Aus Sicherheitsgründen wird dieser Header häufig gekürzt oder ganz entfernt.
  • X-Powered-By: zeigt das verwendete Framework, zum Beispiel PHP/8.2. Sollte man aus demselben Grund lieber abschalten.
  • Alt-Svc: signalisiert, dass der Server auch HTTP/3 unterstützt.
  • Set-Cookie: hier lohnt sich ein Blick auf die Flags Secure, HttpOnly und SameSite.

Wofür Sie das in der Praxis nutzen

Nach den ersten Analysen zeichnen sich meist wiederkehrende Anwendungsfälle ab: das Kontrollieren von Redirect-Ketten nach einer Domain-Migration, das Nachweisen fehlender Security-Header vor einem Audit, das Prüfen, ob ein CDN die Caching-Regeln wirklich umsetzt, oder das Debuggen einer CORS-Fehlermeldung, die sich mit einem fehlenden Access-Control-Allow-Origin-Header erklären lässt.

Datenschutz

Das Tool schickt eine einzelne HEAD- beziehungsweise GET-Anfrage an die angegebene URL und zeigt Ihnen die Antwort direkt an. Weder URL noch Header-Inhalte werden bei uns dauerhaft gespeichert.

Häufige Fragen zur HTTP-Header-Analyse

Warum sehe ich andere Header als in den Chrome DevTools?

Server liefern je nach User-Agent, Cookies oder Standort unterschiedliche Header aus. Unsere Anfrage kommt aus einem deutschen Rechenzentrum und enthält keine Session-Cookies, das Ergebnis kann also leicht abweichen.

Wirken sich Security-Header wirklich auf das Ranking aus?

Ein direkter, messbarer Rankingfaktor sind sie nicht dokumentiert. Google bewertet aber HTTPS und damit indirekt eine sauber konfigurierte Sicherheitsbasis, HSTS und CSP gehören für viele Auditoren zum Standard einer professionell betreuten Seite.

Bringt es etwas, den Server-Header zu verstecken?

Als alleinige Verteidigung nicht, ein Angreifer findet die Software meist auch über andere Wege heraus. Weniger Information erschwert aber automatisierte Massen-Scans etwas, insofern schadet es nicht, den Header zu kürzen oder zu entfernen.

Wie melde ich eine Domain für HSTS-Preload an?

Setzen Sie zunächst max-age=63072000; includeSubDomains; preload als Header, prüfen Sie das Ergebnis hier im Tool, und reichen Sie die Domain anschließend unter hstspreload.org ein.

Kann ich damit auch Redirect-Ketten aufspüren?

Ja, das ist einer der häufigsten Einsatzzwecke. Prüfen Sie die URL, folgen Sie dem Location-Header manuell zur nächsten Adresse und wiederholen Sie den Vorgang, bis Sie bei 200 OK ankommen. Mehr als ein bis zwei Hops sollten es aus Performance-Sicht nicht sein.