llms.txt für Agenten — Discovery, Census & Grenzen

Agenten brauchen Orientierung, bevor sie deine Webseite Seite für Seite parsen. llms.txt ist der Vorschlag dafür: eine schlanke Markdown-Datei unter /llms.txt, die Titel, Kurzbeschreibung und priorisierte Links liefert. Dieser Beitrag klärt, was die Datei leistet und wo sie endet — mit Google-Position (Mueller / Search Central), Census-Zahlen, Beispielstruktur, Markdown-Negotiation und dem Bezug zu GEO & AI-Sichtbarkeit. Praxis bei Modern Stack: /llms.txt und /llms.json aus dem Content-Katalog, volle Markdown-Auslieferung auf Content-URLs.

Was ist llms.txt — und was ist sie nicht?

Antwort zuerst: llms.txt ist eine freiwillige Markdown-Karte unter /llms.txt für Sprachmodell-Agenten; sie ist kein W3C-Standard, kein Google-Ranking-Faktor und kein Ersatz für crawlbare HTML-Antworten.

Der Vorschlag auf llmstxt.org (Jeremy Howard / Answer.AI, 2024) adressiert ein praktisches Problem: Agenten und Modelle haben begrenzte Kontextfenster, während moderne Webseiten Navigation, Skripte, Banner und Cookie-Layer mitschleppen. Eine Datei im Domain-Root soll diese Last abnehmen — analog zu robots.txt (Crawler-Regeln) und einer Sitemap (URL-Liste), aber mit kurzen Beschreibungen, die Textmodelle direkt lesen können.

Was sie ist:

• Kuratierte Liste der wichtigsten URLs (Leistungen, Themen, Regionen, Kontakt, Studien)
• Kurzer Marken-/Scope-Einzeiler für den ersten Glance
• Optional Verweise auf Markdown-Fassungen derselben Seiten
• Einstiegspunkt für Tools, die bewusst nach /llms.txt fragen

Was sie nicht ist:

• Kein Ranking-Signal in Google Search (inkl. generativer Search-Features)
• Keine Garantie für Zitationen in ChatGPT, Perplexity oder Claude
• Kein Ersatz für Direct Answers, FAQ und sauberes HTML
• Keine Heilung für JS-Shells, blockierte Crawler oder Pagebuilder-Rauschen
• Kein Beweis, dass fehlende Datei = Sichtbarkeitsverlust

Wer nur eine llms.txt hochlädt und glaubt, damit „AI-ready“ zu sein, optimiert eine Karte ohne Straße. Primär bleiben Crawlability, Extrahierbarkeit und answer-first Copy.

Warum Google Search llms.txt für Rankings ignoriert

Antwort zuerst: Laut Google Search Central und John Mueller nutzt Google Search llms.txt (und ähnliche AI-Textdateien) nicht für Rankings oder generative Search-Sichtbarkeit — die Datei hilft und schadet dort nicht.

Die offizielle Guidance unter AI features and your website stellt klar: Du brauchst keine neuen maschinenlesbaren AI-Dateien, Markup-Sonderwege oder Markdown-Doppelungen, um in Google Search (inklusive generativer Features) zu erscheinen — Search selbst nutzt sie nicht. Ergänzend: Es ist in Ordnung, llms.txt für andere Dienste zu pflegen; Google Search ignoriert sie für Visibility und Rankings.

John Mueller (Search Relations) hat die Position mehrfach verschärft: Selbstberichtete Dateien können Systeme nicht vertrauenswürdig zwischen Webseiten differenzieren — jedes Projekt kann „wir sind die beste Quelle“ schreiben. Für Discovery verweist er zurück auf normales HTML und interne Links. Ein sinnvoller Restnutzen bleibt On-Site: Wenn ein Agent bereits auf deiner Domain ist, kann eine Karte Navigation und Kauf-/Kontaktpfade erleichtern — vergleichbar mit einem Ladenverzeichnis, nachdem jemand den Laden betreten hat.

Für dich heißt das: Investiere in llms.txt parallel zu SSR/SSG und GEO-Content — nie als Google-Hebel und nie als Ersatz für HTML. Wer Agenten blockiert (robots, WAF, Cloudflare-Bot-Fight ohne Allowlist), bleibt unsichtbar, egal wie sauber die Datei formatiert ist.

