Von Traffic zu Answer Share – warum Crawler-Policy 2026 eine Strategieentscheidung ist
Jahrelang war robots.txt eine Einzeiler-Entscheidung: Suchmaschinen erlaubt, alles andere egal. Das hat sich geändert. Die Frage, welche Bots Zugriff auf den eigenen Content bekommen, ist heute keine technische Konfiguration mehr – sie ist eine Entscheidung darüber, welche Rolle der eigene Content im KI-Ökosystem spielen soll.
Von Traffic zu Answer Share
Bisher war SEO eine Traffic-Disziplin. Die Kernfrage: Wie viele Menschen klicken auf meine Seite? Mit KI-Antwortsystemen – ChatGPT, Perplexity, Claude, Gemini – verschiebt sich die relevante Kennzahl.
Nicht mehr nur: „Wie viele klicken auf meine Seite?”
Sondern: „Wie oft bin ich Teil der Antwort?”
Ein Fachartikel wird nicht mehr direkt besucht, aber seine Inhalte erscheinen in einem Drittel aller Antworten zu einem bestimmten Thema. Klassischer Traffic sinkt, Einfluss steigt. Diese Kennzahl – Answer Share – ist noch nicht standardisiert messbar, aber sie ist real.
Das verändert, wie man „ai-input erlauben” bewerten muss. Es geht nicht nur um Sichtbarkeit in Antworten. Es geht um Marken- und Autoritätsaufbau ohne direkten Klick – und darum, wie viel davon man kontrolliert oder den Algorithmen überlässt.
Wer KI-Zitier-Crawler blockiert, verzichtet bewusst auf diesen Layer. Das kann sinnvoll sein. Aber es sollte eine Entscheidung sein, keine Untätigkeit.
Das eigentliche Risiko: asymmetrische Wertschöpfung
Das Grundproblem ist nicht das Crawling selbst. Es ist die Entkopplung von Nutzung und Gegenleistung.
Suchmaschinen haben einen impliziten Tausch: Indexierung gegen Traffic. Google liest einen Artikel und schickt Besucher zurück. Das war schon immer ein asymmetrischer Deal, aber es gab einen messbaren Rückkanal.
KI-Systeme liefern oft keinen direkten Rückkanal. Das erzeugt drei konkrete Risiken:
Content-Kommodifizierung – Spezifisches Wissen wird Teil eines generischen Modells, das dieselbe Information ohne Quellennennung weitergibt. Der Wissensvorsprung, der den Content wertvoll machte, verschwindet.
Brand-Dilution – Inhalte werden genutzt, ohne klare Attribution. Ein Nutzer bekommt die Antwort, aber nicht die Marke, die dahintersteht.
Disintermediation – Nutzer bekommen Antworten direkt im Chat-Interface, ohne die Seite je zu sehen. Für Geschäftsmodelle, die auf Zugriffsvolumen basieren (Werbung, Lead-Generierung), ist das ein strukturelles Problem.
Deshalb ist ai-train eine andere Kategorie als ai-input – nicht nur technisch, sondern wirtschaftlich. Training gibt Inhalte dauerhaft in ein Modell ab. Zitierung kann Sichtbarkeit schaffen. Beides mit demselben robots.txt-Eintrag zu regeln ist ein Präzisionsproblem.
Die technische Realität: robots.txt vs. Intent
robots.txt wurde entwickelt, um Zugriffsrechte zu regeln – nicht Verwendungszwecke. Das ist das Kernproblem beim Einsatz gegen KI-Crawler.
Ein Bot kann technisch identisch crawlen, aber semantisch völlig unterschiedlich nutzen:
Suchergebnisseite – klassische Suchmaschinen-Indexierung.
Direkte Antwort – RAG-basierte Zitierung in KI-Systemen.
Modell-Update – Content fließt dauerhaft in ein Sprachmodell ein.
robots.txt sieht nur: „darf lesen oder nicht”. Es unterscheidet nicht zwischen diesen drei Zwecken.
Das erklärt, warum neue Signalebenen entstehen:
llms.txt ist eine deklarative Datei, die KI-Agenten und Language Models erklärt, wie mit dem Content umgegangen werden soll – ähnlich wie robots.txt, aber für Intent statt für Zugriff.
HTTP-Header-Erweiterungen wie X-Robots-Tag werden experimentell für KI-spezifische Direktiven diskutiert, sind aber noch nicht etabliert.
Terms of Service und Legal Layer werden zunehmend relevant, weil robots.txt keine rechtlich durchsetzbare Zugangskontrolle ist. Mehrere laufende Klagefälle drehen sich genau um diese Frage.
Wichtig: Diese Signale sind aktuell Soft Power, keine harte technische Zugangskontrolle. Ein Bot, der die Policy ignoriert, kann es technisch weiterhin tun. Aber der Legal-Layer wird schärfer, und KI-Anbieter haben ein wachsendes Interesse, deklarierte Policies zu respektieren – weil es ihnen hilft, Klagen zu vermeiden.
Was llms.txt leisten kann – auch ohne Standard
llms.txt ist kein IETF-Standard und wird von keinem Crawler zwingend ausgewertet. Trotzdem lohnt sich die frühe Adoption aus zwei Gründen.
Intent-Externalisierung: Eine llms.txt macht die eigene Policy maschinenlesbar. Statt implizit zu hoffen, dass Crawler die robots.txt-Anweisungen richtig interpretieren, wird explizit kommuniziert: „Zitierung ja, Training nein.” Das ist keine Garantie, aber es schafft eine dokumentierte Position.
Future-Proofing: robots.txt war anfangs ebenfalls freiwillig – heute ist es faktisch verbindlich, weil sich ein De-facto-Standard gebildet hat. llms.txt befindet sich in derselben frühen Phase. Wer jetzt eine saubere Policy hinterlegt, ist kompatibel, sobald sich ein Standard etabliert.
astro-crawler-policy generiert robots.txt und llms.txt aus einer einzigen, typisierten Konfiguration zur Build-Zeit. Die Unterscheidung zwischen search, ai-input und ai-train ist direkt konfigurierbar – ohne manuelles Datei-Editieren.
Die fünf Entscheidungsmuster
Die meisten Organisationen fallen in eines dieser Muster – je nachdem, wie sie Content nutzen und schützen wollen:
Nur Suchmaschinen (seoOnly): Traditionelle Indexierung, alle KI-Crawler blockiert. Für Unternehmen, die Content als proprietären Wettbewerbsvorteil sehen und KI-Sichtbarkeit nicht priorisieren.
Zitierfreundlich (citationFriendly): Suchmaschinen und Zitier-Bots erlaubt, Training-Crawler blockiert. Der häufig sinnvollste Kompromiss – Answer Share aufbauen ohne Content als Trainingsdaten abzugeben.
Offen für KI (openToAi): Alle Crawler erlaubt. Für Open-Source-Projekte, öffentliche Dokumentation oder Inhalte, die explizit zur freien Nutzung gedacht sind.
Training blockieren (blockTraining): Suchmaschinen und Zitier-Bots erlaubt, Training-Bots blockiert. Ähnlich wie citationFriendly, aber mit expliziterem Fokus auf den Schutz vor Modell-Nutzung.
Lockdown: Alles blockiert. Für sensible Inhalte, Intranets oder Seiten, die grundsätzlich nicht indexiert werden sollen.
Entscheidungsframework: drei Fragen
Statt Bauchgefühl gibt es drei Fragen, die die richtige Policy in den meisten Fällen eingrenzen:
Frage 1 – Ist der Content differenzierend oder austauschbar?
Differenzierender Content (Research, proprietäre Daten, Expertenwissen) hat ein hohes Reproduktionsrisiko – Training blockieren ist naheliegend. Austauschbarer Content (allgemeine Marketingtexte) ist weniger kritisch.
Frage 2 – Monetarisierung über Zugriff oder Einfluss?
Wer über Seitenbesuche monetarisiert (Werbung, direkte Lead-Generierung), sollte bei ai-input vorsichtiger sein. Wer Einfluss und Markenautorität aufbaut (Thought Leadership, Fachinformation), profitiert eher von ai-input erlaubt.
Frage 3 – Wie hoch ist das Reproduktionsrisiko?
Hoch bei: Research-Inhalten, proprietären Datensätzen, kuratierten Fachartikeln. Niedrig bei: allgemeinen Erklärungen, öffentlich zugänglichem Basiswissen, Marketing-Copy.
Operative Umsetzung: wie anfangen
Minimal-Setup (ein bis zwei Stunden)
- Bestehende robots.txt auditieren: welche AI-User-Agents sind bekannt, welche fehlen?
- Relevante Bots identifizieren: GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Google-Extended, CCBot (Common Crawl) sind die wichtigsten
- Eines der fünf Muster auswählen
- llms.txt anlegen – auch eine grobe Version ist besser als keine
Fortgeschrittenes Setup
- Content-Kategorien differenzieren: unterschiedliche Policies für
/blog/,/docs/,/research/per Pfad - Logfile-Analyse: welche Bots crawlen tatsächlich, mit welcher Frequenz?
- Monitoring aufsetzen: Änderungen an Bot-User-Agents verfolgen (die Liste wächst)
Was Blocking nicht löst
Selbst eine vollständige Blockade aller AI-Crawler ist kein absoluter Schutz.
Inhalte können über Drittseiten in Modelle gelangen, die dieselben Inhalte aggregieren oder zitieren. Trainingsdaten entstehen nicht nur durch direktes Crawling der eigenen Domain. Aggregatoren, Zitierplattformen und weitergeleitete Inhalte umgehen direkte Blockaden strukturell.
Das bedeutet: Blocking ist keine Garantie, sondern eine Positionsbestimmung. Es signalisiert, was erlaubt ist – und schafft eine rechtliche Grundlage für den Fall, dass diese Position verletzt wird. Es verhindert nicht jede Form der Nutzung.
Das mindert die Relevanz der Entscheidung nicht. Es verändert nur, womit man rechnen sollte.
Welche Rolle soll der eigene Content spielen?
Die eigentliche Frage ist nicht „Blockieren oder erlauben?” Sie ist: Welche Rolle soll unser Content im KI-Ökosystem spielen?
Keine dieser Positionen ist per se richtig oder falsch. Sie hängen davon ab, wie Content im Geschäftsmodell funktioniert, wie hoch das Reproduktionsrisiko ist und welche Rolle Sichtbarkeit gegenüber Kontrolle spielt.
Die Entscheidung, die man nicht trifft, trifft sich selbst. Wer keine explizite Policy hat, überlässt die Einordnung den Bots – und die folgen den Default-Regeln ihres jeweiligen Anbieters. Das ist kein Notfall. Aber das Fenster, in dem diese Entscheidung noch rückwirkend Relevanz hat, schließt sich mit jedem Crawl-Zyklus ein Stück weiter.