llms.txt-Validator
Prüft Titel, Zusammenfassung, Abschnitte, Links, optionale Einträge und Befunde mit Quellzeilen.
Web / SEOllms.txt in der Praxis: Ein Einstieg, der wirklich hilft
llms.txt ist ein knapper Leseplan für Sprachmodell-Agenten, keine neue Zugriffskontrolle und keine Sitemap im modischen Mantel. Gut wird die Datei durch Auswahl: Zeige die Seiten, die deine Website erklären, halte sie mit den übrigen Publikationssignalen konsistent und lass jeden Link sein Kontextbudget verdienen.
Eine Konvention mit bewusst engem Auftrag
Das brauchbare Denkmodell ist eine README im Wurzelverzeichnis der öffentlichen Website. Formal verlangt der aktuelle Vorschlag eine anfängliche H1. Danach dürfen vor der ersten H2 optional eine Blockquote-Zusammenfassung sowie normales Markdown als Fließtext oder Liste folgen. H2-Abschnitte enthalten konventionell Markdown-Links als Listeneinträge. Eine knappe, linkzentrierte Datei ist redaktionell sinnvoll, weil sie Discovery-Aufwand reduziert; sie ist aber keine Regel, die gültigen Text vor der ersten H2 ungültig macht.
Die Datei erteilt keine Berechtigung, erzwingt keinen Abruf und verbessert nicht automatisch Sichtbarkeit oder Zitation. Jeder Betreiber entscheidet selbst, ob er sie liest und beachtet. Sie umgeht keine Anmeldung, zieht bereits gesammelte Inhalte nicht zurück und rettet keine schlechten Zielseiten. Du veröffentlichst ein Angebot: „Wenn du eine knappe Karte dieser Website brauchst, beginne hier.“ Der llms.txt-Validator beseitigt strukturelle Gründe, dieses Angebot abzulehnen; annehmen muss es das fremde System trotzdem selbst.
llms.txt und llms-full.txt bedienen zwei Budgets
Die kurze Datei hilft einem Agenten zu entscheiden, was er als Nächstes lädt. Dort gehören die kanonische Übersicht, wichtige Produkt- oder Dokumentationsbereiche, zentrale Referenzen und ein überschaubarer Optional-Abschnitt hin. Optional heißt: Hintergrund, ergänzende Quellen und lange Dokumente, auf die ein Leser bei knappem Kontext verzichten kann. Wenn du jede Sprachvariante, jeden Filterzustand, jeden Changelog-Eintrag und sämtliche Rechtsseiten auflistest, kuratierst du nicht mehr. Du zwingst den Verbraucher, jene Prioritäten unter Tokenkosten selbst zu rekonstruieren, die du nicht setzen wolltest.
llms-full.txt ist die Begleiterin für Websites, die sinnvoll einen größeren zusammenhängenden Dokumentationskörper anbieten können. Das ist kein Freibrief, gerendertes HTML samt Menüs, Cookie-Dialogen und wiederholten Footern stumpf aneinanderzukleben. Verwende stabile Überschriften, einheitliche Begriffe, klare Grenzen und genug Struktur, damit eine Aussage auffindbar bleibt. Entferne Navigation, die ohne Browser keine Bedeutung hat, aber behalte Einschränkungen, Voraussetzungen und sichere Beispiele: Gerade diese Sätze verhindern, dass ein Agent eine technisch richtige Aussage im falschen Kontext anwendet. Die Kurzfassung darf auf das volle Dokument verweisen, aber sie darf Orientierung nicht dorthin abschieben. Ein Agent mit engem Budget muss allein mit llms.txt vernünftig starten können.
Halte die drei öffentlichen Karten widerspruchsfrei
robots.txt, sitemap.xml und llms.txt beantworten verschiedene Fragen. Robots formuliert Zugriffspolitik für kooperative Crawler. Die Sitemap zählt indexierbare URLs auf. Die Sprachmodell-Datei empfiehlt eine Lesereihenfolge. Keine ersetzt die andere, doch Widersprüche sind Betriebsfehler. Eine Seite zu empfehlen, die du für die angesprochene Crawler-Gruppe sperrst, ist offensichtlich sinnlos. Umgeleitete, entfernte oder nicht kanonische Ziele bringen veraltete Routen in Umlauf. Ein wichtiger Bereich in llms.txt, der komplett in der Sitemap fehlt, kann Absicht sein — dann sollte es auch eine begründete Absicht sein.
Lass alle drei Artefakte aus demselben kanonischen Routenbestand entstehen, aber behalte ihre unterschiedlichen Auswahlregeln. Prüfe Sprachpfade, abschließende Slashes, Großschreibung und Redirects so, wie sie tatsächlich ausgeliefert werden. Der KI-Crawler-robots.txt-Prüfer wertet eingefügte Regeln oder eine öffentliche Robots-URL für einen Pfad aus, zeigt passende Gruppe, entscheidende Direktive und Quellzeile und trennt Suche, Training und nutzergesteuerte Agenten. Auch eine korrekt gelesene Robots-Regel bleibt eine Anweisung an kooperative Crawler, keine technische Zugriffssperre.
Prüfe Entwurf und Auslieferung getrennt
Schreibe lokal und validiere zunächst das eingefügte Markdown. Trenne formale Gültigkeit von redaktioneller Qualität: Verlange die anfängliche H1, erhalte optionale Zusammenfassung und Projektdetails vor der ersten H2 und parse H2-Ressourcenabschnitte, ohne jeden Fließtext als Link auszugeben. Typische Qualitätsprobleme sind leere Ressourcenabschnitte, relativ falsch aufgelöste Ziele, doppelte kanonische URLs, veraltete Anker und Beschriftungen, die nicht mehr zum Ziel passen. Eine formal gültige Datei kann trotzdem unbrauchbar sein; kein Validator entscheidet, ob zwanzig beinahe gleiche Links hilfreich sind.
Nach dem Deploy lädst und prüfst du die öffentliche /llms.txt, nicht das Artefakt aus dem Repository. Falsche Inhaltsvarianten, CDN-Caches, eine als Status 200 ausgelieferte HTML-Fehlerseite oder ein Build mit dem gestrigen Stand liegen zwischen Quelle und Leitung. Der URL-Modus des Validators verwendet dafür einen begrenzten Same-Origin-Helfer: öffentliche HTTP(S)-Ziele mit Endung /llms.txt, feste Ports, keine Redirects, kurze Zeitlimits und beschränkte Größe. Das ist eine gezielte Publikationskontrolle, keine Simulation jedes denkbaren Crawlers.
Plane für das echte Kontextbudget
Auch ein Agent, der die Datei abruft, trifft ökonomische Entscheidungen. Vielleicht liest er nur den ersten passenden Abschnitt, folgt zwei Links, fasst zusammen und stoppt. Aussagekräftige Linktexte und knappe Notizen schlagen daher schiere Menge. Benenne Artefakt und Zweck: „API-Anmeldung und Fehlermodell“ ist besser als „Entwicklerdoku“. Stelle Voraussetzungen vor Spezialreferenzen. Ordne Abschnitte nach Nutzerabsicht, nicht nach deinem internen Organigramm; ein Agent sucht eine Antwort, keine Abbildung der Redaktionszuständigkeiten. Setze absolute kanonische URLs ein, wenn derselbe Text außerhalb seines Ursprungs gelesen werden kann, und verlinke keine Suchergebnisse, deren Inhalt sich bei jedem Abruf verschiebt. Behauptungen gehören nicht exklusiv in das Inventar; die verlinkte Seite bleibt die maßgebliche Quelle und muss allein verständlich sein.
Behandle Änderungen als Vertragspflege. Bei einer umbenannten Route aktualisierst du Sitemap, Redirect, Navigation, llms.txt und Vollfassung zusammen. Ein automatischer Linkcheck gehört in die Pipeline, eine redaktionelle Prüfung trotzdem in den Release: HTTP 200 beweist Erreichbarkeit, nicht Relevanz. Prüfe außerdem, ob neue Pflichtseiten ältere Empfehlungen verdrängen sollten, statt die Liste bei jedem Release nur wachsen zu lassen. Wird eine Website-Funktion für Agenten aufrufbar, braucht sie weiterhin verständliche Dokumentation für Menschen. Der WebMCP-Tool-Validator prüft Tool-Metadaten, ersetzt aber keine Erklärseite. Zugriffsdaten liest du vorsichtig: Ein Abruf beweist Interesse an der Datei, nicht dass ein Modell ihren Inhalt benutzt, geglaubt oder zitiert hat.