HTTP-Statuscodes verstehen: Was 200, 301, 404 und 503 für dein Monitoring bedeuten

Jede Antwort eines Webservers beginnt mit einer dreistelligen Zahl. Browser zeigen sie selten an, aber für Monitoring, Suchmaschinen und API-Clients ist sie die wichtigste Information der ganzen Antwort. HTTP-Statuscodes sagen, ob eine Anfrage geklappt hat, ob der Inhalt umgezogen ist, ob der Fehler beim Client liegt oder ob der Server gerade ein Problem hat.

In diesem Artikel erklären wir die Codes, die dir im Alltag wirklich begegnen, zeigen, wie Google sie behandelt, und beschreiben, welche Codes ein Uptime- oder Link-Monitoring als Fehler werten sollte und welche nicht.

HTTP-Statuscodes: die fünf Klassen

Die erste Ziffer bestimmt die Klasse. Festgelegt sind die Codes in RFC 9110, der aktuellen Spezifikation der HTTP-Semantik.

Für das Monitoring ist die Faustregel einfach: 2xx ist gut, 3xx muss man verfolgen, 4xx und 5xx sind Fehler. Im Detail lohnt sich aber ein genauerer Blick, denn nicht jeder 200 ist ein Erfolg und nicht jeder 403 ein Ausfall.

2xx: Erfolg, zumindest laut Server

200 OK ist die Standardantwort für eine erfolgreiche Anfrage. 201 Created liefern APIs, wenn eine Ressource angelegt wurde, 204 No Content bedeutet Erfolg ohne Antwortinhalt. Health-Endpunkte antworten oft mit 200 oder 204.

Wichtig ist: Ein 2xx sagt nur, dass der Server die Anfrage aus seiner Sicht erfolgreich verarbeitet hat. Er sagt nichts darüber, was auf der Seite steht. Viele Anwendungen fangen Fehler ab und zeigen eine freundliche Fehlerseite, liefern dabei aber trotzdem 200. Ein Shop zeigt dann „Leider ist ein Fehler aufgetreten“, und das Monitoring meldet alles grün.

Google nennt solche Seiten Soft 404: Seiten, die mit 200 antworten, inhaltlich aber leer sind oder einen Fehler melden. Search Console weist sie gesondert aus. Für dein Monitoring heißt das: Prüfe auf wichtigen Seiten zusätzlich einen Suchbegriff, der nur auf der echten Seite vorkommt, etwa den Namen des Warenkorb-Buttons oder einen Marker im Footer. Alternativ prüfst du, dass ein typischer Fehlertext nicht vorkommt.

3xx: Weiterleitungen richtig einsetzen

Weiterleitungen sind kein Fehler, aber eine häufige Fehlerquelle. Die wichtigsten Codes:

• 301 Moved Permanently: Die Ressource ist dauerhaft umgezogen. Der Klassiker für geänderte URLs, den Wechsel von http auf https oder von www auf die Hauptdomain.
• 302 Found: Vorübergehende Weiterleitung. Die ursprüngliche URL bleibt die eigentliche Adresse.
• 303 See Other: Typisch nach einem abgeschickten Formular, damit der Browser die Ergebnisseite per GET lädt.
• 304 Not Modified: Keine echte Weiterleitung, sondern eine Antwort auf eine bedingte Anfrage. Der Client darf seine zwischengespeicherte Version weiterverwenden.
• 307 Temporary Redirect und 308 Permanent Redirect: Wie 302 und 301, aber mit der ausdrücklichen Regel, dass der Client die Methode und den Body beibehält. Bei 301 und 302 machen Clients aus einem POST historisch oft ein GET.

Für Suchmaschinen ist der Unterschied zwischen dauerhaft und vorübergehend relevant. Laut der Dokumentation von Google zu HTTP-Statuscodes werten Googles Systeme 301 und 308 als starkes Signal, dass das Ziel der Weiterleitung verarbeitet werden soll, 302 und 307 dagegen nur als schwaches Signal. Googles Crawler folgen standardmäßig bis zu zehn Weiterleitungen hintereinander.

In der Praxis entstehen Probleme meist durch Weiterleitungsketten und Schleifen. Nach mehreren Relaunches landet ein alter Link über http, www, eine alte Kategorie und eine neue Kategorie erst nach vier Sprüngen am Ziel. Jeder Sprung kostet Zeit, und irgendwann zeigt eine Regel auf eine andere, die wieder zurückzeigt. Leite deshalb immer direkt auf die endgültige URL weiter und passe interne Links an, statt dich auf Weiterleitungen zu verlassen. Wie du dabei systematisch vorgehst, beschreiben wir in unserem Leitfaden Defekte Links finden und SEO schützen.

