Stilisiertes Browserfenster mit strukturierten Elementen und einem KI-Agenten-Cursor an einem Formularfeld — Symbol für agententaugliche Websites

Agentic Browsing: Googles neuer Lighthouse-Check — ist Ihre Website für KI-Agenten bereit?

Beim Durchsehen der PageSpeed Insights ist uns dieser Tage etwas Neues aufgefallen: eine Kategorie, die wir dort noch nie gesehen hatten. Sie heißt „Agentic Browsing" und misst nicht, ob ein Mensch mit der Seite zurechtkommt, und auch nicht, ob der Google-Crawler sie indexieren kann. Sie misst, ob ein KI-Agent die Seite lesen, verstehen und bedienen kann.

Der Hintergrund: Google hat diese Kategorie mit Lighthouse 13.3 (Anfang Mai 2026) aus dem Experimentierstatus in die Standard-Konfiguration übernommen. Sie taucht damit nicht nur im Entwickler-Werkzeug Lighthouse auf, sondern auch in den PageSpeed Insights und in den Chrome-DevTools. Wer die Geschwindigkeit seiner Seite prüft, sieht den neuen Abschnitt seither gleich mit.

Was Lighthouse jetzt zusätzlich prüft

Gemeint sind mit „Agenten" die browsergesteuerten Assistenten, die gerade entstehen: ChatGPT, Claude, Perplexity, Gemini und Ähnliche, die eine Seite nicht nur lesen, sondern auf ihr handeln sollen, einen Termin buchen, ein Formular ausfüllen, eine Information gezielt herausziehen. Ein solcher Agent „sieht" eine Seite anders als ein Mensch. Er verlässt sich nicht auf das visuelle Layout, sondern auf die Struktur darunter.

Genau diese Struktur nimmt der neue Check unter die Lupe. Vier Bereiche stehen im Mittelpunkt.

llms.txt: eine maschinenlesbare Inhaltsübersicht. Das ist eine schlichte Textdatei im Wurzelverzeichnis der Domain (/llms.txt), die einem Sprachmodell in kompakter Form sagt, worum es auf der Seite geht und welche Unterseiten wichtig sind. Der Vorschlag stammt aus dem Jahr 2024; einige hundert Websites setzen ihn bereits ein. Verbindlich genutzt wird er von den KI-Anbietern noch nicht, der Lighthouse-Audit prüft vorerst nur, ob die Datei überhaupt vorhanden ist.

Agenten-taugliche Barrierefreiheit. Ein Agent arbeitet auf dem sogenannten Accessibility-Tree, derselben strukturierten Repräsentation einer Seite, die auch ein Screenreader nutzt. Hat jeder Button, jedes Eingabefeld einen programmatisch lesbaren Namen? Sind die Rollen korrekt ausgezeichnet, die Eltern-Kind-Beziehungen sauber? Was einem blinden Menschen die Bedienung ermöglicht, ermöglicht sie auch der Maschine.

Layout-Stabilität. Springt das Layout, während die Seite lädt, ist das für einen Menschen ärgerlich. Für einen Agenten ist es ein echtes Risiko: Erkennt er einen Button, und die Seite verschiebt sich, bevor er klickt, löst er die falsche Aktion aus oder scheitert ganz. Der Audit greift hier auf eine bekannte Größe zurück: Cumulative Layout Shift, einen der Core Web Vitals.

WebMCP: explizite Schnittstellen für Agenten. Das ist der jüngste und experimentellste Teil. WebMCP (Web Model Context Protocol) erlaubt es einer Seite, einzelne Funktionen, etwa „Kontaktformular absenden", als klar beschriebene Werkzeuge für Agenten anzubieten, statt dass der Agent sich das Anklicken zusammenraten muss. Es lässt sich deklarativ am HTML-Formular hinterlegen oder per JavaScript. Wichtig zur Einordnung: WebMCP wurde Anfang 2026 von Google und Microsoft vorgeschlagen und läuft seit Chrome 149 in einem zeitlich begrenzten Origin Trial. Ein ratifizierter Standard ist es nicht.

Kein Punktwert, sondern Signale

Eine Besonderheit ist wichtig, damit hier keine falsche Dringlichkeit entsteht: Anders als bei Performance oder Barrierefreiheit gibt es keinen Wert von 0 bis 100. Lighthouse zeigt stattdessen, wie viele der Vorbereitungs-Prüfungen bestanden wurden, und den Status jeder einzelnen: bestanden, nicht bestanden, Warnung. In der Praxis bestehen die meisten Seiten heute schon drei der vier Prüfungen, den Accessibility-Tree, die Layout-Stabilität und, sofern die Datei angelegt ist, die llms.txt. Das noch experimentelle WebMCP wird nicht abgestraft, wenn man es auslässt.

