Google Lighthouse hat eine neue Kategorie – was das für digitale Barrierefreiheit bedeutet

KI-Agenten sind kein Zukunftsszenario mehr. Sie surfen, vergleichen, buchen und kaufen — jetzt, im Auftrag echter Menschen. Und Google hat mit Lighthouse 13.3 (veröffentlicht im Mai 2026) ein klares Signal gesendet: Das Open-Source-Audit-Tool enthält jetzt eine brandneue, experimentelle Kategorie namens Agentic Browsing.

Das ist kein rein technisches Update, das Entwickler:innen zur Kenntnis nehmen und wieder vergessen. Es ist ein Richtungssignal — und für Teams, die bereits ernsthaft an digitaler Barrierefreiheit arbeiten, auch eine gute Nachricht: Sie sind weiter, als Sie denken.

Was ist die Lighthouse-Kategorie Agentic Browsing?

Lighthouse misst bislang vier Bereiche: Performance, Einhaltung der Web Content Accessibility Guidelines (WCAG), SEO und Best Practices. Die Kategorie Agentic Browsing fügt eine fünfte Perspektive hinzu — mit einer simplen, aber entscheidenden Frage: Kann ein KI-Agent Ihre Website überhaupt nutzen?

Anders als der bekannte 0–100-Score in den Performance- oder Accessibility-Kategorien liefert Agentic Browsing keine gewichtete Punktzahl. Stattdessen gibt es eine fraktionale Bestanden/Nicht-bestanden-Quote über alle Prüfungen, einen eindeutigen Status für spezifische technische Anforderungen und informative Zählwerte als schnellen Überblick.

Google macht deutlich: Die Standards für das "agentische Web" sind noch im Entstehen. Die Kategorie ist als experimentell markiert — es gibt noch kein Ranking-Signal. Was sie heute darstellt, ist eine klare Aussage über die Richtung, in die sich das Web entwickelt.

Die vier Prüfbereiche — was sie testen und was sie bedeuten

1. Der Accessibility-Baum — die Prüfung, die an Ihre bestehende Arbeit anknüpft

Dies ist die ausgereifteste der vier Prüfungen — und die, die am direktesten mit dem zusammenhängt, was viele Teams bereits tun.

KI-Agenten sehen eine Seite nicht so, wie ein Mensch sie sieht. Sie navigieren über den Accessibility-Baum — die strukturierte, semantische Repräsentation aller Inhalte und interaktiven Elemente einer Seite, die der Browser aus dem HTML erzeugt. Googles eigene Dokumentation beschreibt ihn als das "primäre Datenmodell" für Agenten.

Das klingt bekannt — denn es ist derselbe Baum, auf den Screenreader angewiesen sind. Ein Button ohne zugänglichen Namen ist für jemanden, der einen Screenreader nutzt, unsichtbar. Und genauso unsichtbar für einen KI-Agenten, der eine Aufgabe erledigen soll. Dasselbe gilt für unbeschriftete Formularfelder, falsch verschachtelte ARIA-Rollen (Accessible Rich Internet Applications) und fehlerhafte Fokus-Steuerung.

Lighthouse filtert eine spezifische Teilmenge der WCAG-Prüfungen, die für maschinelle Interaktion entscheidend sind: Jedes interaktive Element muss einen programmatischen Namen haben, Rollen und Eltern-Kind-Beziehungen müssen valide sein, und Inhalte dürfen nicht aus dem Accessibility-Baum ausgeblendet sein, während sie interaktiv bleiben.

Die Schlussfolgerung: Wer bereits in semantisches HTML und korrekte ARIA-Beschriftungen investiert hat, um Menschen mit Behinderungen zu unterstützen, hat damit gleichzeitig die Grundlage für agentische Bereitschaft gelegt. Es ist dieselbe Arbeit — aus einem neuen Blickwinkel betrachtet.

2. Layout-Stabilität (CLS) — warum springende Seiten Agenten-Aufgaben zum Scheitern bringen

Der Cumulative Layout Shift (CLS) ist seit 2020 ein Core Web Vital und misst, wie stark sich Seitenelemente beim Laden verschieben. Er taucht jetzt in der Kategorie Agentic Browsing auf — aus einem konkreten Grund: Springende Layouts sind nicht nur für Menschen störend, sie sind für Agenten ein funktionales Problem.