4xx: Fehler beim Client, aber nicht immer ein Ausfall

Die 4xx-Klasse bedeutet, dass die Anfrage aus Sicht des Servers nicht in Ordnung ist. Das ist nicht automatisch ein Problem deiner Website.

• 400 Bad Request: Die Anfrage ist fehlerhaft, zum Beispiel ungültige Parameter oder ein kaputter Header.
• 401 Unauthorized: Trotz des Namens geht es um fehlende oder ungültige Anmeldedaten. Eine geschützte API antwortet ohne Token mit 401.
• 403 Forbidden: Der Server verweigert den Zugriff, auch mit Anmeldung. Firewalls und Bot-Schutz antworten automatisierten Anfragen häufig mit 403.
• 404 Not Found: Unter dieser Adresse gibt es nichts, zumindest nicht mehr.
• 405 Method Not Allowed: Die Methode ist für diese URL nicht erlaubt. Manche Server lehnen etwa HEAD ab, obwohl GET funktioniert.
• 410 Gone: Die Seite wurde bewusst und dauerhaft entfernt.
• 429 Too Many Requests: Rate Limiting. Der Client hat zu viele Anfragen gestellt und soll warten, oft mit einem Retry-After-Header.

Google behandelt alle 4xx-Codes außer 429 gleich: Der Inhalt wird nicht verwendet, bereits indexierte URLs fallen mit der Zeit aus dem Index. 429 dagegen wertet Google wie einen Serverfehler und drosselt das Crawling. Für SEO bedeutet das: Ein 404 auf einer Seite, die Besucher und Backlinks hat, kostet Sichtbarkeit. Ein 404 auf einer URL, die es nie gab, ist dagegen völlig normal. Wenn du eine Seite bewusst entfernst und es keinen passenden Ersatz gibt, ist 410 die ehrlichere Antwort; gibt es einen Nachfolger, ist eine 301-Weiterleitung besser.

Für das Monitoring ist entscheidend, wer die Anfrage stellt. Bei deinen eigenen Seiten ist ein 404 auf der Startseite oder im Checkout ein echter Fehler. Bei Links auf fremde Websites bekommst du dagegen häufig 401, 403 oder 429, weil der fremde Server automatisierte Anfragen abweist, obwohl die Seite für Menschen tadellos funktioniert. Ein gutes Link-Monitoring wertet solche Antworten bei externen Links nicht als defekt, sonst füllt sich der Bericht mit Fehlalarmen.

5xx: Der Server hat ein Problem

Die 5xx-Klasse ist das, was man klassisch unter einem Ausfall versteht.

• 500 Internal Server Error: Ein unbehandelter Fehler in der Anwendung, etwa eine Exception, eine fehlgeschlagene Datenbankabfrage oder ein Konfigurationsfehler.
• 502 Bad Gateway: Ein Proxy oder Load Balancer hat vom dahinterliegenden Server keine gültige Antwort bekommen. Typisch, wenn PHP-FPM oder ein Node-Prozess abgestürzt ist, während Nginx noch läuft.
• 503 Service Unavailable: Der Dienst ist vorübergehend nicht verfügbar, wegen Überlastung oder Wartung.
• 504 Gateway Timeout: Der Proxy hat zu lange auf den dahinterliegenden Server gewartet.

Google drosselt bei 5xx das Crawling. Bereits indexierte Seiten bleiben zunächst im Index, werden aber entfernt, wenn der Fehler dauerhaft anhält. Ein kurzer Ausfall schadet deinem Ranking also in der Regel nicht, ein tagelanger schon.

Wenn du ein CDN wie Cloudflare einsetzt, begegnen dir außerdem Codes wie 521, 522 oder 526. Diese gehören nicht zum HTTP-Standard, sondern sind eigene Codes des Anbieters. Alle drei bedeuten, dass das CDN deinen Ursprungsserver nicht oder nicht sicher erreicht hat, und sind für das Monitoring genauso ernst zu nehmen wie ein 502.

Wartungsarbeiten: lieber 503 als 200

Für geplante Wartung ist 503 der richtige Code, idealerweise mit einem Retry-After-Header. So wissen Browser, Crawler und API-Clients, dass der Zustand vorübergehend ist. Eine Wartungsseite mit 200 landet im schlimmsten Fall als Inhalt im Index, eine 302-Weiterleitung auf /wartung verwirrt Suchmaschinen und Clients gleichermaßen.

