Eine URL, die einen HTTP-Fehlercode zurückgibt, weist nicht immer auf dieselbe Störung hin. Zwischen einer fehlerhaften Anfrage (400), einer gelöschten Seite (404) und einem überlasteten Server (503) unterscheiden sich Ursache, Auswirkungen auf die Indexierung und die erforderlichen Maßnahmen grundlegend. Wer die Unterschiede zwischen diesen Codes kennt, kann Korrekturen priorisieren und Schäden für die Suchmaschinenoptimierung begrenzen.
HTTP-Fehlercodes: unterschiedliche Auswirkungen der 4xx- und 5xx-Familien
Die erste Ziffer des Statuscodes zeigt, auf welcher Seite das Problem liegt. Die 4xx- und 5xx-Familien haben ganz unterschiedliche Auswirkungen darauf, wie Suchmaschinen-Crawler eine Website durchsuchen.
| Code | Familie | Ursache des Problems | Auswirkung auf die Indexierung |
|---|---|---|---|
| 400 | 4xx (Client) | Fehlerhafte URL, nicht codierte Zeichen, fehlender Parameter | Seite wird als nicht vorhanden behandelt und nach einigen Versuchen aus dem Index entfernt |
| 403 | 4xx (Client) | Zugriff vom Server verweigert (Berechtigungen, .htaccess) | Seite wird nicht indexiert, solange der Zugriff gesperrt bleibt |
| 404 | 4xx (Client) | Gelöschte Seite, geänderte URL ohne Weiterleitung, defekter Link | Seite wird nach und nach aus dem Index entfernt |
| 500 | 5xx (Server) | Interner Fehler: fehlerhaftes Skript, beschädigte Konfiguration | Das Crawling der gesamten Website wird verlangsamt |
| 502 | 5xx (Server) | Ungültige Antwort, die der Proxy oder das Gateway erhalten hat | Wie bei 500: Das Crawling wird gebremst |
| 503 | 5xx (Server) | Server nicht verfügbar (Wartung, Überlastung) | Crawling wird ausgesetzt; bei anhaltendem Fehler können indexierte Seiten entfernt werden |
Wichtig ist: Ein anhaltender 5xx-Fehler kann dazu führen, dass bereits indexierte Seiten entfernt werden. Ein einzelner 404-Fehler hat dagegen keine nennenswerten Auswirkungen auf den Rest der Website.
Google weist darauf hin, dass 5xx- und 429-Antworten seine Crawler vorübergehend verlangsamen. Dauert das Problem an, wirkt es sich auch auf andere URLs des Hosts aus. Eine ausführliche Anleitung erklärt, wie Sie eine ungültige Server-URL korrigieren und die einzelnen Codefamilien genau unterscheiden.
Fehler in robots.txt: Der Fall, der das Crawling einer ganzen Website blockiert
Dieses Szenario wird von Mitbewerbern selten behandelt, obwohl es die weitreichendsten Schäden verursachen kann. Eine 5xx-Antwort auf die Datei robots.txt setzt das Crawling des gesamten Hosts aus. Google versucht, diese Datei vor jeder Crawling-Sitzung abzurufen. Erhält der Crawler einen Serverfehler, zieht Google es vor, gar nichts zu crawlen, statt möglicherweise auf gesperrte Seiten zuzugreifen.
Die Diagnose beginnt daher mit dieser Datei. Ihre Erreichbarkeit lässt sich in wenigen Sekunden mit einer direkten Anfrage im Browser überprüfen (votredomaine.com/robots.txt). Gibt die Seite den Statuscode 200 und lesbaren Inhalt zurück, liegt das Problem an anderer Stelle.
Wenn der Proxy die eigentliche Ursache verschleiert
Ein 502- oder 504-Fehler bei robots.txt kann von einer Zwischeninstanz (Reverse-Proxy, CDN) und nicht vom Anwendungsserver verursacht werden. Um die Ursache einzugrenzen, muss die Kommunikation zwischen Proxy und Upstream-Server untersucht werden. Die Protokolle des Proxys (Nginx, Varnish, Cloudflare) zeigen, ob die Anfrage den Ursprungsserver erreicht hat oder unterwegs in einen Timeout gelaufen ist.
Wer einen Proxy-Timeout mit einem Ausfall der Anwendung verwechselt, nimmt möglicherweise unnötige Codeänderungen vor, obwohl das Problem in der Netzwerkkonfiguration liegt.
Ungültige URLs erkennen: Methoden und Tools kombinieren
Ein einzelnes Tool reicht nicht aus. Jede Quelle deckt einen anderen Aspekt der Erkennung ab. Durch den Abgleich lassen sich blinde Flecken vermeiden.
- Der Bericht „Crawling-Statistiken“ in der Google Search Console zeigt, wie häufig Googlebot auf Fehler stößt, um welche Art von Fehlern es sich handelt (5xx, 404, DNS-Timeout) und wie sich diese im Zeitverlauf entwickeln. Er bietet die Perspektive der Suchmaschine.
- Die Serverprotokolle (access.log, error.log) liefern die Rohdaten: IP-Adresse des Clients, angeforderte URL, zurückgegebener Statuscode und genaue Uhrzeit. So lassen sich Fehlerhäufungen erkennen, die mit einem Deployment oder einer Überlastung zusammenhängen.
- Ein Crawler wie Screaming Frog oder Sitebulb folgt den internen Links der Website und meldet alle URLs, die einen ungewöhnlichen Statuscode zurückgeben. Er erkennt auch defekte Links in der internen Verlinkung, die in der Search Console nicht sichtbar sind.
Der Abgleich von Search Console und Serverprotokollen ist nach wie vor die zuverlässigste Methode. Die Search Console meldet URLs, die Google nicht erreichen konnte; die Protokolle zeigen, warum und wann der Server den Fehler zurückgegeben hat.
DNS-Fehler oder Timeout: falsch positive Ergebnisse erkennen
Ein DNS-Problem bedeutet nicht zwangsläufig, dass der Server ausgefallen ist. Der DNS-Server kann vorübergehend nicht erreichbar sein, obwohl die Website normal funktioniert. Google meldet solche Fälle in der Search Console als „DNS-Fehler“. Bevor Sie Änderungen an der Anwendung vornehmen, können Sie mit einem Tool wie dig oder nslookup die DNS-Auflösung prüfen und diese Möglichkeit ausschließen.
Serverfehler beheben: Prioritäten nach Statuscode und Dauer setzen
Nicht jeder Fehler ist gleich dringend. Ein vorübergehender 503-Fehler mit einem Retry-After-Header ist weniger schwerwiegend als ein dauerhafter 500-Fehler auf einer Seite mit hohem organischem Traffic.
Geplante Wartung und Retry-After-Header
Der HTTP-Standard sieht vor, dass ein Server mit 503 antworten und einen Retry-After-Header mitsenden kann, der Crawlern mitteilt, wann sie es erneut versuchen sollen. Fehlt dieser Header, behandelt Google den 503-Fehler wie einen gewöhnlichen Vorfall und verlangsamt das Crawling, ohne zu wissen, wann ein erneuter Versuch sinnvoll ist. Wird der Header bei einer geplanten Wartung hinzugefügt, lassen sich die Auswirkungen auf die Indexierung begrenzen.
301-Weiterleitungen bei wiederkehrenden 404-Fehlern
Eine gelöschte Seite, auf die eingehende Links verweisen, verliert ihren gesamten SEO-Wert, wenn sie weiterhin einen 404-Fehler zurückgibt. Eine 301-Weiterleitung auf die relevanteste Seite überträgt den Großteil der Signale. Alle 404-Fehler auf die Startseite umzuleiten, ist dagegen kontraproduktiv: Google ignoriert solche pauschalen Weiterleitungen mit der Zeit.
Die Priorisierung erfolgt anhand zweier Datenpunkte: der Anzahl eingehender Links zur fehlerhaften URL (über die Search Console oder Ahrefs) und des Traffics, den sie vor ihrer Löschung generiert hat. URLs ohne Links und ohne Traffic können ohne Folgen einen 404-Status zurückgeben.
Das wichtigste Ergebnis: Anhaltende 5xx-Fehler beeinträchtigen das Crawling der gesamten Website, während 4xx-Fehler auf die jeweils betroffene Seite beschränkt bleiben. Bei jedem Vorfall sollten Sie zuerst die Erreichbarkeit von robots.txt prüfen und die Berichte der Search Console mit den Serverprotokollen abgleichen.
