llms.txt vs. robots.txt: zwei Dateien, zwei Aufgaben

Der zentrale Unterschied: Zugang steuern oder Inhalte erklären

Die ähnlich klingenden Dateinamen führen schnell zu einem falschen Schluss: Beide Dateien hätten etwas mit Bots zu tun und seien daher austauschbare Steuerdateien. Tatsächlich beantworten sie grundverschiedene Fragen. Die robots.txt gehört zum Robots Exclusion Protocol. Ein Crawler ruft sie vor dem Crawlen einer Website ab, sucht nach einer Regel für seinen User-Agent und prüft, ob der gewünschte URL-Pfad erlaubt oder ausgeschlossen ist. Die Datei ist damit eine öffentlich einsehbare Crawl-Richtlinie.

Die llms.txt ist dagegen ein offener Formatvorschlag für eine kompakte Markdown-Datei. Sie führt ausgewählte, öffentlich erreichbare Seiten auf und versieht sie mit kurzen Beschreibungen. Ein Sprachmodell oder Agent soll nicht Tausende Navigations-, Filter- oder Archivseiten durchsuchen müssen, sondern erhält eine redaktionell gepflegte Karte der wichtigsten Inhalte. Es geht um Orientierung und Kontext, nicht um Erlaubnis oder Verbot.

Daraus folgt die wichtigste Praxisregel: Wenn Sie einen dokumentierten KI-Crawler vom Abruf ausschließen möchten, arbeiten Sie mit dessen User-Agent-Regel in robots.txt. Wenn Sie zentrale Leistungen, Produktinformationen, Dokumentationen oder Richtlinien besser auffindbar machen möchten, kuratieren Sie diese in llms.txt. Wer beides möchte – beispielsweise Modelltraining ausschließen, aber öffentliche Informationen klar strukturiert anbieten – nutzt beide Dateien parallel.

llms.txt und robots.txt im direkten Vergleich

Die folgende Tabelle trennt Zweck, Wirkung und Pflege. Besonders wichtig ist die Zeile zum Training: Eine llms.txt enthält keine standardisierten Trainingsfreigaben. Fantasie-Direktiven wie Allow-AI-Training, Disallow-AI oder AI-Training-Policy gehören nicht zum dokumentierten Formatvorschlag und erzeugen keine verlässliche technische Wirkung.

So sehen beide Dateien in der Praxis aus

Eine gute llms.txt beginnt mit genau einer H1, gefolgt von einer knappen Zusammenfassung als Blockquote. Danach gruppieren H2-Überschriften die wichtigsten absoluten Links. Die Beschreibungen sollten konkret sagen, was auf der Zielseite zu finden ist. Ein kurzer, geprüfter Katalog ist wertvoller als ein automatisch eingefügter Dump der gesamten Sitemap.

# Beispiel GmbH

> Software für digitale Terminplanung im deutschen Mittelstand.

## Produkt

