- [ Startseite ](/de/) / - Best Practices # Best Practices Zehn Regeln, die Fehler, die uns am häufigsten begegnen, und konkrete Muster für Mehrsprachigkeit, Sicherheit und CI. Zuletzt aktualisiert: 29. Juli 2026 ## Zehn Regeln - **Kuratieren.** Eine kurze Liste aussagekräftiger Seiten schlägt eine lange Liste mittelmäßiger. Zielen Sie auf 10 bis 30 Links in der Wurzeldatei. - **Absolute URLs verwenden.** Immer `https://ihredomain.de/...`. Relative URLs sind technisch erlaubt, aber fragil. - **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. - **Die Zusammenfassung sachlich halten.** Das Blockzitat nach der H1 sollte klingen wie ein Wikipedia-Einstieg, nicht wie ein Landingpage-Header. - **Ein Satz pro Eintrag.** Die Notiz nach dem Doppelpunkt dient der Abgrenzung, nicht dem Marketing. - **Den Abschnitt `Optional` sparsam einsetzen.** Er ist der richtige Ort für Presse, Markenmaterial und Archive. Kippen Sie dort nicht Ihre halbe Sitemap hinein. - **Stabile URLs spiegeln.** Zieht eine Seite aus der `llms.txt` um, aktualisieren oder weiterleiten. Tote URLs beschädigen den Ruf der Datei. - **`llms-full.txt` veröffentlichen, wenn der Inhalt textlastig ist.** Dokumentation, Tutorials und Referenzmaterial profitieren. Galerien, interaktive Werkzeuge und vorwiegend visuelle Inhalte nicht. - **Den [Validator](/de/validator/) in CI laufen lassen.** Eine Content-Migration, die Ihre Datei zerlegt, sollte den Build scheitern lassen. - **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. ⚠ Anti-Muster: llms.txt als SEO-Einfallstor Die Datei mit keywordlastigen Notizen vollzustopfen bringt nichts. Es gibt keinen Beleg dafür, dass ein großes LLM Keyword-Dichte aus llms.txt ausliest. Für jeden, der die Datei direkt abruft, wirkt es außerdem billig. ## Mehrsprachige Websites Die Spezifikation schweigt zur Internationalisierung. Zwei Muster funktionieren in der Praxis: - **Eine englische Datei an der Wurzel.** Die einfachste Variante. Die meisten LLM-Clients übersetzen im Vorbeigehen. Für die meisten Websites ausreichend. - **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](/de/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](/de/beispiele/): übernehmen, was funktioniert. - [Validator](/de/validator/): die eigene Datei prüfen. - [llms.txt erstellen](/de/llms-txt-erstellen/) für Ihren Stack. - [Nutzt Google llms.txt?](/de/nutzt-google-llms-txt/) ## Quellen - [ llmstxt.org, offizielle Spezifikation ](https://llmstxt.org/) - [ Ahrefs: We Analyzed 137K Sites, 97% of llms.txt Files Never Get Read (Juni 2026) ](https://ahrefs.com/blog/llmstxt-study/) Auf dieser Seite - [ Zehn Regeln ](#regeln) - [ Typische Fehler ](#fehler) - [ Mehrsprachige Websites ](#mehrsprachig) - [ Sicherheit und Datenschutz ](#sicherheit) - [ Automatisierung in CI ](#automatisierung)