llms.txt v2 und WebMCP: So machen Sie Ihre B2B-Website für KI-Agenten lesbar – und kontrollierbar

Zwischen dem 5. und dem 10. August 2026 haben sich für Betreiber kommerzieller Websites drei Dinge geändert, die nichts miteinander zu tun zu haben scheinen und doch zusammengehören: Shopify schaltete WebMCP für alle Liquid-Storefronts scharf, Cloudflare machte es einen Tag später per Dashboard-Schalter für jede Site hinter seinem Netz verfügbar, und Jeremy Howard veröffentlichte die erste Revision der llms.txt-Spezifikation seit ihrer Einführung 2024.

Die gemeinsame Klammer: Websites werden nicht mehr nur von Menschen und Suchmaschinen-Crawlern gelesen, sondern von KI-Agenten, die Inhalte verstehen und Aktionen auslösen sollen. llms.txt v2 kümmert sich um die erste Hälfte, WebMCP um die zweite. Dieser Beitrag zeigt, was Sie an Ihrer B2B-Website konkret ändern – und wo Sie besser die Bremse ziehen, weil die Datenlage schlicht dünn ist.

Was llms.txt v2 gegenüber v1 ändert

llms.txt ist eine Markdown-Datei im Wurzelverzeichnis Ihrer Domain, die einem Sprachmodell eine kuratierte Landkarte Ihrer Inhalte gibt: ein H1 mit dem Projektnamen, ein Blockquote mit der Kurzbeschreibung, danach H2-Abschnitte mit annotierten Linklisten. Das Format erschien am 3. September 2024. Die Seite llmstxt.org weist seitdem exakt eine Änderung aus: „modified Aug 10, 2026". Das ist v2 – eine Revision derselben Spezifikationsseite, kein neues Dokument und kein Neubau für bestehende Dateien.

Die substanzielle Neuerung sind zwei formale Link-Relationen. Bisher war die Beziehung zwischen einer HTML-Seite und ihrer Markdown-Fassung reine Namenskonvention – ein Agent musste raten. v2 macht sie explizit:

• rel="alternate" type="text/markdown" – zeigt von einer Seite auf ihre Markdown-Fassung.
• rel="describedby" – zeigt von einer Seite auf die für sie zuständige llms.txt.

Dazu kommen drei kleinere, in der Praxis aber sehr relevante Klarstellungen. Erstens erlaubt v2 zwei URL-Muster für Markdown-Zwillinge: das Anhängen (/docs/tutorial.html.md, in v1 das einzig zulässige) oder das Ersetzen der Endung (/docs/tutorial.md); für Verzeichnispfade entsprechend index.html.md oder index.md. Beide sind gültig, damit unterschiedliche CMS und Static-Site-Generatoren teilnehmen können, ohne ihr Routing umzubauen.

Zweitens gilt eine llms.txt jetzt ausdrücklich für die Seiten unterhalb ihres Pfads, und die spezifischste Datei gewinnt. Wer nur ein Unterverzeichnis kontrolliert – typisch für ein Doku-Portal unter /docs/ oder einen Produktbereich in einem größeren Konzernauftritt – kann damit teilnehmen, ohne Zugriff auf das Domain-Root zu brauchen.

Drittens hat v2 das Referenz-Tooling llms_txt2ctx aus dem Vorschlag entfernt. Der Abschnitt „Optional" trägt dadurch keine mechanische Semantik mehr – er bleibt konventionell als Sammelplatz für sekundäre Links nützlich, aber kein Werkzeug schneidet ihn mehr automatisch weg. Und die Spezifikation beschreibt nicht mehr spekulativ, wie Sprachmodelle Websites nutzen könnten, sondern wie Agenten sie tatsächlich nutzen: llms.txt lesen oder durchsuchen, dann den Links zu LLM-freundlichen Inhalten folgen.

