HTTP-Statuscodes für Entwickler erklärt – Was jeder Code bedeutet

Warum du HTTP-Statuscodes verstehen musst#

Deine E-Commerce-Seite gibt während des Checkouts einen 500-Fehler zurück. Kunden sehen "Etwas ist schiefgelaufen". Aber was ist tatsächlich schiefgelaufen? Der Server läuft einwandfrei. Die Datenbank ist online. Das Problem liegt woanders – aber die 500 verrät dir nicht, wo.

Dein API-Endpoint gibt einen 429-Fehler zurück, und deine mobile App stürzt ab, statt eine Wiederholungsmeldung anzuzeigen. Nutzer denken, die App sei kaputt, dabei macht dein Rate-Limiter nur seinen Job.

Deine Statusseite zeigt "Alle Systeme betriebsbereit", aber Kunden melden Seiten, die als HTTP 403 Forbidden laden. Dein Monitoring hat es nicht erkannt, weil es nur die Startseite prüft.

HTTP-Statuscodes sind Signale. Sie sagen dir, was schiefgelaufen ist und wo du nachsehen musst. Aber nur, wenn du verstehst, was jeder Code bedeutet.

Dieser Guide erklärt jeden HTTP-Statuscode, dem du begegnen wirst, was ihn auslöst und was du tun solltest, wenn du einen siehst.

---

HTTP-Statuscodes: Das vollständige Bild#

HTTP-Antworten sind in fünf Klassen organisiert:

• 1xx (100-199): Informational — "Anfrage erhalten, wird verarbeitet"
• 2xx (200-299): Erfolg — "Alles hat funktioniert"
• 3xx (300-399): Weiterleitung — "Versuche es woanders"
• 4xx (400-499): Client-Fehler — "Du hast einen Fehler gemacht"
• 5xx (500-599): Server-Fehler — "Wir haben einen Fehler gemacht"

Jede Klasse sagt dir, wo das Problem liegt. Bei 4xx-Fehlern liegt das Problem an der Anfrage (falsche URL, falsche Authentifizierung, fehlende Daten). Bei 5xx-Fehlern liegt das Problem am Server.

---

2xx Erfolgs-Statuscodes (Alles hat funktioniert)#

200 OK#

Was es bedeutet: Die Anfrage war erfolgreich. Der Antwort-Body enthält die angeforderten Daten.

Wann du es siehst:

• Browser lädt eine Webseite
• API gibt JSON-Daten zurück
• Formular-Übermittlung erfolgreich

Beispiel:

GET /api/users/123
Response: 200 OK
Body: {"id": 123, "name": "John", "email": "john@example.com"}

Aktion: Keine. Alles funktioniert korrekt.

201 Created#

Was es bedeutet: Die Anfrage war erfolgreich und eine neue Ressource wurde erstellt. Die Antwort enthält die neu erstellte Ressource.

Wann du es siehst:

• POST zum Anlegen eines neuen Users gibt 201 Created zurück
• Anlegen einer neuen Bestellung gibt 201 Created zurück
• Hochladen einer Datei gibt 201 Created zurück

Beispiel:

POST /api/users
Request: {"name": "Jane", "email": "jane@example.com"}
Response: 201 Created
Body: {"id": 456, "name": "Jane", "email": "jane@example.com", "created_at": "2026-02-20T10:00:00Z"}

Aktion: Keine. Die Ressource wurde erfolgreich erstellt.

202 Accepted#

Was es bedeutet: Die Anfrage wurde zur Verarbeitung angenommen, aber noch nicht verarbeitet. Wird für asynchrone Operationen verwendet.

Wann du es siehst:

• Einreichen eines länger laufenden Jobs (z.B. Video-Encoding, Report-Generierung)
• Batch-Verarbeitungs-Operationen
• Aufgaben, die im Hintergrund verarbeitet werden

Beispiel:

