Wer heute eine Website betreibt, optimiert längst nicht mehr nur für Menschen und für Googlebot. ChatGPT, Claude und Perplexity schicken eigene Crawler los, lesen Seiten in Echtzeit nach, wenn Nutzer eine Frage stellen, und entscheiden in Sekundenbruchteilen, ob ein Inhalt zitierfähig genug ist, um in einer Antwort aufzutauchen. Für diese Systeme reicht guter Content allein nicht, sie brauchen technische Signale, die maschinell eindeutig auslesbar sind, allen voran llms.txt und strukturierte Daten. Das ist die technische Seite dessen, was wir als GEO-Agentur für Kunden umsetzen. Dieser Beitrag zeigt, wie beide Bausteine konkret funktionieren, was sie tatsächlich leisten und wo die Erwartungen noch zu hoch gegriffen sind.
Warum technische Signale für KI-Sichtbarkeit jetzt zählen
Ein Mensch, der eine Website besucht, orientiert sich an Navigation, Bildern und Layout. Ein KI-System tut das nicht. Es zerlegt eine Seite in Text, sucht nach eindeutigen Aussagen und versucht, Struktur dort zu erkennen, wo eigentlich Design steht. Je mehr davon explizit gemacht wird, etwa durch eine klare Inhaltsübersicht oder maschinenlesbare Auszeichnungen, desto weniger muss ein Modell raten. Und je weniger ein Modell raten muss, desto größer die Chance, dass eine Seite als Quelle in einer generierten Antwort landet und nicht in der stillen Mehrheit der nie zitierten Treffer verschwindet.
Das ist der Kern dessen, was wir bei Generative Engine Optimization als technisches Fundament bezeichnen. Content-Qualität, Entity-Aufbau und Autorität sind die eine Hälfte der Gleichung, wie wir bereits im Beitrag zu KI-Shopping-Agenten im E-Commerce beschrieben haben. Die andere Hälfte ist rein technisch: Kann ein Crawler die Seite überhaupt erreichen, und findet er dort die Struktur, die er braucht, um sie korrekt einzuordnen? Zwei Bausteine entscheiden das maßgeblich, llms.txt als Wegweiser auf Domain-Ebene und strukturierte Daten als Auszeichnung auf Seitenebene. Beide werden in diesem Beitrag im Detail behandelt, mit echten Beispielen statt Theorie.
Was ist llms.txt? Herkunft und Zweck
Die Idee stammt von Jeremy Howard, Mitgründer von Fast.ai und Answer.AI, der den Vorschlag am 3. September 2024 unter der Adresse llmstxt.org veröffentlichte. Der Gedanke dahinter ist simpel und lehnt sich bewusst an zwei etablierte Konzepte an: robots.txt regelt, was ein Crawler crawlen darf, die sitemap.xml listet, welche Seiten überhaupt existieren. llms.txt geht einen Schritt weiter und liefert eine kuratierte, priorisierte Zusammenfassung der wichtigsten Inhalte einer Domain, geschrieben in einfachem Markdown und adressiert an Sprachmodelle, nicht an klassische Suchmaschinen-Indexer.
Der Hintergrund: Sprachmodelle arbeiten mit einem begrenzten Kontextfenster. Eine komplette Website mit Navigation, Werbebannern, Cookie-Hinweisen und verschachteltem HTML in dieses Fenster zu pressen, ist ineffizient und fehleranfällig. Eine llms.txt liefert stattdessen genau das, was ein Modell tatsächlich braucht, nämlich eine kurze Einordnung, worum es auf der Domain geht, plus eine strukturierte Liste der wichtigsten Unterseiten mit einem Satz Kontext pro Link. Aus einem verschachtelten Website-Baum wird eine flache, sofort verwertbare Übersicht.
Wichtig für die Einordnung: llms.txt ist kein offizieller Web-Standard wie robots.txt, der im Robots Exclusion Protocol als RFC 9309 verankert ist. Es handelt sich um einen offenen, community-getriebenen Vorschlag ohne verbindliche Verpflichtung für Anbieter, ihn auszulesen. Das relativiert die Erwartungen, ändert aber nichts daran, dass das Format inzwischen breite Unterstützung bei Entwicklerwerkzeugen und Dokumentationsplattformen gefunden hat, dazu mehr in Abschnitt 5.
Aufbau und Syntax einer llms.txt-Datei
Die Datei liegt im Root-Verzeichnis einer Domain unter /llms.txt, exakt wie robots.txt und sitemap.xml. Der Aufbau folgt einer klaren, minimalen Struktur:
- H1-Überschrift mit dem Namen der Website oder des Projekts, einziger verpflichtender Bestandteil der Spezifikation.
- Blockquote direkt darunter mit einer kurzen, prägnanten Zusammenfassung, was die Seite anbietet.
- Optionale Freitext-Absätze mit zusätzlichem Kontext, ohne feste Formatvorgabe.
- Ein oder mehrere H2-Abschnitte, die jeweils eine Liste von Markdown-Links im Format
[Linktext](URL): kurze Beschreibungenthalten. - Ein optionaler Abschnitt namens „Optional" für Links, die ein Modell bei knappem Kontextfenster zuerst weglassen kann, ohne den Kern zu verlieren.
In der Praxis hat sich zusätzlich eine Variante namens llms-full.txt etabliert. Hier wird nicht mehr nur verlinkt, der komplette Seiteninhalt landet direkt eingebettet in der Datei. Diese Erweiterung ist kein Bestandteil der ursprünglichen Spezifikation, sie hat sich vor allem bei Entwickler-Dokumentationen durchgesetzt, wo ein Modell den vollständigen Text in einem einzigen Abruf benötigt, etwa um Code-Beispiele korrekt zu übernehmen.
Praxisbeispiel: die llms.txt von Beyond Media
Theorie ist das eine, ein reales Beispiel überzeugt mehr. Unsere eigene Datei unter beyond-media.de/llms.txt folgt bewusst der schlanken Variante der Spezifikation:
# Beyond Media GmbH
> Beyond Media ist eine inhabergeführte SEO-, SEA- und GEO-Agentur mit Sitz in Kirchheim am Neckar, gegründet 2004. Als Google Premier Partner (Top 3 % weltweit) betreut ein Team von 30+ Spezialisten mehr als 200 Kunden im deutschsprachigen Raum in den Bereichen Suchmaschinenoptimierung, Suchmaschinenwerbung, Generative Engine Optimization (KI-Sichtbarkeit), Content und Webentwicklung.
## Leistungen
- [SEO](https://www.beyond-media.de/seo/): Suchmaschinenoptimierung für nachhaltiges organisches Wachstum
- [SEA](https://www.beyond-media.de/sea/): Suchmaschinenwerbung und Kampagnenmanagement (Google Ads, Microsoft Ads)
- [GEO](https://www.beyond-media.de/geo/): Generative Engine Optimization für Sichtbarkeit in ChatGPT, Gemini, Perplexity & Co.
- [Alle Leistungen](https://www.beyond-media.de/leistungen/): Überblick über das gesamte Leistungsspektrum
## Unternehmen
- [Startseite](https://www.beyond-media.de/): Beyond Media im Überblick
- [Über die Agentur](https://www.beyond-media.de/agentur/): Geschichte, Team und Standort in Kirchheim am Neckar
- [Referenzen](https://www.beyond-media.de/referenzen/): Kunden und Case Studies
- [Kontakt](https://www.beyond-media.de/kontakt/): Kontaktaufnahme und Anfrage eines Erstgesprächs
## Weitere Ressourcen
- [Blog](https://www.beyond-media.de/blog/): Fachartikel zu SEO, SEA, GEO und Online-Marketing
Drei Dinge lassen sich daran ablesen, die für jede eigene Datei gelten: Die Zusammenfassung im Blockquote beantwortet in einem Satz, wer wir sind und was wir tun, ohne Marketing-Floskeln. Die H2-Abschnitte gruppieren nach Nutzerabsicht, nicht nach interner Sitemap-Struktur. Und jeder Link bekommt einen kurzen, sachlichen Zusatz, der einem Modell erspart, die Zielseite erst öffnen zu müssen, um zu verstehen, worum es dort geht.
Ein nüchterner Blick: Wird llms.txt heute schon ausgelesen?
Hier lohnt sich Ehrlichkeit statt Euphorie. Bislang hat keiner der großen KI-Anbieter offiziell bestätigt, llms.txt-Dateien systematisch in die eigene Crawling- oder Retrieval-Pipeline einzubinden. Weder OpenAI noch Anthropic noch Perplexity listen das Format in ihrer offiziellen Crawler-Dokumentation als ausgelesene Quelle. Wer eine llms.txt einrichtet und danach unmittelbar mehr Zitationen in ChatGPT erwartet, wird enttäuscht.
Trotzdem ist die Investition aus drei Gründen sinnvoll. Erstens haben Werkzeuge, mit denen Entwickler und Agenten Inhalte direkt einlesen, das Format bereits produktiv im Einsatz, etwa Dokumentationsplattformen, die automatisch eine llms.txt neben jeder gehosteten Seite generieren, und Coding-Assistenten, die gezielt danach suchen, bevor sie eine komplette Website crawlen. Zweitens verhalten sich die nutzergetriebenen Fetcher der großen Anbieter, also ChatGPT-User, Claude-User und Perplexity-User, beim Live-Abruf einer Seite ähnlich wie ein Mensch mit wenig Zeit. Eine klare, kuratierte Übersicht hilft auch dann, wenn sie nicht als eigenes Dateiformat erkannt, sondern einfach als zusätzliche, gut lesbare Seite mitgelesen wird. Drittens ist der Aufwand minimal, eine einzelne Textdatei, während der mögliche Nutzen mit der weiteren Verbreitung des Formats nur wächst. Das Chancen-Aufwands-Verhältnis stimmt, auch ohne offizielle Bestätigung der Modellanbieter.
Die wichtigsten KI-Crawler und ihre User-Agents
Bevor eine llms.txt oder strukturierte Daten überhaupt etwas bewirken können, muss die robots.txt die relevanten Crawler durchlassen. Ein häufiger, vermeidbarer Fehler ist eine pauschale Disallow-Regel, die versehentlich auch KI-Crawler mit erfasst. Diese Useragents sollten Website-Betreiber kennen und gezielt in der robots.txt gegenprüfen:
| User-Agent | Anbieter | Funktion |
|---|---|---|
GPTBot | OpenAI | Crawlt Inhalte für das Training generativer KI-Modelle |
OAI-SearchBot | OpenAI | Indexiert Seiten für die Suchfunktion in ChatGPT |
ChatGPT-User | OpenAI | Ruft Seiten live ab, wenn ein Nutzer ChatGPT konkret danach fragt |
ClaudeBot | Anthropic | Crawlt Webinhalte, die zum Training von Claude beitragen können |
Claude-User | Anthropic | Ruft Seiten ab, wenn ein Nutzer Claude direkt danach fragt |
Claude-SearchBot | Anthropic | Prüft Inhalte zur Verbesserung der Suchqualität von Claude |
PerplexityBot | Perplexity | Erfasst Seiten, um sie in Suchergebnissen zu verlinken |
Perplexity-User | Perplexity | Ruft Seiten im Auftrag einer konkreten Nutzeranfrage ab |
Google-Extended | Steuert die Nutzung von Inhalten für Gemini- und Vertex-AI-Training, unabhängig von Googlebot |
Zwei Details sind für die Praxis entscheidend. Erstens gilt Google-Extended unabhängig von Googlebot: Wer Google-Extended in der robots.txt blockiert, bleibt trotzdem regulär in der Google-Suche sichtbar, laut Googles eigener Dokumentation hat das Token keinen Einfluss auf Rankings. Zweitens respektieren die nutzergetriebenen Agenten wie ChatGPT-User, Claude-User und Perplexity-User robots.txt-Regeln teilweise nicht in derselben Konsequenz wie klassische Trainings-Crawler, da sie im Namen einer konkreten Nutzeranfrage handeln, ähnlich einem Menschen, der manuell einen Link öffnet. Wer Inhalte grundsätzlich von KI-Training ausschließen, aber in Live-Antworten trotzdem zitiert werden möchte, muss diese Unterscheidung gezielt in der robots.txt abbilden. Eine pauschale Sperre aller KI-Bots trifft sonst auch die Anfragen, die eigentlich zu mehr Sichtbarkeit führen könnten.
Strukturierte Daten, die KI-Suchsysteme wirklich nutzen
Über Schema Markup und strukturierte Daten für klassische Google-Rich-Results haben wir an anderer Stelle bereits ausführlich geschrieben. Für KI-Suchsysteme zählen teilweise dieselben Schema.org-Typen, aber mit einer anderen Gewichtung, weil ein Sprachmodell keine Snippets rendert, sondern Fakten extrahiert und in eine Antwort einbaut.
Organization mit sameAs, die Basis der Entity-Erkennung
Ein KI-System muss eine Marke zunächst eindeutig als Entität erkennen, bevor es sie zitieren kann. Die sameAs-Eigenschaft im Organization-Schema verlinkt auf externe, autoritative Profile derselben Entität, etwa Wikipedia, Wikidata, LinkedIn-Unternehmensseite oder Crunchbase. Je konsistenter Name, Beschreibung und Adresse über all diese Quellen hinweg sind, desto sicherer kann ein Modell Aussagen aus unterschiedlichen Quellen derselben Marke zuordnen. Bei Inkonsistenzen besteht die Gefahr, dass zwei Erwähnungen fälschlich als zwei unterschiedliche Unternehmen behandelt werden.
Article und BlogPosting mit vollständigen Autoren- und Datumsangaben
Bei Fachartikeln zählt für KI-Systeme vor allem, ob Autorenschaft und Aktualität eindeutig maschinenlesbar sind. Die Eigenschaften author, datePublished, dateModified und publisher im Article- oder BlogPosting-Schema sind dafür die Mindestangaben. Fehlt das Datum oder ist es nicht im Schema, sondern nur irgendwo im Fließtext hinterlegt, kann ein Modell nicht zuverlässig einschätzen, ob eine Information noch aktuell ist, und zitiert im Zweifel eine neuere Konkurrenzquelle.
FAQPage für direkt extrahierbare Antworten
Kaum ein Schema-Typ liefert einem Sprachmodell fertigere Bausteine als FAQPage. Frage und Antwort liegen bereits in der Struktur vor, die ein Modell für eine Antwort braucht, ganze Sätze, in sich abgeschlossen, ohne dass zusätzlicher Kontext aus umliegenden Absätzen nötig wäre. Ein Beispiel für die korrekte Auszeichnung:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Muss eine llms.txt-Datei valide JSON-LD enthalten?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Nein. llms.txt ist eine reine Markdown-Datei nach der Spezifikation von llmstxt.org. Strukturierte Daten wie JSON-LD sind ein komplett getrenntes Konzept und werden pro Einzelseite im HTML-Code eingebunden, nicht in der llms.txt."
}
}]
}
BreadcrumbList für den Kontext innerhalb der Seitenhierarchie
Auch wenn BreadcrumbList vor allem aus der klassischen SEO-Welt bekannt ist, hilft die Auszeichnung KI-Systemen ebenfalls, einen Inhalt richtig einzuordnen, etwa ob eine Seite ein allgemeiner Ratgeberartikel oder eine spezifische Unterseite eines Leistungsbereichs ist. Wichtig dabei, gerade bei individuell zusammengestellten Schema-Arrays: Alle URLs in itemListElement müssen absolut angegeben werden, inklusive Protokoll und Domain. Relative Pfade werden von manchen Validatoren zwar toleriert, von anderen Systemen jedoch nicht zuverlässig aufgelöst, was im schlechtesten Fall dazu führt, dass die komplette Breadcrumb-Angabe verworfen wird.
Checkliste: llms.txt und strukturierte Daten kombinieren
Beide Bausteine ergänzen sich, sie ersetzen sich nicht. llms.txt liefert die Landkarte auf Domain-Ebene, strukturierte Daten liefern die Details auf Seitenebene. Eine kompakte Umsetzungsreihenfolge:
- robots.txt prüfen: GPTBot, ClaudeBot, PerplexityBot und Google-Extended gezielt gegenprüfen, damit keiner davon versehentlich über eine pauschale Regel ausgesperrt wird.
- llms.txt unter /llms.txt anlegen: H1, Blockquote-Zusammenfassung, zwei bis vier H2-Abschnitte mit den wichtigsten Unterseiten und einem Satz Kontext pro Link.
- Organization-Schema mit sameAs pflegen: Verlinkung auf Wikipedia, Wikidata, LinkedIn und weitere autoritative Profile, konsistent über alle Plattformen hinweg.
- Article- und BlogPosting-Schema vollständig füllen: Autor, Veröffentlichungs- und Änderungsdatum, Publisher, jeweils im Schema selbst, nicht nur im sichtbaren Text.
- FAQPage nur bei tatsächlich sichtbaren FAQ-Inhalten einsetzen: Fragen und Antworten müssen auf der Seite lesbar sein, nicht nur im Schema versteckt.
- Alle URLs im Schema absolut angeben: Speziell bei BreadcrumbList und mainEntityOfPage, um Fehlinterpretationen durch Validatoren und KI-Systeme zu vermeiden.
- Regelmäßig testen: Mit dem Rich Results Test von Google und durch gezielte Testfragen an ChatGPT, Claude und Perplexity zur eigenen Marke.
Häufig gestellte Fragen
Ersetzt llms.txt die robots.txt oder die Sitemap?
Nein. Alle drei Dateien haben unterschiedliche Aufgaben und ergänzen sich. robots.txt regelt Zugriffsrechte für Crawler, sitemap.xml listet vollständig alle indexierbaren URLs für Suchmaschinen, llms.txt liefert eine kuratierte, priorisierte Zusammenfassung für Sprachmodelle. Alle drei sollten parallel gepflegt werden.
Muss llms.txt bei jeder Content-Änderung aktualisiert werden?
Nicht bei jeder kleinen Änderung, aber bei neuen Kernseiten, größeren strukturellen Umbauten oder wenn sich die inhaltliche Priorität einer Domain verschiebt, etwa nach einem Relaunch oder der Einführung eines neuen Leistungsbereichs. Eine veraltete llms.txt, die auf nicht mehr existierende Seiten verweist, schadet mehr, als eine fehlende Datei nutzt.
Reicht strukturiertes Markup allein, ohne llms.txt?
Für die klassische Google-Suche ja, für die KI-Sichtbarkeit im weiteren Sinne nicht ganz. Strukturierte Daten liefern Detailtiefe auf Seitenebene, llms.txt liefert die Übersicht auf Domain-Ebene, gerade für Systeme, die eine Website zum ersten Mal einordnen. Beide Bausteine adressieren unterschiedliche Momente im Auslese-Prozess eines KI-Systems.
Kann eine falsch konfigurierte robots.txt die KI-Sichtbarkeit komplett blockieren?
Ja. Eine pauschale Disallow: /-Regel für alle User-Agents sperrt automatisch auch GPTBot, ClaudeBot und PerplexityBot mit aus, selbst wenn eine perfekte llms.txt und lückenlose strukturierte Daten vorhanden sind. Der erste Schritt jeder GEO-Maßnahme sollte deshalb immer die robots.txt-Prüfung sein, nicht die Content-Optimierung.
Fazit
llms.txt und strukturierte Daten lösen unterschiedliche Probleme, gehören aber zusammen. Die eine Datei sorgt dafür, dass ein KI-System eine Domain auf den ersten Blick versteht, die andere sorgt dafür, dass die einzelne Seite darunter präzise und eindeutig ausgelesen werden kann. Keines von beiden ersetzt gute Inhalte oder eine durchdachte GEO-Strategie, aber ohne diese technische Basis verpufft auch der beste Content, weil er von Crawlern gar nicht erst sauber erfasst wird. Wer, wie im Beitrag zu KI-Shopping-Agenten beschrieben, in ChatGPT, Gemini oder Perplexity sichtbar werden will, sollte robots.txt, llms.txt und Schema-Markup als ein zusammenhängendes technisches Fundament behandeln, nicht als drei separate Aufgaben. Wir unterstützen Sie gerne dabei, dieses Fundament für Ihre Website aufzusetzen und laufend zu pflegen, sprechen Sie unser GEO-Team an.
Quellen
llms.txt-Spezifikation: The /llms.txt file, Jeremy Howard, Answer.AI (2024)
Anthropic / Claude: Does Anthropic crawl data from the web?
Perplexity: Perplexity crawlers
Google Search Central: AI features and your website, Google-Extended