Aspekt	v1 (03.09.2024)	v2 (10.08.2026)
Verknüpfung Seite ↔ Markdown	Namenskonvention, nicht deklariert	rel="alternate" type="text/markdown"
Verweis auf llms.txt	nur implizit über /llms.txt im Root	rel="describedby"
URL-Muster Markdown-Zwilling	1 Muster: tutorial.html.md	2 Muster: .html.md oder .md
Geltungsbereich	faktisch Domain-Root	Subpath, spezifischste Datei gewinnt
Auslieferungswege	Datei im Root	Datei + HTML-link + HTTP-Link-Header
Referenz-Tooling	llms_txt2ctx Teil des Vorschlags	entfernt, „Optional" ohne Mechanik

Ausliefern: HTML-Link-Element oder HTTP-Header

Beide Wege sind in v2 gleichwertig spezifiziert. Welcher besser passt, entscheidet Ihre Infrastruktur – nicht Ihre Ästhetik.

Weg A: link-Element im head

Der naheliegende Weg für statische Seiten und alles, was ein zentrales Template hat. Zwei Zeilen, ausgeliefert mit jeder Seite:

<link rel="alternate" type="text/markdown" href="/docs/tutorial.md">
<link rel="describedby" href="/docs/llms.txt">

Vorteil: sichtbar im Quelltext, trivial zu prüfen, keine Server-Konfiguration nötig. Nachteil: Sie brauchen Zugriff auf das Template jeder Seitengattung, und für Nicht-HTML-Ressourcen – PDF-Datenblätter, JSON-Endpunkte, Bilder – funktioniert es gar nicht.

Weg B: HTTP-Link-Response-Header

Der Header-Weg ist der mächtigere. Die Spezifikation nennt ihn in dieser Form:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown",
      </docs/llms.txt>; rel="describedby"

Das lässt sich zentral auf Server- oder CDN-Ebene setzen, ohne eine einzige Seite anzufassen – in nginx mit add_header Link in einem location-Block, in Apache mit Header set Link, bei Cloudflare in einer Transform Rule oder einem Worker. Und es funktioniert für beliebige Ressourcentypen, also auch für die PDF-Datenblätter, die in vielen Maschinenbau-Auftritten den eigentlichen Informationswert tragen.

Wichtig in beiden Fällen: Die Markdown-Datei muss mit Content-Type: text/markdown; charset=utf-8 ausgeliefert werden. Viele Webserver liefern .md per Default als text/plain oder – schlimmer – als application/octet-stream aus, was manche Clients zum Download-Dialog statt zur Verarbeitung bewegt. Prüfen Sie das, bevor Sie irgendetwas anderes tun.

Markdown-Zwillinge aus dem eigenen CMS erzeugen

Die Link-Relationen sind wertlos, wenn dahinter keine saubere Markdown-Fassung liegt. Und genau hier scheitern die meisten Umsetzungen – weil ein zweiter Pflegepfad entsteht, der nach drei Monaten veraltet ist.

Die Regel lautet: ein Quelldokument, zwei Ausgabeformate. Die Markdown-Fassung wird aus derselben Quelle gerendert wie das HTML, im selben Build-Schritt, mit demselben Deployment. Wenn Ihr CMS strukturierte Inhalte speichert – Headless-CMS, Markdown-Frontmatter, ein Datenbankfeld mit Rich Text – ist das ein zusätzlicher Renderer, keine zweite Redaktion.

Was in die Markdown-Fassung nicht gehört: Navigation, Footer, Cookie-Banner, Newsletter-Einschübe, „Das könnte Sie auch interessieren"-Blöcke, Werbung, Social-Buttons. Diese Boilerplate ist genau der Ballast, den ein Agent sonst durch das Kontextfenster schleppt. Was hineingehört: H1, Fließtext, Listen, Tabellen, Codeblöcke, sinnvolle Alt-Texte und – wichtig – absolute oder korrekt aufgelöste Links, damit der Agent von der Markdown-Fassung aus weiterspringen kann.