In Laravel erledigt das der Wartungsmodus: php artisan down antwortet standardmäßig mit 503, und mit php artisan down --retry=60 setzt Laravel zusätzlich den Retry-After-Header. Andere Frameworks und Webserver bieten Vergleichbares.

HTTP-Statuscodes selbst prüfen

Für einen schnellen Blick reicht curl auf der Kommandozeile. Nur den Statuscode einer URL zeigt dir dieser Befehl:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com

Willst du sehen, wohin eine URL weiterleitet und wie viele Sprünge es sind, lässt du curl den Weiterleitungen folgen und gibst Endstatus, Anzahl der Sprünge und Ziel-URL aus:

curl -sIL -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}\n" http://example.com

Mit curl -sIL https://example.com ohne die Ausgabeoptionen siehst du die Header jeder einzelnen Antwort der Kette. Beachte, dass -I eine HEAD-Anfrage sendet. Einige Server beantworten HEAD anders als GET, etwa mit 405 oder sogar 404. Wenn dir ein Ergebnis seltsam vorkommt, prüfe mit GET gegen.

Welche Statuscodes dein Monitoring als Fehler werten sollte

Aus den Abschnitten oben ergeben sich ein paar praktische Regeln für Uptime-Monitore:

1. Standard: 2xx ist erreichbar, alles andere nicht. Das deckt die allermeisten Seiten ab.
2. Weiterleitungen verfolgen und das Endziel bewerten. Wer http:// überwacht, will wissen, ob die https-Seite am Ende funktioniert, nicht nur, ob der Server einen 301 schickt. Begrenze die Anzahl der Sprünge, damit Schleifen als Fehler auffallen.
3. Erwartete Codes bewusst festlegen. Ein geschützter API-Endpunkt soll ohne Anmeldung 401 liefern. Überwachst du ihn ohne Token, ist 401 die richtige Antwort, und ein 200 wäre ein Grund zur Sorge.
4. Inhalt prüfen, nicht nur den Code. Ein Suchbegriff fängt Soft 404 und abgefangene Fehler ab, die mit 200 antworten.
5. Zeitlimits setzen. Eine Seite, die nach 40 Sekunden einen 200 liefert, ist für Besucher praktisch nicht erreichbar.
6. Fehler bestätigen, bevor du alarmierst. Ein einzelner 502 während eines Deployments oder ein kurzer Timeout ist kein Ausfall. Eine zweite Prüfung kurz danach trennt echte Probleme von Ausreißern.

Für das Link-Monitoring gelten etwas andere Regeln: 4xx und 5xx auf internen Links sind defekt und gehören behoben, 3xx ist kein Fehler, aber ein Hinweis, den Link auf das Ziel umzustellen. Bei externen Links solltest du typische Bot-Sperren wie 401, 403 oder 429 nicht als defekt zählen. Welche weiteren Checks sich für eine Website lohnen, beschreiben wir in Website-Monitoring einrichten.

So hilft dir Kaspar

Kaspars Uptime-Monitore prüfen deine Seiten per GET, HEAD oder POST. Standardmäßig gilt jede Antwort mit 2xx als erreichbar. Weiterleitungen verfolgen wir bis zu fünf Sprünge weit und bewerten die Antwort am Ende der Kette; mehr Sprünge werten wir als Fehler. Unter „Erwartete Statuscodes“ legst du fest, welche Codes ein Monitor stattdessen akzeptieren soll, und mit einem Suchbegriff prüfst du, ob ein Text vorhanden oder gerade nicht vorhanden ist. Das Zeitlimit stellst du pro Monitor zwischen 1 und 30 Sekunden ein. Schlägt eine Prüfung fehl, wiederholen wir sie innerhalb von Sekunden und alarmieren dich erst, wenn der Fehler bestätigt ist, per E-Mail, Slack oder Telegram.

Im selben Konto legst du Scans nach defekten Links an. Diese Scans folgen internen Weiterleitungen und melden Links, die mit 4xx oder 5xx antworten oder gar nicht erreichbar sind. Externe Links fragen wir per HEAD ab und versuchen es mit GET, wenn der Server HEAD ablehnt. Typische Bot-Sperren fremder Websites wie 401, 403 oder 429 zählen wir dabei nicht als defekten Link. Einzelne Seiten kannst du ohne Konto mit unserem kostenlosen Broken-Link-Checker prüfen, der dir zusätzlich zeigt, welche Links weiterleiten. Die Tarife findest du auf unserer Preisseite, alle Funktionen im Überblick unter Features.