llms.txt- und Agent-Manifest-Seiten: Ein gepflegter maschinenlesbarer Site-Index

Eine llms.txt- und Agent-Manifest-Seite ist ein maschinenorientierter Index, der KI-Systemen mitteilt, wofür eine Website steht, welche öffentlichen Seiten maßgeblich sind und – wenn das Unternehmen Agentenaktionen unterstützt – welche verifizierten Fähigkeiten und Richtlinien gelten. Sie ist eine Karte zu gepflegten Quellen, kein Ersatz für diese Quellen und kein Versprechen, dass ein bestimmter Crawler sie nutzt.

Ihr Vertrag ist Identität → Umfang → maßgebliche Ziele → optionale Fähigkeiten → Einschränkungen → Aktualität. Die Datei ist erfolgreich, wenn eine Maschine sie abrufen, ohne Raten interpretieren, live kanonische URLs verfolgen und zu Fakten gelangen kann, die noch mit der Produktionsrealität übereinstimmen.

Beantwortete Fragen

Die primäre Frage ist: „Welche Teile dieser Website sollte ein KI-System nutzen, um die Organisation, ihre Inhalte und ihre unterstützten Aktionen zu verstehen?" Unterstützende Fragen sind:

• Wie lauten der kanonische Name, die Domain, der Zweck und die Zielgruppe der Website?
• Welche Produkt-, Service-, Dokumentations-, Preis-, Richtlinien- und Support-Seiten sind maßgeblich?
• Welche Seiten sollten Archiven, Kampagnenseiten, Parametern oder duplizierten regionalen Versionen vorgezogen werden?
• Bietet die Website eine tatsächliche Agentenfunktion oder nur menschenlesbare Informationen?
• Wo sind Authentifizierung, Ratengrenzen, Datenhandhabung, Geschäftsbedingungen und Support dokumentiert?
• Welche Aussagen sind beschreibende Anleitungen und keine Zugriffskontrollregeln?
• Wer besitzt die Datei, welches Ereignis löst ein Update aus und wie wird Abweichung erkannt?

Wann dieser Beitragstyp verwendet wird

Verwenden Sie diesen Typ, wenn die Website genügend öffentliche, dauerhafte Inhalte hat, die von einem kuratierten maschinenorientierten Index profitieren, und jemand die Pflege übernehmen kann. Der Grund für die Veröffentlichung ist, Mehrdeutigkeit für Retrieval-Systeme zu reduzieren, nicht eine weitere URL um ihrer selbst willen zu schaffen.

Verwechseln Sie Anleitung nicht mit Kontrolle. robots.txt drückt Crawler-Zugriffspräferenzen aus; eine XML-Sitemap hilft Crawlern, URLs zu entdecken; Authentifizierung und Autorisierung entscheiden, ob eine Aktion stattfinden darf. llms.txt bietet kuratierten Kontext. Ein Satz in llms.txt kann keinen Zugriff gewähren, Zugriff entziehen, ein Geheimnis schützen oder die Bedingungen einer Zielseite außer Kraft setzen.

Am besten geeignet für diese Unternehmenstypen

