KI-Crawler: Was robots.txt, llms.txt und strukturierte Daten wirklich bewirken

Eine professionelle Website erhält heute Traffic von Crawlern, die es vor drei Jahren noch nicht gab: GPTBot für das Training von OpenAI, ClaudeBot für Anthropic, Google-Extended für die KI-generierten Übersichten von Google, PerplexityBot für die Antworten von Perplexity. Jeder von ihnen hält sich an das Robots-Exclusion-Protokoll – oder eben nicht –, und jeder erfüllt eine andere Funktion, je nachdem, ob er ein Modell trainiert, Inhalte für eine Konversationsantwort indexiert oder eine Quelle in Echtzeit zitiert. Diese Vielfalt zu ignorieren bedeutet entweder, versehentlich wichtig gewordene Akquisekanäle zu blockieren, oder Inhalte absaugen zu lassen, die besser außerhalb von Trainingsdatensätzen geblieben wären.

#Die Familien der KI-Crawler und ihre Funktion

Hinter dem Sammelbegriff „KI-Crawler“ verbergen sich drei unterschiedliche Verwendungszwecke, die nicht dieselbe Zugriffspolitik verlangen.

Die Unterscheidung zwischen einem Trainings-Crawler und einem Echtzeit-Browsing-Agenten ist zentral. Wer GPTBot blockiert, verhindert nicht, dass ChatGPT-User eine Seite besucht, wenn ein Nutzer explizit nach Informationen zu einer bestimmten Website fragt: Es handelt sich um zwei getrennte Agenten mit getrennten Regeln in der robots.txt.

#Was robots.txt wirklich leisten kann

Das Robots-Exclusion-Protokoll bleibt eine Konvention, keine technische Barriere. Ein regelkonformer Crawler hält sich daran; ein nachlässiger ignoriert es schlicht – das erklärt die wiederkehrenden Kontroversen um Bytespider oder andere schwer identifizierbare Agenten. Für die Crawler, die sich daran halten, bleibt die Syntax die klassische des REP-Standards (Robots Exclusion Protocol).

User-agent: GPTBot
Disallow: /konto/
Disallow: /suche/
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Bytespider
Disallow: /

Diese Datei zeigt eine differenzierte Richtlinie: Google-Extended wird erlaubt, weil die Sichtbarkeit in den KI-Übersichten von Google strategisch wichtig bleibt, ClaudeBot wird blockiert, falls der Anbieter nicht möchte, dass seine Inhalte ein fremdes Modell trainieren, und Bytespider wird vorsorglich gesperrt. Jede Website sollte das nach ihren eigenen Geschäftszielen abwägen, statt eine generische Vorlage zu übernehmen.

#llms.txt: eine aufkommende Konvention, kein Standard

Die Ende 2024 eingeführte Datei llms.txt bietet eine strukturierte Markdown-Zusammenfassung des Website-Inhalts, die direkt von einem Sprachmodell gelesen werden soll, statt einen Crawler zu steuern. Sie liegt im Stammverzeichnis, neben robots.txt und sitemap.xml.

llms.txt wird von keinem der großen Modellanbieter offiziell als verbindliche Quelle für die Indexierung übernommen; ihr Wert bleibt die Lesbarkeit, die sie einem Agenten bietet, der sich dafür entscheidet, sie zu konsultieren.

In der Praxis listet die Datei die wichtigsten Bereiche einer Website mit kurzer Beschreibung und Link auf, in einem Format, das einem kommentierten Inhaltsverzeichnis nahekommt:

# Mail Studio

> Fachmagazin für aktuelle Themen der Webberufe.

