Eure robots.txt bringt gar nichts, wenn der Server "Nein" sagt

Beim Thema KI-Sichtbarkeit (GEO / Generative Engine Optimization) gibt es viele Stellschrauben – und genau wie im klassischen SEO spielt auch hier die robots.txt eine wichtige Rolle. Wer will, dass ChatGPT, Claude oder Perplexity die eigenen Inhalte lesen und zitieren, trägt brav die passenden User-Agents ein und setzt sie auf Allow.

Fall erledigt, Häkchen dran? Leider nein.

In den letzten Wochen bin ich in der Praxis über ein Phänomen gestolpert, das zwar selten vorkommt, dafür aber umso tückischer ist – weil man es normalerweise gar nicht zu Gesicht bekommt: Die robots.txt erlaubt den KI-Bots alles – und der Server knallt ihnen trotzdem die Tür vor der Nase zu. 🚪

Ein Schild an der Tür hilft nicht, wenn das Gartentor abgeschlossen ist

Stellt euch das mal bildlich vor: Ihr hängt ein Schild an eure Haustür mit der Aufschrift "KI-Bots herzlich willkommen!". Genau das macht ihr mit so einem Eintrag in der robots.txt:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

Sieht gut aus, oder? Das Problem dabei: Wenn der Bot gar nicht erst bis zu eurer Haustür durchkommt, bringt euch das schönste Schild der Welt nichts.

Genau das habe ich festgestellt. Die robots.txt war astrein konfiguriert – aber die Crawler von OpenAI (GPTBot) und Anthropic (ClaudeBot) bekamen schon beim allerersten Aufruf der Domain einen HTTP-Statuscode 403 (Forbidden) um die Ohren gehauen. Und zwar nicht nur für die eigentlichen Inhalte, sondern sogar schon für die robots.txt selbst.

Woher kommt dieser 403-Fehler eigentlich?

Da die Blockade schon beim Abruf der robots.txt greift, könnt ihr WordPress und eure SEO-Plugins direkt mal aus der Schusslinie nehmen. Meistens steckt die Ursache nicht einmal in der .htaccess. Die Sperre passiert eine ganze Etage höher – auf Server- bzw. VHost-Ebene:

• Hoster-Standardeinstellungen: Viele Hosting-Anbieter sperren KI-Crawler standardmäßig serverseitig, um sich Serverlast und Bandbreite zu sparen.
• Web Application Firewalls (WAF): Sicherheitssysteme wie ModSecurity, Cloudflare oder Sucuri stufen aggressive oder unbekannte Bots gerne automatisch als Bedrohung ein.
• Bad-Bot-Filter im Webserver: Regeln direkt in Apache oder Nginx, die bestimmte User-Agents pauschal blockieren.

So testet ihr selbst, ob euer Server KI-Bots aussperrt

Der Haken an der Geschichte: Ruft ihr eure Website ganz normal im Browser auf, ladet ihr die Seite als menschlicher Nutzer. Ihr bekommt euren gewohnten Statuscode 200 OK und merkt überhaupt nicht, dass die KI-Bots parallel draußen vor der Tür stehen.

Um das zu checken, müsst ihr euch gegenüber eurem Server als KI-Bot ausgeben (User-Agent-Spoofing). Am schnellsten geht das über die Kommandozeile (Terminal unter Mac / Eingabeaufforderung unter Windows) mit cURL. Kopiert euch einfach die folgenden Befehle rein:

Test für den GPTBot (ChatGPT):

curl -I -A "GPTBot" https://eure-domain.de/robots.txt

Test für den ClaudeBot (Claude):

curl -I -A "ClaudeBot" https://eure-domain.de/robots.txt

Und so lest ihr das Ergebnis:

• HTTP/1.1 200 OK (bzw. HTTP/2 200): Alles bestens! Der Server lässt den Bot durch, eure robots.txt-Regeln greifen wie gewünscht.
• HTTP/1.1 403 Forbidden: Alarmstufe Rot. Euer Server blockiert den Bot aktiv – die KI kann eure Website schlichtweg nicht lesen.
• curl: (28) Failed to connect / Timeout: Der Server antwortet erst gar nicht (Silent Drop). Auch das läuft am Ende auf dasselbe hinaus: Der Bot wird effektiv ausgesperrt.

Was das für eure GEO-Strategie bedeutet

Für Brand Visibility und GEO ist dieser Fehler aus meiner Sicht ein echter Stille-Post-Killer. Wer in den Antworten von ChatGPT, SearchGPT, Claude oder Perplexity auftauchen will, muss dafür sorgen, dass die Crawler die eigenen Inhalte überhaupt fehlerfrei auslesen können.

Blockiert euer Hoster die Bots, werdet ihr für KI-Suchmaschinen schlicht unsichtbar – völlig egal, wie durchdacht und gut aufbereitet euer Content eigentlich ist. Der beste Content nützt nichts, wenn er gar nicht erst gelesen wird.