Cyberknecht

Wissen / Cheatsheets / Webentwicklung

HTTP-Statuscodes: 200, 301, 404, 500 erklärt

Die wichtigsten HTTP-Antworten und typische Ursachen.

Stand: 27.10.2026 · Redaktion: Carl Thorns · Kostenlos und ohne Anmeldung

PDF herunterladenAlle Ressourcen

Dieser Leitfaden führt dich vom konkreten Ausgangsproblem über die praktische Umsetzung bis zur überprüfbaren Abnahme. Jeder Abschnitt nennt eine Methode, ein Beispiel, ein Erfolgskriterium und eine typische Fehlerquelle.

Arbeitsablauf auf einen Blick

1. 2xx: Erfolg

200 bedeutet erfolgreiche Antwort, 201 neu angelegte Ressource, 204 Erfolg ohne Body.

Praxisbeispiel
POST /api/items → 201 Created mit Location-Header.
So erkennst du, dass es funktioniert: API-Vertrag passt zu Status und Response-Body.
Typischer Fehler: Bei 204 dennoch JSON-Body erwarten.

2. 3xx: Umleitung

301/308 stehen für permanente, 302/307 für temporäre Weiterleitung; 307/308 bewahren die HTTP-Methode.

Praxisbeispiel
GET /alt → 301 Location: /neu
So erkennst du, dass es funktioniert: Redirect endet auf der gewünschten Ressource.
Typischer Fehler: Lange Redirect-Ketten oder Schleifen.

3. 4xx: Clientfehler

400 ungültige Anfrage, 401 nicht authentifiziert, 403 verboten, 404 nicht gefunden, 409 Konflikt, 429 zu viele Anfragen.

Praxisbeispiel
GET /api/private → 401 mit passender Authentifizierungsinformation.
So erkennst du, dass es funktioniert: Client erhält einen verständlichen, nicht sensitiven Fehler.
Typischer Fehler: 401 und 403 verwechseln oder interne Details verraten.

4. 5xx: Serverfehler

500 unerwarteter Serverfehler, 502 Gatewayfehler, 503 temporär nicht verfügbar, 504 Gateway-Timeout.

Praxisbeispiel
503 mit Retry-After bei geplanter Wartung.
So erkennst du, dass es funktioniert: Monitoring und Logs erfassen Fehler ohne personenbezogene Details zu leaken.
Typischer Fehler: Alle Exceptions pauschal als 200 zurückgeben.

5. Diagnose mit curl

Untersuche Status, Header und Weiterleitungen getrennt.

Praxisbeispiel
curl -I https://example.org curl -L -I https://example.org/alt
So erkennst du, dass es funktioniert: Erwarteter Endstatus und Redirect-Pfad sind nachvollziehbar.
Typischer Fehler: Nur Browseranzeige statt HTTP-Antwort prüfen.

Abnahmeprotokoll für die Praxis

Nutze die folgenden Punkte als dokumentierbare Abnahme. Trage bei jedem Punkt Datum, getestete URL beziehungsweise System, Ergebnis und gegebenenfalls einen offenen Befund ein.

  1. Abnahmekriterium: API-Vertrag passt zu Status und Response-Body.

  2. Abnahmekriterium: Redirect endet auf der gewünschten Ressource.

  3. Abnahmekriterium: Client erhält einen verständlichen, nicht sensitiven Fehler.

  4. Abnahmekriterium: Monitoring und Logs erfassen Fehler ohne personenbezogene Details zu leaken.

  5. Abnahmekriterium: Erwarteter Endstatus und Redirect-Pfad sind nachvollziehbar.

Fachquellen und weiterführende Dokumentation

Diese Primärquellen dienen zur Vertiefung und zur Prüfung versionsabhängiger Details. Bei rechtlichen Themen ersetzt der Leitfaden keine individuelle Rechtsberatung.

Praxisvertiefung: Statuscodes als Diagnosehilfe

2xx bedeutet erfolgreiche Verarbeitung, 3xx Umleitung, 4xx Problem mit der Anfrage und 5xx Serverfehler. Ein 200-Status garantiert keinen inhaltlich korrekten HTML-Inhalt.

Technische Umsetzung

200 OK, 201 Created, 301 Moved Permanently, 302 Found, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error, 503 Service Unavailable.

So überprüfst du das Ergebnis

Prüfe mit curl -I und bei Bedarf ohne -I den vollständigen Response. Für SEO sind unnötige Redirect-Ketten und Soft-404-Seiten besonders relevant.