HTTP-Statuscode & Redirect-Checker

#HTTP-Statuscode & Redirect-Checker

HTTP-Statuscodes prüfen, Weiterleitungsketten testen und Response-Header analysieren. Diagnose von 1xx- bis 5xx-Fehlercodes nach RFC 9110, SEO-Auswirkungen und Behebungen.

Praxisnahe Produktions-Szenarien:
Statuscode & Anfrageumgebungs-Konfigurator
▼
Dynamische Simulationsparameter
Simulierte Netzwerklatenz45 ms
Effektive Cache-TTL3,600s (1.0h)
6 Geparste Header-Felder
Bidirektionale Fehlersymptom-Suche:
Healthy request executionNormal page view
RFC-Code: 200Idempotent: JASicher (Safe): JAZwischenspeicherbar (Cacheable): STANDARDMÄSSIG
HTTP-Weiterleitungs-AblaufdiagrammRTT: 45ms | Score: 100%
100%Sicherheits-Score1.0hCache-TTL-MessanzeigeCLIClient45ms200Ursprungsserver (Origin)SAFE
200

OK

RFC 9110 §15.3.1
2xx Statusklasse RFC-Header konform

Standard successful HTTP response. Action requested was received, understood, and accepted.

Primäre Produktionsursachen
  • Normal resource fetch
  • Successful query execution
  • API payload return
Fehlerbehebung & Architektur-Lösungen
  • Keep payload sizes optimized with gzip/brotli
  • Set explicit Cache-Control headers
RFC-Header-Prüfmatrix für HTTP 200:
Content-TypeVorhanden
Cache-ControlVorhanden
ETag / ValidatorVorhanden
Location HeaderNicht erforderlich
Engine: RFC 9110 / RFC 9111 Client-Evaluierungs-PipelineAusgewählt: 200 OK
RFC-Konformitätsspektrum60+ Statuscodes

Vollständige Abdeckung der IETF-Standards RFC 9110, RFC 9111, RFC 7235, RFC 6585 und RFC 8297.

Client-Arbeitsspeicher-IsolationKein Server-Upload

Private Cookies, JWT-Header und geheime URL-Tokens verlassen niemals Ihre lokale Browser-Sandbox.

Googlebot SEO-AuswirkungTiefen-Algorithmen-Audit

Modelliert PageRank-Link-Equity, Soft-404-Risiken, Crawl-Budget-Verbrauch und Deindexierungs-Geschwindigkeit.

Client-seitige Verarbeitung

Hochperformante Berechnung und Analyse direkt im lokalen Arbeitsspeicher des Browsers.

Zero-Server-Upload-Datenschutz

Alle Payloads und Header verbleiben strikt lokal ohne externe Serverkommunikation.

Produktionsreifer Export

Saubere, optimierte Ausgabeformate für den sofortigen produktiven Einsatz.

Die HTTP-Statusvalidierung entspricht den IETF-Standards RFC 9110 (HTTP-Semantik), RFC 9111 (HTTP-Caching), RFC 7235 (HTTP-Authentifizierung), RFC 6585 sowie Google Search Central-Spezifikationen. Weiterleitungsketten vor dem Produktiv-Rollout im Staging testen.

Technische Referenz & Architektur-Leitfaden

HTTP-Statuscode & Redirect Checker — Referenzhandbuch

HTTP-Statuscodes prüfen, Redirect-Ketten testen und Response-Header analysieren. Diagnose von 1xx- bis 5xx-Statuscodes, RFC-Spezifikationen, SEO-Einfluss und Behebungen.

HTTP-Statuscode & Redirect Checker — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss
HTTP-Statuscode & Redirect Checker — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss

Wichtige Parameter & Einstellungen

HTTP-Statuscode (RFC 9110)Dreistellige Ganzzahl (100 bis 599)

Der durch IETF RFC 9110 standardisierte dreistellige numerische Antwort-Statuscode. Unterteilt in 1xx (Information), 2xx (Erfolg), 3xx (Weiterleitung), 4xx (Client-Fehler) und 5xx (Server-Fehler).

Standard: 301
Ziel-URL oder Endpunkt-URIRFC 3986 Uniform Resource Identifier

Die Ziel-URL des Endpunkts, die auf HTTP-Statuscodes, Header-Konfigurationen und Weiterleitungs-Hops (Redirect Chains) überprüft wird.