Von SaaS-Generatoren, die Ihre Site crawlen und daraus eine llms.txt bauen, raten wir ab. Sie erzeugen einen Snapshot, der ab dem nächsten Deployment falsch ist, und sie schicken Ihre Inhaltsstruktur durch einen fremden Dienst. Ein Build-Schritt im eigenen CI kostet einmalig ein paar Stunden und ist danach wartungsfrei.

Was llms.txt bringt – und was nicht

Hier muss man ehrlich sein, auch wenn es der Artikelprämisse widerspricht. Die Wirkungsbelege für llms.txt sind dünn.

Google Search ignoriert die Datei. Die Search-Central-Dokumentation ist an dem Punkt unmissverständlich: Man braucht „kein spezielles AI-Markup und keine llms.txt-Datei", um in Googles generativen Sucherlebnissen sichtbar zu sein; die Datei schadet weder, noch hilft sie Sichtbarkeit oder Rankings. Support steht nicht auf der Agenda. Die v2-Revision hat daran nichts geändert. Wer llms.txt als SEO-Maßnahme verkauft, verkauft Ihnen etwas Falsches.

Chrome behandelt sie als optional. Lighthouse hat seit etwa Mai 2026 eine Kategorie „Agentic Browsing" im Audit. Der Check versucht, die Datei abzurufen, und meldet Serverfehler – eine fehlende Datei (HTTP 404) wird als N/A gewertet, nicht als Fehlschlag. Ihr Lighthouse-Score leidet also nicht, wenn Sie nichts tun.

Es gibt keine öffentliche Nutzungsmessung. Bis heute existiert keine belastbare Erhebung, dass KI-Crawler llms.txt auf beliebigen Sites tatsächlich abrufen. Weder Anbieter- noch Analystendaten quantifizieren Verbreitung oder Zugriffe; die Rede ist von „tausenden Sites", ohne dass jemand die Abrufseite gemessen hätte.

Was bleibt, ist trotzdem nicht nichts. Der belastbare Nutzen liegt in den Markdown-Zwillingen selbst: Ein Agent, der 4.000 Zeichen strukturierten Text verarbeitet statt 90.000 Zeichen HTML mit Navigation, Inline-Styles und Tracking-Skripten, arbeitet nachweislich sparsamer und präziser – unabhängig davon, ob er den Weg über llms.txt oder über einen Link im Suchergebnis gefunden hat. Und der Aufwand für v2 ist, wenn die Zwillinge einmal stehen, eine Frage von zwei Template-Zeilen. Das ist ein günstiges Verhältnis, auch ohne Rankingversprechen.

WebMCP: Ihre Website ist möglicherweise schon eine Werkzeugkiste

WebMCP bringt die Idee des Model Context Protocol in den Browser. Statt dass ein Agent Ihre Seite per Screenshot analysiert, Elemente errät und Klicks simuliert, registriert Ihre Seite selbst Werkzeuge: benannte, beschriebene Funktionen mit einem JSON-Schema für die Parameter. Der Agent liest die Werkzeugliste und ruft auf, was er braucht – klassisches Tool Use, nur eben von der Website deklariert statt von einem Server.

Die Zeitleiste erklärt, warum das im August 2026 plötzlich überall auftauchte:

Datum	Ereignis
28.08.2025	Microsoft schlägt WebMCP vor
10.02.2026	Erster W3C-Draft aus der Web Machine Learning Community Group (Ingenieure von Google und Microsoft)
15.05.2026	„Intent to Experiment" in Chromium eingereicht, drei Tage später genehmigt
18./19.05.2026	Ankündigung des öffentlichen Origin Trials auf der Google I/O; Laufzeit Chrome 149 bis 156 (Chrome 146 hatte die API nur hinter einem Flag)
05.08.2026	Shopify aktiviert WebMCP standardmäßig für jede Liquid-Storefront und die Hydrogen-Developer-Preview
06.08.2026	Cloudflare stellt WebMCP als Developer Preview für jede Site hinter seinem Netz bereit – Schalter im Dashboard, ohne Code-Änderung

