Schema, llms.txt und Structured Outputs: Was wofür taugt

Schema-Markup, Taxonomien, JSON Schema und llms.txt landen in Diskussionen über KI gern im selben Topf. Sie strukturieren Informationen, greifen aber an verschiedenen Stellen. Wer sie trennt, kann genauer entscheiden, was eine Website oder ein KI-Workflow wirklich braucht.

Die Kurzfassung:

Schema.org als Suchsignal

JSON-LD kann Suchmaschinen Entitäten und Seiteninhalte in einer standardisierten Form beschreiben. Google nutzt strukturierte Daten unter anderem, um Seiten für Rich Results zu verstehen. Das Markup muss zum sichtbaren Inhalt passen; selbst korrektes Markup garantiert keine besondere Darstellung.¹

Für Google AI Overviews und AI Mode gelten laut Search Central keine zusätzlichen technischen Anforderungen. Strukturierte Daten sind für diese Funktionen nicht erforderlich. Crawlbare Seiten, hilfreicher sichtbarer Inhalt und die üblichen Search-Grundlagen bleiben maßgeblich.²

Daraus folgt weder „Schema bringt KI-Zitationen” noch „LLMs können Schema nicht lesen”. In SEO-Kreisen hört man oft einen Satz wie den von Michael Curtis: „Der ganze Witz an LLMs ist, dass sie Freitext verstehen.” Das trifft einen Kern: Modelle sind für Fließtext gebaut, nicht auf Schema angewiesen. Es ist aber keine Löschung. Tokenisierung zerlegt Text in Fragmente, sie zerstört die JSON-Struktur nicht. Ob ein Crawler JSON-LD verarbeitet und ob ein Antwortsystem das Signal später nutzt, hängt von seiner Pipeline ab. Der belastbare Rat ist unspektakulär: sichtbare Fakten klar schreiben und passendes Schema.org-Markup deckungsgleich ergänzen.

Taxonomie, JSON Schema und Structured Outputs

Bei Modellausgaben beginnt die Struktur eine Ebene früher. Eine Taxonomie definiert den Inhalt: erlaubte Kategorien, ihre Bedeutung und die Abgrenzung ähnlicher Labels. JSON Schema beschreibt anschließend die Form, etwa Feldnamen, Datentypen, Pflichtfelder und zulässige Werte. Structured Outputs übergeben dieses Schema technisch an eine unterstützte Modell-API.

Ein kleiner Content-Prüfworkflow könnte diese Taxonomie verwenden:

• aussage_typ: Leistung, Anspruch, Frist, Kontakt oder Recht
• evidenz_status: belegt, unklar, widersprüchlich oder fehlt
• risiko: niedrig, mittel oder hoch

Das Ausgabe-Schema legt fest, dass jede Prüfung eine Kategorie, einen Status und einen Textbeleg braucht:

{
  "type": "object",
  "properties": {
    "aussage_typ": {
      "type": "string",
      "enum": ["Leistung", "Anspruch", "Frist", "Kontakt", "Recht"]
    },
    "evidenz_status": {
      "type": "string",
      "enum": ["belegt", "unklar", "widersprüchlich", "fehlt"]
    },
    "source_quote": { "type": "string" },
    "review_required": { "type": "boolean" }
  },
  "required": ["aussage_typ", "evidenz_status", "source_quote", "review_required"],
  "additionalProperties": false
}

Damit wird die Ausgabe vergleichbarer und technisch validierbar. Inhaltlich richtig ist sie noch nicht. Ein Modell kann ein gültiges JSON mit einer falschen Kategorie oder einem unpassenden Zitat liefern. Deshalb braucht der Workflow zwei Prüfungen: zuerst gegen das JSON-Schema, danach gegen Quelle oder Testset. Bei regulierten Aussagen gehört eine menschliche Freigabe dazu. Die Anbieter-Dokumentationen zu Structured Outputs weisen ebenfalls darauf hin, dass Schema-Konformität keine inhaltliche Richtigkeit garantiert.³⁴

Dieses JSON-Schema hat nichts mit Schema.org-Markup auf einer Website zu tun. Der gleiche Begriff bezeichnet zwei verschiedene Werkzeuge.

llms.txt als Wegweisung für Agenten

llms.txt ist eine Proposal, kein ratifizierter Webstandard. Die aktuelle v2-Fassung beschreibt eine kleine Markdown-Übersicht, die Agenten zu wichtigen Inhalten führt. Besonders naheliegend ist das bei umfangreicher Softwaredokumentation. Detailseiten können zusätzlich als Markdown verlinkt oder per Content Negotiation angeboten werden.⁵

