Error Pages & KI-Crawler: Wie 404, 500 und 429 die GEO beeinflussen

Laut der Dokumentation von Google Search Central entfernt Google eine URL aus dem Index, wenn Googlebot länger als zwei Tage nur 503- oder 429-Antworten erhält (https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors, 2025). Für Website-Betreiber bedeutet das: Ein Serverfehler läuft gegen eine klare Frist, bevor er zum Sichtbarkeitsproblem wird.

Definition: Error Pages sind die Antworten, die ein Server bei einem Problem liefert, etwa die HTTP-Statuscodes 404 (nicht gefunden), 500 (interner Serverfehler) oder 429 (zu viele Anfragen). Für GEO (Generative Engine Optimization) sind sie relevant, weil KI-Crawler wie GPTBot, PerplexityBot oder ClaudeBot diese Codes auswerten und ihr Crawling-Verhalten und teils die Aufnahme einer Seite danach ausrichten.

KI-Crawler und Fehlerseiten: mehr Bots als nur Googlebot

Bis vor kurzem musste eine Website im Grunde mit einem einzigen Crawler klarkommen: Googlebot. Heute kommen GPTBot, PerplexityBot, ClaudeBot und CCBot hinzu, und jeder Anbieter definiert eigene Regeln für den Umgang mit Fehlercodes.