1. SaaS . Die beste Passung, da ein Softwareunternehmen normalerweise unterschiedliche Produkt-, Funktions-, Preis-, Integrations-, API-, Sicherheits-, Status- und Dokumentationsquellen hat. Der Index kann auflösen, welche Seite für welche Tatsache zuständig ist, während ein separates Fähigkeitenmanifest nur Aktionen beschreiben kann, die das Produkt tatsächlich unterstützt.
2. E-Commerce . Stark, wenn Produkte, Versand, Rückgaben, Verfügbarkeit und Kundendienstrichtlinien öffentlich und kanonisch sind. Halten Sie volatile Artikeldaten in Feeds oder APIs; verwenden Sie den Index, um auf diese gepflegten Quellen zu verweisen, anstatt einen Katalog in Markdown zu kopieren.
3. Marktplätze . Wertvoll, wenn Käufer-, Verkäufer-, Anbieter- und Plattformrichtlinien unterschiedlich sind. Kennzeichnen Sie jede Zielgruppe und Rechtsordnung, damit ein Agent nicht Verkäuferregeln auf einen Käufer anwendet oder Plattforminventar aus einem einzigen Angebot ableitet.
4. B2B-Dienstleistungen . Nützlich zur Klärung von Fähigkeiten, Branchen, Servicegrenzen, Nachweisen, Beschaffungsmaterial und Kontaktwegen. Wandeln Sie keinen verhandelten Umfang oder kundenspezifisches Versprechen in eine universelle maschinenorientierte Behauptung um.
5. Agenturen . Nützlich, wenn das Unternehmen viele Service-, Methodik-, Fallstudien- und Experteseiten pflegt. Kundenportale, Anmeldeinformationen, private Berichte und interne Playbooks bleiben außerhalb der öffentlichen Datei.
6. Hersteller und Industrieunternehmen . Nützlich, um Systeme zu Produktfamilien, Spezifikationen, Zertifizierungen, Handbüchern, Händlern und Sicherheitsdokumenten zu leiten. Der Index darf sicherheitskritische Anweisungen niemals paraphrasieren, wenn das kontrollierte Dokument die Autorität ist.

Kleine Broschüren-Websites mit fünf stabilen Seiten gewinnen wenig aus einem weiteren gepflegten Artefakt. Websites ohne klaren Inhaltsverantwortlichen sollten Kanonisierung, Navigation und Quellenqualität beheben, bevor sie eine Datei veröffentlichen, die sofort abweichen wird.

Suchintention

Die Suchintention ist das von einer Anfrage erwartete Ergebnis. Dieser Typ hat zwei Zielgruppen mit unterschiedlicher Intention. Eine Maschine ruft einen vorhersagbaren Stammpfad ab und erwartet prägnantes Markdown, stabile Überschriften, kanonische Links und keine dekorativen Ablenkungen. Ein menschlicher Sucher möchte normalerweise Implementierungsanleitungen: „llms.txt-Beispiel", „Was gehört in llms.txt" oder „Agent-Manifest-Format". Die öffentliche Erklärungsseite kann diese Fragen beantworten, während das bereitgestellte /llms.txt für den Maschinenabruf optimiert bleibt.

Die Datei selbst ist keine Keyword-Landingpage. Fügen Sie keine generischen Definitionen, wiederholten Kategoriebegriffe oder hunderte Blog-Links hinzu, um sie „rankieren" zu lassen. Jede zusätzliche Zeile verbraucht Aufmerksamkeit und schafft eine weitere Wartungsverpflichtung. Bevorzugen Sie zehn bewusste Links mit klaren Beschreibungen gegenüber einem Datenauswurf von zehntausend URLs.

Da Konventionen und Verbraucherunterstützung sich ändern können, geben Sie an, worauf Ihre Implementierung basiert, und vermeiden Sie die Behauptung universeller Akzeptanz. Ein erfolgreicher Abruf beweist nur, dass die Datei zugänglich und parsbar ist; er beweist nicht, dass ein bestimmtes KI-Produkt sie für Ranking, Retrieval, Training oder Zitierung verwendet.

Seitenstruktur

Wortbänder sind Bearbeitungsbeschränkungen, keine Ziele. Die bereitgestellte Datei sollte prägnant genug bleiben, um Zeile für Zeile geprüft zu werden. Die menschenorientierte Implementierungsnotiz kann länger sein, darf aber nicht in die Maschinendatei kopiert werden.

Eine typische kuratierte Datei umfasst etwa 200–700 Wörter. Länge ist kein Qualitätssignal: Die richtige Größe ist der kleinste Index, der Identität etabliert und einen Verbraucher zu gepflegten Quellen führt, ohne wesentliche Unterschiede zu verbergen.

Erforderliche Elemente

Der Index muss im besten Sinne langweilig sein: vorhersagbar, explizit und leicht zu diffen. Platzieren Sie kritische Interpretationshinweise vor optionalen Links, damit ein teilweises Lesen keine falsche Schlussfolgerung ergibt.

Frontmatter