POST /api/batch-emails/send
Request: {"recipient_ids": [1,2,3,...,10000]}
Response: 202 Accepted
Body: {"job_id": "job_12345", "status": "queued"}

Aktion: Die Aufgabe ist in der Queue. Prüfe später mit der Job-ID den Status.

204 No Content#

Was es bedeutet: Die Anfrage war erfolgreich, aber es gibt keinen Inhalt zurückzugeben.

Wann du es siehst:

• DELETE-Anfragen (erfolgreich gelöscht, nichts zurückzugeben)
• Erfolgreiches PATCH ohne Antwort-Body
• Webhook-Bestätigungen

Beispiel:

DELETE /api/users/123
Response: 204 No Content
Body: (leer)

Aktion: Keine. Die Aktion war erfolgreich.

---

3xx Weiterleitungs-Statuscodes (Versuche es woanders)#

301 Moved Permanently#

Was es bedeutet: Die Ressource wurde dauerhaft auf eine neue URL verschoben. Suchmaschinen aktualisieren ihren Index, und Browser verwenden für zukünftige Anfragen die neue URL.

Wann du es siehst:

• Website wurde von www.oldsite.com zu newsite.com migriert
• Alter API-Endpoint durch neuen ersetzt
• URL-Struktur geändert

Beispiel:

GET /old-page.html
Response: 301 Moved Permanently
Header: Location: /new-page.html

Aktion:

• Für Nutzer: Browser folgt der Weiterleitung automatisch (transparent)
• Für SEO: Stelle sicher, dass 301 für dauerhafte Änderungen verwendet wird (Google überträgt PageRank)
• Für APIs: Clients sollten auf die neue URL umstellen

302 Found (Temporary Redirect)#

Was es bedeutet: Die Ressource wurde vorübergehend auf eine andere URL verschoben. Die ursprüngliche URL ist noch gültig, daher cachen Browser die neue URL NICHT.

Wann du es siehst:

• Temporäre Weiterleitungen während Wartungsarbeiten
• Weiterleitungen zur Login-Seite
• A/B-Testing (einige Nutzer vorübergehend auf neue Version umleiten)

Beispiel:

GET /products/discount-flash-sale
Response: 302 Found
Header: Location: /products/2026-flash-sale

Aktion: Browser folgt der Weiterleitung vorübergehend, behandelt die ursprüngliche URL aber weiterhin als primär.

304 Not Modified#

Was es bedeutet: Die Ressource hat sich seit deiner letzten Anfrage nicht geändert. Verwende die gecachte Version.

Wann du es siehst:

• Browser prüft, ob sich die Webseite seit dem letzten Besuch geändert hat (prüft Änderungsdatum/ETag)
• API gibt 304 zurück, wenn sich Daten seit der letzten Anfrage nicht geändert haben
• Reduziert Bandbreite, indem unveränderte Daten nicht erneut gesendet werden

Beispiel:

GET /api/user-profile
Request Header: If-Modified-Since: 2026-02-19 10:00:00
Response: 304 Not Modified
Body: (leer – verwende die zuvor gecachte Version)

Aktion: Browser/Client verwendet lokal die gecachte Version.

307 Temporary Redirect#

Was es bedeutet: Wie 302, aber garantiert, dass die HTTP-Methode während der Weiterleitung gleich bleibt.

Technischer Unterschied:

• 302 erlaubt einen Methodenwechsel (POST → GET nach Weiterleitung)
• 307 behält die Methode bei (POST → POST nach Weiterleitung)

Wann du es siehst:

• Formular-Übermittlung leitet auf Bestätigungsseite weiter (POST → POST)
• API-Weiterleitungen, die die Methode beibehalten müssen

Warum es wichtig ist: Ältere Browser haben POST-Weiterleitungen manchmal in GET umgewandelt, wodurch Formulardaten verloren gehen konnten. 307 verhindert das.

---

4xx Client-Fehler-Codes (Du hast einen Fehler gemacht)#

400 Bad Request#