Zwei Missverständnisse tauchen in Audits immer wieder auf. Erstens: „Google hat irgendwo eine llms.txt, also ist das ein Ranking-Signal.“ Das ist kein Endorsement der Search-Relations-Teams — Dateien auf fremden Google-Properties sagen nichts über die Ranking-Pipeline. Zweitens: „Ohne llms.txt werde ich in AI Overviews nicht genannt.“ Search Central widerspricht dem explizit: Du brauchst die Datei nicht, um in Google Search inklusive generativer Features zu erscheinen. Was du brauchst, bleibt crawlbares HTML mit klaren Antworten — plus die Erlaubnis, dass gewünschte Fetcher deine Origin erreichen.

Wie hilft llms.txt bei Agent-Discovery — und wie nicht?

Antwort zuerst: Die Datei zeigt Agenten, welche URLs auf deiner Domain zählen; sie entscheidet nicht, welche Domain eine generative Engine überhaupt auswählt.

Was Agent-Discovery praktisch bedeutet

1. Ein Tool oder Agent landet auf deiner Origin (Link, Suchergebnis, bekannte Marke, direkter Host).
2. Es ruft optional /llms.txt / /llms.json ab, um Scope und Prioritäten zu verstehen.
3. Es folgt den gelisteten URLs — idealerweise mit Markdown-Fetch statt HTML-Scraping.
4. Zitierfähig wird nur, was auf diesen URLs als klare Antwortpassage steht.

Was sie nicht leistet

• Keine „nimm mich statt Konkurrent X“-Differenzierung über die Datei allein
• Keine Reparatur fehlender Direct Answers oder leerer SPA-Bodies
• Keine Umgehung blockierter KI-Crawler
• Keine Kompensation für tote Links in der Karte (tote Links sind schlimmer als keine Datei)

Die Kette lautet: Discover Host → Karte lesen → URL fetchen → Passage extrahieren. Bricht ein Glied, bleibt llms.txt Dekoration. Vertiefung zur Zitationsseite: ChatGPT-Sichtbarkeit.

In der Praxis unterscheiden sich drei Agenten-Typen. Recherche-Agenten wollen schnell Scope und Primärquellen. Coding-/Integrations-Agenten wollen stabile API- oder Doku-URLs. Buchungs- oder Outreach-nahe Tools wollen Kontakt, Leistungen und nächste Schritte. Eine gute llms.txt bedient alle drei mit getrennten Abschnitten statt einer undifferenzierten Linkflut. Was sie nicht ersetzen kann: den Moment, in dem ein Modell zwischen zwei Domains wählen muss — das bleibt Sache von Reputation, Entitäten, internen Links und der Qualität der HTML-Antworten selbst.

Wie sieht eine saubere llms.txt-Struktur aus?

Antwort zuerst: H1 mit Marke, Blockquote-Summary, dann H2-Abschnitte mit kommentierten Links — nur stabile, zitierfähige URLs, keine Parameter-Spam-Liste.

