Best Practices

Zehn Regeln

1. Kuratieren. Eine kurze Liste aussagekräftiger Seiten schlägt eine lange Liste mittelmäßiger. Zielen Sie auf 10 bis 30 Links in der Wurzeldatei.
2. Absolute URLs verwenden. Immer https://ihredomain.de/.... Relative URLs sind technisch erlaubt, aber fragil.
3. Nach Produktbereich gruppieren. Abschnitte wie Produkt, Preise, Entwickler entsprechen dem, wie ein Mensch und ein LLM denken. Vermeiden Sie Töpfe wie Blog, Doku oder Guides, sofern sie nicht Ihrer echten Navigation entsprechen.
4. Die Zusammenfassung sachlich halten. Das Blockzitat nach der H1 sollte klingen wie ein Wikipedia-Einstieg, nicht wie ein Landingpage-Header.
5. Ein Satz pro Eintrag. Die Notiz nach dem Doppelpunkt dient der Abgrenzung, nicht dem Marketing.
6. Den Abschnitt Optional sparsam einsetzen. Er ist der richtige Ort für Presse, Markenmaterial und Archive. Kippen Sie dort nicht Ihre halbe Sitemap hinein.
7. Stabile URLs spiegeln. Zieht eine Seite aus der llms.txt um, aktualisieren oder weiterleiten. Tote URLs beschädigen den Ruf der Datei.
8. llms-full.txt veröffentlichen, wenn der Inhalt textlastig ist. Dokumentation, Tutorials und Referenzmaterial profitieren. Galerien, interaktive Werkzeuge und vorwiegend visuelle Inhalte nicht.
9. Den Validator in CI laufen lassen. Eine Content-Migration, die Ihre Datei zerlegt, sollte den Build scheitern lassen.
10. Die Datei datieren. Ein kurzer Hinweis wie „Zuletzt geprüft 2026-04-01“ im Text hilft Menschen wie Crawlern.

Typische Fehler

• Keine H1. Die H1 ist das einzige Pflichtelement. Ohne sie ist die Datei ungültig.
• Mehrere H1. Nutzen Sie H2 für Abschnitte. Es darf genau eine H1 geben.
• Eigenes Front-Matter. Kein YAML, kein JSON-Kopf. Die Spezifikation ist eng, Clients parsen Zusätze nicht.
• Eingefügte Markdown-Tabellen oder Bilder. Bleiben Sie bei Überschrift, Blockzitat und Listen. Tabellen und Bilder bringen einem LLM nichts.
• URLs hinter Login aufführen. Erfordert eine Seite eine Anmeldung, listen Sie sie nicht: das LLM läuft gegen eine Wand.
• Zu lange Beschreibungen. „Die weltweit fortschrittlichste KI-gestützte Plattform für synergetische Transformation“ hilft niemandem. Halten Sie Notizen unter 15 Wörtern.
• 500 URLs auflisten. Wenn Sie so viele brauchen, brauchen Sie llms-full.txt, produktspezifische Varianten, oder beides.
• Die robots.txt vergessen. Stellen Sie sicher, dass /llms.txt nicht blockiert ist.

Mehrsprachige Websites

Die Spezifikation schweigt zur Internationalisierung. Zwei Muster funktionieren in der Praxis:

1. Eine englische Datei an der Wurzel. Die einfachste Variante. Die meisten LLM-Clients übersetzen im Vorbeigehen. Für die meisten Websites ausreichend.
2. Varianten je Sprache. Servieren Sie /llms.txt als Standard, dazu /de/llms.txt und /fr/llms.txt. Verlinken Sie sie aus dem Text der Wurzeldatei oder unter einem Optional-Abschnitt.

Welches Muster auch immer: duplizieren Sie keine URL-Sets über Sprachen hinweg. Jede Variante sollte auf die lokalisierte Fassung jeder Seite zeigen.

Sicherheit und Datenschutz

• Alles in llms.txt ist öffentlich. Behandeln Sie die Datei als Rundfunk.
• Niemals Staging- oder Preview-URLs auflisten. Sie werden von allem aufgegriffen, was die Datei herunterlädt.
• Keine URLs mit Geheimnissen im Query-String. Klingt selbstverständlich, kommt trotzdem vor.
• Was hinter Login Nutzerdaten zeigt, gehört nicht hierher.
• Die Datei bei jedem Release prüfen. Eine durchgerutschte Entwurfs-URL ist der häufigste Sicherheitsfehler.

Es gibt einen zweiten Grund, die Datei wie Konfiguration zu behandeln: Agenten sind darauf ausgelegt, ihr zu vertrauen. In der Ahrefs-Auswertung von 137 210 Domains war der größte Forschungs-Crawler auf diesen Dateien ein Bot namens prompt-injection-survey. Halten Sie den Inhalt in Form von Daten, nie in Form von Anweisungen.

Automatisierung in CI

Behandeln Sie llms.txt wie jedes andere Artefakt: generieren, validieren, Releases daran knüpfen.

• Aus der Inhaltsquelle generieren (CMS, MDX-Sammlung, Datenbank).
• Den Validator in CI laufen lassen und bei jedem Fehler den Build scheitern lassen.
• Die Datei zwischen Releases diffen und bei großen Löschungen die Doku-Verantwortlichen alarmieren.
• Die Produktions-URL nach dem Deploy prüfen: curl -fsS https://ihredomain.de/llms.txt | head -1.

Nächste Schritte

• Beispiele aus der Praxis: übernehmen, was funktioniert.
• Validator: die eigene Datei prüfen.
• llms.txt erstellen für Ihren Stack.
• Nutzt Google llms.txt?