Was es bedeutet: Die Anfrage war fehlerhaft formatiert. Der Server konnte sie nicht verstehen.

Wann du es siehst:

• Fehlerhaftes JSON im Request-Body
• Fehlende Pflichtfelder
• Ungültiges Parameterformat
• Syntaxfehler im Query-String

Beispiel:

POST /api/users
Request Body: {"name": "Jane" "email": "jane@example.com"}
                              ↑ Fehlendes Komma
Response: 400 Bad Request
Body: {"error": "Invalid JSON syntax"}

Aktion:

• Request-Formatierung prüfen
• JSON-Syntax validieren
• Sicherstellen, dass Pflichtfelder vorhanden sind
• Parametertypen mit der API-Dokumentation abgleichen

401 Unauthorized#

Was es bedeutet: Authentifizierung fehlgeschlagen oder fehlt. Du hast nicht nachgewiesen, wer du bist.

Wann du es siehst:

• Kein Authentifizierungs-Token bereitgestellt
• Authentifizierungs-Token ist ungültig oder abgelaufen
• Falscher Username/Passwort
• Fehlender API-Key

Beispiel:

GET /api/user-profile
(Kein Authorization-Header)
Response: 401 Unauthorized
Body: {"error": "Authentication required"}

Aktion:

• Gültige Authentifizierung bereitstellen (Login, API-Key, Token, etc.)
• Abgelaufene Tokens erneuern
• Prüfen, ob die Zugangsdaten korrekt sind

403 Forbidden#

Was es bedeutet: Authentifizierung war erfolgreich, aber du hast keine Berechtigung, auf diese Ressource zuzugreifen.

Wann du es siehst:

• User versucht, das Konto eines anderen Users zu löschen
• User versucht, auf einen Admin-only-Endpoint zuzugreifen
• User versucht, auf eine Ressource einer anderen Organisation zuzugreifen
• Unzureichende Berechtigungen/Rolle

Beispiel:

DELETE /api/users/999
(Authentifiziert als User 123, versucht User 999 zu löschen)
Response: 403 Forbidden
Body: {"error": "You can only delete your own account"}

Aktion:

• Korrektes Konto mit passenden Berechtigungen verwenden
• Bei Bedarf erweiterte Berechtigungen anfordern
• Prüfen, ob du auf die richtige Ressource zugreifst

404 Not Found#

Was es bedeutet: Die Ressource existiert nicht oder der Server weiß nicht, wie er diesen Endpoint behandeln soll.

Wann du es siehst:

• URL-Tippfehler (/users/ vs /users)
• Endpoint existiert nicht
• Gelöschte Ressource
• Falsche API-Version

Beispiel:

GET /api/users/nonexistent-id-12345
Response: 404 Not Found
Body: {"error": "User not found"}

Aktion:

• URL-Schreibweise prüfen
• Verifizieren, dass der Endpoint existiert
• API-Dokumentation prüfen
• Eine andere ID/Ressource versuchen

405 Method Not Allowed#

Was es bedeutet: Der Endpoint existiert, unterstützt aber diese HTTP-Methode nicht.

Wann du es siehst:

• POST auf einem Endpoint verwenden, der nur GET akzeptiert
• DELETE auf einem Endpoint verwenden, der kein Löschen unterstützt
• PATCH verwenden, wenn nur PUT erlaubt ist

Beispiel:

DELETE /api/domains/123
(Wenn DELETE auf dem domains-Endpoint nicht unterstützt wird)
Response: 405 Method Not Allowed
Header: Allow: GET, POST, PUT

Aktion: Verwende die korrekte HTTP-Methode. Die Antwort enthält in der Regel den Allow-Header mit den gültigen Methoden.

408 Request Timeout#

Was es bedeutet: Der Server hat zu lange auf das Senden der Anfrage durch den Client gewartet und aufgegeben.

Wann du es siehst:

• Langsamer Client lädt eine große Datei hoch
• Netzwerkverbindung bricht mitten in der Anfrage ab
• Anfrage dauert länger als der Server-Timeout (üblicherweise 30-300 Sekunden)

