Was sind HTTP-Statuscodes?

Statuscodes sind Teil des Protokolls HTTP, das der Eintrag zu HTTP in diesem Glossar erklärt. RFC 9110, im Juni 2022 von der IETF veröffentlicht, legt die gültigen Codes zwischen 100 und 599 fest und teilt sie nach der ersten Ziffer in fünf Klassen ein. Die beiden letzten Ziffern stehen für keine Kategorie.

- 1xx, informativ: Die Anfrage ist angekommen, die Verarbeitung läuft weiter. - 2xx, Erfolg: Die Anfrage wurde empfangen, verstanden und angenommen. - 3xx, Umleitung: Es ist ein weiterer Schritt nötig, meist die Anfrage an eine andere Adresse. - 4xx, Fehler des Clients: Die Anfrage ist fehlerhaft oder kann nicht erfüllt werden, etwa weil sie eine Seite verlangt, die es nicht gibt. - 5xx, Fehler des Servers: Die Anfrage schien gültig, aber der Server konnte sie nicht erfüllen.

Die erste Ziffer sagt also, wo das Problem liegt. Ein 4xx verweist auf die Anfrage, ein 5xx auf den Server.

RFC 9110 verpflichtet jeden Client, die Klasse eines Codes zu verstehen, auch wenn er den einzelnen Code nicht kennt. Ein unbekannter Code wird wie das x00 seiner Klasse behandelt: Ein 299, den niemand kennt, gilt als 200, ein 599 als 500.

Die häufigsten Codes, den Erfolg 200, die dauerhafte Weiterleitung 301 und den 404 für eine nicht gefundene Seite, erklärt der Eintrag zu HTTP. Daneben gibt es weitere, die für SEO Folgen haben:

- 304 Not Modified: Der Client hat gefragt, ob seine Kopie noch gilt, und der Server antwortet mit Ja, ohne Inhalt zu senden. - 307 und 308: vorübergehende und dauerhafte Weiterleitung, wie 302 und 301. Bei 302 und 301 darf der Client aus historischen Gründen beim Folgen der Weiterleitung aus einem POST ein GET machen; für den Fall, dass das nicht gewollt ist, sieht der RFC 307 und 308 vor. Der 308 stammt vom Juni 2014 und ist viel jünger als die anderen. - 410 Gone: Die Ressource ist nicht mehr verfügbar und kommt wahrscheinlich nicht zurück. Weiß der Server nicht, ob das dauerhaft ist, soll er laut RFC den 404 verwenden. - 429 Too Many Requests: Der Client hat in kurzer Zeit zu viele Anfragen geschickt. Definiert ist er in RFC 6585 vom April 2012. - 503 Service Unavailable: Der Server kann die Anfrage wegen vorübergehender Überlastung oder geplanter Wartung nicht bearbeiten. Mit dem Header Retry-After kann er angeben, wann es sich lohnt, es erneut zu versuchen.

Google entscheidet anhand des Codes, was mit jeder URL geschieht. In seiner Dokumentation steht, dass ein 2xx keine Indexierung garantiert, dass 307 wie 302 und 308 wie 301 behandelt wird und dass seine Crawler bei einem 304 dem nächsten System melden, der Inhalt sei seit dem letzten Crawling unverändert.

Bei den 4xx behandelt Google alle Codes gleich, außer dem 429: Es nutzt den Inhalt nicht, indexiert neue URLs nicht und entfernt bereits indexierte aus dem Index. Für Google haben 410 und 404 also dieselbe Wirkung, auch wenn sie im RFC Verschiedenes bedeuten. Der 429 dagegen gilt wie ein 5xx als Zeichen, dass der Server überlastet ist, und die Crawler verlangsamen vorübergehend.

Um das Crawling kurzfristig zu drosseln, etwa wenn die Website außer Betrieb ist, empfiehlt Google, für einige Stunden oder ein bis zwei Tage einen 500, 503 oder 429 zu senden. Beim 503 und 429 berücksichtigt es den Header Retry-After. Sieht Googlebot dieselben Fehler mehrere Tage lang bei einer URL, kann sie aus dem Index fallen.

Für zds.es haben wir das am 15. Oktober 2026 gemessen. Wir haben alle 1.389 URLs der Sitemap abgerufen, ohne Weiterleitungen zu folgen, und alle 1.389 antworteten mit 200. Eine erfundene Adresse lieferte einen echten 404, und eine Schriftdatei, die wir mit ihrem ETag erneut anforderten, einen 304.

• Jeder URL den Code geben, der ihren tatsächlichen Zustand beschreibt, nicht einen, der günstiger aussieht.
• 410 verwenden, wenn ein Inhalt absichtlich entfernt wurde, und 404, wenn offen ist, ob er zurückkommt.
• Wartungen mit einem 503 und dem Header Retry-After planen und nicht länger als ein bis zwei Tage dauern lassen.
• In die Sitemap nur URLs aufnehmen, die mit 200 antworten.
• Codes mit einer direkten Anfrage prüfen, etwa mit curl, weil der Browser Weiterleitungen folgt, ohne sie zu zeigen.

• Eine Fehlerseite mit 200 ausliefern, die Google dann als Soft 404 werten kann.
• Erwarten, dass ein 410 eine URL schneller aus dem Index entfernt als ein 404, obwohl Google beide gleich behandelt.
• Crawler mit 401 oder 403 bremsen wollen: Laut Google haben diese Codes keinen Einfluss auf die Crawling-Frequenz.
• Eine 503-Wartungsseite wochenlang aktiv lassen.
• Einen 5xx, also ein Problem des Servers, mit einem 4xx verwechseln, der die Anfrage betrifft.