Cloudflares Formulierung war bemerkenswert direkt: „Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin." Technisch laufen die Tools der Preview vollständig im Browser des Besuchers, ohne Server-Roundtrip; Sessions und Credentials bleiben am Origin des Betreibers, das HTML wird lediglich an der Edge um die Tool-Registrierung ergänzt.

Tools registrieren: zwei Wege

Der kanonische Einstiegspunkt heißt seit Sommer 2026 document.modelContext. Der frühere Getter navigator.modelContext ist ab Chrome 150 als deprecated markiert und bleibt während des Origin Trials vorerst als Alias erhalten – neuer Code sollte ihn nicht mehr verwenden. Die imperative Registrierung sieht so aus:

document.modelContext.registerTool({
  name: "verfuegbarkeit_pruefen",
  description: "Prüft die Lagerverfügbarkeit für eine Artikelnummer.",
  inputSchema: {
    type: "object",
    properties: {
      artikelnummer: { type: "string", pattern: "^[A-Z]{2}-[0-9]{5}$" },
      stueckzahl:    { type: "integer", minimum: 1, maximum: 500 }
    },
    required: ["artikelnummer", "stueckzahl"]
  },
  async execute({ artikelnummer, stueckzahl }) {
    const r = await fetch("/api/lager?a=" + encodeURIComponent(artikelnummer));
    const d = await r.json();
    return { content: [{ type: "text",
      text: d.bestand >= stueckzahl ? "verfuegbar" : "nicht verfuegbar" }] };
  }
});

Ergänzend spezifiziert sind getTools() und executeTool(). Der zweite, für bestehende Auftritte oft attraktivere Weg ist die deklarative Annotation vorhandener HTML-Formulare über Attribute wie toolname und tooldescription – damit wird ein Kontaktformular oder eine Produktsuche zum Werkzeug, ohne dass Sie eine API dahinter neu bauen. Dass die Parameter über ein JSON-Schema beschrieben werden, ist derselbe Mechanismus, den Sie vom JSON-Mode und von Function-Calling kennen.

Zur Effizienz: Belastbare Zahlen gibt es nicht. Mehrere unabhängige Quellen – Cloudflares eigener Blog eingeschlossen – halten ausdrücklich fest, dass keine quantifizierten Token- oder Performance-Werte veröffentlicht sind. Qualitativ ist der Effekt trotzdem klar: Ein strukturierter Tool-Aufruf ersetzt Dutzende Screenshot-Analyse-Klick-Zyklen. Cloudflare formuliert es als „Tokens für Aufgaben statt für Navigation". Wer Ihnen eine Prozentzahl nennt, hat sie erfunden.

Sicherheitsfolgen: fremde Agenten lösen Aktionen aus

Sobald Ihre Seite Werkzeuge anbietet, gelten dieselben Risiken wie für einen Server-seitigen MCP-Endpunkt – nur dass der Aufrufer ein Agent ist, den Sie nicht kontrollieren und dessen Betreiber Sie nicht kennen.

Das anerkannte Kernrisiko ist Prompt Injection. Die Formulierung aus der Diskussion um die Spezifikation trifft es genau: Ein WebMCP-Tool übergibt eine Intent-Level-API an ein Sprachmodell, das nicht vertrauenswürdige Inhalte liest. Ein präparierter Text auf einer anderen Seite, in einer E-Mail oder in einem Produktkommentar kann den Agenten dazu bringen, Ihre Werkzeuge anders zu benutzen als vom Nutzer beabsichtigt. Das verwandte Muster – Tool Poisoning, also manipulierte Werkzeugbeschreibungen – kennt man aus Server-MCP-Deployments.