Standard: https://example.com/old-page
Simuliertes User-Agent-ProfilHTTP-Client-Header-String

Der beim Test übermittelte User-Agent-Request-Header. Simuliert Suchmaschinen-Crawler (Googlebot Desktop, Googlebot Smartphone) gegenüber regulären Webbrowsern oder Entwicklertools.

Standard: googlebot-smartphone
Diagnostischer Architektur-KontextAuswahl des Evaluierungsmodus

Schaltet den Diagnosefokus flexibel um zwischen REST-API-Microservices, Crawler-SEO für Suchmaschinen, clientseitigem Browser-SPA-Fetch und Edge-CDN-/Reverse-Proxy-Infrastrukturen.

Standard: seo-crawler
Unformatierte HTTP-Response-HeaderCRLF-getrennter HTTP-Header-Text

Unformatierte HTTP-Statuszeile und Header-Schlüssel-Wert-Paare aus dem Terminal (cURL), dem DevTools-Netzwerk-Tab des Browsers oder Produktionsserver-Logs für das clientseitige Parsing.

Standard: HTTP/1.1 301 Moved Permanently Location: https://example.com/new-page Cache-Control: public, max-age=86400
HTTP-Request-Methode (Verb)RFC 9110 Anfragemethode

Die verwendete HTTP-Methode (GET, HEAD, POST, PUT, DELETE, PATCH, OPTIONS). Bestimmt, ob Redirect-Statuscodes den Request-Body beibehalten oder in GET umwandeln.

Standard: GET

Profi-Tipps & Best Practices

Die 301- vs. 308-Methodenumschreibungs-Falle: Warum POST-Requests zu GET mutieren

Historisch bedingt konvertierten gängige Webbrowser und HTTP-Client-Bibliotheken POST-Requests fälschlicherweise in GET-Requests, sobald sie eine 301 Moved Permanently- oder 302 Found-Antwort erhielten (RFC 7231 §6.4.2). Dieses Verhalten bricht schreibende REST-API-Operationen und Datei-Uploads ab. Um zu garantieren, dass HTTP-Methoden (POST, PUT, DELETE) und Payload-Bodies bei einer permanenten Weiterleitung strikt unverändert bleiben, definierten RFC 7538 und RFC 9110 den Statuscode HTTP 308 Permanent Redirect. Verwenden Sie für API-Endpunkte stets 308 und reservieren Sie 301 für klassische HTML-Seitenmigrationen.

404 Not Found vs. 410 Gone: Googlebot-Deindexierung gezielt beschleunigen

Wird eine Seite dauerhaft ohne Ersatz gelöscht, signalisiert HTTP 410 Gone Suchmaschinen-Crawlern unmissverständlich, dass die Entfernung beabsichtigt und endgültig ist. Während der Googlebot einen Status 404 Not Found als potenziell temporär einstuft und die verwaiste URL über Wochen oder Monate hinweg erneut crawlt, belegen offizielle Richtlinien von Google Search Central, dass HTTP 410 Gone die Entfernung aus dem Google-Index signifikant beschleunigt und wertvolles Crawl-Budget sofort schont.

RFC 9111 Heuristisches Standard-Caching bei Fehlercodes

Gemäß RFC 9111 §6.1 sind mehrere HTTP-Statuscodes standardmäßig zwischenspeicherbar – selbst wenn kein expliziter 'Cache-Control'-Header gesendet wird. Konkret gestatten 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 und 501 heuristisches Caching durch intermediäre Proxys und CDNs. Liefert eine API infolge eines kurzzeitigen Datenbank-Failovers fälschlich einen 404- oder 405-Fehler aus, cachen Edge-Proxys diese Fehlerantwort unter Umständen und liefern nachfolgenden legitimen Anfragen weiterhin 404 aus, sofern dies nicht durch 'Cache-Control: no-store, no-cache' verhindert wird.

502 Bad Gateway vs. 504 Gateway Timeout: Upstream-Fehler präzise lokalisieren