Folgen Sie der Frontmatter-Spezifikation . Verwenden Sie bei dieser Beitragstypspezifikation entity = "post-type-llms-txt-page" und schemaType = "Article". Verwenden Sie auf einer menschenorientierten Implementierungsseite für eine bestimmte Organisation eine stabile Identität wie acme-ai-access-index, keinen Kampagnenbegriff oder kein Datum.

Verwenden Sie Article, weil die Webseite die Implementierung erklärt. Schema-Markup beschreibt sichtbare Inhalte; es macht die rohe Textdatei nicht zu einem anerkannten Agentenprotokoll. Markieren Sie die Seite nicht als SoftwareApplication, Dataset oder HowTo, es sei denn, ihre sichtbaren Inhalte und Vorlage erfüllen die relevanten Anforderungen unabhängig.

Die rohe /llms.txt-Datei hat normalerweise kein Frontmatter, da Frontmatter nicht in die veröffentlichte Ausgabe durchsickern darf. Speichern Sie ihre operativen Metadaten im CMS, der Generatorkonfiguration oder einem Repository-Datensatz: kanonische Domain, Gebietsschema-Umfang, Eigentümer, Quellsammlung, Generierungsmodus, letztes Verifizierungsdatum, nächste Überprüfungsregel, Validierungsergebnis und Alarmziel. Wenn lokalisierte Dateien existieren, dokumentieren Sie die Auswahlregel und behalten Sie eine eindeutige kanonische Stammantwort.

Vollständiges Beispiel

Diese fiktive Datei demonstriert einen prägnanten Index für eine SaaS-Plattform. Ihre URLs, Produkte und Fähigkeiten sind Beispiele; das Muster ist die Spezifikation.

# Northstar Analytics

> Northstar Analytics ist eine Reporting-Plattform für Betriebsteams. Dieser Index verweist auf die öffentlichen Seiten, die das Produkt, die Pläne, die Dokumentation, die Richtlinien und die unterstützte Agentenfähigkeit definieren.

Zugriffsberechtigungen werden durch robots.txt, Authentifizierung und die unten verlinkten Richtlinien gesteuert. Diese Datei gewährt keinen Zugriff oder keine Erlaubnis zur Wiederverwendung von Inhalten.

## Produkt

