Was sind HTTP-Statuscodes?
HTTP-Statuscodes sind die dreistelligen Zahlen, die ein Server mit jeder Antwort zurückschickt, um dem Client mitzuteilen, was passiert ist: Die Anfrage war erfolgreich, die Ressource wurde verschoben, der Client hat einen Fehler gemacht oder der Server ist gescheitert. Sie sind im HTTP-Standard (RFC 9110) definiert und der schnellste Weg, um zu verstehen, warum sich eine Seite, ein API-Aufruf oder eine Monitoring-Prüfung so verhalten hat. Dieser Spickzettel behandelt die Codes, denen Sie im Produktivbetrieb tatsächlich begegnen, was sie für SEO und Uptime bedeuten und welche davon einen Alarm verdienen.
Die fünf Klassen von HTTP-Statuscodes
Die erste Ziffer eines Statuscodes bestimmt seine Klasse. An der Klasse erkennen Sie sofort, ob es sich um einen Erfolg, eine Weiterleitung, ein Problem auf Client-Seite oder einen Serverfehler handelt.
Statuscode-Klassen
1xx-Informationsantworten
1xx-Codes sind Zwischenantworten, die vor der endgültigen Antwort gesendet werden. Browser und HTTP-Bibliotheken verarbeiten sie automatisch, daher tauchen sie in Logs oder Monitoring-Ergebnissen selten auf.
Continue
Der Server hat die Request-Header empfangen, und der Client darf den Request-Body senden. Wird mit dem Header Expect: 100-continue bei großen Uploads verwendet.
Switching Protocols
Der Server wechselt auf Wunsch des Clients das Protokoll – meist beim Upgrade einer Verbindung auf WebSocket.
Early Hints
Early Hints: Der Server sendet Link-Header vor der endgültigen Antwort, damit der Browser kritisches CSS, Schriften oder Skripte schon vorab laden kann.
2xx-Erfolgsantworten
2xx-Codes bedeuten, dass die Anfrage empfangen, verstanden und angenommen wurde. Für die meisten Seiten und Health-Check-Endpunkte ist 200 die erwartete Antwort – alles andere verdient einen zweiten Blick.
OK
Die Anfrage war erfolgreich, und der Response-Body enthält die angeforderte Ressource. Die normale Antwort für Seiten und GET-Anfragen.
Created
Die Anfrage war erfolgreich und hat eine neue Ressource erstellt, typischerweise nach einem POST an eine API. Der Location-Header verweist meist auf die neue Ressource.
No Content
Die Anfrage war erfolgreich, es gibt aber keinen Body zurückzugeben. Üblich bei DELETE-Anfragen und bei APIs, die nur eine Aktion bestätigen.
Partial Content
Der Server liefert nur einen Teil der Ressource, weil der Client einen Range-Header gesendet hat. Wird für Video-Streaming und fortsetzbare Downloads genutzt.
Worauf Sie bei 2xx-Antworten achten sollten
- Ein 200 beweist nicht, dass die Seite funktioniert: Eine Fehlerseite mit Status 200 erscheint in der Google Search Console als „Soft 404“
- Prüfen Sie, ob wichtige Seiten den erwarteten Inhalt liefern, nicht nur einen Erfolgscode
- Erwarten Sie 201 oder 204 von schreibenden Endpunkten; ein 200 kann dort auf eine geänderte API hinweisen
- 206 sollte nur dort auftauchen, wo Sie tatsächlich Range-Anfragen bedienen
3xx-Weiterleitungen
3xx-Codes teilen dem Client mit, dass die Ressource woanders liegt oder sich nicht geändert hat. Die richtige Weiterleitung ist wichtig für SEO: Google behandelt permanente und temporäre Weiterleitungen unterschiedlich, wenn es entscheidet, welche URL indexiert wird.
Moved Permanently
Moved Permanently. Die Ressource hat eine neue, dauerhafte URL. Geeignet für Domainumzüge, HTTPS-Migrationen und neue URL-Strukturen. Clients dürfen dabei POST in GET umwandeln.
Found
Found. Die Ressource liegt vorübergehend unter einer anderen URL, die ursprüngliche soll indexiert bleiben. Geeignet für kurzfristige Umleitungen wie Wartungsseiten.
Not Modified
Not Modified. Die zwischengespeicherte Kopie ist noch gültig, der Server sendet keinen Body. Ein Zeichen, dass bedingte Anfragen und Caching-Header funktionieren.
Temporary Redirect
Temporary Redirect. Wie 302, aber der Client muss die Anfrage mit derselben Methode und demselben Body wiederholen – wichtig für Formulare und API-Aufrufe.
Permanent Redirect
Permanent Redirect. Wie 301, aber Methode und Body dürfen sich nicht ändern. Die sichere Wahl, um API-Endpunkte dauerhaft zu verschieben.
Wie sich Weiterleitungen auf SEO auswirken
- Google wertet 301 und 308 als starkes Signal, die Ziel-URL zu indexieren, 302 und 307 dagegen als schwaches Signal (Google Search Central)
- Die Crawler von Google folgen standardmäßig bis zu 10 Weiterleitungen – aber jeder Zwischenschritt kostet Zeit, verlinken Sie daher direkt auf die finale URL
- Weiterleitungsschleifen machen eine URL für Nutzer und Crawler unerreichbar
- Nutzen Sie permanente Weiterleitungen für dauerhafte Umzüge; ein langlebiges 302 sendet widersprüchliche Signale
- Prüfen Sie nach einer Migration, dass alte URLs weiterleiten statt 404 zu liefern
4xx-Client-Fehler
4xx-Codes bedeuten, dass der Server einen Fehler beim Client sieht: eine falsche URL, fehlende Zugangsdaten oder zu viele Anfragen. Diese Fehler sehen Nutzer am häufigsten, und ein plötzlicher Anstieg deutet meist auf einen defekten Link, einen Deployment-Fehler oder eine geänderte API hin.
Bad Request
Bad Request. Der Server kann die Anfrage wegen fehlerhafter Syntax, ungültigem JSON oder fehlender Parameter nicht verarbeiten. Prüfen Sie die clientseitige Validierung und die API-Payloads.
Unauthorized
Unauthorized. Die Authentifizierung fehlt oder ist ungültig. Normal bei geschützten Endpunkten; ein Anstieg kann auf abgelaufene Tokens oder Credential-Stuffing-Angriffe hindeuten.
Forbidden
Forbidden. Der Server hat die Anfrage verstanden, verweigert sie aber – auch mit gültigen Zugangsdaten. Prüfen Sie Rollen, Dateiberechtigungen sowie Firewall- und CDN-Regeln.
Not Found
Not Found. Der Server findet die angeforderte Ressource nicht. Meist verursacht durch gelöschte Seiten, Tippfehler oder fehlende Weiterleitungen.
Gone
Gone. Die Ressource wurde absichtlich entfernt und kommt nicht zurück. Google behandelt 404 und 410 gleich: Die URL wird aus dem Index entfernt.
Too Many Requests
Too Many Requests. Der Client hat ein Rate-Limit überschritten. Der Retry-After-Header gibt an, wann er es erneut versuchen kann. Google behandelt 429 wie einen Serverfehler und crawlt langsamer.
Worauf Sie bei 4xx-Antworten achten sollten
- 404-Fehler auf Seiten, die bisher funktioniert haben – meist eine fehlende Weiterleitung nach einem Release oder einer Migration
- Steigende 401-/403-Raten, die auf abgelaufene Zugangsdaten oder falsch konfigurierte Zugriffsregeln hinweisen können
- 400-Fehler nach einem Deployment, oft ein Zeichen für eine geänderte API
- 429-Fehler bei echten Nutzern oder dem Googlebot – dann sind Ihre Rate-Limits zu streng
- Indexierte URLs, die 4xx liefern, werden aus dem Google-Index entfernt
5xx-Server-Fehler
5xx-Codes bedeuten, dass die Anfrage gültig war, aber der Server – oder etwas dahinter – versagt hat. Diese Fehler legen eine Website lahm und sollten deshalb immer einen Alarm auslösen.
Internal Server Error
Internal Server Error. Ein unerwarteter Zustand hat den Server daran gehindert, die Anfrage zu erfüllen – typischerweise eine unbehandelte Exception, eine fehlgeschlagene Datenbankabfrage oder eine fehlerhafte Konfiguration.
Bad Gateway
Bad Gateway. Ein Proxy, Load Balancer oder CDN hat eine ungültige Antwort vom Upstream-Server erhalten. Prüfen Sie, ob die Anwendung dahinter läuft und erreichbar ist.
Service Unavailable
Service Unavailable. Der Server kann die Anfrage wegen Überlastung oder Wartung vorübergehend nicht bearbeiten. Senden Sie bei geplanten Ausfällen einen Retry-After-Header.
Gateway Timeout
Gateway Timeout. Ein Proxy oder Gateway hat nicht rechtzeitig eine Antwort vom Upstream-Server erhalten. Suchen Sie nach langsamen Abfragen, hängenden Workern oder Netzwerkproblemen.
Worauf Sie bei 5xx-Antworten achten sollten
- Jeder 5xx-Fehler auf Startseite, Login, Checkout oder Health-Check-Endpunkt erfordert sofortiges Handeln
- 502 und 504 deuten meist auf die Infrastruktur zwischen Nutzer und Anwendung hin: Proxys, Load Balancer, CDNs
- 503 bei Lastspitzen ist eine Warnung vor Kapazitätsengpässen
- Anhaltende 5xx-Fehler bremsen das Crawling von Google und führen irgendwann zur Entfernung indexierter URLs (Google Search Central)
- Sporadische 5xx-Fehler bleiben ohne kontinuierliches Monitoring leicht unbemerkt
So überwachen Sie HTTP-Statuscodes
Niemand kann Server-Logs rund um die Uhr beobachten – automatisieren Sie es: Ein Uptime-Monitor ruft Ihre URLs in festen Abständen auf und alarmiert Sie, sobald eine Prüfung fehlschlägt. Beginnen Sie mit den Seiten, die Umsatz bringen oder für Nutzer wichtig sind, und ergänzen Sie dann API- und Health-Check-Endpunkte. Unser Leitfaden zum Website-Monitoring erklärt, wie Sie auswählen, was Sie überwachen.
Statuscodes mit nanokoi.io überwachen
Das Uptime-Monitoring von nanokoi.io prüft Ihre URLs im Free-Tarif alle 5 Minuten, im Starter-Tarif jede Minute und im Professional-Tarif alle 30 Sekunden und alarmiert Sie per E-Mail, Slack oder Webhook, wenn eine Prüfung fehlschlägt. Zusätzlich überwacht es SSL-Zertifikate und DNS-Einträge, sodass Sie Fehlerursachen erkennen, bevor Nutzer sie bemerken. Alle Tarife und Prüfintervalle im Überblick.
Best Practices
- Überwachen Sie kritische Seiten und Endpunkte, nicht nur die Startseite
- Alarmieren Sie bei jedem 5xx und bei 4xx-Antworten von URLs, die immer funktionieren sollten
- Leiten Sie Alarme dorthin, wo Ihr Team arbeitet – etwa in einen eigenen Slack-Kanal (siehe unsere Anleitung zum Einrichten eines Slack-Webhooks)
- Prüfen Sie Weiterleitungen nach jeder Migration oder URL-Änderung erneut
- Liefern Sie hilfreiche Fehlerseiten mit dem korrekten Statuscode aus, nie eine Fehlerseite mit 200
Typische Statuscode-Szenarien
Statuscodes treten selten allein auf. Diese Muster werden Sie im Produktivbetrieb wiedererkennen – mit den Codes, auf die Sie achten sollten, und dem besten Ansatzpunkt für die Behebung.
Checkout scheitert unter Last
Kunden erhalten beim Abschluss eines Kaufs eine Fehlermeldung.
500, 502, 503
Verlorene Bestellungen und abgebrochene Warenkörbe
Anwendungslogs, Datenbankverbindungen, Status des Zahlungsanbieters und Serverkapazität prüfen
Mobile App lädt keine Inhalte
App-Nutzer sehen plötzlich leere Bildschirme oder Fehlermeldungen.
429, 401
Frustrierte Nutzer und abgebrochene Sitzungen
API-Rate-Limits, Ablauf von Tokens und die Retry-Logik des Clients überprüfen
Traffic bricht nach einem Relaunch ein
Alte URLs liefern Fehler, statt auf ihre neue Adresse weiterzuleiten.
404, 301
Verlorene Rankings und defekte Backlinks
Jede alte URL per 301 oder 308 weiterleiten, die Sitemap aktualisieren und interne Links korrigieren
Bilder und CSS fehlen bei manchen Nutzern
Seiten laden in bestimmten Regionen ohne Styling oder Bilder.
403, 404, 502
Eine kaputt wirkende Website und schlechte Nutzererfahrung
CDN-Konfiguration, Verbindung zum Origin-Server, Zugriffsregeln und Cache-Einstellungen prüfen
So beheben Sie einen HTTP-Fehler
Wenn ein Alarm ausgelöst wird, gehen Sie in einer festen Reihenfolge vor. Das spart Zeit und verhindert, dass Sie Symptome statt Ursachen beheben.
- 1
Umfang und Auswirkung einschätzen
Welche URLs sind betroffen, seit wann und für wen? Ein einzelner Endpunkt und eine ganze Domain sind sehr unterschiedliche Vorfälle.
- 2
Die Anfrage reproduzieren
Wiederholen Sie die Anfrage mit curl oder den Entwicklertools Ihres Browsers. Prüfen Sie URL, Methode, Header und Body auf Tippfehler oder fehlende Parameter.
- 3
Aus einem anderen Netzwerk testen
Rufen Sie dieselbe URL von einem anderen Standort oder Netzwerk auf, um lokale Probleme auszuschließen, und vergleichen Sie die Antwort des CDN mit der des Origin-Servers.
- 4
Abhängigkeiten prüfen
Prüfen Sie bei 5xx-Fehlern Datenbanken, Backend-Dienste, Drittanbieter-APIs und Serverressourcen wie CPU, Arbeitsspeicher und Festplatte.
- 5
Letzte Änderungen überprüfen
Die meisten Vorfälle folgen auf ein Deployment, eine Konfigurationsänderung oder ein abgelaufenes Zertifikat bzw. eine abgelaufene Domain. Schauen Sie zuerst in Ihr Änderungsprotokoll.
- 6
Wiederholung verhindern
Richten Sie nach der Behebung einen Monitor für die betroffene URL ein und dokumentieren Sie den Vorfall, damit der nächste schneller gelöst ist.
Häufige Fragen zu HTTP-Statuscodes
Was ist der Unterschied zwischen 4xx- und 5xx-Statuscodes?
4xx-Codes bedeuten, dass der Server einen Fehler beim Client sieht, etwa eine nicht vorhandene Seite oder ungültige Zugangsdaten. 5xx-Codes bedeuten, dass die Anfrage gültig war, der Server sie aber nicht verarbeiten konnte.
Sollte ich eine 301- oder eine 302-Weiterleitung verwenden?
Verwenden Sie 301 (oder 308), wenn eine Seite dauerhaft umgezogen ist – Google wertet das als starkes Signal, die neue URL zu indexieren. Nutzen Sie 302 (oder 307) nur für vorübergehende Umleitungen, bei denen die ursprüngliche URL indexiert bleiben soll.
Was ist der Unterschied zwischen 404 und 410?
404 besagt, dass die Ressource nicht gefunden wurde; 410, dass sie absichtlich entfernt wurde und nicht zurückkommt. Google behandelt beide gleich und entfernt die URL aus dem Index.
Welche HTTP-Statuscodes sollten einen Alarm auslösen?
Jede 5xx-Antwort sowie 4xx-Antworten von URLs, die immer funktionieren sollten – etwa Startseite, Login, Checkout und Health-Check-Endpunkte. Auch unerwartete Weiterleitungen auf diesen URLs sind einen Alarm wert.
Erkennen Sie HTTP-Fehler vor Ihren Nutzern
Überwachen Sie Ihre wichtigsten URLs mit nanokoi.io und erhalten Sie Alarme per E-Mail, Slack oder Webhook, wenn eine Prüfung fehlschlägt. Der Free-Tarif umfasst bis zu 5 URLs mit Prüfungen alle 5 Minuten.
Kostenlos mit dem Monitoring startenKeine Kreditkarte erforderlich