Agentic Browsing & llms.txt: Ist deine Website bereit für KI-Agenten?

Seit Lighthouse 13.3 prüft Google per Kategorie Agentic Browsing, ob deine Website KI-Agenten-bereit ist. Was der Audit checkt und wie du llms.txt richtig aufsetzt.

Seit dem 7. Mai 2026 prüft Google etwas Neues an deiner Website. In Lighthouse 13.3, dem Audit-Werkzeug hinter den Chrome DevTools und PageSpeed Insights, gibt es eine zusätzliche Kategorie neben Performance, SEO und Best Practices: Agentic Browsing. Sie misst nicht, wie deine Seite für Menschen aussieht. Sie misst, wie gut KI-Agenten mit ihr arbeiten können.

Das ist keine Spielerei für Tech-Konzerne. KI-Agenten wie Perplexity Comet, OpenAI Atlas oder die Claude-Browser-Erweiterung surfen heute im Auftrag von Nutzern: Sie recherchieren, vergleichen Anbieter, füllen Formulare aus und schließen Käufe ab. Wenn deine Website für diese Agenten schwer lesbar ist, fällt sie aus deren Empfehlungen heraus. Dieser Artikel zeigt dir, was der Audit genau prüft, wie du ihn selbst durchführst, wie du eine korrekte llms.txt aufsetzt und warum es dabei einen handfesten Widerspruch bei Google gibt, den du kennen solltest.

Was ist Agentic Browsing, und warum prüft Google das plötzlich?

Ein KI-Agent liest eine Website anders als ein Mensch. Er sieht kein Layout, keine Farben, keine Bilder im klassischen Sinn. Er greift auf die Struktur zu: den Accessibility-Tree, die Überschriften-Hierarchie, die Beschriftungen von Buttons und Formularfeldern. Genau dieselbe Datenbasis, die auch ein Screenreader für blinde Nutzer verwendet. Ist diese Struktur sauber, kann der Agent zuverlässig handeln. Ist sie chaotisch, rät er oder bricht ab.

Mit Lighthouse 13.3 hat Google die Kategorie Agentic Browsing aus dem experimentellen Status in die Standard-Konfiguration übernommen. In Chrome ab Version 150 erscheint sie ohne weiteres Zutun in den DevTools, und seit Ende Mai 2026 liefert auch PageSpeed Insights unter pagespeed.web.dev entsprechende Ergebnisse. Die Kategorie ist laut Chrome-Dokumentation ausdrücklich "in Entwicklung" und basiert auf vorgeschlagenen Standards. Sie bekommt deshalb bewusst keine 0-bis-100-Note, sondern zeigt eine Pass-Quote: wie viele der Einzelchecks bestanden sind.

Der Grund für das Timing ist simpel. Der Anteil automatisierter, agentischer Zugriffe auf Websites ist im letzten Jahr um 7.851 Prozent gestiegen, so der State-of-Agentic-Traffic-Report von HUMAN Security (April 2026). Google bereitet das Web auf eine Zukunft vor, in der ein erheblicher Teil der Besucher gar keine Menschen mehr sind, sondern Agenten, die für Menschen arbeiten.

Den Test selbst machen: Schritt für Schritt

Du brauchst kein Tool zu kaufen und keinen Entwickler. Es gibt drei Wege, deine Website sofort zu prüfen.

Weg 1: Chrome DevTools (ab Chrome 150). Öffne die Seite, die du testen willst. Drücke F12 für die DevTools, wechsle in den Reiter "Lighthouse" (eventuell hinter dem Pfeil-Symbol versteckt), achte darauf, dass die Kategorie "Agentic Browsing" angehakt ist, und klicke auf "Analyze page load". Nach dem Durchlauf findest du den Abschnitt Agentic Browsing im Report mit der Pass-Quote und den einzelnen Checks.

Weg 2: PageSpeed Insights (ohne Chrome-Update). Wenn du kein Chrome 150 hast, öffne pagespeed.web.dev, gib deine URL ein und starte die Analyse. Den Agentic-Browsing-Abschnitt findest du im Ergebnis weiter unten. Das ist der einfachste Weg für alle, die nichts installieren wollen.

Weg 3: Lighthouse über die Kommandozeile (für Entwickler). Mit Node.js installierst du Lighthouse per npm und lässt es gegen deine URL laufen. Ab Version 13.3 ist die Kategorie in der Standard-Konfiguration enthalten. Praktisch, wenn du den Check in eine Deployment-Pipeline einbauen willst.

Die Pass-Quote zeigt die bestandenen von den jeweils anwendbaren Checks. zenku.studio steht im Screenshot oben bei 3 von 3, seit die Seite eine saubere llms.txt hat. Viele KMU-Websites landen ohne diese Datei zunächst bei 1 von 2, weil die llms.txt fehlt und WebMCP noch fast niemand umsetzt. Genau darin liegt die Chance: Der Rückstand ist in etwa einer Stunde aufgeholt.

