Sperrt deine Website KI-Crawler, ohne dass du es weisst?

Ja, das kann passieren, und zwar ohne dass irgendjemand es beschlossen hat. Am 30. August 2026 haben wir die robots.txt unserer eigenen Seiten nicht im Code, sondern so gelesen, wie ein Besucher sie bekommt. Auf jeder Adresse stand ein Block, den wir nie geschrieben hatten: ChatGPT, Claude und weitere Antwortmaschinen durften nicht lesen. Der Anbieter, der die Seiten ausliefert, hatte ihn eingefügt. Unsere eigene Datei sagte «alles erlaubt» und stand darunter, wirkungslos. Wer prüfen will, ob es ihm genauso geht, schaut nicht in seinen Code, sondern ruft seine Adresse mit /robots.txt am Ende auf.

Was ist eigentlich passiert?

Die Datei robots.txt liegt auf jeder Website und sagt Maschinen, was sie lesen dürfen. Unser Code lieferte eine kurze Fassung: ein Eintrag für alle Crawler, alles erlaubt. Zwischen unserem Server und dem Besucher sitzt aber ein Dienst, der die Seiten schneller macht und vor Angriffen schützt. Dieser Dienst hat eine Einstellung, die KI-Crawler pauschal aussperrt, und sie war für unsere Zone aktiv. Er fügte deshalb bei jeder Auslieferung einen eigenen Block an den Anfang der Datei: ClaudeBot, GPTBot, Google-Extended, Applebot-Extended, Bytespider, CCBot, Amazonbot und ein Crawler von Meta, alle mit «Disallow: /».

Das Tückische: Die spezifischere Regel gewinnt. Unser «alles erlaubt» galt für alle, der Block galt für genau diese Crawler, also zählte der Block. Die Messung am Server selbst zeigte die saubere Datei. Erst die Messung von aussen zeigte die Wahrheit. Wer nur den Code prüft, sieht das Problem nie.

Warum zählt das für einen kleinen Betrieb?

Antwortmaschinen wie ChatGPT nennen nur Betriebe, deren Seiten sie lesen konnten. Alles, was man für die Sichtbarkeit in der KI-Suche tun kann, also strukturierte Angaben, klare Texte, eine Datei llms.txt, setzt voraus, dass der Crawler überhaupt hineinkommt. Ein Betrieb mit gesperrten Crawlern ist für diese Werkzeuge nicht vorhanden, so gut seine Seite auch gebaut ist.

Der Block hatte sogar einen Widerspruch eingebaut: Eine Zeile erlaubte die Verwendung der Inhalte als Referenz in Antworten, drei Zeilen später war das Lesen verboten. Wer nicht lesen darf, kann nicht referenzieren.

Wie prüfst du deine eigene Seite?

Drei Schritte, keiner braucht Fachwissen. Erstens: Öffne im Browser deine Adresse mit /robots.txt am Ende, etwa www.dein-betrieb.ch/robots.txt. Steht dort ein Abschnitt mit «Cloudflare Managed» oder einzelne Zeilen mit GPTBot, ClaudeBot oder Google-Extended und «Disallow: /», sperrt deine Seite diese Crawler. Zweitens: Die Datei ist nur die halbe Wahrheit. Am 2. Oktober 2026 fanden wir bei einer Vorschau eine zweite Sperre, die in keiner Datei stand: Anfragen mit der Kennung eines KI-Crawlers bekamen schlicht die Antwort «blockiert». Darum fragt unser GEO-Checker die Seite zusätzlich mit der Kennung von GPTBot und ClaudeBot ab und zeigt, ob eine Antwort kommt. Drittens: Wiederhole die Prüfung nach jedem Anbieterwechsel und nach jeder neuen Domain. Die Einstellung wirkt je Zone, manchmal je Konto.

Was tust du, wenn deine Seite sperrt?

Die Sperre sitzt in der Verwaltung deines Hosting- oder Schutzanbieters, nicht in deiner Website. Bei uns hiess die Einstellung «AI Crawl Control» und lag im Dashboard der Zone. Nach dem Abschalten haben wir nachgemessen: Die ausgelieferte Datei enthielt nur noch unsere eigene Zeile, und Anfragen mit der Kennung von GPTBot und ClaudeBot bekamen die Seite mit Status 200, auf der Startseite und auf Unterseiten.

Eine Abwägung bleibt dir: Du kannst das Training von KI-Modellen mit deinen Inhalten ablehnen und trotzdem das Lesen für Antworten erlauben. Die beiden Dinge sind getrennte Fragen. Für einen Betrieb, der gefunden werden will, spricht alles dafür, das Lesen zu erlauben. Wer unsicher ist, lässt sich die Datei von seinem Webmaster zeigen, und zwar die ausgelieferte, nicht die im Code.