Eine Alltagsmetapher hilft bei der Einordnung, solange man sie nicht überstrapaziert. Ein Hausmeister, hier ein Agent, soll dein Haus, deine Website, aufräumen. Die robots.txt ist das Schild „Betreten verboten" an bestimmten Türen, ein echtes Zugriffssignal. Die llms.txt ist dagegen nur ein freiwilliger Zettel am Eingang: „Die wichtigsten Infos liegen auf dem Tisch im Wohnzimmer." Ob der Hausmeister den Zettel liest, ob er ihm folgt und ob das seine Arbeit beschleunigt, ist von Agent zu Agent unterschiedlich und durch nichts garantiert.

Die Abgrenzung zu bestehenden Webmechanismen ist wichtig:

Google Search verwendet llms.txt laut eigener Anleitung nicht für Sichtbarkeit oder Rankings. Chrome und Lighthouse behandeln die Datei dagegen als optionale Konvention für agentisches Browsen; fehlt sie, ist der Check nicht automatisch ein Fehler.²⁶ Das ist kein Widerspruch. Search-Ranking und Agenten-Navigation sind verschiedene Anwendungsfälle.

Auch die bisherige Adoption belegt keine Wirkung. Eine SE-Ranking-Analyse von knapp 300.000 Domains fand in ihrer Stichprobe bei 10,13 Prozent eine llms.txt, aber keine Korrelation mit der untersuchten LLM-Zitationshäufigkeit.⁷ Das ist eine Anbieteranalyse, kein Web-Zensus und kein Kausalnachweis.

Was meine Website tatsächlich zeigt

Auf dieser Website gibt es eine llms.txt. HTML bleibt das Standardformat; ausgewählte Seiten lassen sich über denselben URL-Pfad auch als Markdown abrufen:

curl -sS -D - \
  -H 'Accept: text/markdown' \
  -o /dev/null \
  https://martin-moeller.biz/lab/ki/verstaendnis-steuern-schema-llms-txt

Beim Check am 15. August 2026 lieferte die Seite Content-Type: text/markdown und Vary: Accept. Damit ist technisch belegt, dass ein Client eine Markdown-Repräsentation anfordern kann. Nicht belegt ist, dass Google, ChatGPT oder Claude die Seite dadurch häufiger zitieren.

Genau diese Trennung macht die Implementierung als Arbeitsprobe nützlich: robots.txt regelt Zugriff, llms.txt kuratiert Einstiegspunkte, Content Negotiation liefert eine andere Repräsentation, und der sichtbare Artikel bleibt die inhaltliche Quelle.

Wann sich der Aufwand lohnt

• Schema.org-Markup lohnt sich, wenn Google für den Inhalt einen passenden Typ und eine sinnvolle Suchdarstellung dokumentiert.
• Taxonomie plus JSON Schema lohnt sich, sobald mehrere Modellausgaben verglichen, geprüft oder von Code weiterverarbeitet werden.
• Structured Outputs lohnen sich, wenn die gewählte API das Schema technisch erzwingen kann.
• llms.txt lohnt sich, wenn wichtige Inhalte bewusst für Agenten kuratiert und die Links aktuell gehalten werden.

Ein pauschales „einbauen, schadet nicht” greift zu kurz. Jede zusätzliche Schicht kann veralten. Ohne gepflegte Ziele wird aus der Wegweisung schnell eine Liste kaputter oder falscher Prioritäten. Bei meiner eigenen llms.txt bleibt das deshalb eine Wette, kein Werkzeug: Ich pflege sie, weil der Aufwand gering ist, nicht weil ich einen Effekt nachweisen kann.

Für Suchsichtbarkeit bleibt das GEO-Playbook der breitere Rahmen. Hier geht es um die technische Grenze: Was lässt sich auszeichnen, validieren oder ausliefern, und was ist damit noch nicht bewiesen?

Die kurze Version

1. Schema.org-Markup ist ein Suchsignal für Google, kein dokumentierter Zitationshebel für LLMs.
2. llms.txt ist eine optionale Proposal für Agenten, kein Rankingfaktor und kein Zugriffssignal wie robots.txt.
3. JSON Schema und Structured Outputs regeln die Form einer Modellausgabe. Über deren inhaltliche Richtigkeit sagen sie nichts.
4. Meine eigene Website liefert llms.txt und eine Markdown-Repräsentation aus. Das ist technisch belegt, keine Zitationsgarantie.
5. Alle vier Ebenen lohnen sich unterschiedlich. Ein pauschales „einbauen, schadet nicht” greift zu kurz.

Quellen & Referenzen