Die vier Prüfbereiche im Detail

Die Kategorie gruppiert ihre Checks in vier Bereiche. Hier ist, was jeder einzelne verlangt und wie du ihn bestehst.

Prüfbereich	Was geprüft wird	So bestehst du
llms.txt	Maschinenlesbare Zusammenfassung am Domain-Root	Datei unter /llms.txt mit H1, mind. 50 Zeichen und mind. einem Markdown-Link
Accessibility-Tree	Namen, Labels, Baum-Integrität, Sichtbarkeit interaktiver Elemente	Jeder Button und jedes Formularfeld hat einen programmatischen Namen, saubere ARIA-Rollen
Layout-Stabilität	Cumulative Layout Shift (CLS)	CLS unter 0,1, kein springendes Layout beim Laden
WebMCP	Strukturierte Tools, die Agenten direkt aufrufen können	2026 noch experimentell. Ein Fehlschlag ist hier laut Google ausdrücklich okay

1. llms.txt: die maschinenlesbare Zusammenfassung

Lighthouse prüft drei Dinge an deiner llms.txt. Erstens muss die Datei eine Markdown-H1 enthalten, also eine Zeile, die mit einem Rautezeichen und dem Namen deiner Website beginnt. Zweitens muss sie mindestens 50 Zeichen lang sein. Drittens muss sie mindestens einen echten Markdown-Link im Format eckige-Klammern-Text-runde-Klammern-URL enthalten. Eine nackte URL zählt nicht.

Wichtig für die Bewertung: Fehlt die Datei komplett (HTTP 404), wertet Lighthouse das als "nicht zutreffend", nicht als Durchfall. Liefert dein Server dagegen einen echten Fehler (HTTP 5xx), gilt der Check als nicht bestanden. Erfüllt die Datei eine der drei Formatregeln nicht, erscheint der Hinweis "folgt nicht den Empfehlungen". Wie du die Datei korrekt aufbaust, zeige ich dir im nächsten Abschnitt mit einer kompletten Vorlage.

2. Accessibility-Tree: dieselbe Basis wie für Screenreader

KI-Agenten nutzen den Accessibility-Tree als primäres Modell, um eine Seite zu verstehen. Lighthouse filtert dafür eine Teilmenge seiner ohnehin vorhandenen Accessibility-Checks heraus, die für maschinelle Interaktion kritisch sind: Hat jeder Button, jeder Link und jedes Eingabefeld einen programmatischen Namen? Sind die ARIA-Rollen korrekt und der Baum sauber verschachtelt? Sind interaktive Elemente sichtbar und fokussierbar?

Die gute Nachricht: Wenn deine Website die normalen Lighthouse-Accessibility-Audits schon gut besteht, bestehst du diesen Bereich mit hoher Wahrscheinlichkeit. Es sind keine neuen Anforderungen, sondern bekannte Barrierefreiheits-Grundlagen, neu gerahmt für Agenten. Wer hier sauber arbeitet, hilft also blinden Nutzern und KI-Agenten gleichzeitig. Diese strukturelle Sauberkeit ist auch Teil jedes ordentlichen Technical-SEO-Audits.

3. Layout-Stabilität: warum springende Seiten Agenten verwirren

Cumulative Layout Shift kennst du aus den Core Web Vitals. Hier taucht die Metrik wieder auf, weil Agenten, die zur Orientierung Screenshots einer Seite machen, von einem während des Ladens springenden Layout durcheinandergebracht werden. Der Schwellenwert ist derselbe wie bei den Core Web Vitals: Ein CLS unter 0,1 gilt als gut. Wer seine Ladeperformance ohnehin im Griff hat, hat auch diesen Punkt erledigt.

4. WebMCP: das Protokoll der Zukunft

WebMCP steht für Web Model Context Protocol, eine experimentelle, browser-native Schnittstelle, die Google und Microsoft im Februar 2026 vorgestellt und im W3C-Umfeld als Entwurf veröffentlicht haben. Die Idee: Eine Website stellt ihre Aktionen wie Suche, Buchung oder In-den-Warenkorb als strukturierte Werkzeuge bereit, die ein Agent direkt aufrufen kann, statt mühsam Screenshots zu interpretieren.

Es gibt zwei Wege, das umzusetzen: deklarativ über HTML-Attribute an Formularen (Attribute, die mit data-webmcp beginnen) oder imperativ über eine JavaScript-Methode (navigator.modelContext.registerTool). Verbreitet ist davon 2026 noch fast nichts. WebMCP läuft im Chrome-149-Origin-Trial, getestet wird es von Größen wie Booking.com, Expedia und Shopify. Die Lighthouse-Dokumentation sagt selbst, dass dieser Check heute auf fast jeder Seite fehlschlägt und das in Ordnung ist. Du musst hier also aktuell nichts tun, solltest aber wissen, wohin die Reise geht.

