Agentic Browsing bezeichnet eine neue Prüfkategorie in Google Lighthouse, die misst, wie gut eine Website von autonomen KI-Agenten verstanden und bedient werden kann. Statt eines klassischen 0-bis-100-Scores arbeitet sie als Pass-/Fail-Checkliste mit einer anteiligen Bestehensquote (zum Beispiel 3/3). Sie bewertet, ob ein KI-Agent die Inhalte, Funktionen und Formulare einer Seite eigenständig erfassen und ausführen kann, und gruppiert das in vier Signalbereiche: das Vorhandensein einer llms.txt im Domain-Root, die WebMCP-Tool-Registrierung, die Integrität des Accessibility-Trees und den Cumulative Layout Shift (CLS).
Was Agentic Browsing in Lighthouse genau ist
Agentic Browsing ist mit Lighthouse 13.3.0 (veröffentlicht am 7. Mai 2026) aus dem experimentellen Status in die Standard-Konfiguration gewandert. Damit läuft die Kategorie nun bei einem regulären Lighthouse-Audit automatisch mit, ohne dass Du eine experimentelle Flag setzen musst. Auch PageSpeed Insights hat die Kategorie geerbt, sodass die Prüfung sowohl in der lokalen Lighthouse-Instanz als auch im öffentlichen Google-Tool sichtbar ist.
Der entscheidende Unterschied zu den klassischen Lighthouse-Kategorien wie Performance, Accessibility oder SEO ist die Darstellung des Ergebnisses. Agentic Browsing liefert keinen gewichteten Score zwischen 0 und 100. Stattdessen siehst Du eine Readiness-Checkliste: Jeder Prüfpunkt besteht oder besteht nicht, und das Tool zeigt eine anteilige Bestehensquote wie 3/3 oder 2/4. Diese Logik macht die Kategorie eher zu einer Diagnose-Liste als zu einer Benotung. Du erkennst auf einen Blick, welche konkreten technischen Voraussetzungen für agentische Nutzung erfüllt sind und welche fehlen.
Wichtig für die Einordnung: Google sammelt mit dieser Kategorie Daten und gibt Signale. Agentic Browsing ist kein Ranking-Faktor. Die Ergebnisse beeinflussen also nicht direkt Deine Position in den klassischen Suchergebnissen. Sie sind ein technisches Readiness-Signal dafür, wie gut ein KI-Agent mit Deiner Seite arbeiten kann. Die zugrundeliegenden Standards sind ausdrücklich als „proposed“ beziehungsweise experimentell gekennzeichnet, was bedeutet, dass sich Prüfpunkte und Bewertungslogik in kommenden Versionen noch ändern können.
Die vier Signalbereiche im Detail
Agentic Browsing prüft, ob ein KI-Agent eine Seite verstehen und bedienen kann, anhand von vier Signalbereichen. Jeder Bereich adressiert eine andere Schicht der Maschinenlesbarkeit:
- llms.txt im Domain-Root: Die Prüfung schaut, ob unter der Domain-Wurzel eine
llms.txt-Datei liegt. Diese Datei ist als strukturierter Wegweiser für Large Language Models gedacht und soll einem Agenten in kompakter Form vermitteln, welche Inhalte und Ressourcen einer Seite relevant sind. - WebMCP-Tool-Registrierung: Hier wird geprüft, ob die Seite über das experimentelle WebMCP-Protokoll Tools registriert, also Funktionen und Formulare so deklariert, dass ein Agent sie entdecken und aufrufen kann.
- Accessibility-Tree: Geprüft werden Namen und Labels von Elementen, die Integrität der Rollen- und Baumstruktur (role/tree integrity) sowie die Sichtbarkeit. Ein sauberer Accessibility-Tree ist nicht nur für Screenreader entscheidend, sondern auch für Agenten, die die Seite über dieselbe semantische Schicht interpretieren.
- Cumulative Layout Shift (CLS): Die Layoutstabilität aus den Core Web Vitals fließt ebenfalls ein. Verschiebt sich das Layout nach dem Laden, kann ein Agent Elemente verfehlen oder falsche Aktionen auslösen, daher zählt ein niedriger CLS als positives Signal.
Warum Agentic Browsing für Betreiber relevant wird
Die Logik hinter der Kategorie ergibt sich aus einer Verschiebung im Nutzungsverhalten. Immer häufiger interagieren nicht nur Menschen mit einer Website, sondern auch KI-Agenten, die im Auftrag eines Nutzers Aufgaben erledigen: einen Termin buchen, ein Produkt in den Warenkorb legen, ein Formular ausfüllen oder Informationen aus mehreren Quellen zusammentragen. Ein Browser wie Chrome experimentiert mit Mechanismen, die solchen Agenten den direkten Zugriff auf Seitenfunktionen ermöglichen. Agentic Browsing in Lighthouse ist die Messlatte dafür, ob Deine Seite diesen Agenten überhaupt eine saubere Angriffsfläche bietet.
Für Dich als Betreiber bedeutet das: Eine Seite, die für Menschen gut funktioniert, ist nicht automatisch für Agenten gut bedienbar. Ein KI-Agent verlässt sich nicht auf visuelle Gestaltung, sondern auf die semantische und strukturelle Schicht. Fehlt ein sauberer Accessibility-Tree, sind Buttons ohne Label versehen oder verschiebt sich das Layout, stolpert der Agent an Stellen, die einem menschlichen Nutzer gar nicht auffallen würden. Die vier Signalbereiche decken genau diese Bruchstellen ab.
| Signalbereich | Was geprüft wird | Warum es für Agenten zählt |
|---|---|---|
| llms.txt | Existenz der Datei im Domain-Root | Strukturierter Wegweiser zu relevanten Inhalten |
| WebMCP | Registrierung von Tools/Funktionen | Agent kann Formulare und Funktionen direkt aufrufen |
| Accessibility-Tree | Namen, Labels, Rollen, Sichtbarkeit | Semantische Schicht, über die der Agent die Seite liest |
| CLS | Layoutstabilität nach dem Laden | Verhindert, dass der Agent Elemente verfehlt |
Ein konkretes Beispiel
Angenommen, Du betreibst einen Onlineshop und ein KI-Agent soll im Auftrag eines Kunden ein Produkt suchen und in den Warenkorb legen. Führst Du ein Lighthouse-Audit ab Version 13.3.0 aus, taucht die Kategorie Agentic Browsing automatisch im Bericht auf. Liegt keine llms.txt unter deine-domain.de/llms.txt, fällt dieser Prüfpunkt durch. Hat der „In den Warenkorb“-Button kein zugängliches Label und ist nur über ein Icon erkennbar, schlägt der Accessibility-Tree-Check an. Verschiebt sich das Layout, weil ein Banner nachlädt, sinkt der CLS-Wert. Das Ergebnis könnte dann zum Beispiel 1/4 lauten und Dir genau zeigen, an welchen drei Stellen ein Agent scheitern würde. Dieselbe Prüfung kannst Du auch über PageSpeed Insights öffentlich abrufen, ohne Lighthouse lokal zu installieren.
Wie Du die Prüfung praktisch nutzt
Behandle Agentic Browsing als Diagnose, nicht als Note. Weil das Ergebnis eine Checkliste ist, kannst Du die durchgefallenen Prüfpunkte einzeln abarbeiten:
- Lege eine
llms.txtim Domain-Root an und pflege darin die zentralen Inhalte und Einstiegspunkte Deiner Seite. - Prüfe und bereinige den Accessibility-Tree: vergib sprechende Labels, achte auf korrekte ARIA-Rollen und stelle sicher, dass interaktive Elemente sichtbar und benannt sind.
- Reduziere den Cumulative Layout Shift, indem Du Platz für nachladende Elemente reservierst und Schriften sowie Bilder stabil einbindest.
- Evaluiere WebMCP, wenn Du Agenten gezielt den Aufruf von Formularen und Funktionen ermöglichen willst, beachte aber den experimentellen Status.
Da die Standards als „proposed“ gelten, lohnt es sich, die offizielle Dokumentation regelmäßig zu prüfen. Die Scoring-Logik der Kategorie ist bei Google dokumentiert: Lighthouse Agentic Browsing Scoring.
Agentic Browsing im Verhältnis zu klassischer Suchmaschinenoptimierung
Es lohnt sich, Agentic Browsing klar von der klassischen Suchmaschinenoptimierung abzugrenzen, weil beide leicht verwechselt werden. Klassisches SEO zielt darauf ab, dass eine Seite in den Suchergebnissen möglichst weit oben erscheint, wenn ein Mensch eine Suchanfrage stellt. Dafür zählen Faktoren wie relevante Inhalte, eine sinnvolle interne Verlinkung, technische Sauberkeit und Backlinks. Agentic Browsing dagegen fragt nicht, ob eine Seite gut rankt, sondern ob ein KI-Agent sie nach dem Aufruf auch bedienen kann. Es ist eine Readiness-Prüfung für die Maschine-Maschine-Interaktion, nicht für die Sichtbarkeit in der Ergebnisliste.
Diese Unterscheidung ist deshalb wichtig, weil Agentic Browsing ausdrücklich kein Ranking-Faktor ist. Du verbesserst durch ein gutes Ergebnis in dieser Kategorie nicht automatisch Deine Position in den klassischen Suchergebnissen. Was Du verbesserst, ist die Wahrscheinlichkeit, dass ein Agent, der bereits auf Deiner Seite gelandet ist, dort erfolgreich eine Aufgabe abschließt. In einer Welt, in der Nutzer zunehmend Aufgaben an Agenten delegieren, kann genau das den Unterschied zwischen einem abgeschlossenen und einem abgebrochenen Vorgang ausmachen, etwa zwischen einer ausgefüllten Kontaktanfrage und einem Agenten, der am Formular scheitert.
Zugleich gibt es eine deutliche Überschneidung: Viele Maßnahmen, die für Agentic Browsing helfen, zahlen auch auf andere Qualitätsziele ein. Ein sauberer Accessibility-Tree verbessert die Barrierefreiheit für Menschen mit Behinderung und damit die Lighthouse-Accessibility-Kategorie. Ein niedriger Cumulative Layout Shift ist seit Jahren Teil der Core Web Vitals und wirkt sich auf die wahrgenommene Qualität für alle Nutzer aus. Wer die durchgefallenen Prüfpunkte abarbeitet, betreibt also keine isolierte Agenten-Optimierung, sondern verbessert die Seite auf mehreren Ebenen gleichzeitig.
Grenzen und offene Fragen
Weil Agentic Browsing jung und der zugrundeliegende Standard als „proposed“ gekennzeichnet ist, solltest Du die Kategorie mit der nötigen Vorsicht einordnen. Mehrere Punkte sind heute noch offen:
- Die Prüfpunkte können sich ändern. Da der Standard experimentell ist, ist nicht garantiert, dass die heutigen vier Signalbereiche in dieser Form bestehen bleiben. Lighthouse kann Prüfpunkte ergänzen, anpassen oder die Bewertungslogik verfeinern.
- Die praktische Verbreitung ist begrenzt. WebMCP befindet sich im Origin-Trial-Stadium, und auch das llms.txt-Konzept ist noch nicht flächendeckend etabliert. Ein durchgefallener Prüfpunkt bedeutet daher nicht zwingend, dass eine Seite schlecht gebaut ist, sondern oft nur, dass ein sehr neues Feature noch nicht implementiert wurde.
- Es ist kein Garant für Agentenfähigkeit. Auch eine Seite mit voller Bestehensquote kann in der Praxis Probleme bereiten, etwa wenn komplexe Abläufe mehrere Schritte und Zustände umfassen, die eine Checkliste nicht abdeckt.
Für die Praxis heißt das: Nutze Agentic Browsing als nützlichen Frühindikator und als strukturierte To-do-Liste, aber überschätze die einzelne Bestehensquote nicht. Der größte unmittelbare Hebel liegt ohnehin in den Bereichen, die auch ohne Agenten Sinn ergeben, also einem sauberen Accessibility-Tree und einem stabilen Layout. WebMCP und llms.txt sind die eher zukunftsgerichteten Bausteine, deren Aufwand Du gegen den experimentellen Status abwägen solltest.
FAQ zu Agentic Browsing
Ist Agentic Browsing ein Ranking-Faktor?
Nein. Google sammelt darüber Daten und gibt Signale, aber die Kategorie beeinflusst nicht direkt Deine Position in den klassischen Suchergebnissen. Sie ist ein technisches Readiness-Signal für die Bedienbarkeit durch KI-Agenten.
Bekomme ich einen Score von 0 bis 100?
Nein. Anders als Performance oder SEO liefert Agentic Browsing keinen gewichteten Score, sondern eine Pass-/Fail-Checkliste mit einer anteiligen Bestehensquote wie 3/3.
Seit wann ist die Kategorie standardmäßig aktiv?
Seit Lighthouse 13.3.0 vom 7. Mai 2026. Davor war sie experimentell. PageSpeed Insights hat die Kategorie ebenfalls übernommen.
Welche vier Bereiche werden geprüft?
Das Vorhandensein einer llms.txt im Domain-Root, die WebMCP-Tool-Registrierung, die Integrität des Accessibility-Trees sowie der Cumulative Layout Shift (CLS).
Sind die Standards final?
Nein. Die zugrundeliegenden Standards sind ausdrücklich als „proposed“ beziehungsweise experimentell gekennzeichnet und können sich in kommenden Lighthouse-Versionen noch ändern.