Das Browser-Sicherheitsmodell mildert das, ersetzt aber keine eigenen Kontrollen: Tools laufen sequenziell, Formulare erfordern standardmäßig eine manuelle Absendung durch den Nutzer, und der Nutzer kann den Agentenzugriff einsehen. Belegte Vorfälle oder Breach-Daten gibt es bislang nicht – was angesichts der Verfügbarkeit erst seit August 2026 wenig aussagt.

Vier Maßnahmen, die wir bei jedem Setup verlangen:

1. Authentifizierung und Rate-Limits je Tool. Nicht pro Seite, nicht pro IP allein – pro Werkzeug. Ein lesendes produkt_suchen verträgt 60 Aufrufe pro Minute, ein schreibendes angebot_anfordern vielleicht drei pro Stunde und Session.
2. Keine zustandsändernden Tools ohne explizite Bestätigung. Alles, was etwas anlegt, verschickt, bucht oder bezahlt, braucht einen Nutzerschritt im Browser. Read-only-Werkzeuge dürfen frei laufen, schreibende nie.
3. Serverseitige Validierung, immer. Das JSON-Schema ist eine Beschreibung für den Agenten, keine Sicherheitsgrenze. Jeder Parameter wird am Origin erneut geprüft – so, als käme er aus einem manipulierten Client. Er kommt aus einem manipulierbaren Client.
4. Audit-Log auf eigener Infrastruktur. Wer hat wann welches Werkzeug mit welchen Parametern aufgerufen? Dieses Protokoll gehört in Ihr System, nicht ausschließlich in das Dashboard eines CDN-Anbieters. Für den Nachweis gegenüber Datenschutzaufsicht und Revision brauchen Sie exportierbare, von Ihnen kontrollierte Daten – dieselbe Logik, die auch beim KI-Gateway und beim On-Premise-Betrieb gilt.

Umstellung in einer Stunde: die Checkliste

Ehrlich zweigeteilt, weil die beiden Themen unterschiedlich viel Arbeit machen. llms.txt v2 ist tatsächlich Stundenarbeit. WebMCP ist es nur, wenn Sie auf Shopify laufen oder hinter Cloudflare sitzen – eine eigene Tool-Registrierung per document.modelContext ist Entwicklungsarbeit von Tagen bis Wochen, inklusive Sicherheitsabnahme.

Teil 1: Bestandsaufnahme (15 Minuten)

1. Prüfen, ob WebMCP bereits ausgeliefert wird: Seite in Chrome öffnen, DevTools-Konsole, document.modelContext?.getTools?.() ausführen. Kommt eine Werkzeugliste zurück, bietet Ihre Site bereits Aktionen an – prüfen Sie sofort, welche.
2. Bei Cloudflare zusätzlich im Dashboard nachsehen, ob der WebMCP-Schalter aktiv ist. Bei Shopify gilt: aktiv, sofern nicht ausdrücklich deaktiviert.
3. curl -sI https://ihre-domain.de/llms.txt – existiert die Datei, und mit welchem Status?

Teil 2: llms.txt auf v2 (30–45 Minuten)

1. llms.txt anlegen oder aktualisieren: H1 mit Firmenname, Blockquote mit einem Satz Kurzbeschreibung, H2-Abschnitte mit annotierten Links auf die wichtigsten 30 bis 100 Seiten. Jeder Link bekommt einen Halbsatz Kontext.
2. Markdown-Zwillinge erzeugen – Build-Schritt, nicht Handarbeit. Muster wählen (.md oder .html.md) und konsequent durchhalten.
3. Content-Type: text/markdown; charset=utf-8 für .md konfigurieren.
4. Beide Link-Relationen setzen – im Template oder als HTTP-Header.
5. Bei mehreren Bereichen: eigene llms.txt je Unterpfad, Subpath-Regel nutzen.

Teil 3: Verifikation (15 Minuten)