llms.txt erstellen: komplette Anleitung mit Vorlage

Die llms.txt wurde im September 2024 von Jeremy Howard vorgeschlagen. Der Gedanke dahinter: Das Kontextfenster eines Sprachmodells ist zu klein, um eine ganze Website zu erfassen. Du als Betreiber weißt aber am besten, welche Informationen zählen. Die llms.txt ist deine kuratierte Zusammenfassung, abgelegt unter deinedomain.de/llms.txt.

Die Spezifikation ist schlank. Pflicht ist nur die H1 mit dem Namen der Website. Empfohlen sind ein Blockquote mit einer Kurzbeschreibung sowie H2-Abschnitte mit Linklisten zu deinen wichtigsten Seiten. So sieht eine vollständige, spec-konforme Datei für ein deutsches Dienstleistungsunternehmen aus:

Die Regeln im Detail: Die H1 ganz oben ist Pflicht. Das mit einem Größer-als-Zeichen eingeleitete Blockquote ist die Kurzsummary für das Modell. Die H2-Abschnitte gruppieren Links im Format Text in eckigen Klammern, URL in runden Klammern, danach optional ein Doppelpunkt und eine kurze Notiz. Ein Abschnitt mit dem reservierten Namen "Optional" enthält Links, die ein Modell bei knappem Kontext weglassen darf. Lege die Datei im Root-Verzeichnis ab, sodass sie unter deinedomain.de/llms.txt erreichbar ist.

Bei WordPress legst du die Datei am einfachsten über ein kleines Snippet oder ein SEO-Plugin an, das eigene Dateien im Root ausliefert. Bei statischen Seiten oder Astro legst du sie in den public-Ordner. Ein Beispiel siehst du übrigens live unter zenku.studio/llms.txt, gebaut nach genau diesen Regeln. Nach dem Hochladen validierst du das Ergebnis mit dem Lighthouse-Audit oder rufst die URL einfach im Browser auf.

Der Google-Widerspruch: kein Ranking-Signal, trotzdem geprüft

Jetzt kommt der Punkt, der die meisten verwirrt, und den kein anderer deutscher Artikel sauber auflöst. Google Search sagt klar, dass llms.txt für die Suche keine Rolle spielt. John Mueller aus dem Search-Relations-Team verglich die Datei mit dem alten Keywords-Meta-Tag, das Suchmaschinen ignorieren, und sagte sinngemäß, für die Suche werde das nicht ausgewertet. Gary Illyes ergänzte, Google unterstütze llms.txt nicht und habe das auch nicht vor.

Gleichzeitig prüft Lighthouse, ebenfalls ein Google-Produkt, die Datei aktiv. Wie passt das zusammen? Es sind zwei verschiedene Teams mit zwei verschiedenen Zielen. Das Search-Team spricht über Rankings und AI Overviews in der Google-Suche, dort zählt llms.txt nicht. Das Chrome-Team optimiert für browserbasierte KI-Agenten, die Aufgaben erledigen, und dort hilft die Datei. Beide Aussagen sind gleichzeitig wahr. Search Engine Land hat diese Inkonsistenz dokumentiert und kommt zum gleichen Schluss: Die Audits zielen auf Agenten und Browser-Werkzeuge, nicht auf Google-Rankings.

Die Konsequenz für dich: Setze eine llms.txt nicht auf, weil du dir bessere Google-Rankings davon versprichst. Die gibt es dadurch nicht. Setze sie auf, weil KI-Agenten und KI-Suchdienste deine Seite damit besser verstehen und dich eher als Quelle heranziehen. Das ist dieselbe Logik wie bei der Optimierung für KI-Antworten, die wir im Detail im Artikel zu GAIO und KI-Suche behandeln. Beide Themen sind Teil einer modernen SEO-Strategie für KMU, die über klassische Rankings hinausdenkt.

Wie ernst ist das? Die Zahlen zum Agenten-Traffic

Die Skepsis ist berechtigt: Lohnt sich der Aufwand für etwas, das heute kaum jemand nutzt? Die Wachstumszahlen sprechen eine deutliche Sprache. Der agentische Traffic ist binnen eines Jahres um 7.851 Prozent gestiegen. Den größten Anteil halten dabei agentische Browser: Perplexity Comet liegt bei rund 48 Prozent der beobachteten Agenten-Aktivität, OpenAI Atlas bei 21 Prozent, die Claude-Browser-Erweiterung bei 17 Prozent.