Google begründet das offen: Die Standards des agentischen Webs entstehen gerade erst. Es geht zunächst darum, Daten zu sammeln und konkrete Hinweise zu geben, nicht darum, Seiten zu ranken. Niemand verliert hier morgen eine Platzierung. Es ist eine Standortbestimmung, kein Urteil.

Von „empfohlen werden" zu „bedient werden"

In den letzten Monaten ging es viel darum, von KI-Systemen empfohlen zu werden, die Frage, ob ChatGPT oder Perplexity eine Marke als Antwort nennt. Agentic Browsing ist die nächste, handlungsorientierte Stufe: nicht nur genannt zu werden, sondern von einem Agenten tatsächlich bedient werden zu können. Der Unterschied ist konkret. Empfohlen zu werden bringt Sichtbarkeit. Bedient werden zu können heißt, dass ein Assistent im Auftrag eines Nutzers auf Ihrer Seite einen Termin anfragt oder ein Formular ausfüllt, ohne daran zu scheitern.

Das ist heute noch Zukunftsmusik mit kleinen Vorboten. Aber die Richtung ist absehbar genug, um die eigene Seite einmal daraufhin anzusehen.

Wer sauber baut, ist schon halb agent-ready

Der beruhigende Teil: Sieht man sich die geprüften Signale an, fällt auf: Sie decken sich fast vollständig mit dem, was eine gut gebaute Website ohnehin hat. Ein sauberer Accessibility-Tree ist nichts anderes als gute Barrierefreiheit, die seit dem Barrierefreiheitsstärkungsgesetz für viele Anbieter ohnehin Pflicht ist. Ein stabiles Layout ist ein Core Web Vital, das Google seit Jahren bewertet. Semantisches HTML und klar strukturierte Inhalte sind seit jeher die Grundlage guter Technik.

Anders gesagt: Wer seine Seite sauber, semantisch und barrierefrei baut, ist heute schon zur Hälfte agent-ready, ohne ein einziges neues Schlagwort gelesen zu haben. Die Investition in Barrierefreiheit zahlt damit doppelt, für Menschen mit Einschränkungen und für die Maschinen, die künftig in deren Auftrag handeln. Übrig bleibt als wirklich Neues vor allem das experimentelle WebMCP und die llms.txt.

Was das praktisch heißt

Es heißt ausdrücklich nicht: „Bauen Sie jetzt WebMCP ein, oder Sie sind abgehängt." Das wäre angesichts eines Origin Trials ohne ratifizierten Standard verfrüht. Es heißt: Die Fundamente (saubere Struktur, stabiles Layout, echte Barrierefreiheit, gute Inhalte) machen Ihre Seite heute schon weitgehend agent-tauglich, und sie sind aus eigenem Recht sinnvoll, ganz unabhängig von KI-Agenten. Das wirklich Experimentelle obendrauf kann man im Auge behalten und angehen, wenn sich die Standards gesetzt haben. Wir richten Seiten so ein, dass dieser Schritt später klein ist, weil die Basis stimmt.

Quellen: Chrome for Developers (Lighthouse: Agentic Browsing); Google Search Central. Stand Juli 2026.

Häufige Fragen

Muss ich jetzt sofort etwas ändern?

Nein. Der Check vergibt keinen Score und beeinflusst keine Platzierung, er ist eine Standortbestimmung. Eine sauber und barrierefrei gebaute Seite besteht die meisten Prüfungen ohnehin.

Was ist llms.txt?

Eine kurze, maschinenlesbare Textdatei im Wurzelverzeichnis Ihrer Domain, die KI-Systemen einen Überblick über Ihre Inhalte gibt. Der Lighthouse-Audit prüft vorerst nur, ob sie existiert.

Brauche ich WebMCP?

Heute nicht zwingend. WebMCP ist experimentell (Origin Trial in Chrome) und kein verabschiedeter Standard. Perspektivisch sinnvoll für Schlüssel-Aktionen wie Kontakt oder Buchung, aber kein Grund zur Eile.

Was hat Barrierefreiheit damit zu tun?

Sehr viel. KI-Agenten arbeiten auf demselben Accessibility-Tree wie Screenreader. Wer barrierefrei baut, ist damit zugleich ein gutes Stück agent-tauglich.

Wo sehe ich diesen Check?

In den Google PageSpeed Insights, in Lighthouse (ab Version 13.3) und in den Chrome-DevTools, als eigener Abschnitt „Agentic Browsing“.

CloudWebDevs
About the Author

CloudWebDevs

Wiesbaden

CloudWebDevs ist der technische Partner für sichere und ausfallsichere Web-Architektur. Mit tiefen Wurzeln in der Prozessoptimierung und einem Tech-Stack auf Industriestandard übersetzen wir komplexe Anforderungen in effiziente, automatisierte und wartungsfreie digitale Plattformen – von der ersten Code-Zeile bis zum automatisierten Deployment.