llms.txt ist ein 2024 veröffentlichter Community-Entwurf: eine Markdown-Datei im Wurzelverzeichnis, die die wichtigsten Inhalte einer Website auflistet. Kein großer Anbieter wertet sie bislang offiziell aus. Für Marketing-Websites ist der Nutzen deshalb unbelegt; für Entwicklerportale und Produktdokumentation kann sie sich lohnen. Der Aufwand liegt bei wenigen Stunden.
Was schlägt der llms.txt-Entwurf konkret vor?
Der Vorschlag stammt aus dem Jahr 2024 und ist bewusst schlicht gehalten. Unter der Adresse mit dem Zusatz llms.txt liegt eine reine Markdown-Datei: eine Überschrift mit dem Namen des Projekts, ein kurzer Absatz zur Einordnung und darunter thematisch gruppierte Linklisten mit je einem erklärenden Halbsatz.
Die Idee dahinter: Ein Sprachmodell mit begrenztem Kontextfenster soll nicht erst eine verschachtelte Navigation, ein Cookie-Banner und drei Werbeflächen durchqueren müssen, um zur Sache zu kommen. Es bekommt stattdessen eine kuratierte Landkarte in einem Format, das sich ohne Aufbereitung lesen lässt.
Ergänzend kursiert eine ausführlichere Variante, die nicht nur verlinkt, sondern die Inhalte selbst als zusammengefassten Fließtext enthält. Beide Varianten sind Vorschläge einzelner Autoren, kein verabschiedeter Standard einer Normungsorganisation.
Bemerkenswert ist, was der Entwurf weglässt. Es gibt keine Angabe zur Aktualität, keine Prioritätswerte, keine Signatur und keinen Mechanismus, mit dem ein abfragendes System die Richtigkeit der Liste prüfen könnte. Wer die Datei ernst nehmen wollte, müsste ihr blind vertrauen.
Wie unterscheidet sich das von robots.txt und Sitemap?
Die Unterschiede sind grundsätzlich, auch wenn alle drei Dateien im Wurzelverzeichnis liegen. Eine robots.txt regelt Zugriff: Sie sagt, welcher Crawler welche Pfade nicht abrufen soll. Eine XML-Sitemap regelt Vollständigkeit: Sie listet maschinenlesbar alle Adressen auf, die indexiert werden sollen.
llms.txt regelt weder das eine noch das andere. Sie trifft eine redaktionelle Auswahl und behauptet, dies seien die wichtigsten Seiten. Damit ist sie näher an einem gut gemachten Inhaltsverzeichnis als an einem technischen Protokoll.
- robots.txt wird von praktisch allen seriösen Crawlern gelesen und befolgt.
- Das Sitemap-Protokoll ist zwischen den großen Suchmaschinen abgestimmt und dokumentiert.
- llms.txt hat keinen vergleichbaren Rückhalt und keine verbindliche Spezifikation.
- Nur robots.txt kann Zugriffe tatsächlich einschränken, die beiden anderen Dateien nicht.
Werten die großen Anbieter die Datei überhaupt aus?
Nach heutigem Stand nein. Vertreter von Google haben sich öffentlich skeptisch geäußert und darauf hingewiesen, dass ihre Systeme die Datei nicht heranziehen. Auch von den Betreibern der bekannten Chat-Assistenten gibt es keine Dokumentation, die eine Auswertung bestätigt.
Wer in Serverprotokollen nachsieht, findet gelegentlich Abrufe der Datei — meist von Analysewerkzeugen, Neugierigen oder kleineren Diensten. Ein Abruf ist aber kein Beleg dafür, dass der Inhalt eine Antwort beeinflusst hat.
Diese Lage kann sich ändern. Sie sollte nur nicht dazu verleiten, die Datei heute als Sichtbarkeitsmaßnahme zu verkaufen. Ein Vorschlag, den niemand auswertet, wirkt genauso wenig wie ein unadressierter Brief.
Woher stammt dann der Eindruck, die Datei wirke?
Wer eine llms.txt anlegt, betreibt meistens ein technisch gut geführtes Projekt: aufgeräumte Struktur, gepflegte Dokumentation, kurze Antwortzeiten, sprechende Adressen. Wenn solche Websites häufiger in KI-Antworten auftauchen, liegt das an diesen Eigenschaften und nicht an einer zusätzlichen Textdatei.
Hinzu kommt ein zweiter Effekt, der leicht mit Wirkung verwechselt wird. Die Arbeit an der Datei zwingt zu einer Auswahl. Wer festlegen muss, welche zwanzig Seiten die wichtigsten sind, bemerkt dabei regelmäßig, dass die eigene Navigation etwas anderes behauptet. Dieser Erkenntnisgewinn ist echt — er entsteht beim Nachdenken, nicht beim Ausliefern.
Trennen Sie deshalb Ursache und Begleiterscheinung, bevor Sie ein Budget freigeben. Die Frage lautet nicht, ob erfolgreiche Websites diese Datei haben, sondern ob eine Website durch sie erfolgreicher wird. Für die zweite Frage fehlt bislang jeder Beleg.
Lohnt sich der Aufwand für eine Unternehmenswebsite?
Rechnen Sie nüchtern. Eine handgepflegte llms.txt für eine Website mit vierzig Seiten kostet beim ersten Anlegen wenige Stunden. Teuer wird sie danach: Jede neue Seite, jede Umbenennung und jede gelöschte Adresse muss nachgezogen werden, sonst zeigt die Datei auf Fehlerseiten.
Ein Anbieter von Schulverwaltungssoftware, der sein Handbuch monatlich erweitert, braucht dafür einen automatisierten Generierungsschritt im Build. Wer die Datei von Hand pflegt, hat nach zwei Quartalen eine Karteileiche im Wurzelverzeichnis.
Automatisiert erzeugt und in die Veröffentlichungskette eingehängt ist der laufende Aufwand nahe null. Genau dann spricht wenig dagegen, sie mitzuliefern — als Wette mit kleinem Einsatz, nicht als Maßnahme mit versprochener Wirkung.
Kalkulieren Sie außerdem das Risiko der stillen Falschangabe. Eine Übersicht, die dreißig Seiten nennt, von denen fünf nicht mehr existieren, beschreibt Ihre Website falsch. Sollte sie eines Tages doch ausgewertet werden, wirkt eine veraltete Datei schlechter als gar keine.
Was wirkt stattdessen belegbar?
Alles, was auch ohne llms.txt gelesen wird. Eine vollständige, saubere XML-Sitemap. Serverseitig ausgelieferter Text statt nachgeladener Fragmente. Sprechende Adressen, korrekte Statuscodes und eine Navigation, die jede wichtige Seite in wenigen Klicks erreichbar macht.
- Liefern Sie die Kerninhalte ohne JavaScript-Ausführung im ersten HTML-Dokument aus.
- Halten Sie die Sitemap frei von Weiterleitungen und Fehlerseiten.
- Vergeben Sie eindeutige Titel und Überschriften, die den Seiteninhalt benennen.
- Verlinken Sie wichtige Unterseiten aus dem Fließtext, nicht nur aus der Fußzeile.
- Halten Sie Ladezeiten und Antwortcodes stabil, damit Abrufe nicht abbrechen.
Eine Datei, die niemand liest, ersetzt keine Seite, die jeder lesen kann.
Wann ist eine llms.txt trotzdem sinnvoll?
Es gibt Fälle mit unmittelbarem Nutzen, und sie haben nichts mit Suchsichtbarkeit zu tun. Wenn Entwicklerinnen und Entwickler Ihre Programmierschnittstelle mit einem Assistenten erschließen, hilft eine kompakte Markdown-Übersicht sofort: Sie kopieren die Adresse in den Chat und haben eine verlässliche Landkarte statt eines Zufallsfunds.
Dasselbe gilt für interne Wissenssammlungen und Dokumentationsportale, die von hauseigenen Assistenten durchsucht werden. Hier steuern Sie das abfragende System selbst und können festlegen, dass es die Datei liest. Aus dem Community-Vorschlag wird dann eine ganz normale Konfigurationsdatei.
Der Unterschied ist wichtig: Im ersten Fall bitten Sie fremde Systeme um Beachtung, im zweiten weisen Sie Ihr eigenes System an. Nur der zweite Fall hat eine kalkulierbare Wirkung.
Wie regeln Sie KI-Crawler in der robots.txt?
Hier wird es konkret, denn diese Datei wird tatsächlich befolgt. Die Anbieter dokumentieren ihre Kennungen öffentlich, und sie unterscheiden inzwischen nach Zweck. Prüfen Sie vor jeder Regel, welchen Zweck Sie erlauben und welchen nicht.
- GPTBot von OpenAI sammelt Material für das Modelltraining.
- OAI-SearchBot und ChatGPT-User bedienen Suche und einzelne Seitenaufrufe während eines Chats.
- ClaudeBot und die zugehörigen Such- und Nutzerkennungen von Anthropic sind ähnlich aufgeteilt.
- PerplexityBot arbeitet für den Suchindex des gleichnamigen Dienstes.
- Google-Extended ist keine Kennung, sondern ein Steuertoken für die Nutzung in Googles KI-Produkten.
Prüfen Sie außerdem, ob Ihre Schutzeinrichtungen die Regeln aushebeln. Viele Auslieferungsnetze blockieren automatisierte Zugriffe unabhängig von der robots.txt. Eine großzügige Freigabe in der Textdatei nützt nichts, wenn das vorgelagerte System jede Anfrage mit einer Fehlerseite beantwortet.
Sperren Sie nicht pauschal. Wer alle Kennungen ausschließt, entfernt sich zugleich aus den Antworten, in denen er gefunden werden möchte. Sinnvoll ist die Trennung nach Zweck: Training verbieten, Abruf zur Beantwortung erlauben.
Sichtbarkeit oder Inhaltsschutz — wie entscheiden Sie?
Das ist keine technische, sondern eine geschäftliche Frage. Ein Softwareanbieter, dessen Vertrieb über Fachartikel entsteht, verliert durch eine Sperre potenzielle Erwähnungen. Ein Fachverlag, dessen Erlöse an bezahlten Inhalten hängen, verliert durch eine Freigabe möglicherweise Abonnements.
Wir empfehlen, die Entscheidung schriftlich zu begründen und mit einem Überprüfungstermin zu versehen. Sie hängt von Geschäftsmodell und Marktposition ab und wird in zwölf Monaten unter anderen Vorzeichen neu zu bewerten sein.
Was Sie in jedem Fall vermeiden sollten: eine halbherzige Mischung aus gesperrten Kennungen, ungepflegten Sonderdateien und der Hoffnung, dass irgendetwas davon schon wirken wird. Klarheit in der robots.txt ist mehr wert als jede zusätzliche Datei daneben.
Halten Sie schriftlich fest, welche Kennung Sie zu welchem Zeitpunkt gesperrt haben. Wenn in einem halben Jahr die Nennungen in einem bestimmten Assistenten ausbleiben, ist diese Notiz der schnellste Weg zur Erklärung — schneller jedenfalls als die Suche in der Versionsgeschichte des Servers.