Beim Einkaufen ist der Trend noch deutlicher. Laut Salesforce nutzen 45 Prozent der Konsumenten KI für mindestens einen Teil ihrer Kaufentscheidung. McKinsey beobachtet, dass Besucher, die über KI-Dienste auf eine Seite kommen, 38 Prozent kaufbereiter sind als über klassische Kanäle. ChatGPT verarbeitet nach eigenen Angaben rund 50 Millionen Shopping-Anfragen pro Tag, und für 2026 werden KI-getriebene Einkäufe im Handel auf rund 20,9 Milliarden Dollar geschätzt.

Heute macht agentischer Traffic für die meisten Websites noch einen kleinen Anteil aus. Aber die Kurve ist steil, und der Vorbereitungsaufwand ist gering. Wer jetzt eine saubere Grundlage schafft, ist vorbereitet, bevor der Wettbewerb überhaupt merkt, dass sich etwas verändert hat.

Checkliste nach Website-Typ: Was musst du wirklich tun?

Nicht jede Website braucht dasselbe. Hier die konkreten Prioritäten nach Geschäftstyp.

Lokales Dienstleistungsunternehmen (Handwerk, Praxis, Kanzlei): Setze eine llms.txt mit deinen Leistungen, deinem Einzugsgebiet und der Kontaktseite auf. Achte darauf, dass deine Kontaktdaten und Öffnungszeiten als sauberer Text vorliegen, nicht nur als Bild. Das deckt fast den gesamten relevanten Nutzen für dein Geschäft ab.

Onlineshop (WooCommerce, Shopify): llms.txt mit Kategorien und wichtigen Info-Seiten (Versand, Rückgabe, Kontakt). Produktseiten brauchen saubere, beschriftete Buttons (In den Warenkorb, Variantenauswahl) und ein stabiles Layout ohne Sprünge. Hier wird WebMCP mittelfristig am wichtigsten, weil Agenten künftig direkt Käufe auslösen sollen.

B2B-Dienstleister oder SaaS: llms.txt mit Leistungen, Referenzen und Kontakt. Lege Wert auf gut strukturierte, in den Lesefluss eingebettete Inhalte, denn Agenten zitieren dich als Quelle, wenn deine Seite ein Thema klar und vollständig abdeckt. Das verbindet sich direkt mit einer durchdachten Content-Cluster-Strategie.

Was alle drei gemeinsam brauchen: semantisches HTML, programmatische Namen für alle interaktiven Elemente und ein CLS unter 0,1. Das sind keine exotischen Anforderungen, sondern solide Webhandwerk-Grundlagen, die nebenbei deine Barrierefreiheit und deine Core Web Vitals verbessern.

Häufige Fehler beim Agentic-Browsing-Audit

Vier Stolpersteine sehen wir immer wieder. Erstens: eine llms.txt ohne H1, ohne Link oder unter 50 Zeichen. Sie existiert, besteht den Check aber nicht. Zweitens: ein Serverfehler beim Abrufen der Datei, etwa durch eine falsche Weiterleitung. Das wertet Lighthouse als echten Durchfall, schlimmer als eine fehlende Datei. Drittens: ein hoher CLS durch nachladende Banner, Werbeflächen oder Schriften. Viertens: Buttons und Formularfelder ohne erkennbaren Namen, oft bei reinen Icon-Buttons oder selbstgebauten Dropdowns.

Häufige Fragen

Brauche ich Chrome 150, um den Test zu machen?

Nein. In Chrome ab Version 150 erscheint die Kategorie automatisch in den DevTools. Hast du eine ältere Version, nutze einfach PageSpeed Insights unter pagespeed.web.dev, dort ist der Check seit Ende Mai 2026 ebenfalls verfügbar, ganz ohne Update.

Verbessert eine llms.txt mein Google-Ranking?

Nein. Google Search wertet die Datei nicht für Rankings aus, das hat Google mehrfach bestätigt. Der Nutzen liegt bei KI-Agenten und KI-Suchdiensten, die deine Seite damit besser erfassen, sowie beim Bestehen des Lighthouse-Audits.

Ist eine fehlende llms.txt schlimm?

Im Audit wird eine fehlende Datei als "nicht zutreffend" gewertet, nicht als Durchfall. Ein Serverfehler beim Abruf dagegen schon. Da die Datei in einer Stunde erstellt ist und der agentische Traffic schnell wächst, lohnt sich das Aufsetzen trotzdem.

Muss ich jetzt WebMCP einbauen?

2026 nicht. Die Technik ist experimentell, und Google sagt selbst, dass ein Fehlschlag bei diesem Check derzeit normal ist. Konzentriere dich auf llms.txt, Accessibility und Layout-Stabilität. WebMCP wird relevant, wenn Chrome 150 breit verfügbar ist.