- [Produktübersicht](https://www.northstar.example/product): Aktueller Produktumfang und unterstützte Reporting-Workflows.
- [Pläne und Preise](https://www.northstar.example/pricing): Aktuelle öffentliche Pläne, enthaltene Funktionen und Abrechnungsbedingungen.
- [Integrationen](https://www.northstar.example/integrations): Unterstützte Datenquellen und Zielsysteme.

## Dokumentation

- [Dokumentations-Startseite](https://docs.northstar.example/): Aktuelle Benutzer- und Administratordokumentation.
- [API-Referenz](https://docs.northstar.example/api/): Öffentliche Endpunkte, Schemas, Authentifizierung, Fehler und Ratengrenzen.
- [Versionshinweise](https://docs.northstar.example/releases/): Datierte Änderungen am Produkt- und API-Verhalten.

## Vertrauen und Support

- [Sicherheit](https://www.northstar.example/security): Sicherheitsprogramm und aktuelle Zusicherungsdokumente.
- [Datenschutzrichtlinie](https://www.northstar.example/privacy): Datenverarbeitung, Aufbewahrung und Benutzerrechte.
- [Support](https://www.northstar.example/support): Unterstützte Kontaktwege und Service-Status-Link.

## Agentenfähigkeit

- [Berichtsexport-Aktion](https://docs.northstar.example/agents/export-report): Authentifizierter Aktionsvertrag, akzeptierte Eingaben, Ausgabeformat, Ratengrenzen und Fehlerbehandlung. Die Verfügbarkeit hängt vom Plan und der Rolle des Benutzers ab.

## Optional

- [Forschungsbibliothek](https://www.northstar.example/research): Original-Benchmark-Berichte mit Methoden und Veröffentlichungsdaten.

Verifiziert am 2026-08-27 durch das Dokumentationsbetriebsteam. Generiert aus dem kanonischen öffentlichen Ressourcenregister; nach Produkt-, Plan-, Richtlinien-, API- oder URL-Änderungen validieren.

Das Beispiel deklariert nur eine Fähigkeit, weil ein tatsächlicher, dokumentierter Aktionsvertrag existiert. Wenn das Produkt keine unterstützte Agentenaktion hat, lassen Sie diesen Abschnitt weg. Leiten Sie niemals eine Transaktionsfähigkeit aus dem Vorhandensein eines Suchfelds, Formulars oder undokumentierten Endpunkts ab.

Für ein Agent-Manifest, das getrennt von /llms.txt gespeichert wird, behalten Sie dieselbe Disziplin bei. Geben Sie ein versioniertes Format, eine kanonische Kennung, einen Produktionsendpunkt, eine Authentifizierungsmethode, erlaubte Operationen, Ein- und Ausgabeschema, Ratengrenzen, Einwilligungsgrenzen, Fehlerzustände und Richtlinien-URLs an. Validieren Sie es gegen das Live-System. Eine syntaktisch gültige Deklaration, die eine deaktivierte Aktion bewirbt, ist trotzdem falsch.

Design-Galerie

Die Rohdatei hat wenig visuelles Design – das ist beabsichtigt. Galerie-Varianten sollten Informationsarchitektur, Scan-Reihenfolge, mobile Lesbarkeit der menschlichen Implementierungsseite und operative Nachweise testen – nicht Dekoration.

Qualitäts-Checkliste

Veröffentlichen Sie nur, wenn jede zutreffende Aussage wahr ist:

• Die Datei ist unter der beabsichtigten Stamm-URL ohne Authentifizierung, Weiterleitungsschleifen, Consent Walls oder einer gerenderten Anwendungs-Shell erreichbar.
• Die Antwort ist lesbarer Klartext oder Markdown, verwendet UTF-8 und ist nicht auf JavaScript angewiesen, um ihren Inhalt anzuzeigen.
• Die H1 gibt den kanonischen Organisations- oder Websitenamen an, und die Beschreibung nennt Zweck, Zielgruppe und Umfang ohne Slogans.
• Jede verlinkte URL ist kanonisch, öffentlich, per Richtlinie indexierbar, erreichbar und im Besitz der Organisation oder klar als extern gekennzeichnet.
• Linkbeschreibungen geben an, welche Autorität das Ziel hat; sie wiederholen keinen generischen Ankertext wie „mehr erfahren".
• Primäre Produkt-, Preis-, Dokumentations-, Richtlinien- und Supportquellen stimmen mit dem Index überein.
• Archivseiten, Suchergebnisse, Tracking-Parameter, doppelte Gebietsschemata, Kampagnenseiten und Low-Value-Tag-Seiten sind ausgeschlossen.
• Fähigkeitsbehauptungen entsprechen einem live unterstützten, authentifizierten Vertrag und enthalten die relevanten Einschränkungen.
• Kein Geheimnis, Token, privater Endpunkt, personenbezogene Daten, Client-Dokument, unveröffentlichter Roadmap-Eintrag oder sicherheitsrelevantes Implementierungsdetail erscheint.
• Zugriffs-, Berechtigungs-, Lizenzierungs- und Richtliniensprache verweist auf kontrollierende Quellen und wird nicht vom Index widersprochen.
• Die Datei behauptet kein garantiertes Ranking, keine Zitierung, keinen Trainingsausschluss und keine universelle Verbraucherunterstützung.
• Gebietsschema und regionaler Umfang sind explizit, wo Preise, Richtlinien, Verfügbarkeit oder Dokumentation abweichen.
• Der Eigentümer, das Quellregister, der Generierungsprozess und die Validierungsmethode sind außerhalb oder am Ende der Datei aufgezeichnet.
• Prüfungen auf defekte Links, unerwartete Weiterleitungen, Antwortstatus, Content-Hash und erforderliche Abschnitte werden nach relevanten Bereitstellungen durchgeführt.
• Das Verifizierungsdatum ändert sich nur, nachdem Ziele, Beschreibungen, Fähigkeiten und Richtlinien substanziell geprüft wurden.

Häufige Fehler

Die Datei wie eine Sitemap behandeln. Ein vollständiges URL-Inventar zerstört die Priorisierung und ist schwer zu überprüfen. Behalten Sie XML-Sitemaps für die Entdeckung bei; kuratieren Sie llms.txt um maßgebliche Quellen und sinnvolle Gruppen.

Sie wie eine Zugriffskontrolle behandeln. Eine Aufforderung in Markdown ist keine Durchsetzungsebene. Drücken Sie Crawl-Regeln in robots.txt aus, schützen Sie private Ressourcen mit Authentifizierung und platzieren Sie verbindliche Anforderungen in den entsprechenden Richtlinien- und Systemkontrollen.

Zielinhalte in den Index kopieren. Wiederholte Preise, Produktspezifikationen und Richtlinien weichen ab. Fassen Sie nur genug zusammen, um die Autorität zu identifizieren, und verlinken Sie dann auf die gepflegte Quelle.

Spekulative Fähigkeiten veröffentlichen. Ein undokumentiertes Formular oder ein API-Pfad macht eine Website nicht agentenbereit. Deklarieren Sie nur produktionsunterstützte Aktionen mit Authentifizierung, Schemas, Einschränkungen, Fehlern und einem Eigentümer.

Alles „nur für den Fall" aufnehmen. Mehr Links erzeugen mehr Mehrdeutigkeit und mehr Fehlerpunkte. Optionale Inhalte sollten sich die Aufnahme verdienen, indem sie ein wahrscheinliches Retrieval-Bedürfnis beantworten, das primäre Abschnitte nicht abdecken.

Privates Material offenlegen. Öffentliche maschinenlesbare Dateien sind öffentlich. Listen Sie niemals Staging-Hosts, interne APIs, Anmeldeinformationen, Kundenexporte, unveröffentlichte Dokumente oder Sicherheitsdetails auf, die nicht absichtlich zur Veröffentlichung freigegeben wurden.

Ohne Governance generieren. Automatisierung kann schlechte Quelldaten mit hoher Geschwindigkeit reproduzieren. Ein Generator benötigt ein genehmigtes Quellregister, Ausschlussregeln, deterministische Sortierung, Validierung, Überprüfungsverantwortung und Bereitstellungsalarme.

Eine generierte Datei manuell bearbeiten. Die nächste Generierung überschreibt die Korrektur. Korrigieren Sie den Quelldatensatz oder Generator, generieren Sie neu und zeichnen Sie die materielle Änderung auf.

Nicht unterstützte Ergebnisse behaupten. „Dies garantiert KI-Zitate" verwandelt eine unsichere Implementierungskonvention in ein irreführendes Versprechen. Berichten Sie Zugänglichkeit und Retrieval-Nachweise getrennt von Sichtbarkeits- und Zitationsergebnissen.

Das Datum aktualisieren, ohne die Realität zu prüfen. Ein neuer Zeitstempel kann keine defekte Dokumentations-URL, umbenannten Plan oder deaktivierte Aktion reparieren. Verifizierung bedeutet, jede wichtige Deklaration mit ihrer Produktionsquelle zu vergleichen.

Interne Verlinkung

Verlinken Sie die menschliche Implementierungsseite nach oben zu SEO-Beitragstypen , wenn ein Autor den Maschinenindex von einem Verzeichnis, einer Dokumentationsseite oder einer Richtlinie unterscheiden muss. Verlinken Sie von jeder operativen Behauptung zu ihrer kontrollierenden Quelle: Produktumfang zur Produktseite, aktuelle Preise zu Preisen, Verhalten zur Dokumentation, Berechtigungen zu Zugriffskontrollen und Verpflichtungen zur Richtlinie.

Die Rohdatei sollte kanonische absolute URLs verwenden, da sie außerhalb der normalen Websitenavigation abgerufen werden kann. Bevorzugen Sie eine maßgebliche Quelle pro Fakt. Wenn zwei Seiten überlappen, klären Sie die Zuständigkeit, bevor Sie beide aufführen; der Index sollte die Quellhierarchie offenlegen, keine internen Meinungsverschiedenheiten verewigen.

Verwenden Sie kurze, stabile Abschnittsnamen wie Produkt, Dokumentation, Richtlinien und Agentenfähigkeiten. Behalten Sie Gebietsschema-Varianten nur in klar gekennzeichneten Gruppen, wenn sie sich materiell unterscheiden. Verlinken Sie nicht jeden Blogbeitrag; wählen Sie dauerhafte Forschung oder Anleitungen nur, wenn sie einem System helfen, das Thema und die Nachweise der Website zu verstehen.

Eingehende Links sind auch operativ wichtig. Dokumentation, Entwicklerportale und KI-Zugänglichkeitsanleitungen sollten Betreuer auf den Implementierungsdatensatz verweisen, während der Datensatz auf die Live-Datei und den Validator verweist. Das schafft einen Überprüfungspfad für Menschen, ohne den Maschinenindex zu überladen.

Wie man Ergebnisse misst

Messen Sie die Datei zuerst als Infrastruktur und dann als Sichtbarkeitsfaktor. Ein Anstieg der Zitate kann llms.txt nicht allein deshalb zugeschrieben werden, weil beides nach der Veröffentlichung geschah.

Verfolgen Sie vier Ebenen:

• Verfügbarkeit: Stamm-URL-Antwortstatus, Weiterleitungsverhalten, Inhaltstyp, Kodierung, Latenz, Render-Unabhängigkeit und Betriebszeit.
• Integrität: Parse-Erfolg, erforderliche Abschnitte, doppelte URLs, defekte Links, Weiterleitungsziele, kanonische Abweichungen, unbefugte Domains, offengelegte Geheimnisse und Content-Hash-Änderungen.
• Aktualität: Tage seit substanzieller Verifizierung, Zieländerungen seit Verifizierung, Quellregister-Abdeckung, Bestätigung durch den Eigentümer und Zeit bis zur Behebung von Abweichungen.
• Ergebnisse: Serverlog-Abrufe durch identifizierbare Agenten, soweit rechtlich und technisch angemessen, Besuche auf indizierten Zielen, KI-Zitate bevorzugter kanonischer Seiten und Antwortgenauigkeit für verfolgte Marken- oder Produktfragen.

Erstellen Sie eine Baseline vor der Bereitstellung: Welche URLs werden zitiert, welche Fakten werden falsch dargestellt, ob die Stammdatei existiert und welche Crawler sie anfordern. Vermerken Sie die Veröffentlichung und jedes wesentliche Update. Vergleichen Sie Beobachtungszeiträume, die lang genug sind, um nicht einen einzelnen Abruf oder ein Zitat als Trend zu lesen, und bewahren Sie die Unterscheidung zwischen Korrelation und Kausalität.

Testen Sie die Fehlermodi direkt. Benennen Sie eine Staging-Kopie einer aufgeführten URL um und bestätigen Sie, dass der Validator den Bruch erkennt. Ändern Sie eine kanonische Zuordnung und bestätigen Sie, dass der Generator den Index aktualisiert. Deaktivieren Sie eine Fähigkeit in einer kontrollierten Testumgebung und bestätigen Sie, dass die Manifest-Prüfung fehlschlägt. Diese Tests beweisen das Wartungssystem, nicht die externe Akzeptanz.

Verwenden Sie wie wir Ergebnisse messen , um technische Verfügbarkeit, maschinelle Repräsentation, Entdeckung, Zitierung, Engagement und Geschäftsergebnisse zu trennen. Überprüfen Sie in AmICited die Live-Datei unter Agent Accessibility und verwenden Sie den Cockpit-Bericht , um zitierte URLs und KI-Sichtbarkeit neben Bereitstellungsvermerken zu beobachten. Die glaubwürdige Erfolgsbehauptung ist „die Datei ist gültig, aktuell und leitet Systeme zu den beabsichtigten Quellen"; jede nachgelagerte Sichtbarkeitsänderung erfordert separate Nachweise.

FAQ

Häufig gestellte Fragen