Wenn ein KI-Agent einen Button identifiziert und sich die Seite verschiebt, bevor er interagieren kann, löst er entweder die falsche Aktion aus oder schlägt ganz fehl. Für Agenten, die im Auftrag von Nutzer:innen Aufgaben erledigen — Buchungen, Formular-Übermittlungen, Käufe — ist das kein kleines Ärgernis. Es ist ein Aufgabenabbruch.

Typische Ursachen: Bilder ohne feste Dimensionen, Schriften, die nach dem ersten Rendering laden, und Inhalte, die durch Drittanbieter-Skripte nachträglich über dem Fold eingefügt werden. Der Lighthouse-Performance-Audit und der Core-Web-Vitals-Bericht in der Google Search Console zeigen diese Probleme an.

3. llms.txt — eine neue Konvention, die Sie kennen sollten

Neben robots.txt (für Suchcrawler) und sitemap.xml (für die Indexierung) gibt es jetzt eine dritte Konvention: llms.txt. Diese Markdown-Datei liegt im Root-Verzeichnis Ihrer Domain — zum Beispiel unter https://euredomain.de/llms.txt — und gibt großen Sprachmodellen (Large Language Models, LLMs) und KI-Agenten eine kompakte, strukturierte Übersicht über Ihre Website und ihre wichtigsten Inhalte.

Lighthouse prüft, ob diese Datei vorhanden ist. Ein 404-Fehler führt zur Bewertung "Nicht anwendbar" — die Datei ist derzeit optional, keine Pflicht. Wirft Ihr Server jedoch einen Fehler, wenn die Datei abgerufen wird, wird das markiert.

Die llms.txt-Konvention gewinnt an Verbreitung, aber die meisten Websites haben sie noch nicht — und das ist völlig normal. Eine einfache Version ist in unter einer Stunde erstellt: eine Markdown-Datei im Root-Verzeichnis, die Zweck und wichtigste Seiten Ihrer Website beschreibt. Es ist die Maßnahme mit dem niedrigsten Aufwand und dem deutlichsten Signal, die Sie heute umsetzen können.

4. WebMCP — der kommende Standard: beobachten, nicht in Panik geraten

Das Web Model Context Protocol (WebMCP) ist eine experimentelle Browser-API, die Websites ermöglicht, ihre Funktionen KI-Agenten explizit zugänglich zu machen. Statt einen Agenten raten zu lassen, was ein Button bewirkt, teilt WebMCP es ihm direkt mit — über maschinenlesbare Definitionen, die an Formulare und interaktive Elemente angehängt werden.

Der Standard ist noch in aktiver Entwicklung. Die meisten Websites werden diese Prüfung nicht bestehen — und Google erwartet das. Die richtige Reaktion ist nicht Aktionismus, sondern Vorbereitung: Inventarisieren Sie jetzt Ihre wichtigsten Formulare und Interaktionen (Demo-Anfragen, Anmeldungen, Checkouts, Kontaktformulare), damit Ihr Team handlungsbereit ist, sobald die Spezifikation ausgereift genug ist. Beobachten, nicht überstürzen.

Warum das weit über das Entwickler:innen-Gespräch hinausgeht

Die Kategorie Agentic Browsing ist ein technisches Update mit strategischen Konsequenzen.

Für E-Commerce- und Finanzdienstleistungs-

Teams sind KI-Shopping-Agenten und Finanz-Assistenten bereits im Einsatz. Wenn jemand einer KI die Aufgabe überträgt — ein Produkt finden, Tarife vergleichen, einen Checkout abschließen — surft der Agent in ihrem Auftrag. Websites mit unbeschrifteten Formularen, instabilem Layout und fehlender maschinenlesbarer Struktur sind schwerer zu bedienen. Diese Reibung hat direkte Auswirkungen auf Conversions, nicht nur auf die Nutzererfahrung.

Für SaaS- und B2B-Technologieunternehmen

Nutzen Enterprise-Käufer:innen zunehmend KI-gestützte Evaluierungs-Tools, um Anbieter zu bewerten — bevor ein Mensch überhaupt involviert wird. Eine strukturierte, beschriftete, stabile Website signalisiert technische Reife und Vertrauenswürdigkeit.

Der Bezug zu rechtlichen Anforderungen ist ebenso direkt. Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 und setzt den European Accessibility Act in deutsches Recht um — mit WCAG 2.2 Level AA als technischer Grundlage. Die Kategorie Agentic Browsing weist in dieselbe Richtung: Barrierefreie Websites sind agentisch bereit. Die Arbeit ist dieselbe Arbeit.

So führen Sie das Audit in Chrome durch