## Hauptbereiche
- [Frontend](https://www.mail-studio.com/de/frontend-de/): Frameworks, Performance, Barrierefreiheit
- [KI](https://www.mail-studio.com/de/ki/): KI-Werkzeuge für Entwickler, MCP, Agenten
- [Sicherheit](https://www.mail-studio.com/de/sicherheit/): Härtung, Schwachstellen, Best Practices

Die Verbreitung bleibt uneinheitlich: Keine große Konversations-Suchmaschine hat bestätigt, die Datei systematisch für Indexierung oder Priorisierung zu nutzen. Sie zu veröffentlichen ist eher eine vernünftige, kostengünstige Wette als eine technische Pflicht – im selben Geist wie das Bereitstellen von Funktionen über einen MCP-kompatiblen Server, der ein verwandtes Ziel verfolgt: eine Website oder einen Dienst nativ für einen Agenten statt nur für einen Menschen lesbar zu machen.

#Die Rolle strukturierter Daten bei KI-Antworten

Schema.org-Markup (Article, FAQPage, HowTo, Product) dient längst nicht mehr nur den Rich Snippets klassischer Suchergebnisse. Konversationelle Antwortsysteme stützen sich stark auf dieselben Daten, um überprüfbare Fakten zu extrahieren, eine Quelle mit Autor und Datum zu zitieren oder die Struktur eines Blogbeitrags zu verstehen. Ein Artikel ohne Article-Markup und ohne expliziten author startet im Nachteil gegenüber einem gleichwertigen, korrekt ausgezeichneten Konkurrenten.

#Sollte man Trainings-Crawler blockieren?

Die Frage spaltet die Inhaltsanbieter. Das Blockieren von GPTBot und ClaudeBot schützt den Wert eigener Inhalte vor kostenloser Weiterverwendung durch fremde Modelle, nimmt der Website aber auch eine Form von Präsenz in den künftigen Antworten eben dieser Modelle, während Nutzer zunehmend zu Konversationsassistenten statt zur klassischen Suche greifen. Eine universelle Antwort gibt es nicht: Eine Anwaltskanzlei oder ein Anbieter kostenpflichtiger Schulungen hat beim Blockieren mehr zu gewinnen als ein technischer Blog, der seine Bekanntheit aufbauen will. Die Entscheidung hängt vom Geschäftsmodell ab, nicht von einer generischen Best Practice, die man unreflektiert anwendet.

Ein zunehmend verbreiteter Kompromiss besteht darin, die Indexierung öffentlicher redaktioneller Inhalte zu erlauben, während Bereiche mit hohem kommerziellem Wert – Premium-Inhalte, firmeneigene technische Dokumentation, detaillierte Preisseiten – über gezielte Disallow-Regeln für diese Verzeichnisse statt einer pauschalen Sperre der ganzen Domain blockiert werden.

#Konkret prüfen, was eine Website tatsächlich besucht

Über die deklarative Konfiguration hinaus lässt sich nur anhand der Server-Logs feststellen, was wirklich passiert. Ein Filter auf den User-Agent, abgeglichen mit der Quell-IP-Adresse, unterscheidet einen echten GPTBot von einem Nachahmer, der lediglich den angegebenen User-Agent kopiert: Die großen Anbieter veröffentlichen offizielle IP-Bereiche oder bieten eine Überprüfung per umgekehrter DNS-Auflösung mit anschließender Vorwärtsauflösung an – dieselbe Methode, die historisch zur Authentifizierung von Googlebot verwendet wurde.

#Das Wichtigste in Kürze

Der Umgang mit KI-Crawlern spielt sich auf drei Ebenen ab: robots.txt, um eine Zugriffspolitik pro Agent festzulegen, llms.txt als optionale Ergänzung für die Modelle, die sich für das Lesen entscheiden, und strukturierte Daten, damit erlaubte Inhalte nach dem Sammeln korrekt interpretiert werden. Keiner dieser Hebel ist eine absolute Garantie, aber ihre Kombination bleibt der beste verfügbare Schutz für eine Website, die ihre Sichtbarkeit in KI-generierten Antworten bewusst steuern will.

Weiterführend: der Leitfaden KI für Webentwickler und das Dashboard GA4 und Search Console, um den Traffic von KI-Referrern zu verfolgen.