Robots.txt Ratgeber

Robots.txt HTTP-Statuscodes: 200, 404, 403, 429 und 5xx

Wie HTTP-Antworten von robots.txt Googlebot beeinflussen: 2xx, Redirects, 404, 403, 429, 5xx, Caching und Netzwerkfehler.

Von Robots.txt Tools Editorial TeamZuletzt geprüft am 2026-09-133 Min. Lesezeit
Robots.txt HTTP-Statuscodes: 200, 404, 403, 429 und 5xx

Die HTTP-Antwort von /robots.txt gehört zur Crawl-Policy. Perfekte Regeln helfen wenig, wenn der Endpunkt einen falschen Status liefert, in Redirects hängen bleibt oder beim Deployment ausfällt.

Kurzübersicht

AntwortTypisches Google-Verhalten
2xxrobots.txt-Inhalt wird verarbeitet
3xxRedirects werden bis zu einem Limit verfolgt
Die meisten 4xx außer 429Behandlung wie keine gültigen Einschränkungen
429Überlastungs-/Rate-Limit-Signal
5xxCrawling wird temporär reduziert/gestoppt und erneut versucht
DNS-/NetzwerkfehlerÄhnlich wie Serverfehler

200: Normalfall

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8

Google erwartet UTF-8 und verarbeitet höchstens 500 KiB der Datei. Ein 200 bedeutet daher nicht automatisch, dass eine extrem große Datei vollständig berücksichtigt wird.

404: meist „keine Einschränkungen“

Eine fehlende robots.txt blockiert Google nicht. Normale 4xx außer 429 werden wie das Fehlen einer gültigen Datei behandelt.

Ein 404 schützt deshalb keine Staging-Umgebung und keine privaten Inhalte. Dafür ist Authentifizierung nötig.

403 und 401 sind kein Disallow

Antwortet WAF, CDN oder Middleware auf /robots.txt mit:

HTTP/1.1 403 Forbidden

liest Google die beabsichtigten Regeln nicht. Das kann dazu führen, dass Einschränkungen verloren gehen statt stärker zu werden.

429 ist anders

429 Too Many Requests signalisiert Überlastung oder Rate-Limiting und kann Crawling reduzieren. Es ist kein reguläres Konfigurationswerkzeug für robots.txt.

5xx kann Crawling vorübergehend bremsen

Bei 500, 502 oder 503 versucht Google die Datei erneut abzurufen und kann das Crawling reduzieren. Eine zuletzt bekannte gültige robots.txt kann noch eine Zeit lang relevant sein.

Prüfe Edge Functions, Upstreams, Rewrites und Migrationen, die aus einer statischen Datei versehentlich einen fehlerhaften dynamischen Endpunkt gemacht haben.

Redirects müssen sauber enden

Typische Fehler:

  • HTTP/HTTPS-Schleifen;
  • www und Apex leiten gegenseitig um;
  • Locale-Middleware verschiebt /robots.txt in eine Sprachroute;
  • Auth-Middleware schickt Crawler zum Login;
  • CDN liefert HTML mit Status 200.

Die echte Antwort prüfen

Kontrolliere:

  • endgültige URL;
  • HTTP-Status;
  • Content-Type;
  • Größe und Encoding;
  • Cache-Header;
  • WAF-Verhalten je User-agent;
  • ob der Body wirklich robots.txt-Text ist.

Diagnose-Reihenfolge

  1. Live-/robots.txt abrufen.
  2. End-URL und Status notieren.
  3. Redirects, CDN und WAF prüfen.
  4. UTF-8 und Dateigröße prüfen.
  5. Syntax validieren.
  6. Repräsentative URLs testen.
  7. Serverlogs auf Fehler prüfen.
  8. Caching einer älteren Policy berücksichtigen.
  9. Nach der Korrektur weiter überwachen.

HTTP-Auslieferung ist Teil der robots.txt-Korrektheit. Derselbe Text kann mit 200, 403, 404 oder 5xx völlig unterschiedliche Crawl-Folgen haben.

Passende Anleitungen