Lighthouse in DevTools öffnen

Wenn die Agentic-Browsing-Kategorie in Ihrer Chrome- oder Lighthouse-Version verfügbar ist:

1. Öffnen Sie die Seite, die Sie testen möchten.

2. Öffnen Sie Chrome DevTools (F12 oder Rechtsklick → Untersuchen).

3. Navigieren Sie zum Lighthouse-Panel.

In einigen experimentellen Builds benötigen Sie möglicherweise Chrome Canary oder ein Feature-Flag, um neue Kategorien zu sehen. Wenn Sie keine Agentic-Browsing-Kategorie sehen, ist das Feature in Ihrem Build wahrscheinlich noch nicht verfügbar.

Die Agentic-Browsing-Kategorie aktivieren

Im Lighthouse-Panel wählen Sie in der Regel aus, welche Kategorien ausgeführt werden sollen. Wenn Agentic Browsing verfügbar ist, aktivieren Sie das entsprechende Kontrollkästchen neben Performance, Accessibility, SEO und anderen. Dann:

• Wählen Sie den Gerätetyp (Mobile oder Desktop), da sich Layout und Verhalten unterscheiden können

• Aktivieren Sie optional Throttling für realistischere Bedingungen

• Klicken Sie auf „Seitenaufruf analysieren"

Das Audit führt eine neue Navigation der getesteten Seite mit den Agentic-Browsing-Prüfungen durch.

Pass-Ratios und einzelne Prüfergebnisse auswerten

Wenn der Bericht abgeschlossen ist, sehen Sie:

• Einen Gesamt-Score oder eine zusammenfassende Anzeige für Agentic Browsing

• Eine Liste bestandener Prüfungen, die bestätigen, dass die Seite in bestimmten Bereichen agententauglich ist

• Eine Liste fehlgeschlagener oder „nicht anwendbarer" Prüfungen, jeweils mit Details und teilweise Code-Snippets

Für konsistentere Ergebnisse sollten Sie die Bedingungen stabil halten:

• Verwenden Sie dieselbe URL und dieselben Query-Parameter

• Deaktivieren Sie A/B-Tests oder zufällige Inhalte, wo möglich

• Führen Sie Audits in derselben Chrome-Version mit denselben Lighthouse-Einstellungen durch

Beachten Sie: Jede CLS- oder Timing-Varianz kann die Scores zwischen den Durchläufen leicht verschieben.

So interpretieren Sie die Ergebnisse

Welche Fehler jetzt am wichtigsten sind

Nicht alle Fehler sind in Bezug auf den aktuellen Geschäftseinfluss gleich zu gewichten. Priorisieren Sie:

• Probleme mit der Accessibility-Tree-Gesundheit — sie beeinflussen assistive Technologien und die aktuellen Lighthouse-Accessibility-Scores

• Layout-Stabilität (CLS und ähnliches) — sie sind Teil der Core Web Vitals und stehen bereits im Fokus der Performance-Optimierung

• Kritische Interaktionsprobleme — Buttons, Formulare oder Navigation, die nicht konsistent auffindbar oder klickbar sind

Checks mit niedrigerer Priorität und experimentellem Charakter — wie ein fehlendes llms.txt oder WebMCP-Manifest — sind eher relevant für zukunftsorientierte Vorbereitung als für den heutigen Traffic oder aktuelle Rankings.

Was kommt als nächstes?

Digitale Barrierefreiheit wurde lange vor allem als Compliance-Thema betrachtet — eine Anforderung, die das Gesetz vorschreibt. Die Kategorie Agentic Browsing verschiebt diese Perspektive grundlegend. Wenn KI-Agenten dieselbe semantische Struktur nutzen wie assistive Technologien, wird Barrierefreiheitsarbeit zur Infrastruktur des modernen Webs — nicht zur Pflichtübung.

Teams, die barrierefreie digitale Erlebnisse aufgebaut haben, sind nicht nur beim BFSG vorne dabei. Sie sind auch für die nächste Ära des Webs gut aufgestellt — und wer Barrierefreiheit kontinuierlich über eine digitale Barrierefreiheitsplattform managt, bleibt es auch.

Eine digitale Welt ohne Barrieren zu bauen bedeutet, eine zu bauen, die für alle funktioniert — einschließlich der Agenten, die im Auftrag aller handeln.

Quellen: Lighthouse Agentic Browsing Scoring, Chrome for Developers (Mai 2026) · Registered WebMCP Tools · llms.txt audit · Build agent-friendly websites, web.dev