Lighthouse misst jetzt Agentic Browsing — was Google damit prüft, und warum unsere AI-Ready-Stacks ohne weitere Implementierung schon im grünen Bereich liegen

TL;DR — die 90-Sekunden-Zusammenfassung

Was ist neu?

Lighthouse hat eine experimentelle Kategorie Agentic Browsing bekommen — vier Themenfelder: WebMCP-Integration, Auffindbarkeit, Accessibility-Baum, Layout-Stabilität.

Wie wird bewertet?

Keine 0-bis-100-Punktzahl — stattdessen eine Pass-Ratio plus Pass/Fail-Status pro Audit.

Bin ich als Moselwal-Kunde versorgt?

Ja, weitgehend. moselwal/webmcp liefert die WebMCP-Tools, die A11y-Disziplin ist Teil unserer Editor-/Template-Konvention, CLS wird über die Site-Package-Templates kontrolliert, llms.txt ist bei jeder Plattform aktiv.

Was Lighthouse jetzt misst

Google hat Lighthouse seit Performance, Accessibility, Best Practices, SEO und PWA-Zeiten als das de-facto-Quality-Gate für Web-Auslieferung positioniert. Mit der neuen Kategorie Agentic Browsing — derzeit als experimentell markiert — kommt eine weitere Achse dazu, die auf eine sehr konkrete Frage zielt: Wie gut kann ein KI-Agent diese Seite verstehen und mit ihr interagieren?

Die Kategorie ist nicht nur dokumentarisch gemeint. Lighthouse läuft typischerweise in CI/CD-Pipelines mit, also wird Agentic Browsing in den kommenden Monaten zu einer messbaren Anforderung an Frontend-Teams werden — vergleichbar mit dem, was Core Web Vitals seit 2020 sind. Wer heute schon strukturell für Agenten gebaut hat, sieht morgen einen grünen Score, ohne dass das Build-System aufschreit.

Die fünf Audit-Bereiche im Einzelnen

1. Registrierte WebMCP-Tools

Lighthouse spricht über die Chrome-DevTools-Protocol-(CDP-)WebMCP-Domain mit der Seite und beobachtet, welche Tools registriert werden. Bewertet werden sowohl deklarative Tools (im HTML als spezielle Tags markiert) als auch imperative Tools (in JavaScript per navigator.modelContext.registerTool() registriert).

2. Forms ohne deklaratives WebMCP

Forms, die nicht über WebMCP deklariert sind, sind für Agenten eine Black Box — der Agent muss raten, was die Input-Felder bedeuten und welche Validierungen greifen. Das Audit findet Forms ohne WebMCP-Annotation und flaggt sie.

3. WebMCP-Schema-Validität

Wenn ein Tool ein Input-Schema deklariert (JSON-Schema-ähnliche Struktur mit Typen und Pflichtfeldern), prüft Lighthouse, ob das Schema syntaktisch und semantisch valide ist. Ungültige Schemas führen zu Audit-Fehlern.

4. llms.txt als Auffindbarkeits-Signal

Lighthouse prüft, ob im Stammverzeichnis der Domain eine llms.txt liegt — eine maschinenlesbare Zusammenfassung der Site, die LLMs als Einstiegsdokument nutzen können. Wichtiger Hinweis: Googles eigener AI Optimization Guide vom Mai 2026 sagt, dass llms.txt für SERP-Sichtbarkeit nicht zwingend ist — Lighthouse misst sie trotzdem, weil sie für Agent-Discovery sinnvoll bleibt.

5. Accessibility-Audits aus Agenten-Perspektive

Agenten nutzen den Accessibility-Baum als primäres Datenmodell. Lighthouse zieht eine Untermenge, die für Maschinen besonders relevant ist:

• Namen und Labels — jedes interaktive Element braucht einen programmatischen Namen.
• Baum-Integrität — Rollen und Parent-/Child-Beziehungen müssen valide sein.
• Sichtbarkeit — kein Inhalt ist im A11y-Baum versteckt, während er interaktiv ist.

Plus Cumulative Layout Shift (CLS) als Stabilitäts-Metric.

Warum es keine 0-bis-100-Punktzahl gibt