Beispiel:

POST /api/upload
(Hochladen einer 500MB-Datei über langsame Verbindung dauert 10 Minuten)
Response: 408 Request Timeout

Aktion:

• Anfrage wiederholen
• Große Anfragen in kleinere Chunks aufteilen
• Netzwerkverbindung prüfen
• Bei Bedarf Client-Timeout erhöhen

429 Too Many Requests#

Was es bedeutet: Du sendest zu viele Anfragen. Rate-Limit überschritten.

Wann du es siehst:

• API-Rate-Limit erreicht (z.B. 100 Requests/Minute)
• E-Mails werden zu schnell versendet
• Brute-Force-Login-Versuche
• Web Scraper belastet den Server zu stark

Beispiel:

GET /api/users/123
(100. Anfrage in der letzten Minute)
Response: 429 Too Many Requests
Header: Retry-After: 60
Body: {"error": "Rate limit exceeded. Try again in 60 seconds"}

Aktion:

• Vor erneutem Versuch warten (Retry-After-Header prüfen)
• Exponential Backoff implementieren
• Pagination für große Result Sets verwenden
• Ergebnisse lokal cachen statt erneut anzufordern

---

5xx Server-Fehler-Codes (Wir haben einen Fehler gemacht)#

500 Internal Server Error#

Was es bedeutet: Auf dem Server ist etwas schiefgelaufen, und der Server kann keine weiteren Details liefern.

Wann du es siehst:

• Unbehandelte Exception im Code
• Datenbank-Verbindung fehlgeschlagen
• Out-of-Memory
• Unerwarteter Zustand

Beispiel:

POST /api/checkout
Response: 500 Internal Server Error
Body: {"error": "Something went wrong"}

Warum es vage ist: Server geben aus Sicherheitsgründen keine internen Fehlerdetails an Clients weiter. Detaillierte Fehlermeldungen helfen Angreifern.

Aktion:

• Server-Logs auf den eigentlichen Fehler prüfen
• Bei Drittanbieter-Service: Support kontaktieren
• Bei eigenem Service: Error-Logs prüfen, bei Bedarf neu starten, letztes Deployment zurückrollen

501 Not Implemented#

Was es bedeutet: Der Server unterstützt diese HTTP-Methode oder dieses Feature nicht.

Wann du es siehst:

• Server unterstützt keine HTTP/2-Features
• WebSocket nicht unterstützt
• Bestimmte HTTP-Methoden sind nicht implementiert

Beispiel:

OPTIONS /api/users
(Server unterstützt OPTIONS-Methode nicht)
Response: 501 Not Implemented

Aktion: In der Regel nichts – verwende eine andere Methode oder einen anderen Service. In modernen APIs selten.

502 Bad Gateway#

Was es bedeutet: Der Server hat eine ungültige Antwort von einem vorgelagerten Server erhalten.

Reale Szenarien:

1. Reverse Proxy (Nginx) kann das Backend nicht erreichen

   Client → Nginx (Gateway) → Node.js Backend
                   ↑
            Backend ist offline oder reagiert nicht
   

2. Load Balancer erreicht kein gesundes Backend

   Client → Load Balancer → Backend Server
                         ↑
              Alle Backends offline oder langsam
   

3. API Gateway erreicht den Microservice nicht

   Client → API Gateway → Auth Service (offline)
                       → User Service
                       → Order Service
   

Warum es passiert:

• Backend-Server ist abgestürzt
• Netzwerk-Konnektivität verloren
• Vorgelagerter Server ist langsam und läuft in Timeout
• Vorgelagerter Server gibt fehlerhafte Antwort zurück

Beispiel:

GET /dashboard
Response: 502 Bad Gateway

Hinter den Kulissen:

Nginx hat die Anfrage erhalten
Versuchte, sie an Node.js-Server auf localhost:3000 weiterzuleiten
Verbindung verweigert (Server läuft nicht)
Nginx gab zurück: 502 Bad Gateway