Die Differenzierung zwischen 502 und 504 lokalisiert die genaue Fehlerebene in modernen Reverse-Proxy-Architekturen (Nginx, AWS ALB, Cloudflare). Ein 502 Bad Gateway bedeutet, dass der Reverse-Proxy eine TCP-Verbindung zum Upstream-Anwendungscontainer aufbauen konnte, aber ein sofortiges TCP-Connection-Reset, fehlerhafte Response-Header oder einen Prozessabsturz (z. B. Node.js OOM Kill) registrierte. Ein 504 Gateway Timeout zeigt hingegen an, dass der Upstream-Prozess den Request zwar annahm und aktiv blieb, die Antwort jedoch nicht vor Ablauf des Proxy-Timeouts (etwa 'proxy_read_timeout') fertigstellen konnte.

Häufige Fehlerquellen & Fehlerbehebung

⚠️ERR_TOO_MANY_REDIRECTS (Zyklische Endlosschleife bei 301/302)

Dieser Fehler tritt auf, wenn URL A auf URL B weiterleitet und diese direkt oder indirekt wieder auf URL A zurückverweist. In Cloudflare- und Reverse-Proxy-Umgebungen resultiert dies meist aus einer 'SSL/TLS-Verschlüsselungs-Fehlkonfiguration' (z. B. Cloudflare im Modus 'Flexible SSL', das via unverschlüsseltem HTTP mit dem Ursprungsserver kommuniziert, während der Server eine strikte HTTP-zu-HTTPS-Weiterleitung via 301 erzwingt). Beheben Sie dies, indem Sie den Cloudflare-SSL-Modus auf 'Full (Strict)' umstellen oder die Rewrite-Regeln des Webservers synchronisieren.

⚠️CORS-Preflight-Fehlschlag bei Antworten mit 401 Unauthorized oder 403 Forbidden

Wenn ein Browser einen CORS-Preflight-Request (OPTIONS) oder einen authentifizierten Fetch-Aufruf absetzt, verwerfen Backend-Sicherheitsfilter (wie Spring Security, Express-Middleware oder AWS API Gateway) die Anfrage häufig mit 401 oder 403, bevor die 'Access-Control-Allow-Origin'-Header injiziert werden. Der Browser interpretiert dies als generischen CORS-Netzwerkfehler anstelle einer Authentifizierungsanforderung. Stellen Sie sicher, dass Ihre Sicherheits-Pipeline Preflight-OPTIONS-Anfragen von Authentifizierungsprüfungen ausnimmt und CORS-Header auch bei allen 4xx-Fehlerantworten zuverlässig mitsendet.

⚠️Soft-404-Warnung in der Google Search Console bei fehlenden Inhalten

Ein Soft 404 entsteht, wenn ein Webserver eine Seite mit dem Statuscode HTTP 200 OK ausliefert, der Seiteninhalt jedoch de facto leer ist, 'Artikel nicht gefunden' anzeigt oder stumm auf die Startseite weiterleitet. Der Googlebot stuft dies als irreführend ein, da Nutzer in eine Sackgasse geraten, während der Index die URL als valides Dokument führt. Konfigurieren Sie Ihren Webserver oder Ihre Next.js-Route so, dass explizit HTTP 404 Not Found oder 410 Gone zurückgegeben wird, oder leiten Sie per 301 auf eine gleichwertige, thematisch relevante Kategorieseite weiter.

⚠️503 Service Unavailable ohne Retry-After-Header führt zu SEO-Rankingverlust

Wird eine Anwendung für planmäßige Wartungsarbeiten offline genommen, führt ein reiner 503 Service Unavailable ohne RFC 7231 'Retry-After'-Header dazu, dass Suchmaschinen-Crawler die Downtime als unkontrollierten Systemausfall werten. Längere 503-Zustände ohne diesen Header provozieren vorübergehende Rankingverluste. Konfigurieren Sie Ihre Wartungsseite stets so, dass ein Header wie 'Retry-After: 3600' (Angabe in Sekunden) oder ein HTTP-Datums-String nach RFC 1123 mitgesendet wird, der dem Googlebot den exakten Wiederholungszeitpunkt mitteilt.

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen HTTP 301- und 302-Weiterleitungen?▼

Eine Weiterleitung mit HTTP 301 Moved Permanently signalisiert, dass die angeforderte Ressource dauerhaft an eine neue URL verschoben wurde. Suchmaschinen wie Google vererben 90 % bis 99 % des PageRank-Link-Equities an das neue Ziel und ersetzen die alte URL im Index. Zudem cachen Browser 301-Redirects standardmäßig aggressiv im lokalen Speicher. Ein HTTP 302 Found zeigt hingegen eine rein temporäre Verlagerung an: Suchmaschinen behalten die ursprüngliche URL im Index und Browser cachen die Weiterleitung im Regelfall nicht.