- [Funktionen](https://example.com/funktionen): Terminbuchung, Erinnerungen und Teamkalender.
- [Preise](https://example.com/preise): Tarife, enthaltene Leistungen und Vertragsbedingungen.

## Hilfe

- [Dokumentation](https://example.com/docs): Einrichtung und Nutzung der Plattform.
- [Kontakt](https://example.com/kontakt): Support und Vertriebsanfragen.

In diesem Beispiel gibt es keine User-Agents, Verbote oder Trainingsbedingungen. Die Datei beschreibt ausschließlich öffentliche Inhalte. Sensible URLs gehören schon deshalb nicht hinein, weil llms.txt selbst öffentlich abrufbar ist.

Eine robots.txt verwendet dagegen Regelgruppen. Das folgende Beispiel schließt den dokumentierten Trainingscrawler GPTBot aus, erlaubt OAI-SearchBot den allgemeinen Abruf, sperrt aber einen internen Pfad. Die globale Gruppe gilt für andere kooperative Crawler. Der Sitemap-Hinweis erleichtert das Auffinden der XML-Sitemap.

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /
Disallow: /intern/

User-agent: *
Disallow: /intern/
Disallow: /konto/

Sitemap: https://example.com/sitemap.xml

Ein Disallow: / bedeutet innerhalb der passenden Gruppe, dass kein Pfad gecrawlt werden soll. Ein leeres Disallow: verbietet dagegen nichts. Solche kleinen Syntaxunterschiede können die Wirkung vollständig umkehren. Vor der Veröffentlichung sollten daher bestehende Regeln gesichert, zusammengeführt und auf der produktiven URL geprüft werden.

KI-Crawler sind nicht alle dasselbe

„KI-Bot“ ist kein einzelner Zweck. Anbieter unterscheiden heute häufig zwischen Crawling für Modellentwicklung, automatischer Suche und einem Abruf, den ein Nutzer unmittelbar auslöst. OpenAI dokumentiert beispielsweise GPTBot für potenzielles Modelltraining, OAI-SearchBot für die Suche und ChatGPT-User für nutzerinitiierte Aktionen. Anthropic trennt ClaudeBot, Claude-SearchBot und Claude-User. Perplexity beschreibt PerplexityBot für Suchfunktionen und Perplexity-User für nutzerinitiierte Abrufe.

Diese Trennung ermöglicht eine differenzierte Strategie. Ein Unternehmen kann Training ablehnen und einen Suchcrawler trotzdem zulassen, wenn es in KI-gestützten Suchergebnissen auffindbar bleiben möchte. Nutzerinitiierte Fetcher sind ein Sonderfall: Anbieter weisen darauf hin, dass solche Abrufe anders behandelt werden können als automatisches Crawling und robots.txt-Regeln nicht immer auf dieselbe Weise greifen. Deshalb sollte die Entscheidung pro dokumentiertem Token getroffen und regelmäßig gegen die aktuellen Anbieterinformationen geprüft werden.

Google-Extended verdient eine zusätzliche Klarstellung. Es ist ein Kontroll-Token, mit dem Websitebetreiber laut Google die Nutzung von Inhalten für bestimmte Gemini-Modelle und Grounding-Funktionen beeinflussen können. Es ist kein klassischer separater Crawlername, der zwingend als eigener HTTP-User-Agent erscheint. Google erklärt außerdem, dass die Einstellung die Aufnahme oder das Ranking in der klassischen Google-Suche nicht beeinflusst. Pauschale Formulierungen wie „Google komplett blockieren“ wären daher irreführend.

Das richtige Zusammenspiel mit sitemap.xml

In einer sauberen technischen Architektur stehen nicht zwei, sondern drei Dateien nebeneinander. Die sitemap.xml bildet die breite URL-Ebene ab. Sie hilft Suchmaschinen und anderen unterstützenden Crawlern, kanonische, indexierbare Seiten zu entdecken und Aktualisierungen einzuordnen. Die llms.txt bildet die redaktionelle Prioritätsebene ab: Welche wenigen Seiten erklären Unternehmen, Produkt, Preise, Dokumentation oder Richtlinien am besten? Die robots.txt bildet die Crawl-Policy ab.

Für einen Shop kann die Sitemap Tausende Produkt- und Kategorieseiten enthalten. Eine llms.txt sollte daraus nicht automatisch Tausende Links wiederholen. Sinnvoller sind die wichtigsten Kategorien, zentrale Kaufberatung, Versand- und Rückgaberegeln, eine Unternehmensseite sowie wenige erklärungsbedürftige Kernprodukte. In robots.txt können parallel Filterparameter, Warenkorb- oder Kontopfade ausgeschlossen werden, sofern dies zur technischen Strategie passt.

Für eine SaaS-Website ist die Aufteilung ähnlich: Sitemap für alle indexierbaren Landingpages und Dokumentationsseiten, llms.txt für Produktüberblick, Funktionen, Pricing, API-Einstieg, Changelog und Support, robots.txt für interne oder technisch wertlose Crawl-Pfade. Dadurch bleibt jede Datei klein genug für ihren Zweck, und Zuständigkeiten werden leichter prüfbar.

Sieben typische Fehler bei llms.txt und robots.txt

1. Training mit llms.txt steuern wollen: Der Formatvorschlag definiert keine Crawl- oder Trainingsverbote. Dafür gedachte Fantasie-Direktiven werden durch ihre bloße Veröffentlichung nicht wirksam.
2. robots.txt als Sicherheitsschicht behandeln: Die Datei versteckt nichts. Sie nennt Pfade sogar öffentlich. Login, serverseitige Autorisierung und geeignete Netzwerkregeln schützen sensible Inhalte.
3. alle KI-Bots pauschal gruppieren: Trainingscrawler, Suchcrawler und Nutzerabrufe können unterschiedliche Ziele erfüllen. Eine absichtliche Entscheidung pro Zweck ist meist sinnvoller.
4. die Sitemap in llms.txt kopieren: Eine llms.txt gewinnt durch Auswahl und Beschreibung. Tausende ungeprüfte URLs erhöhen Rauschen, Dateigröße und Pflegeaufwand.
5. widersprüchliche Regeln veröffentlichen: Neue Bot-Gruppen dürfen vorhandene globale Regeln nicht versehentlich aushebeln. Bestehende Dateien müssen vor Änderungen vollständig geprüft werden.
6. Erlaubnis mit Erfolg verwechseln: Weder robots.txt noch llms.txt garantieren Abrufe, KI-Zitate oder mehr Traffic. Aussagen über sichere Rankings oder feste Sichtbarkeitssteigerungen sind nicht seriös.
7. nach dem Upload nicht mehr prüfen: Links verschwinden, Canonicals ändern sich und Anbieter ergänzen Bot-Tokens. Beide Dateien brauchen einen Verantwortlichen und einen realistischen Prüfzyklus.

Die Kombination in sieben Schritten umsetzen

1. Ziele trennen: Schreiben Sie zuerst auf, welche Inhalte öffentlich auffindbar sein sollen, welche Crawler-Zwecke Sie erlauben und welche Pfade technisch geschützt werden müssen.
2. bestehende robots.txt sichern: Laden Sie die produktive Datei herunter. Prüfen Sie globale Gruppen, CMS-Regeln, Sitemap-Hinweise und bereits vorhandene Bot-Direktiven.
3. Bot-Policy festlegen: Entscheiden Sie separat über Modellentwicklung, automatische KI-Suche und nutzerinitiierte Abrufe. Nutzen Sie nur Tokens, die der jeweilige Anbieter aktuell offiziell dokumentiert.
4. Kerninhalte auswählen: Begrenzen Sie llms.txt auf Seiten, die eine reale Frage beantworten oder Ihr Angebot verlässlich erklären. Entfernen Sie Suchseiten, Tag-Archive, Tracking-URLs und Duplikate.
5. Dateien erzeugen und redigieren: Verwenden Sie den robots.txt-Assistenten für einen zusammenführbaren Entwurf und den llms.txt-Generator für die kuratierte Markdown-Struktur. Prüfen Sie jede Zeile vor dem Upload.
6. im Webroot veröffentlichen: Beide Dateien müssen unter dem jeweiligen Standardpfad mit erfolgreichem HTTP-Status erreichbar sein. Prüfen Sie Content-Type, Zeichencodierung und Weiterleitungsketten.
7. regelmäßig kontrollieren: Testen Sie tote Links, geänderte Canonicals, neue Kernseiten und aktualisierte Anbieterregeln. Dokumentieren Sie das Prüfdatum intern; ein Datum allein macht veraltete Inhalte nicht aktuell.

Für kleine Websites ist diese Arbeit oft in einem überschaubaren Redaktionsprozess lösbar. Größere Domains sollten Verantwortlichkeiten zwischen SEO, Entwicklung, Content und Datenschutz klären. robots.txt-Änderungen können große Crawl-Auswirkungen haben; llms.txt-Änderungen sind redaktionell risikoärmer, sollten aber ebenso wahr und aktuell bleiben.

Welche Datei brauche ich für welches Ziel?

Möchten Sie GPTBot für Modellentwicklung ausschließen, gehört die passende Regel in robots.txt. Möchten Sie OAI-SearchBot oder Claude-SearchBot bewusst anders behandeln, ist ebenfalls robots.txt das richtige Werkzeug. Möchten Sie dagegen erklären, welche Produktseite, Dokumentation oder Preisseite die maßgebliche Quelle ist, gehört der Link in llms.txt. Möchten Sie Suchmaschinen eine vollständige Liste indexierbarer URLs bereitstellen, verwenden Sie sitemap.xml.

Bei vertraulichen Kundendaten, internen Dokumenten oder nicht öffentlichen Staging-Systemen ist keine dieser drei Dateien ausreichend. Solche Ressourcen müssen technisch geschützt werden. Die klare Trennung verhindert zugleich falsche Erwartungen: robots.txt ist eine freiwillig beachtete Crawl-Konvention, llms.txt ein freiwillig ausgewerteter Inhaltsvorschlag und sitemap.xml ein Discovery-Hinweis. Keine Datei ist eine Berechtigungsprüfung.