Google sagt das ausdrücklich im Doku-Text: weil die Standards für das agentische Web noch im Werden sind, will man erstmal Daten erheben und Pass/Fail-Signale liefern, statt eine Rangfolge zu zementieren. Das ist methodisch sauber — eine 0-bis-100-Skala, die später nachgeschärft wird, würde die Bewertung historisch instabil machen.

Praktisch bedeutet das: Sie bekommen eine Pass-Ratio in der Kategorie-Überschrift (z. B. „6 von 8 Audits bestanden") plus Pass/Fail/Warnung pro Audit. CI/CD-Integration ist möglich (Pipeline-Break bei kritischen Fehlern), die Auswertung muss aber etwas reicher sein als ein simpler Score-Schwellwert.

Was unsere AI-Ready-Stacks schon erfüllen — Audit-by-Audit

Hier kommt der direkte Abgleich pro Audit-Bereich:

Konkret heißt das: Wer eine TYPO3-Site auf unserer AI-Ready-Plattform betreibt, sollte beim ersten Lighthouse-Lauf mit der neuen Kategorie alle Pflicht-Audits grün sehen. Die Pass-Ratio sollte 8/8 sein, mit gelegentlichen Warnungen für edge cases.

AI-Ready Commerce (Sylius) — gleicher Aufbau, ein zusätzliches Tool

Für Shop-Sites kommt noch die Tool-Familie für Produkt-Suche und Produkt-Detail dazu. Diese ist Teil unserer Sylius-Site-Package-Erweiterung und folgt demselben deklarativen Pattern wie die TYPO3-Tools.

Wenn Sie nicht bei uns sind — Mindest-Implementierung pro Audit

Die Audits sind nicht exklusiv für unsere Plattform — jedes CMS-/E-Commerce-System kann sie erfüllen, wenn die Disziplin stimmt. Für jeden Audit-Bereich die Mindest-Implementierung:

WebMCP-Tools: Die einfachste Variante ist deklaratives WebMCP-Markup im HTML — keine JavaScript-Komplexität, keine Timing-Probleme. Drei Tools sind ein guter Start: search, navigation, page-content. Wer einen Shop betreibt, ergänzt product-search.

Forms-Annotation: Jedes Form bekommt eine name-Property auf jedes Input-Element plus eine WebMCP-Tool-Annotation, die das Form als aufrufbare Aktion deklariert.

Schema-Validation: JSON-Schema pro Tool definieren, vor dem Deploy gegen einen Validator laufen lassen. CI-Pipeline-Step.

llms.txt: Statisches Markdown-Dokument im Web-Root, das die Site-Struktur und die wichtigsten Inhalte zusammenfasst. Generierung kann manuell sein oder per Build-Step aus den Page-Metadaten.

Accessibility: Semantic-HTML statt <div>-Salat. Jedes interaktive Element bekommt einen programmatischen Namen. ARIA nur ergänzend. CLS unter 0,1.

Wer einen TYPO3- oder Sylius-Bestand hat und das in Eigenregie aufsetzen möchte: Unser Open-Source-Paket moselwal/webmcp ist genau dafür gebaut und MIT-lizenziert. Die Tool-Registry, die Schema-Validation und der CDP-Hook sind out-of-the-box dabei.

Fazit

Lighthouse Agentic Browsing ist die nächste Achse, an der CMS- und Commerce-Plattformen gemessen werden. Die Kategorie ist experimentell, aber die fünf Audit-Bereiche (WebMCP-Tools, Forms-Annotation, Schema-Validität, llms.txt, A11y plus CLS) sind strukturell stabil und werden sich nicht mehr in andere Richtungen entwickeln.

Wer auf unserer AI-Ready-CMS- oder AI-Ready-Commerce-Plattform läuft, ist auf den Audits ohne weitere Implementierung weitgehend grün — weil die Schichten, die Lighthouse misst, die Pflicht-Bausteine unseres Stacks sind. Wer in Eigenregie nachrüsten will, hat mit moselwal/webmcp (Open Source, MIT) und der Semantic-HTML-Disziplin den passenden Werkzeugkasten. Beide Wege führen zum selben Ergebnis: einer Lighthouse-Bestanden-Quote, die nicht im Wartungs-Sprint zusammengeflickt werden muss, sondern Nebenprodukt einer sauberen Architektur ist.