Beispielstruktur (vereinfacht, angelehnt an den llmstxt.org-Vorschlag und die Praxis bei Modern Stack):

    # Modern Stack

    > Webseite-Modernisierung für Dienstleister in D-A-CH —
    > Migration, Redesign, Knowledge Graph und [Conversion](/glossar/conversion).

    ## Leistungen

    - [Webseite modernisieren](https://modern-stack.de/themen/website-modernisierung): Stack-Wechsel ohne Content-Verlust
    - [WordPress-Migration](https://modern-stack.de/themen/wordpress-migration): ab 500 €, bis 10 Seiten
    - [GEO & AI-Sichtbarkeit](https://modern-stack.de/themen/geo-ai-sichtbarkeit): zitierfähige Antworten

    ## Studien & Belege

    - [AI-Readiness-Studie](https://modern-stack.de/studie): Census n=6.675 Dienstleister-Webseiten
    - [Studie Bad Schönborn](https://modern-stack.de/studie/bad-schoenborn): lokale Primärstudie

    ## Regionen

    - [Bad Schönborn](https://modern-stack.de/bad-schoenborn): lokale Conversion-Landing

    ## Optional

    - [llms.txt für Agenten](https://modern-stack.de/themen/llms-txt-agenten): Aufbau, Grenzen, Pflege

Redaktionsregeln:

• 10–30 Links, nicht 300 Tracking-URLs
• Jeder Link: ein erklärender Halbsatz, kein Marketing-Jargon
• Nur Apex-Kanonik (https://modern-stack.de/…), keine www-Duplikate
• „Optional“-Abschnitt für Material, das bei knappem Kontext weggelassen werden darf
• Nach Content-Updates: Datei aus dem Catalog neu erzeugen — keine manuellen Stale-Kopien

Was ist Markdown-Negotiation — und warum zählt sie neben llms.txt?

Antwort zuerst: Markdown-Negotiation liefert bei Accept: text/markdown volle Seiteninhalte; llms.txt zeigt den Weg, Markdown liefert die Nutzlast ohne HTML-Ballast.

Markdown-Negotiation bedeutet: Content-URLs (Themen, Glossar, Regionen, Studien) antworten auf den Accept-Header mit Markdown statt nur HTML. Bei Modern Stack gilt zusätzlich: Default-Content-Type der .md-URLs ist text/plain (besser verträglich für manche Fetcher); text/markdown bei explizitem Accept. Die Inhalte sind vollständig — keine Teaser-Stubs. EN-Felder liegen im Frontmatter für Maschinen; kanonisch bleibt de-DE HTML ohne parallele /en/-Routen.

Im Census liegt Markdown-Negotiation bei 0,3 %. Praktisch nutzen es fast nur modernisierte Stacks. Kombiniert mit llms.txt entsteht der Pfad:

llms.txt entdecken → Markdown-URL fetchen → Passage zitieren

Ohne SSR/SSG und ohne saubere Canonicals bricht die Kette ab. Dann ist die Maschinenkarte nur Dekoration — siehe auch SSR/SSG-Stack und Technical-SEO-Basis.

Was der Census zu llms.txt und Markdown sagt

Antwort zuerst: llms.txt ist selten, Markdown-Negotiation extrem selten — beides ist setzbar, aber kein Nachweis für Sichtbarkeitsverlust bei Fehlen.

In der AI-Readiness-Studie (6.675 Audits deutscher Dienstleister-Webseiten) liegen die Maschinen-Layer weit hinter klassischen SEO-Dateien:

Lesart (hart): Legacy-CMS und Pagebuilder erklären teilweise, warum Maschinenoberflächen fehlen — Plugins liefern selten eine redaktionell sinnvolle llms.txt out of the box. Fehlen von llms.txt allein ist kein belegter Sichtbarkeitsverlust. Agent-Ready ≠ AI-Visibility: Readiness misst technische Extrahierbarkeit; Visibility misst tatsächliche Nennungen — Claims nicht vermischen. Details und Methodik: Studie; lokale Panels: Bad Schönborn, Bruchsal.

Die Referenz Mallorca Expats zeigt den Gegenentwurf nach Migration: llms.txt plus schlankes HTML — sinnvoll für Agenten-Discovery, nicht als Sichtbarkeits-Garantie.

Wie hängt llms.txt mit GEO und AI-Sichtbarkeit zusammen?

Antwort zuerst: GEO braucht zitierfähige HTML-Passagen; llms.txt ist Discovery-/Navigationshilfe — Princeton-Taktiken wirken auf dem Content, nicht in der Karte.

Generative Engines extrahieren Antworten aus Seiten — nicht aus einer selbstberichteten Linkliste. Princeton GEO (Aggarwal et al., arXiv:2311.09735) zeigt, dass Zitate, Statistiken und Quellen Sichtbarkeit in generativen Engines heben können — aber nur auf technisch extrahierbarer Basis. llms.txt beschleunigt, dass Agenten die richtigen URLs finden; sie erzeugt keine Direct Answers.

Reihenfolge bei Modern Stack:

1. Modernisierung / SSR-SSG + Crawlability
2. Answer-first Content, Entities, strukturierte Daten
3. llms.txt / llms.json + Markdown-Negotiation
4. optional Knowledge Graph und Conversion

Wer Schritt 3 vor Schritt 1 setzt, optimiert eine leere Karte. Vertiefung: GEO & AI-Sichtbarkeit, QI-GEO, Empirie GEO-Empirie 2026/2027. Der Agent-Ready-Score misst die technische Schicht — nicht, ob ChatGPT dich namentlich nennt.

GEO-Taktiken (Statistiken mit Jahr, namentliche Quellen, Answer-first) gehören auf die Seiten, die in llms.txt gelistet sind. Die Datei selbst sollte nüchtern bleiben: keine erfundenen Claims, keine „wir sind Marktführer“-Floskeln, keine Keyword-Staffelung. Sonst erzeugst du genau das Selbstlob-Signal, das Mueller als undifferenzierbar beschreibt — und Agenten, die die Karte lesen, bekommen Marketing statt Orientierung. List in llms.txt deshalb immer die kanonische Studien-URL (/studie) und zentrale Themen-Hubs, nicht dutzende UTM-Varianten. Agenten sollen die wenigen Seiten finden, die wirklich zitierfähig sind.

Abgrenzung: Ranking vs. Agent-Discovery vs. GEO

Brauche ich llms.json — und wie pflege ich beides im Betrieb?

Antwort zuerst: llms.json ist optional, aber nützlich für strukturiertes Parsing; beide Dateien müssen mit dem Live-Catalog mitziehen — tote Links sind FAIL.

llms.json ergänzt die Textdatei um strukturierte Metadaten (URLs, Titel, Sprachen), die Agenten parsen können, ohne Markdown zu interpretieren. Modern Stack generiert beide aus dem Content-Katalog — nicht handisch pro Release. Neue Studien, Regionen oder Glossar-Einträge ohne Update erzeugen veraltete Karten.

Betriebs-Checkliste vor Go-Live und nach Content-Updates:

1. /llms.txt und /llms.json erreichbar (Apex, HTTP 200, korrektes Canonical-Host)
2. Gelistete URLs liefern 200; keine Soft-404, keine Redirect-Ketten
3. Markdown-Negotiation: volle DE-Inhalte (+ EN-Felder im Frontmatter)
4. robots.txt blockiert relevante AI-Crawler nicht unnötig
5. Nach Updates: Catalog-Sync, Build, Smoke-Test der Apex-URLs; optional IndexNow für HTML-Seiten

Leere Plugin-Stubs ohne echte URLs signalisieren Nachlässigkeit — besser keine Datei als Placeholders. Pflege gehört in dieselbe Pipeline wie Sitemap und Schema, nicht in einen Freitag-17-Uhr-Hotfix.

Wann lohnt sich llms.txt — und wann nicht?

Antwort zuerst: Sinnvoll als Ergänzung auf einem crawlbarem Stack mit klaren Antwortseiten — sinnlos als alleinige „AI-SEO“-Maßnahme.

Sinnvoll bei: modernisiertem oder modernisierbarem Stack, klaren Leistungs-/Themen-URLs, Markdown-Pfad geplant oder live, Agenten-/B2A-Workflows, die Host-Karten lesen.

Allein zu wenig, wenn: die Webseite eine JS-Shell ist, Direct Answers fehlen, Crawler geblockt sind, oder du hoffst auf Google-Rankings über die Datei. Dann zuerst Webseite-Modernisierung und strukturierte Daten — danach die Maschinenkarte.

Für Branchen-Webseiten (Handwerk, Physio, Steuerberatung, Coaching) gilt dieselbe Logik wie im Census: Zuerst erreichbare, schnelle Seiten mit klarer Leistungsaussage, dann Maschinen-Layer. Eine llms.txt auf einem Baukasten ohne Markdown und ohne Schema ändert wenig an der Extrahierbarkeit — sie dokumentiert bestenfalls Absicht. Nach einem Stack-Wechsel wird sie dagegen billig und wertvoll: Catalog → Datei → Smoke-Test, ohne Plugin-Zoo.

Praxis-Checkliste und nächste Schritte

Vor dem Claim „wir sind agent-ready“ solltest du diese Punkte abhaken — sonst bleibt llms.txt Deko:

1. HTML-first Rendering (SSR/SSG), messbare Core Web Vitals
2. Answer-first H2s auf den Top-URLs, die in der Karte stehen
3. /llms.txt + optional /llms.json aus dem Catalog
4. Markdown-Negotiation ohne Stubs
5. robots/Allowlist für gewünschte KI-Fetcher
6. Census-Kontext verstehen: 15,6 % / 0,3 % sind Gaps — keine Panik-Metrik

Kurz: llms.txt ist Infrastruktur für Agenten-Navigation — Inhalte und Extrahierbarkeit entscheiden über Zitate. Einrichtung oder Audit: Anfrage stellen · info@modern-stack.de.

Weiterführend: ChatGPT-Sichtbarkeit, Crawlability, SSR/SSG-Stack, Webarchitektur im KI-Zeitalter, Glossar llms.txt.