Was unterscheidet 401 Unauthorized von 403 Forbidden?▼

HTTP 401 Unauthorized bedeutet, dass der Anfrage gültige Authentifizierungsdaten fehlen. Gemäß RFC 7235 muss der Server einen 'WWW-Authenticate'-Header mitsenden, der das geforderte Authentifizierungsverfahren definiert (z. B. Basic oder Bearer-Token). Werden gültige Zugangsdaten übermittelt, kann der Zugriff gewährt werden. Im Gegensatz dazu besagt HTTP 403 Forbidden, dass der Server die Identität des Clients zwar kennt, dem Benutzer jedoch die erforderlichen Autorisierungsrechte für diese Ressource fehlen. Das erneute Senden von Anmeldedaten ändert an der Verweigerung nichts.

Wie beeinflussen HTTP-Statuscodes die SEO und das Google-Ranking?▼

HTTP-Statuscodes steuern das Crawling und die Indexierung durch den Googlebot unmittelbar. Ein 200 OK signalisiert funktionierenden, indexierbaren Inhalt. 301- und 308-Redirects konsolidieren das Link-Equity und aktualisieren kanonische URLs ohne Rankingverlust. Die Codes 404 und 410 weisen Crawler an, gelöschte Seiten aus dem Index zu entfernen, wobei 410 die Deindexierung beschleunigt und wertvolles Crawl-Budget schont. 5xx-Serverfehler (insbesondere anhaltende 500 oder 503) deuten auf Serverinstabilitäten hin, woraufhin der Googlebot die Crawling-Frequenz drosselt und betroffene URLs im Ranking herabstuft.

Was ist der Unterschied zwischen 502 Bad Gateway und 504 Gateway Timeout?▼

Beide Statuscodes treten an zwischengeschalteten Reverse-Proxys oder CDNs auf (wie Nginx, Cloudflare oder AWS ALB). Ein 502 Bad Gateway besagt, dass der Proxy den Upstream-Backendserver zwar erreichen konnte, dieser jedoch eine ungültige, korrumpierte oder unvollständige Antwort lieferte (etwa durch einen sofortigen Prozessabsturz oder TCP-Verbindungsabbruch). Ein 504 Gateway Timeout bedeutet, dass der Proxy die Verbindung zum Backend erfolgreich herstellte, das Backend jedoch das konfigurierte Timeout-Limit (wie 'proxy_read_timeout') überschritt, ohne eine Antwort zu senden.

Welche HTTP-Statuscodes sind laut RFC 9111 standardmäßig zwischenspeicherbar?▼

Nach RFC 9111 §6.1 gelten folgende Statuscodes auch ohne explizite Cache-Control-Header als standardmäßig zwischenspeicherbar (heuristisches Caching): 200 OK, 203 Non-Authoritative Information, 204 No Content, 206 Partial Content, 300 Multiple Choices, 301 Moved Permanently, 404 Not Found, 405 Method Not Allowed, 410 Gone, 414 URI Too Long und 501 Not Implemented. Alle übrigen Statuscodes erfordern explizite 'Cache-Control: public'- oder 'max-age'-Direktiven, um von geteilten Caches (Shared Caches/CDNs) vorgehalten zu werden.

Warum werden POST-Requests nach einem 301- oder 302-Redirect in GET umgewandelt?▼

Frühe Webbrowser wandelten POST-Requests bei 301- und 302-Weiterleitungen historisch in GET-Requests um, um zu verhindern, dass Formulardaten beim Folgen des Location-Headers versehentlich mehrfach abgesendet werden. Obwohl dieses nicht standardkonforme Verhalten später in RFC 7231 nachträglich dokumentiert wurde, schufen moderne HTTP-Spezifikationen mit HTTP 307 Temporary Redirect und HTTP 308 Permanent Redirect (RFC 9110) verbindliche Standards, die eine Änderung der HTTP-Methode oder des Request-Bodys bei Weiterleitungen strikt untersagen.

Verwandte Tools & Hilfsprogramme

Alle Tools →