Auswirkungen von HTTP-Statuscodes sowie Netzwerk- und DNS-Fehlern auf die Google Suche

Auf dieser Seite erfährst du, wie sich verschiedene HTTP-Statuscodes, Netzwerkfehler und DNS-Fehler auf die Google Suche auswirken. Dabei gehen wir auf die 20 wichtigsten Statuscodes ein, die der Googlebot im Internet gefunden hat, und beschreiben die wichtigsten Netzwerk- und DNS-Fehler. Selten auftretende Statuscodes wie 418 (I'm a teapot) werden nicht berücksichtigt. Alle auf dieser Seite erwähnten Probleme generieren einen entsprechenden Fehler oder eine entsprechende Warnung im Bericht zur Seitenindexierung in der Search Console.

HTTP-Statuscodes

HTTP-Statuscodes werden von dem Server generiert, auf dem die Website gehostet wird, wenn er auf eine Anfrage von einem Client (z. B. einem Browser oder Crawler) antwortet. Jeder HTTP-Statuscode hat eine bestimmte Bedeutung, aber das Ergebnis der Anfrage ist oft das gleiche. Beispielsweise gibt es mehrere Statuscodes, die eine Weiterleitung signalisieren, das Ergebnis ist aber jeweils identisch.

Die Search Console generiert Fehlermeldungen für Statuscodes im Bereich 4xx–5xx und für fehlgeschlagene Weiterleitungen (3xx). Wenn der Server den Statuscode 2xx zurückgegeben hat, wird der in der Antwort empfangene Inhalt möglicherweise bei der Indexierung berücksichtigt.

Die folgende Tabelle enthält die am häufigsten vom Googlebot festgestellten HTTP-Statuscodes sowie eine Erklärung dazu, wie Google die einzelnen Statuscodes verarbeitet.

HTTP-Statuscodes

2xx (success)

Google zieht den Inhalt für die Indexierung in Betracht. Wenn der Inhalt auf einen Fehler hindeutet, wie zum Beispiel eine leere Seite oder eine Fehlermeldung, zeigt die Search Console einen soft 404-Fehler an.

200 (success)

Google leitet den Inhalt an die Indexierungspipeline weiter. Möglicherweise wird der Inhalt von den Indexierungssystemen anschließend auch indexiert, eine Garantie dafür gibt es jedoch nicht.

201 (created)
202 (accepted)

Der Googlebot wartet eine bestimmte Zeit lang auf den Inhalt und gibt die empfangenen Inhalte dann an die Indexierungspipeline weiter. Das Zeitlimit hängt vom User-Agent ab. Beispielsweise kann der Googlebot (Smartphone) ein anderes Zeitlimit haben als der Googlebot-Image.

204 (no content)

Der Googlebot signalisiert der Indexierungspipeline, dass er keine Inhalte empfangen hat. In der Search Console wird im Bericht zur Seitenindexierung möglicherweise ein soft 404-Fehler angezeigt.

3xx (redirection)

Der Googlebot folgt bis zu zehn Weiterleitungs-Hops. Wenn der Crawler innerhalb von zehn Hops keine Inhalte empfängt, wird in der Search Console im Bericht zur Seitenindexierung ein Weiterleitungsfehler angezeigt. Die Anzahl der Hops, denen der Googlebot folgt, ist abhängig vom User-Agent. Beispielsweise kann der Googlebot (Smartphone) einer anderen Anzahl von Hops folgen als der Googlebot Image.

Bei einer robots.txt-Datei folgt der Googlebot mindestens fünf Weiterleitungs-Hops, wie in RFC 1945 definiert, beendet dann den Vorgang und geht von einem 404 für die robots.txt-Datei aus.

Inhalte, die der Googlebot über die weiterleitende URL empfängt, werden ignoriert und der Inhalt der finalen Ziel-URL wird bei der Indexierung berücksichtigt.

301 (moved permanently)

Der Googlebot folgt der Weiterleitung und die Indexierungspipeline versteht die Weiterleitung als starkes Signal dafür, dass das Weiterleitungsziel kanonisch sein muss.

302 (found)

Der Googlebot folgt der Weiterleitung und die Indexierungspipeline versteht die Weiterleitung als schwaches Signal dafür, dass das Weiterleitungsziel kanonisch sein muss.

303 (see other)
304 (not modified)

Der Googlebot signalisiert der Indexierungspipeline, dass sich der Inhalt seit dem letzten Crawling nicht geändert hat. In der Indexierungspipeline werden Signale für die URL möglicherweise neu berechnet. Ansonsten hat der Statuscode keine Auswirkung auf die Indexierung.

307 (temporary redirect) Gleichbedeutend mit 302.
308 (moved permanently) Gleichbedeutend mit 301.

4xx (client errors)

In der Indexierungspipeline von Google werden keine URLs berücksichtigt, die einen Statuscode zur Indexierung mit dem Status 4xx zurückgeben. URLs, die bereits indexiert sind und den Statuscode 4xx zurückgeben, werden aus dem Index entfernt.

Alle Inhalte, die der Googlebot über URLs empfangen hat und den Statuscode 4xx zurückgeben, werden ignoriert.

400 (bad request)

Alle 4xx-Fehler mit Ausnahme von 429 werden gleich behandelt: Der Googlebot signalisiert der Indexierungspipeline, dass die Inhalte nicht vorhanden sind.

Falls die URL bereits indexiert wurde, entfernt die Indexierungspipeline sie aus dem Index. Neue 404-Seiten werden nicht verarbeitet. Die Crawling-Frequenz nimmt allmählich ab.

401 (unauthorized)
403 (forbidden)
404 (not found)
410 (gone)
411 (length required)
429 (too many requests)

Der Statuscode 429 wird vom Googlebot als Signal dafür verstanden, dass der Server überlastet ist. Dieser Code gilt als Serverfehler.

5xx (server errors)

Die Serverfehler 5xx und 429 sorgen dafür, dass die Crawler von Google das Crawling vorübergehend verlangsamen. Bereits indexierte URLs bleiben vorerst im Index, werden aber schließlich entfernt.

Wenn die robots.txt-Datei mehr als 30 Tage lang einen Serverfehler-Statuscode zurückgibt, verwendet Google die letzte im Cache gespeicherte Kopie der robots.txt-Datei. Falls sie nicht verfügbar ist, geht Google davon aus, dass keine Crawling-Einschränkungen bestehen.

Alle Inhalte, die der Googlebot über URLs empfangen hat und den Statuscode 5xx zurückgeben, werden ignoriert.

500 (internal server error)

Der Googlebot verringert dann die Crawling-Frequenz für diese Website. Die Verlangsamung der Crawling-Frequenz ist proportional zur Anzahl der einzelnen URLs, für die ein Serverfehler zurückgegeben wird. URLs, die dauerhaft einen Serverfehler zurückgeben, werden durch die Indexierungspipeline von Google aus dem Index entfernt.

502 (bad gateway)
503 (service unavailable)

soft 404 Fehler

Ein soft 404-Fehler ist eine URL, die eine Seite mit dem Hinweis zurückgibt, dass die Seite nicht existiert, sowie einen 200 (success)-Statuscode. In einigen Fällen wird eine Seite ohne Hauptinhalt oder eine leere Seite angezeigt.

Solche Seiten können aus verschiedenen Gründen vom Webserver oder Content-Management-System deiner Website oder vom Browser des Nutzers generiert werden. Beispiele:

  • Eine fehlende SSI-Datei (Server Side Includes)
  • Eine unterbrochene Verbindung zur Datenbank
  • Eine leere interne Suchergebnisseite
  • Eine nicht geladene oder anderweitig fehlende JavaScript-Datei

Es ist schlecht, den Statuscode 200 (success) zurückzugeben und dann auf der Seite eine Fehlermeldung anzuzeigen. Nutzer denken möglicherweise, dass es sich um eine funktionierende Seite handelt, erhalten dann aber einen Fehler. Solche Seiten werden von der Google Suche ausgeschlossen.

Wenn der Inhalt einer Seite darauf hinweist, dass es sich eigentlich um eine Fehlerseite handelt, erkennen dies die Algorithmen von Google und die Search Console zeigt einen soft 404-Fehler im Bericht zur Seitenindexierung der Website an.

soft 404-Fehler beheben

Je nach Status der Seite und dem gewünschten Ergebnis kannst du soft 404-Fehler auf verschiedene Arten beheben:

Versuche herauszufinden, welche Lösung für deine Nutzer am besten geeignet ist.

Die Seite und der Inhalt sind nicht mehr verfügbar

Wenn du die Seite entfernt hast und keine Ersatzseite mit ähnlichem Inhalt in deiner Website vorhanden ist, gib den Antwort-(Status-)Code 404 (not found) oder 410 (gone) für die Seite zurück. Diese Statuscodes zeigen den Suchmaschinen an, dass die Seite nicht existiert und der Inhalt nicht indexiert werden soll.

Wenn du Zugriff auf die Konfigurationsdateien deines Servers hast, kannst du diese Fehlerseiten für deine Nutzer sinnvoll anpassen. Eine gut angepasste 404-Seite hilft Nutzern, die gesuchten Informationen zu finden, und bietet weitere hilfreiche Informationen, über die Nutzer dazu animiert werden, sich mehr mit deiner Website zu befassen. Im Folgenden findest du einige Tipps für die Erstellung einer hilfreichen angepassten 404-Seite:

  • Teile Besuchern klar und verständlich mit, dass die gewünschte Seite nicht gefunden wurde. Verwende freundliche und einladende Formulierungen.
  • Achte darauf, dass deine 404-Seite dasselbe Design (einschließlich Bedienung) wie der Rest deiner Website hat.
  • Füge Links zu deinen meistgelesenen Artikeln oder Beiträgen sowie einen Link zur Startseite der Website hinzu.
  • Ziehe in Erwägung, Nutzern die Möglichkeit zu geben, einen fehlerhaften Link zu melden.

Benutzerdefinierte 404-Seiten werden ausschließlich für Nutzer erstellt. Aus Sicht der Suchmaschine sind diese Seiten sinnlos. Deshalb muss der Server den HTTP-Statuscode 404 zurückgeben, um zu verhindern, dass die Seiten indexiert werden.

Die Seite oder der Inhalt befindet sich jetzt an einem anderen Ort

Ist deine Seite umgezogen oder gibt es einen eindeutigen Ersatz dafür in deiner Website, dann gib 301 (permanent redirect) zurück, um die Nutzer weiterzuleiten. Dies unterbricht das Surfen nicht und ist außerdem eine gute Möglichkeit, Suchmaschinen über die neue Position der Seite zu informieren. Verwende das URL-Prüftool, um herauszufinden, ob deine URL den richtigen Code zurückgibt.

Seite und Inhalt sind noch vorhanden

Wenn eine ansonsten fehlerfreie Seite mit einem soft 404-Fehler gekennzeichnet wird, konnte sie wahrscheinlich für den Googlebot nicht richtig geladen werden, ihr fehlten wichtige Ressourcen oder es wurde beim Rendern eine deutlich erkennbare Fehlermeldung angezeigt. Verwende das URL-Prüftool, um den gerenderten Inhalt und den zurückgegebenen HTTP-Code zu untersuchen. Wenn die gerenderte Seite leer oder nahezu leer ist oder der Inhalt eine Fehlermeldung enthält, verweist deine Seite unter Umständen auf viele Ressourcen wie Bilder, Skripts und andere nicht textbasierte Elemente, die nicht geladen werden können. Dies kann als soft 404-Fehler interpretiert werden. Gründe, warum Ressourcen nicht geladen werden, können beispielsweise durch robots.txt blockierte Ressourcen, zu viele Ressourcen auf einer Seite, verschiedene Serverfehler oder langsam ladende sowie sehr große Ressourcen sein.

Netzwerk- und DNS-Fehler

Netzwerk- und DNS-Fehler haben bereits nach kurzer Zeit negative Auswirkungen auf die Präsenz einer URL in der Google Suche. Der Googlebot behandelt Zeitüberschreitungen im Netzwerk, das Zurücksetzen der Verbindung und DNS-Fehler ähnlich wie 5xx-Serverfehler. Bei Netzwerkfehlern verlangsamt sich das Crawling sofort, da ein Netzwerkfehler ein Zeichen dafür sein kann, dass der Server überlastet ist. Da der Googlebot nicht auf den Server zugreifen konnte, auf dem die Website gehostet wurde, hat Google auch keine Inhalte vom Server empfangen. Das Fehlen von Inhalten bedeutet, dass Google die gecrawlten URLs nicht indexieren kann. Bereits indexierte URLs, die nicht erreichbar sind, werden innerhalb von wenigen Tagen aus dem Google-Index entfernt. Die Search Console generiert möglicherweise für jeden Fehler eine eigene Fehlermeldung.

Netzwerkfehler beheben

Diese Fehler treten auf, bevor Google mit dem Crawlen einer URL beginnt oder während sie gecrawlt wird. Sie treten möglicherweise auf, bevor der Server antworten kann – in diesem Fall gibt es keinen Statuscode, der auf Probleme hinweisen kann. Die Diagnose dieser Fehler ist deshalb unter Umständen schwieriger. So lassen sich Fehler bei Zeitüberschreitungen und beim Zurücksetzen der Verbindung beheben:

  • Prüfe die Firewalleinstellungen und Logs. Möglicherweise sind die Blockierregeln zu allgemein. Achte darauf, dass Googlebot-IP-Adressen nicht durch Firewallregeln blockiert werden.
  • Prüfe den Netzwerkverkehr. Du kannst Tools wie tcpdump und Wireshark zur Erfassung und Analyse von TCP-Paketen verwenden. Suche dabei nach Anomalien, die auf eine bestimmte Netzwerkkomponente oder ein Servermodul verweisen.
  • Wenn du nichts Verdächtiges findest, wende dich an den Hostanbieter.

Der Fehler kann in jeder Serverkomponente stecken, die den Netzwerkverkehr verarbeitet. Eine überlastete Netzwerkschnittstelle beispielsweise kann zu Paketverlust und Zeitüberschreitungen führen (es kann also keine Verbindung hergestellt werden) und der Grund dafür sein, dass die Verbindung zurückgesetzt wird (RST-Paket wird gesendet, weil ein Port versehentlich geschlossen wurde).

DNS-Fehler beheben

DNS-Fehler werden meist durch eine fehlerhafte Konfiguration verursacht, können aber auch durch eine Firewallregel hervorgerufen werden, die die DNS-Abfragen des Googlebots blockiert. So lassen sie sich beheben:

  • Prüfe deine Firewallregeln. Achte darauf, dass keine der IP-Adressen von Google durch eine Firewallregel blockiert wird und dass sowohl UDP- als auch TCP-Anfragen zulässig sind.
  • Prüfe die DNS-Einträge. Prüfe, ob deine A- und CNAME-Einträge auf die richtigen IP-Adressen bzw. Hostnamen verweisen. Beispiel: 
    dig +nocmd example.com a +noall +answer
    dig +nocmd www.example.com cname +noall +answer
  • Prüfe, ob alle Nameserver auf die richtigen IP-Adressen deiner Website verweisen. Beispiel: 
    dig +nocmd example.com ns +noall +answer
example.com.    86400  IN  NS  a.iana-servers.net.
example.com.    86400  IN  NS  b.iana-servers.net.
dig +nocmd @a.iana-servers.net example.com +noall +answer
example.com.    86400  IN  A  93.184.216.34
dig +nocmd @b.iana-servers.net example.com +noall +answer
...
  • Wenn du in den letzten 72 Stunden Änderungen an der DNS-Konfiguration vorgenommen hast, musst du möglicherweise warten, bis diese im gesamten DNS-Netzwerk wirksam werden. Um den Vorgang zu beschleunigen, kannst du den Cache der öffentlichen DNS-Server von Google leeren.
  • Wenn du einen eigenen DNS-Server hast, achte darauf, dass er fehlerfrei funktioniert und nicht überlastet ist.