Aktion:

• Prüfen, ob Backend-Services laufen: docker ps, pm2 status, systemd-Status
• Netzwerk-Konnektivität zum Backend prüfen
• Backend-Logs auf Crashes prüfen
• Backend-Service bei Crash neu starten
• Prüfen, ob der Load Balancer korrekt routet

503 Service Unavailable#

Was es bedeutet: Der Server kann Anfragen vorübergehend nicht bearbeiten (Wartung, Überlastung, Abhängigkeiten offline).

Wann du es siehst:

• Server startet neu
• Server ist stark ausgelastet (alle Verbindungen belegt)
• Datenbank ist offline oder wird migriert
• Drittanbieter-Abhängigkeit ist offline
• Deployment läuft (Traffic ist pausiert)

Beispiel:

GET /api/users
Response: 503 Service Unavailable
Header: Retry-After: 600
Body: {"error": "Server is undergoing maintenance. Try again in 10 minutes"}

Warum Server während der Wartung 503 zurückgeben:

• Sagt Clients "das ist temporär, versuche es später erneut"
• Browser und Clients wissen, dass sie automatisch wiederholen sollen
• Suchmaschinen bestrafen 503 nicht (anders als 500, das wie ein Bug aussieht)

Aktion:

• Warten und wiederholen (Retry-After-Header für die Wartezeit prüfen)
• Statusseite auf Wartungsfenster prüfen
• Bei internem Service: warten, bis das Deployment abgeschlossen ist, Logs prüfen

504 Gateway Timeout#

Was es bedeutet: Der Server hat nicht rechtzeitig eine Antwort vom vorgelagerten Server erhalten.

Wann du es siehst:

• Backend-Server ist zu langsam
• Netzwerk-Latenz zu hoch
• Datenbank-Query dauert zu lange
• Vorgelagerter Server hängt

Beispiel:

Backend-Anfrage:
GET /api/heavy-report
30 Sekunden warten...
Timeout!
Response: 504 Gateway Timeout

Reale Ursache:

Client → Nginx (30s Timeout) → Node.js Backend (60s Query)
                             ↑
              Nginx gibt nach 30s auf
              Backend führt die Query weiter aus

Aktion:

• Backend-Performance prüfen
• Nach langsamen Datenbank-Queries suchen
• Code optimieren
• Datenbank-Indizes hinzufügen
• Timeout erhöhen, wenn die Operation legitim länger dauert
• Lange Operationen in asynchrone Jobs aufteilen

---

HTTP-Statuscodes Referenztabelle#

Code	Name	Kategorie	Bedeutung
200	OK	Erfolg	Anfrage erfolgreich
201	Created	Erfolg	Ressource erstellt
202	Accepted	Erfolg	Anfrage zur Verarbeitung in Queue
204	No Content	Erfolg	Erfolg, kein Antwort-Body
301	Moved Permanently	Weiterleitung	Neue URL dauerhaft verwenden
302	Found	Weiterleitung	Vorübergehend auf anderer URL
304	Not Modified	Weiterleitung	Gecachte Version verwenden
307	Temp Redirect	Weiterleitung	HTTP-Methode bei Weiterleitung beibehalten
400	Bad Request	Client-Fehler	Fehlerhafte Anfrage
401	Unauthorized	Client-Fehler	Authentifizierung erforderlich
403	Forbidden	Client-Fehler	Zugriff verweigert
404	Not Found	Client-Fehler	Ressource existiert nicht
405	Method Not Allowed	Client-Fehler	Falsche HTTP-Methode
408	Request Timeout	Client-Fehler	Anfrage hat zu lange gedauert
429	Too Many Requests	Client-Fehler	Rate-Limit erreicht
500	Internal Server Error	Server-Fehler	Generischer Server-Fehler
501	Not Implemented	Server-Fehler	Feature nicht unterstützt
502	Bad Gateway	Server-Fehler	Fehler im vorgelagerten Server
503	Service Unavailable	Server-Fehler	Server vorübergehend offline
504	Gateway Timeout	Server-Fehler	Vorgelagerter Server zu langsam

