Ein HTTP Header Checker zeigt die Metadaten, die ein Webserver für eine URL zurückgibt. Screpy stellt eine öffentliche GET-Anfrage, folgt unterstützten Weiterleitungen und listet die Headernamen und Werte der endgültigen Antwort auf, ohne den Seiteninhalt herunterzuladen. Untersuchen Sie damit eine Weiterleitung, prüfen Sie eine Headeränderung nach der Veröffentlichung oder finden Sie eine unerwartete Indexierungsanweisung.
Beginnen Sie mit der erhaltenen Antwort und vergleichen Sie sie mit dem gewünschten Verhalten dieser Ressource. Eine erfolgreich abgeschlossene Prüfung kann einen Serverfehler oder eine ungeeignete Richtlinie zeigen. Ein grünes Ergebnis bestätigt weder Sicherheit noch Cache-Leistung oder Suchmaschinenindexierung.
Die genaue URL und ihre Antwortkette prüfen
Geben Sie eine vollständige öffentliche HTTP- oder HTTPS-Adresse einschließlich des relevanten Pfads und der Abfrageparameter ein. Startseite, PDF und Produktseite können auf derselben Domain unterschiedliche Header liefern. Für eine fiktive Produktseite ist https://example.com/products/blue-mug/ sinnvoller als die Startseite, wenn Sie genau diese Produktantwort untersuchen möchten.
Lesen Sie die Antwortkette vor der Headertabelle. Eine Weiterleitung kann Protokoll, Host oder Pfad ändern. Die Tabelle enthält die Header der endgültigen Antwort, nicht sämtliche Header aller Schritte. Auch die endgültige Antwort zählt als Schritt der Kette; die Anzahl der Schritte muss daher nicht der Anzahl der Weiterleitungen entsprechen.
Prüfen Sie, ob die endgültige URL zur gewünschten Ressource gehört. Eine Anmeldeseite, Fehlerseite oder ein anderer Host kann unerwartete Werte erklären. Verwenden Sie den Redirect Checker, wenn Sie gezielt den Weiterleitungspfad statt der abschließenden Headerliste untersuchen möchten.
Ein HTTP-Antwortbeispiel lesen
Diese fiktive Antwort zeigt, wie verschiedene Felder unterschiedliche Fragen beantworten. Sie ist kein aufgezeichnetes Prüfergebnis und keine Konfiguration zum pauschalen Kopieren.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
Der Status 200 kennzeichnet eine erfolgreiche Antwort. Content-Type deklariert HTML mit UTF-8-Kodierung. Cache-Control beschreibt Cache-Anweisungen, während X-Robots-Tag eine Indexierungsanweisung enthält. Eine funktionierende Antwort kann also noindex enthalten: HTTP-Erfolg bedeutet nicht, dass die Seite für Suchergebnisse vorgesehen ist.
Die Tabelle zeigt normalisierte kleingeschriebene Headernamen. Groß- und Kleinschreibung macht daraus keine unterschiedlichen Felder. Die MDN-Headerreferenz unterscheidet Anfrage- und Antwortfelder. Dieses Tool zeigt die Antwort, nicht die Cookies, Browsereinstellungen oder Anmeldedaten Ihrer eigenen Sitzung.
Caching und Indexierung getrennt beurteilen
Filtern Sie bei einem konkreten Problem nach dem Headernamen. Überlegen Sie zuerst, was die Ressource benötigt. Häufig geändertes HTML, eine versionierte Datei und ein bewusst aus der Suche ausgeschlossenes Dokument brauchen nicht dieselbe Richtlinie.
| Header | Hilfreiche Frage bei der Prüfung |
|---|---|
content-type |
Passt das deklarierte Format zur erwarteten Ressource oder führte eine Weiterleitung zu einer anderen Antwort? |
cache-control |
Passt die Cache-Richtlinie zu Aktualisierungs- und Datenschutzanforderungen dieser Ressource? |
etag oder last-modified |
Ist ein Validator für bedingte Anfragen vorhanden? Seine Anwesenheit testet keine Revalidierung. |
vary |
Welche Unterschiede in Anfrageheadern nennt die Antwort für die Cache-Auswahl? |
x-robots-tag |
Ist eine beobachtete Noindex-Anweisung für diese URL beabsichtigt? |
no-cache bedeutet nicht „niemals speichern“. Es erlaubt das Speichern, verlangt aber vor der Wiederverwendung eine Validierung. no-store weist Caches an, die Antwort nicht zu speichern. Die MDN-Referenz zu Cache-Control erläutert den Unterschied. Diese Prüfung misst keine Cache-Treffer und löscht keine bereits gespeicherten Kopien.
Eine Indexierungsanweisung ist unabhängig von der Aktualität. Liefert eine zur Indexierung vorgesehene Seite unerwartet noindex, suchen Sie vor einer Änderung die verantwortliche Anwendung, Servereinstellung oder Antwortregel. Prüfen Sie mit dem Noindex Checker auch HTML-Anweisungen. Googles Noindex-Dokumentation erklärt die Anweisung; ihr Auftreten beweist nicht den aktuellen Indexstatus bei Google.
Die Hinweise zu Sicherheitsheadern verstehen
Screpy hebt ausgewählte Angaben zur Prüfung hervor. Behandeln Sie einen Befund als Konfigurationsfrage, nicht als Schwachstellenbericht oder Empfehlung, eine unbekannte Richtlinie auf der veröffentlichten Website einzusetzen.
| Beobachtung | Was die Prüfung feststellt und was nicht |
|---|---|
| HSTS-Prüfung | Sucht einen positiven max-age-Wert in einer HTTPS-Antwort. Sie validiert weder die gesamte HTTPS-Umstellung noch Zertifikate. |
| Fehlende CSP | Sucht Content-Security-Policy in einer als HTML deklarierten Antwort. Ein vorhandener Header garantiert nicht, dass seine Direktiven die Anwendung schützen. |
| Einbettungsprüfung | Sucht frame-ancestors in CSP oder einen erkannten X-Frame-Options-Wert. Ob Einbettung erlaubt sein soll, hängt von der Seite ab. |
| MIME-Sniffing-Prüfung | Prüft, ob X-Content-Type-Options den Wert nosniff deklariert. Sie prüft weder tatsächliche Dateiinhalte noch das Verhalten jedes Browsers. |
Eine Information oder fehlende Richtlinie beweist keine Sicherheitslücke. Ebenso wird eine Richtlinie nicht allein durch einen vorhandenen Header wirksam. Die MDN-CSP-Dokumentation unterscheidet durchgesetzte Richtlinien von Content-Security-Policy-Report-Only, das Verstöße meldet, ohne diese Einschränkungen durchzusetzen. Letzteres beweist nicht, dass eine durchsetzende Richtlinie vorhanden ist.
Prüfen Sie Änderungen anhand der tatsächlichen Ressourcen- und Einbettungsanforderungen Ihrer Anwendung. Der Checker vergibt keine Sicherheitsnote, untersucht keine Zertifikate und validiert nicht jede Direktive. Unsichere Ressourcenverweise im HTML können Sie separat mit dem Mixed Content Checker untersuchen.
Wiederholte und verborgene Werte einordnen
Die Headeranzahl zählt unterschiedliche normalisierte Namen. Die Häufigkeitsspalte zeigt, wie oft ein Name vorkam; gewöhnliche wiederholte Werte bleiben sichtbar. Mehrfaches Auftreten ist nicht automatisch ein Fehler. Prüfen Sie, ob das jeweilige Feld diese Struktur erlaubt und ob die kombinierte Richtlinie beabsichtigt ist.
Vertrauliche Cookie-, Authentifizierungs- und erkannte Geheimwerte werden verborgen oder bereinigt. Ein verborgener Wert ist kein fehlender Header, und sein Auftreten ist keine Bewertung der Cookie-Sicherheit. Ergänzen Sie geschwärzte Werte nicht in einem geteilten Bericht. Untersuchen Sie vertrauliche Details nur in einer geeigneten privaten Debugging-Umgebung.
Filtern Sie nach Namen wie cache-control, statt eine Suche in allen Werten zu erwarten. Bewahren Sie für Vergleiche den Bericht mit der geprüften URL und Uhrzeit auf. Interpretieren Sie einen einzelnen vorhandenen oder fehlenden Header zusammen mit dem endgültigen Status, Ressourcentyp und Abdeckungshinweis.
Teilprüfungen von HTTP-Fehlern unterscheiden
Eine Fehlerantwort des Servers ist etwas anderes als ein nicht erreichbarer Server. Lesen Sie den Abdeckungshinweis, bevor Sie fehlende Zeilen bewerten.
| Ergebnis | Bedeutung und nächster Schritt |
|---|---|
Abschließendes 404 oder 500 mit Headern |
Eine Antwort wurde beobachtet. Prüfen Sie die URL und den Ressourcen- oder Serverfehler; verwechseln Sie Verbindungserfolg nicht mit Seitenerfolg. |
| Teilweise Antwortkette | Einige Schritte wurden beobachtet, die endgültige Antwort aber nicht geprüft. Die endgültigen Header sind unbekannt, nicht nachweislich fehlend. |
| Zeitüberschreitung oder nicht verfügbare Quelle | Die gewünschte Antwort konnte nicht abgerufen werden. Prüfen Sie öffentlichen Zugriff, Adresse und Weiterleitungen vor einem neuen Versuch. |
Der Checker folgt einer begrenzten Zahl von Weiterleitungen und wartet nur begrenzte Zeit. Schleifen, unzugängliche Ziele oder Antworten außerhalb unterstützter Grenzen können die Prüfung unvollständig lassen. Eine leere abschließende Headerliste ist dann keine Liste fehlender Sicherheitsheader.
Private Netzwerkadressen, geschützte Seiten und Anfragen mit Ihren Browser-Cookies sind außerhalb des Formularumfangs. Eine Zugriffsbegrenzung beweist auch nicht, was Googlebot oder ein anderer tatsächlicher Besucher erhält.
Header nach einer Veröffentlichung vergleichen
Notieren Sie vor einer Änderung die genaue URL, endgültige Antwort, Prüfzeit und das Feld, das sich ändern soll. Exportieren Sie den Bericht als Ausgangsstand. Prüfen Sie nach Veröffentlichung der gewünschten Konfiguration dieselbe URL und vergleichen Sie die relevanten Werte statt nur die Anzahl der Header oder Warnungen. Wiederholen Sie dies für einen anderen Ressourcentyp, wenn die Regel auch dort gelten soll.
Zeigt Ihr Browser etwas anderes, öffnen Sie dessen Netzwerkbereich, laden Sie die Seite neu und untersuchen Sie die betreffende Anfrage. Vergleichen Sie URL nach Weiterleitungen, Methode und Anmeldestatus. Eine zwischengespeicherte oder personalisierte Browserantwort muss nicht einer öffentlichen Anfrage aus einem anderen Standort entsprechen. Dieses Formular sendet weder Ihre Benutzer-Cookies noch eigene Authentifizierungsheader.
Prüfen Sie auch, ob ein anderes Diagnosewerkzeug HEAD statt GET verwendet hat. RFC 9110 erklärt, dass HEAD keinen Antwortinhalt liefert und einige erst bei der Inhaltserzeugung bestimmte Felder auslassen darf. Screpy verwendet GET, stoppt aber vor dem Download des Inhalts. Vergleichbare Methoden und Anfragebedingungen helfen bei der Fehlersuche; sie machen nicht jede Serverantwort identisch.