1. curl -sI https://ihre-domain.de/docs/tutorial.md – Status 200 und korrekter Content-Type?
2. curl -sI https://ihre-domain.de/docs/tutorial.html | grep -i '^link:' beziehungsweise Quelltext auf die beiden link-Elemente prüfen.
3. Lighthouse mit der Kategorie „Agentic Browsing" laufen lassen. Erwartung: kein Serverfehler. Ein N/A für fehlende Dateien ist kein Mangel.
4. Markdown-Fassung im Browser öffnen und lesen: Steht dort Inhalt oder Navigation? Wenn Navigation, war der Renderer falsch konfiguriert.

Teil 4: WebMCP – bewusst entscheiden

Wenn Tools bereits ausgeliefert werden, ist die Frage nicht „einschalten?", sondern „welche und mit welchen Grenzen?". Inventarisieren Sie die vorhandenen Werkzeuge, deaktivieren Sie alle zustandsändernden ohne Bestätigungsschritt, ziehen Sie Rate-Limits ein und richten Sie das Audit-Log ein. Wenn Sie eigene Tools bauen wollen, planen Sie das wie eine öffentliche MCP-Integration: Schnittstellendesign, Schema, Authentifizierung, Abnahme – und erst dann Registrierung im Frontend.

Unsere Empfehlung für den typischen B2B-Auftritt im Mittelstand: llms.txt v2 und saubere Markdown-Zwillinge jetzt umsetzen – geringer Aufwand, kein Risiko, klarer Nutzen im Agentenkontext. WebMCP zunächst nur prüfen und absichern, eigene schreibende Werkzeuge erst dann, wenn ein konkreter Anwendungsfall den Aufwand trägt und die Sicherheitsfragen beantwortet sind.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. llmstxt.org Spezifikation, Published Sept 3 2024 / modified Aug 10 2026
2. llmstxt.org/changes Änderungen von v1 zu v2 im Detail
3. searchenginejournal.com llms.txt v2, formale Markdown-Verlinkung, Google-Position
4. refontelearning.com Umsetzungspraxis llms.txt, Lighthouse-Check
5. blog.cloudflare.com WebMCP Developer Preview, 06.08.2026, Edge-Injektion ohne Origin-Änderung
6. infoq.com Einordnung des Cloudflare-Rollouts, keine quantifizierten Effizienzwerte
7. nohacks.co WebMCP-Grundlagen, registerTool, deklarative Formular-Annotation
8. nohacks.co Shopify-Aktivierung 05.08.2026, Anbieterreaktionen
9. spronta.com Zeitleiste, Origin Trial Chrome 149–156, Browser-Status
10. github.com/webmachinelearning/webmcp W3C-Draft, document.modelContext, getTools/executeTool

Häufig gestellte Fragen zu llms.txt v2 und WebMCP

Brauche ich llms.txt überhaupt, wenn Google es ignoriert?

Google erklärt, Support stehe nicht auf der Agenda, und die Datei helfe und schade dem Ranking nicht. Andere KI-Anbieter nutzen sie aktiv - der Aufwand für v2 ist gering, der Nutzen liegt außerhalb der klassischen Suche.

Was ist der Unterschied zwischen llms.txt und WebMCP?

llms.txt beschreibt Inhalte maschinenlesbar. WebMCP stellt ausführbare Werkzeuge bereit, mit denen ein Agent auf Ihrer Seite Aktionen auslöst.

Liefert meine Seite WebMCP bereits aus?

Möglicherweise ja - bei Shopify-Storefronts und Websites hinter Cloudflare wurde es Anfang August 2026 ohne Code-Änderung aktiviert. Prüfen Sie das aktiv.

Wie sichere ich WebMCP-Tools ab?

Wie jede öffentliche Schnittstelle: Authentifizierung, Rate-Limits, keine zustandsändernden Aktionen ohne Bestätigung und ein Audit-Log auf eigener Infrastruktur.