Lighthouse misst jetzt ob deine Website KI-tauglich ist. Was das für SEO bedeutet

Seit dem 7. Mai 2026 steckt in Lighthouse eine neue Kategorie, die viele noch nicht auf dem Schirm haben: Agentic Browsing. Sie ist ab Lighthouse 13.3 standardmäßig aktiv — kein Opt-in, kein Feature-Flag. Wer Chrome 150+ öffnet und DevTools aufmacht, sieht sie bereits.

Die Frage die sie beantwortet: Wie gut kann ein KI-Agent mit deiner Website umgehen?

Was ist ein KI-Agent überhaupt?

Gemeint sind autonome Systeme wie ChatGPT Browsing, Gemini, Perplexity oder Claude — die im Auftrag von Nutzern selbstständig im Web navigieren, Formulare ausfüllen, Informationen extrahieren und Aufgaben erledigen. Kein Mensch klickt dabei, ein Algorithmus übernimmt.

Diese Systeme sehen das Web anders als Menschen. Sie navigieren nicht visuell, sondern über den Accessibility Tree — die semantische Struktur einer Seite. Und sie können strukturierte Beschreibungen von Seitenfunktionen direkt nutzen, wenn Websites diese bereitstellen.

Lighthouse misst jetzt, ob eine Website dafür gerüstet ist.

Was wird konkret geprüft?

Die neue Kategorie hat vier Bereiche:

1. llms.txt

Lighthouse prüft ob yourdomain.com/llms.txt existiert — eine schlichte Markdown-Datei im Root-Verzeichnis, die beschreibt was die Website tut, welche Seiten es gibt und wie die Inhalte strukturiert sind. Gedacht als maschinenlesbare Zusammenfassung für LLMs.

Geprüft wird: Existiert die Datei überhaupt? Hat sie eine H1-Überschrift? Ist sie lang genug? Enthält sie Links zu relevanten Unterseiten?

2. WebMCP

Das ist das ambitionierteste Konzept — und noch das unreifste. WebMCP ist ein Protokoll-Vorschlag, mit dem Websites ihre Funktionen als strukturierte Tools für Agents exponieren können. Ein Buchungsformular würde sich dann nicht als HTML-Formular zeigen, sondern als book_appointment-Tool mit klar definierten Parametern.

Lighthouse prüft via Chrome DevTools Protocol ob solche Tools registriert sind — sowohl deklarativ (im HTML) als auch imperativ (via JavaScript).

Wichtig: WebMCP ist noch ein Origin Trial. Für die meisten Seiten aktuell nicht relevant.

3. Accessibility Tree

Agents navigieren nicht über visuelle UI. Der Accessibility Tree ist ihr primäres Datenmodell — die Struktur, die Screen Reader und jetzt auch KI-Systeme nutzen um eine Seite zu „verstehen”.

Lighthouse prüft:

• Haben alle interaktiven Elemente programmatische Namen? (aria-label, <label>, etc.)
• Sind ARIA-Rollen valide und Parent-Child-Beziehungen korrekt?
• Sind Inhalte im Tree sichtbar wenn sie interaktiv sind?

Wer seinen A11y-Stand bereits pflegt, besteht diese Checks größtenteils automatisch.

4. Layout Stability (CLS)

Kein neuer Audit — Cumulative Layout Shift ist bereits ein Core Web Vital. Aber: Layout-Sprünge durch unsized Images, Ads oder nachgeladene Inhalte machen Seiten für Agents unzuverlässig. Ein Agent der auf einen Button klickt, der sich im letzten Moment verschoben hat, schlägt fehl.

Kein 0–100 Score

Anders als Performance oder SEO gibt es keine klassische Punktzahl. Die Kategorie zeigt stattdessen eine Bruchzahl — z.B. 6/8 Checks bestanden — plus Pass/Fail für jeden einzelnen Audit. Begründung: Die Standards für die Agent-Welt sind noch in Entwicklung, ein gewichteter Score wäre verfrüht.

Der llms.txt-Widerspruch

Wer die letzten Monate verfolgt hat, wundert sich jetzt vielleicht. Hat Google llms.txt nicht abgelehnt?

Ja — aber das ist eine andere Abteilung.

Google Search (John Mueller, Gary Illyes, Juli 2025) ist klar: llms.txt wird nicht für Crawling, Indexing oder Ranking genutzt. Mueller hat es öffentlich mit dem alten Keywords Meta-Tag verglichen. Kein Ranking-Signal, kein Plan das zu ändern.

Chrome / Lighthouse misst es trotzdem — weil die Zielgruppe eine andere ist. Nicht Googlebot, sondern KI-Agents von OpenAI, Anthropic, Perplexity & Co. Und die lesen llms.txt tatsächlich.