---

So debuggst du Probleme mit HTTP-Statuscodes#

Schritt 1: Statuscode identifizieren#

Im Browser:

1. Entwicklertools öffnen (F12)
2. Zum Network-Tab wechseln
3. Fehlgeschlagene Anfrage suchen
4. Die Status-Spalte zeigt den Code

Im Terminal:

curl -i https://example.com/endpoint
# Erste Zeile zeigt: HTTP/1.1 200 OK

In der Anwendung:

• Error-Logs prüfen
• Response-Objekt anschauen
• Die meisten Frameworks geben den Statuscode aus

Schritt 2: Verstehen, was er bedeutet#

Verwende die Kategorien:

• 2xx? Funktioniert wie vorgesehen
• 3xx? Weiterleitungsziel prüfen
• 4xx? Request-Format und Berechtigungen prüfen
• 5xx? Server-Logs und vorgelagerte Abhängigkeiten prüfen

Schritt 3: Response-Body und -Header prüfen#

Response-Body: Die meisten APIs liefern Fehlerdetails:

{
  "error": "User not found",
  "message": "No user with ID 12345",
  "code": "USER_NOT_FOUND"
}

Response-Header: Wichtige:

• Retry-After — Wie lange bis zum erneuten Versuch warten (429, 503)
• Allow — Gültige HTTP-Methoden (405)
• Location — Wohin weiterleiten (3xx)
• WWW-Authenticate — Wie authentifiziert wird (401)

Schritt 4: Aktion basierend auf der Code-Klasse#

4xx Client-Fehler:

• Hast du falsche Daten gesendet? Anfrage korrigieren
• Ist ein Tippfehler in der URL? Korrigieren
• Keine Berechtigung? Zugriff anfordern
• Falscher Endpoint? Dokumentation prüfen

5xx Server-Fehler:

• Läuft der Server? Uptime prüfen
• Zeigen die Logs Fehler? Fehler beheben
• Ist das Upstream offline? Auf Wiederherstellung warten
• Wurde gerade deployt? Bei Bedarf zurückrollen

---

Praxisbeispiel: Ein 502 Bad Gateway debuggen#

Szenario:

GET /api/checkout
Response: 502 Bad Gateway
Kunden können keine Käufe abschließen

Schritt 1: Bestätigen, dass es ein 502 ist ✓ Response-Header zeigt HTTP/1.1 502 Bad Gateway

Schritt 2: Prüfen, was 502 bedeutet ✓ Vorgelagerter Server antwortet nicht korrekt

Schritt 3: Problem diagnostizieren

Laufen die Backend-Services?

docker ps
# Output: checkout-service is not running

✗ Checkout-Service ist abgestürzt

Schritt 4: Root Cause finden

Logs prüfen:

docker logs checkout-service
# Out of memory error!
# Java heap space exhausted

Schritt 5: Beheben

Speicher erhöhen:

docker-compose up -d --build

Oder neu starten:

docker restart checkout-service

Schritt 6: Verifizieren

curl -i https://api.example.com/api/checkout
# HTTP/1.1 200 OK ✓

---

Statuscodes in Echtzeit überwachen#

Warum du sie überwachen solltest#

• Downtime erkennen, bevor Kunden sie melden
• 5xx-Fehler abfangen, die nur bestimmte Endpoints betreffen
• 4xx-Fehler tracken, um API-Missbrauch zu finden
• 429-Rate-Limits überwachen, um zu wissen, wann skaliert werden muss

Was du überwachen solltest#

Kritisch (Pager bei Ausfall):

• Jegliche 5xx-Fehler auf kritischen Endpoints (Checkout, Login, Payment)

Wichtig (untersuchen):