Laut der Entwicklerdokumentation von OpenAI unterscheidet das Unternehmen drei Bot-Typen mit unterschiedlichem robots.txt-Verhalten: GPTBot sammelt Trainingsdaten, OAI-SearchBot bedient die Live-Suche innerhalb von ChatGPT, und ChatGPT-User ruft Seiten während einer Nutzersitzung ab, wobei robots.txt-Regeln hier nicht zwingend gelten (https://developers.openai.com/api/docs/bots). Perplexity trennt ähnlich: PerplexityBot respektiert robots.txt und indexiert nur für die Suche, während Perplexity-User robots.txt bei nutzerausgelösten Live-Abrufen generell ignoriert (https://docs.perplexity.ai/docs/resources/perplexity-crawlers).

Für Fehlerseiten heißt das konkret: Ein dauerhafter 500-Fehler kann zusätzlich zum Trainings-Crawler auch den Live-Abruf treffen, genau in dem Moment, in dem ein Nutzer bei ChatGPT nach deiner Website fragt. Laut einer Analyse von Cloudflare entfallen fast 80 Prozent des gesamten KI-Bot-Traffics auf Trainings-Crawler, während Such- und Live-Nutzerabrufe zusammen unter 5 Prozent liegen (https://blog.cloudflare.com/ai-crawler-traffic-by-purpose-and-industry/, 2025). Volumenmäßig treffen Fehlerseiten also vor allem die Trainings-Crawler, nicht den Moment der Live-Antwort, auch wenn genau dieser Moment für die Sichtbarkeit in der KI-Suche zählt.

429 gegenüber KI-Crawlern richtig einsetzen

Der Statuscode 429 ist keine Erfindung der KI-Ära. Laut RFC 6585 von der IETF ist er bereits seit 2012 offiziell für Rate-Limiting spezifiziert und soll idealerweise mit einem Retry-After-Header angeben, wie lange ein Client warten muss, bevor er es erneut versucht (https://datatracker.ietf.org/doc/html/rfc6585, 2012).

Für Googlebot ist die Reaktion dokumentiert: Laut Google Search Central behandelt Google 429-Antworten wie einen 5xx-Serverfehler und drosselt daraufhin vorübergehend das Crawling der betroffenen Seite (https://developers.google.com/search/docs/crawling-indexing/http-network-errors, 2026). Ob GPTBot, PerplexityBot oder ClaudeBot ihre Crawling-Frequenz nach demselben Muster anpassen, ist öffentlich nicht einheitlich dokumentiert. Wer KI-Crawler gezielt drosseln will, statt sie komplett auszusperren, findet dazu mehr im Beitrag zum Rate Limiting für KI-Crawler.

Drei Ansätze im Vergleich: Fehlerseiten für KI-Crawler gestalten

In der Praxis stehen meist drei Wege zur Auswahl, wie eine Website mit fehlerhaften URLs umgeht. Keiner davon ist frei von Nachteilen.

Ansatz	Funktionsweise	Vorteil	Nachteil
Soft 404	Fehlerseite mit Status 200 statt 404	Wirkt für menschliche Besucher freundlicher	Crawler können die Seite fälschlich als gültigen Inhalt einordnen, weil der Statuscode 200 bleibt
Korrekte Statuscodes	404/410 bei entfernten Seiten, 429 mit Retry-After bei Überlast	Deckt sich mit der dokumentierten Google-Logik, ermöglicht gezielte Steuerung	Braucht saubere Serverkonfiguration und laufendes Monitoring
Rate Limiting einzelner Bots	Gezieltes Drosseln oder Blocken einzelner Crawler bei Serverlast	Schützt Serverressourcen gegenüber Trainings-Crawlern mit hohem Traffic-Anteil	Kann laut Google-Doku nach mehr als zwei Tagen anhaltender Fehlerantworten zur Index-Entfernung führen und trifft möglicherweise auch Live-Abrufe

Als Basis für den laufenden Betrieb passt Option zwei am ehesten zur offiziellen Dokumentation: korrekte Statuscodes, ein funktionierender Retry-After-Header bei 429, und eine gepflegte 404-Seite für tatsächlich entfernte Inhalte. Verschwindet eine Seite endgültig, ist ein 410 oder eine gezielte Weiterleitung meist die sauberere Lösung als ein dauerhafter 404, der Crawler im Unklaren lässt. Rate Limiting eignet sich vor allem als kurzfristige Notbremse bei akuter Serverlast. Im Dauerbetrieb gegenüber einzelnen Bots wird es schnell zum eigenen Risiko, weil dann genau die oben beschriebene Zwei-Tage-Frist greifen kann.

Was anhaltende 5xx-Fehler für deine KI-Sichtbarkeit bedeuten

Laut Google Search Central riskiert eine Website, deren URLs Googlebot länger als zwei Tage nur mit 503- oder 429-Antworten begegnen, dass diese URLs aus dem Index entfernt werden (https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors, 2025). Für die KI-Suche ist das relevant, weil ein aus dem Google-Index entfernter Inhalt dort schlicht nicht mehr als Grundlage für eine Antwort zur Verfügung steht, sofern der jeweilige KI-Anbieter überhaupt auf denselben Index zugreift.

Rechenbeispiel (hypothetisch): Eine Website mit 5.000 Produktseiten, bei der ein Serverfehler drei Tage lang jede zehnte Anfrage mit einem Status 500 beantwortet, würde in diesem Modell rund 500 Seiten betreffen, für die laut Google Search Central nach mehr als zwei Tagen anhaltender 5xx- oder 429-Antworten die Entfernung aus dem Index droht.

Wie viel Crawling-Budget KI-Bots für einzelne Seiten überhaupt aufwenden und wie Server-Antwortzeiten das beeinflussen, erklärt der Beitrag zum Crawl-Budget für KI-Bots. Wer solche Fehler früh erkennen will, kommt an den eigenen Server-Logs nicht vorbei; wie sich GPTBot, PerplexityBot und ClaudeBot dort identifizieren lassen, zeigt der Beitrag zur Log File Analyse.

Fehlerseiten-Pflege: ein laufender Posten in der GEO-Strategie

Eine einmal korrekt konfigurierte Fehlerseite bleibt nicht automatisch korrekt. Deployments ändern Statuscodes, CDN-Konfigurationen überschreiben Retry-After-Header, und ein neuer Rate-Limiter kann versehentlich auch OAI-SearchBot aussperren, obwohl nur GPTBot gemeint war.

Wie stark ein einzelner 429- oder 500-Fehler das Vertrauen eines KI-Systems wie ChatGPT oder Perplexity in eine Domain tatsächlich beeinflusst, ist öffentlich nicht belegt. Für Google ist die Reaktion über die genannten Fristen dokumentiert, für die KI-Suchsysteme fehlt bislang eine vergleichbare offizielle Aussage. Wir beobachten die dokumentierte Google-Logik, ohne daraus eine pauschale Aussage für andere Systeme abzuleiten.

Wichtiger als die exakte Wahl des Statuscodes ist aus unserer Sicht deshalb, dass eine Website überhaupt konsistent reagiert: derselbe Fehlerzustand sollte bei jedem Abruf denselben Code liefern, egal ob Googlebot, GPTBot oder ein menschlicher Besucher anfragt. Uneinheitliche Antworten erschweren es jedem Crawler, den tatsächlichen Zustand einer Seite einzuschätzen, und das gilt für klassisches SEO ebenso wie für GEO.

Häufig gestellte Fragen

Was passiert, wenn GPTBot dauerhaft auf eine 404-Seite trifft? Ein einzelner 404 ist normal und für sich genommen kein Problem, wenn die Seite tatsächlich nicht mehr existiert. Kritisch wird es, wenn ein Server bei bestehenden Seiten fälschlich mit 404 oder 5xx antwortet und das über mehrere Tage anhält.

Ist ein 429-Fehler schädlich für die KI-Sichtbarkeit? Laut Google Search Central behandelt Google 429-Antworten wie einen 5xx-Fehler und drosselt das Crawling vorübergehend. Mit einem korrekten Retry-After-Header lässt sich diese Drosselung gezielt steuern: Der Crawler erfährt, wann ein erneuter Versuch sinnvoll ist.

Sollte ich KI-Crawler bei Serverüberlastung per robots.txt komplett aussperren? Das kann kurzfristig sinnvoll sein, birgt aber laut Google Search Central das Risiko, dass URLs nach mehr als zwei Tagen anhaltender Fehlerantworten aus dem Index verschwinden. Ein gezieltes Rate Limiting einzelner Bots senkt dieses Risiko, weil betroffene URLs weiterhin gelegentlich erfolgreich beantwortet werden.

Wie erkenne ich, ob Fehlerseiten meine KI-Sichtbarkeit beeinträchtigen? Am zuverlässigsten über die Server-Logs, in denen sich Statuscodes je Bot einzeln auswerten lassen. Ergänzend gibt eine geaio-Analyse Findings zu technischen SEO-Faktoren aus, die für die Crawlbarkeit einer Website relevant sind.