Das ist ein echter interner Widerspruch bei Google. Zwei Teams, zwei Antworten auf dieselbe Frage. Search Engine Journal hat das treffend auf den Punkt gebracht: „Google’s llms.txt guidance depends on which product you ask.”

Was bedeutet das jetzt für SEO?

Direkt: nichts. Google hat nicht bestätigt, dass Agentic Browsing ein Ranking-Faktor wird.

Indirekt: mehr als man denkt.

Accessibility Tree war immer schon gut für SEO — semantisches HTML hilft Googlebot genauso wie Agents. Wer hier investiert, zahlt einmal und profitiert mehrfach.

CLS ist bereits Core Web Vital und zählt für Page Experience Signals. Hier gibt es eh keinen Grund nachlässig zu sein.

llms.txt ist fünf Minuten Arbeit. Eine Markdown-Datei mit H1, kurzer Beschreibung und Links zu den wichtigsten Seiten. Sie macht den Lighthouse-Check grün, sie wird von ChatGPT Browsing, Claude und Perplexity gelesen — und sie schadet garantiert nicht.

WebMCP ist Zukunftsmusik. Für die meisten Seiten jetzt noch nicht relevant.

Praxis: So setzt du das heute um

Schritt 1: Lighthouse Agentic Browsing aufrufen

Chrome 150+ öffnen, DevTools → Lighthouse-Tab. Unter „Categories” taucht jetzt „Agentic Browsing” auf. Einfach mitlaufen lassen — es ist standardmäßig aktiv.

Was du siehst: eine Bruchzahl (z.B. 2/4) und darunter die einzelnen Checks mit Pass/Fail. Rote Punkte zeigen wo Handlungsbedarf besteht.

Schritt 2: llms.txt anlegen

Die einfachste Maßnahme mit dem sofortigsten Effekt. Eine Textdatei, Markdown-Format, ins Root-Verzeichnis:

/llms.txt

Mindestinhalt laut Lighthouse-Check:

# Dein Unternehmensname

> Kurze Beschreibung: Was macht dein Unternehmen, für wen, wo.

## Wichtige Seiten

- [Startseite](https://example.de/)
- [Leistungen](https://example.de/leistungen)
- [Kontakt](https://example.de/kontakt)

Lighthouse prüft: H1 vorhanden ✓, Datei nicht leer ✓, Links enthalten ✓.

Für statische Seiten (klassisches HTML): Datei manuell anlegen und bei Änderungen aktualisieren.

Für dynamische Setups (Wordpress, Astro, Next.js, Nuxt): Besser als Endpoint generieren, damit die Artikelliste automatisch aktuell bleibt. In Astro z.B. als src/pages/llms.txt.ts mit getCollection().

Schritt 3: Accessibility Tree prüfen

Die schnellste Methode: Chrome DevTools → Accessibility-Tab → „Enable full-page accessibility tree” aktivieren. Dann durch die wichtigsten interaktiven Elemente klicken und prüfen:

• Haben alle Buttons einen lesbaren Namen? (nicht nur ein Icon ohne aria-label)
• Haben alle Formularfelder ein <label>?
• Gibt es keine div-Buttons ohne role="button"?

Wer axe DevTools (kostenlose Chrome Extension) nutzt, bekommt die kritischen Fehler direkt angezeigt — dieselben Checks die auch Lighthouse ausführt.

Schritt 4: CLS kontrollieren

In Lighthouse → Performance-Kategorie den CLS-Wert ablesen. Über 0.1 ist ein Problem — für Agents noch mehr als für Menschen.

Häufige Ursachen:

• Bilder ohne width und height — Browser reserviert keinen Platz, Bild lädt nach und verschiebt alles
• Schriften die spät laden — font-display: swap hilft, kann aber selbst kleinen CLS verursachen
• Ads oder Banners die nachträglich injiziert werden

Die schnellste Lösung für Bilder: immer width und height im <img>-Tag setzen, auch wenn CSS das Layout übernimmt.

Was du danach hast

Nach diesen drei Schritten solltest du bei den meisten Websites von 2/4 auf 4/4 kommen — vorausgesetzt der A11y-Stand ist solide. WebMCP lass erstmal weg, das ist Origin Trial und nichts für die Produktion.

Fazit

Agentic Browsing ist kein SEO-Ranking-Signal — aber es ist ein Frühindikator wo das Web hingeht. Wer heute schon sauberen A11y-Tree, stabiles Layout und eine llms.txt hat, ist für die nächste Welle gerüstet: autonome KI-Agents als Traffic-Quelle, neben oder anstelle klassischer Suchmaschinen.

Der Aufwand für die meisten gut gepflegten Websites: überschaubar. Der Grund das zu ignorieren: keiner.