Welche KI-Crawler sollte ich in der robots.txt meines Onlineshops zulassen?

Nein. OpenAI unterscheidet beispielsweise den Suchcrawler OAI-SearchBot vom GPTBot, dessen Abrufe für mögliches Modelltraining vorgesehen sind. Die Einstellungen können unabhängig voneinander erfolgen. Wer Trainingszugriff ablehnt, muss deshalb nicht automatisch den Suchcrawler sperren. Maßgeblich ist die aktuelle Crawler-Dokumentation von OpenAI.

Das bedeutet nicht, dass eine Freigabe eine Empfehlung Ihres Shops erzwingt. Sie beseitigt gegebenenfalls ein Zugriffshindernis. Welche Quellen ein System anschließend auswählt, ist eine eigene Entscheidung. Für Händler ist diese Unterscheidung wichtig: Eine technische Freigabe und eine erfolgreiche GEO-Maßnahme sind nicht dasselbe.

Bei Google ist ebenfalls der jeweilige Zweck entscheidend. Für die Suchfunktionen einschließlich AI Overviews und AI Mode ist die Steuerung des Googlebot relevant. Google-Extended betrifft bestimmte Nutzungen in anderen Google-KI-Produkten und ist kein Schalter, mit dem Sie ausschließlich die KI-Antworten in Google Search an- oder ausschalten.

Google erläutert diese Trennung in seiner Dokumentation zu KI-Funktionen in der Suche und der Crawler-Übersicht. Deshalb würden wir vor jeder Änderung schriftlich festhalten: Welcher Dienst soll auf welche öffentlichen Inhalte zugreifen dürfen, und welches Ziel verfolgt die Regel?

Die robots.txt ist nur eine Ebene. Ein CDN, eine Firewall oder ein Bot-Schutz kann eine Anfrage trotzdem abweisen oder eine Browserprüfung verlangen. Umgekehrt belegt ein erfolgreicher Aufruf im eigenen Browser nicht, dass ein Suchcrawler dieselben Inhalte erhält.

Wir würden mit einer betroffenen Produkt- oder Ratgeberseite beginnen und Antwortstatus, Weiterleitungen sowie die ausgelieferten Inhalte prüfen. Eine Fehlerseite mit HTTP 200 ist ebenso wenig hilfreich wie ein CAPTCHA vor der Produktbeschreibung. Bei PrestaShop gehören deshalb Hosting, vorgeschaltete Dienste und relevante Sicherheitsmodule gemeinsam in die Untersuchung.

Ein umbenannter User-Agent allein ist kein belastbarer Nachweis eines echten Anbieterzugriffs. Für die Einordnung von Serverprotokollen sollten die vom Anbieter dokumentierten Verifikationsverfahren beziehungsweise veröffentlichten IP-Bereiche berücksichtigt werden. Bot-Schutz würden wir nicht pauschal abschalten, sondern eine begründete, möglichst eng gefasste Ausnahme prüfen.

• Ziel: Suchsichtbarkeit, Training und nutzerinitiierte Abrufe getrennt einordnen.
• Regeln: die tatsächlich ausgelieferte robots.txt des betroffenen Hosts prüfen.
• Seiten: wichtige Kategorien, Produkte und Ratgeber als konkrete Testfälle auswählen.
• Zugriff: HTTP-Antwort, Weiterleitung, Bot-Schutz und sichtbaren Inhalt vergleichen.
• Nachweise: Protokolle und Anbieterangaben zur Identifikation des Zugriffs heranziehen.
• Nachkontrolle: Änderung dokumentieren und den betroffenen Zugriff erneut beobachten.

So entsteht ein überprüfbares Ergebnis: Welche Regel blockiert welche Seite, und was wurde geändert? Das ist hilfreicher als ein allgemeines Etikett wie „KI-freundlicher Shop“, das keine konkrete Aussage zur Erreichbarkeit macht.

Nein. Die Datei ist eine Anweisung für kooperierende Crawler, keine Zugangskontrolle. Kundenkonten, interne Unterlagen und Testshops brauchen geeignete Authentifizierung beziehungsweise Zugriffsbeschränkungen. Vertrauliche Pfade nur in robots.txt einzutragen macht sie nicht vertraulich.

Auch Crawling und Indexierung sind zu unterscheiden. Google weist darauf hin, dass eine gesperrte URL unter Umständen trotzdem im Suchindex erscheinen kann. Eine noindex-Anweisung muss Google abrufen können, um sie auszuwerten. Die Grundlagen stehen in Googles robots.txt-Einführung. Welche Shop-URLs überhaupt in den Index gehören, behandelt unser eigener Beitrag zu Duplicate Content.

Eine llms.txt ersetzt diese Entscheidungen nicht. Dafür gibt es bereits unseren Beitrag Braucht ein Onlineshop eine llms.txt?. Eine weitere Datei hilft wenig, wenn der eigentliche Seitenabruf an einer Sperre scheitert.

Ein hypothetisches Beispiel: Nach einem Wechsel des Bot-Schutzes bleibt ein Ratgeber für Besucher erreichbar, während automatisierte Suchzugriffe an einer Prüfseite hängen. Wir würden die Änderung eingrenzen, die betroffenen Anfragen nachvollziehen und eine kontrollierte Korrektur mit dem Hostinganbieter abstimmen. Das Beispiel beschreibt einen Prüfablauf, keinen nachgewiesenen Kundenfall.

Unsere GEO-Beratung lässt sich hier mit technischer PrestaShop-Betreuung verbinden. PrestaShop bietet Spielraum für gezielte Anpassungen; ein Wechsel des Shopsystems ist für eine falsch gesetzte Zugriffsregel normalerweise nicht der erste Ansatz. Nach der technischen Prüfung folgt die inhaltliche Frage: Sind die erreichbaren Informationen überhaupt hilfreich und eindeutig? Ob daraus mehr Sichtbarkeit entsteht, prüfen wir separat anhand eines Messplans für KI-Sichtbarkeit.