• Spike bei 429-Fehlern (Rate-Limiting bedeutet, dass du nahe an der Kapazitätsgrenze bist)
• Steigende 502/504-Fehler (Upstream-Verschlechterung)
• Anstieg bei 403/401-Fehlern (möglicher Brute-Force-Angriff)

Informativ (Trends verfolgen):

• 404-Fehler (werden falsche URLs angefragt?)
• 400-Fehler (senden Clients fehlerhafte Anfragen?)

Statuscodes mit Nova Uptime überwachen#

Das Uptime-Monitoring von Nova Uptime trackt HTTP-Statuscodes in Echtzeit:

1. Monitor gibt 200 zurück? Seite ist online ✓
2. Monitor gibt 404 zurück? Falsche URL oder Endpoint gelöscht ✗
3. Monitor gibt 429 zurück? Du wirst rate-limited ⚠️
4. Monitor gibt 502/503 zurück? Backend-Problem ✗
5. Monitor gibt 504 zurück? Timeout, Optimierung nötig ⚠️

Nova Uptime zeigt dir:

• Welche Statuscodes zurückgegeben werden
• Wann sie aufgetreten sind
• Welche Endpoints betroffen sind
• Trend über die Zeit

---

HTTP-Statuscodes und SEO#

Suchmaschinen nutzen Statuscodes, um zu entscheiden, wie Seiten indexiert werden:

200 OK: Diese Seite indexieren (normal)

301 Moved Permanently: Index aktualisieren, sodass er auf die neue URL zeigt

302 Found: Alte URL im Index behalten, der Weiterleitung nicht folgen

304 Not Modified: Nicht erneut crawlen, letzte Version ist aktuell

401/403: Nicht indexieren (Zugriff verweigert)

404 Not Found: Aus dem Index entfernen (Seite ist weg)

410 Gone: Aus dem Index entfernen (Seite ist weg, kommt nicht zurück)

429/503/504: Später wiederholen (temporäres Problem)

5xx-Fehler: Mögliches Site-Problem; Google verlangsamt das Crawling

Wichtig für die Site-Health:

• 301 für dauerhafte URL-Änderungen verwenden (erhält den SEO-Wert)
• 410 verwenden, um Google explizit mitzuteilen, dass eine Seite weg ist
• 5xx-Fehler schnell beheben (Google priorisiert kaputte Seiten ab)
• robots.txt implementieren, um 404s auf nicht-indexierbarem Content zu vermeiden

---

Zusammenfassung: HTTP-Statuscodes Schnellreferenz#

Alles in Ordnung:

• 200 OK — Normaler Erfolg
• 201 Created — Neue Ressource erstellt
• 204 No Content — Erfolg, keine Antwort nötig

Weiterleitung an einen anderen Ort:

• 301/302 — Weiterleitung zur neuen URL folgen
• 304 — Gecachte Version verwenden

Du hast einen Fehler gemacht:

• 400 Bad Request — Request-Formatierung korrigieren
• 401 Unauthorized — Authentifizierung bereitstellen
• 403 Forbidden — Du hast keine Berechtigung
• 404 Not Found — Falsche URL
• 429 Too Many Requests — Langsamer machen, du wirst rate-limited

Wir haben einen Fehler gemacht:

• 500 Internal Server Error — Server-Logs prüfen
• 502 Bad Gateway — Backend-Service ist offline
• 503 Service Unavailable — Server vorübergehend offline
• 504 Gateway Timeout — Backend ist zu langsam

Monitoring mit Nova Uptime: Das HTTP-Monitoring von Nova Uptime erkennt diese Fehler sofort und alarmiert dich, bevor Kunden es merken. Überwache kritische Endpoints, tracke Statuscode-Trends und erhalte Alerts, wenn 5xx-Fehler hochschnellen.

---

Zuletzt aktualisiert: 20. Februar 2026 Nova Uptime überwacht HTTP-Statuscodes über mehr als 50 Check-Typen und alarmiert in Echtzeit bei 5xx-Fehlern