PageSpeed Insights bewertet seit Jahren Performance, Barrierefreiheit, Best Practices und SEO. 2026 gesellte sich still ein fünfter Eintrag zu dieser Reihe: Agentic Browsing. Er beantwortet eine Frage, die die anderen vier Kategorien ignorieren: Kann ein KI-Agent mit dieser Seite tatsächlich arbeiten?
In dieser Anleitung geht es darum, die Prüfung auf der eigenen Website einzusetzen: sie ausführen, verstehen, was jedes Audit tatsächlich aussagt, und mit einer Liste konkreter Korrekturen wieder herauskommen.
Was du am Ende hast
Für wen das gedacht ist: SEO-Verantwortliche, Entwicklerinnen und Website-Betreiber, die wissen wollen, wie sich ihre Seiten verhalten, wenn ein Agent sie besucht und kein Mensch.
Was du am Ende hast: ein echtes Agentic-Browsing-Ergebnis für deine Website, eine Auswertung Audit für Audit mit bestanden, fehlgeschlagen oder nicht zutreffend und eine priorisierte Liste mit Korrekturen.
Voraussetzungen: eine öffentlich erreichbare URL, rund zehn Minuten für den ersten Lauf und Zugriff auf den Code, wenn du noch am selben Tag etwas beheben willst.
Fertig bist du, wenn: du die Bruchzahl Audit für Audit erklären kannst und einschätzen kannst, welche Fehler einen Agenten wirklich daran hindern, eine Aufgabe auf deiner Seite abzuschließen.
Woher die Prüfung kommt und warum jetzt
Die Kategorie Agentic Browsing gab es vor einem Jahr noch nicht. Der Rollout verlief in drei Schritten, alle von Google dokumentiert:
- 7. Mai 2026: Lighthouse 13.3 nimmt die Kategorie in die Standardkonfiguration auf, damit wird sie Teil eines normalen Laufs.
- 22. Juni 2026: Der Chrome-for-Developers-Blog stellt sie im Beitrag zum Toolkit für agentenfreundliche Websites vor, zusammen mit DevTools für Agenten und den WebMCP-Hinweisen.
- 20. Juli 2026: Lighthouse 13.4.1 aktiviert die Kategorie für den API-Pfad von PageSpeed Insights und schreibt, das Release solle PageSpeed Insights innerhalb von zwei Wochen erreichen. Damit liegt der öffentliche Start Anfang August 2026.
Als ich die Prüfung am 11. September 2026 ausführte, stand in der Fußzeile des Berichts eine emulierte Ausführung mit Lighthouse 13.4.1, und Agentic Browsing saß direkt neben SEO. Die Funktion ist also live und nicht auf einen Testkanal beschränkt. Und sie ist ausdrücklich unfertig: Die Kategoriebeschreibung im Bericht sagt es unverblümt — sie befindet sich noch in Entwicklung und kann sich ändern.
Ein praktischer Hinweis vorab: PSI führt die Kategorie für dich auf der Google-Seite aus. Für Prüfungen auf Seitenebene brauchst du weder Chrome 150 noch einen Origin Trial. Versionsanforderungen gelten nur, wenn du die Kategorie lokal in den Chrome DevTools ausführst.
Führe die Prüfung auf deiner eigenen Website aus
- Öffne pagespeed.web.dev und füge deine URL ein. Starte zuerst mit Mobil, wiederhole es dann für Desktop, denn die beiden Laborläufe werden getrennt bewertet.
- Warte, bis die Labordaten fertig sind. Die Felddaten oben stammen aus dem Chrome UX Report und laden schnell. Der Lighthouse-Lauf darunter dauert länger, und dort sitzen die Kategorien.
- Finde die Zeile mit den Werten. Du siehst Leistung, Barrierefreiheit, Best Practices, SEO und danach Agentic Browsing als Bruchzahl statt als Wert von 0 bis 100.
- Klappe die Kategorie auf. Die Auditliste gliedert sich in Agent Accessibility, WebMCP und die üblichen Blöcke für bestandene und nicht zutreffende Prüfungen.
- Öffne jedes fehlgeschlagene Audit. Jede Zeile klappt auf und zeigt die konkrete Regel, das Element oder die Datei hinter dem Fehler, genau das, was ein Ticket zum Beheben braucht.
Die fünfte Kategorie steht in derselben Zeile wie die Werte, die SEO-Teams täglich prüfen. Aufgenommen in PageSpeed Insights am 11. September 2026.
Qualitätsprüfung: Prüfe die Lighthouse-Version in den Ausführungsdetails, bevor du Ergebnisse mit Kolleginnen vergleichst. PSI aktualisiert Lighthouse nach eigenem Zeitplan, und die Kategorie ändert sich zwischen Versionen weiter.
Wenn es klemmt: PSI liefert bei schweren Seiten gelegentlich einen RPC-Timeout zurück. Mir passierte das mitten in der Recherche auf einer großen Website. Versuche es erneut oder teste die Seite lokal mit Lighthouse.
Lies die Bruchzahl richtig
Agentic Browsing hat keinen gewichteten Wert von 0 bis 100, und das ist Absicht. Die Lighthouse-Dokumentation erklärt, dass die Standards für das agentische Web noch entstehen, deshalb liegt der Fokus auf umsetzbaren Signalen statt auf einem Ranking.
Diese Rechnung ist die entscheidende:
Anzeige | Bedeutung |
|---|---|
3/3 | Alle bewerteten Prüfungen bestanden. Nicht zutreffende Audits bleiben außen vor. |
1/3 | Eine bestanden, zwei fehlgeschlagen. Im Nenner stehen nur bestandene und fehlgeschlagene Audits. |
0/3 | Noch nichts von den bewerteten Prüfungen bestanden. Häufig beim ersten Lauf gegen eine schwere Seite mit Werbung. |
Keine Bruchzahl | Alle Audits waren nicht zutreffend oder die Kategorie lief nicht. Prüfe die Ausführungsdetails. |
Die Falle besteht darin, 1/3 als „33 Prozent agentenbereit“ zu lesen. Es ist kein Prozentwert von irgendetwas. Es ist eine Zählung: Von den drei Prüfungen, die auf dieser Seite bewertbar waren, hat eine bestanden, und die Audits, die nicht zutrafen, blieben komplett außerhalb der Rechnung. Im Bericht, den ich ausgewertet habe, liefen sechs Audits, drei waren nicht zutreffend, und die verbleibenden drei ergaben die 1/3.
Die Werte schwanken auch zwischen Läufen auf derselben Seite. Lighthouse nennt drei Ursachen: dynamische Tool-Registrierung (per JavaScript registrierte WebMCP-Tools werden je nach Zeitpunkt erfasst oder verpasst), DOM-Änderungen, die den Barrierefreiheitsbaum umbauen, und Layout-Verschiebungen durch Werbung, Bilder ohne Größenangabe oder nachgeladenen Inhalt. Wenn deine Zahl schwankt, liegt es meist daran.
Arbeite die sechs Audits durch
Der aktuelle PSI-Build führt sechs Audits aus. Eines kommt hinzu: Der Entwicklungszweig von Lighthouse ergänzt bereits eine Prüfung für ai-catalog.json (Agent Resource Discovery) in einer neuen Gruppe Agent Discoverability. Behandle diese Liste also als versionsabhängig.
Audit | Was es prüft | Was „nicht zutreffend“ bedeutet |
|---|---|---|
Barrierefreiheitsbaum fehlerhaft | Eine Teilmenge der Barrierefreiheitsregeln mit Fokus auf Agenten: programmatische Namen und Labels, gültige ARIA-Struktur und Elemente, die interaktiv bleiben, obwohl sie im Baum verborgen sind | Nie; wird immer bewertet |
llms.txt folgt den Empfehlungen nicht | Ob | Die Datei lieferte einen 404. Eine fehlende llms.txt gilt als optional, nicht als Fehler |
Kumulative Layout-Verschiebung | Visuelle Stabilität, damit Agenten, die nach Elementpositionen handeln, während einer Verschiebung nicht das Falsche anklicken | Nie; wird immer bewertet |
WebMCP-Tools registriert | Ob die Seite WebMCP-Tools über die deklarative oder die imperative API registriert | Es wurden keine WebMCP-Tools erkannt |
WebMCP-Formularabdeckung | Deklarative Formulare, denen Tool-Annotationen fehlen | Wie oben |
WebMCP-Schemata gültig | Ob registrierte Tools gültige Ein- und Ausgabeschemata veröffentlichen | Wie oben |
Aufgeklappte Kategorieansicht: zwei Fehler, ein bestandenes Audit und drei nicht zutreffende Prüfungen. Die Fehlerliste ist die kürzeste Aufgabenliste.
Dass die drei WebMCP-Audits als „nicht zutreffend“ erscheinen, ist 2026 normal. WebMCP ist ein vorgeschlagener Standard in der Phase von Origin Trial und früher Vorschau, mit zwei APIs: einer deklarativen, die normale HTML-Formulare annotiert, und einer imperativen, die Tools aus JavaScript registriert. Die meisten Websites setzen noch keine davon um, deshalb zeigen die meisten Berichte dort drei graue Kreise. Grau ist nicht rot. Behandle es nicht als Fehler.
Behebe, was die Prüfung markiert
Vier Korrekturthemen decken die sechs Audits ab. Die drei WebMCP-Zeilen brauchen nur Aufmerksamkeit, wenn du tatsächlich Tools für Agenten anbietest.
Mach den Barrierefreiheitsbaum für Agenten lesbar
Agenten nutzen den Barrierefreiheitsbaum als ihre wichtigste Karte deiner Seite. Er listet Rollen, Namen und Zustände auf. Ein Button ohne zugänglichen Namen ist für sie eine Sackgasse, für Nutzer von Screenreadern übrigens auch.
To do: Arbeite die fehlgeschlagenen Regeln aus dem aufgeklappten Audit durch. Die üblichen Verdächtigen sind Buttons, die nur ein Icon zeigen, Formularfelder ohne Label, Links mit dem Text „hier klicken“, ungültige ARIA-Rollenkombinationen und doppelte IDs, auf die ARIA verweist. Bevorzuge semantisches HTML, ergänze for-Attribute an Labels und gib eigenen Widgets eine explizite Rolle und einen Tabindex, wenn ein natives Element nicht möglich ist.
Erwartetes Ergebnis: Das Audit springt auf bestanden um, und meist verbessert sich gleichzeitig dein regulärer Barrierefreiheitswert, weil die Agentic-Browsing-Version eine fokussierte Teilmenge derselben Prüfungen ist.
Wenn du festhängst: Wenn die Korrekturliste in die Hunderte von Elementen läuft, jage nicht jedem Einzelfall hinterher. Behebe die gemeinsame Komponente, etwa den Icon-Button im Header, und führe die Prüfung erneut aus. Eine Komponente räumt oft Dutzende Zeilen ab.
Veröffentliche eine llms.txt, die die Formatprüfung besteht
Hier steckt eine Falle, in die gerade sorgfältige Menschen tappen. Das Audit prüft nicht nur, ob /llms.txt existiert. Es prüft den Inhalt, und eine Datei, die nur nackte URLs auflistet, fällt durch, weil die Prüfung nach Links im Markdown-Format sucht.
To do: Lege /llms.txt im Wurzelverzeichnis deiner Domain an, mit H1-Überschrift und echten Markdown-Links:
# Firmenname
Kurze Beschreibung dessen, was die Website abdeckt und wie sie genutzt werden sollte.
## Wichtige Seiten
- [Produktüberblick](https://example.com/product)
- [Preise](https://example.com/pricing)
- [Dokumentation](https://example.com/docs)Erwartetes Ergebnis: Das Audit wird grün. Ein 404 erscheint dagegen als nicht zutreffend und ist derzeit akzeptabel. Eine Antwort aus der 500er-Reihe oder ein Abruffehler ist ein echter Fehler, der serverseitig behoben werden muss.
Qualitätsprüfung: Rufe deine eigene /llms.txt im Terminal ab und zähle die Links. Wenn sie wie https://example.com/pricing ohne Klammern aussehen, fällt das Audit durch, obwohl die Datei online ist und Menschen sie lesen können.
Eine ehrliche Einschränkung: Die Google Suche nutzt llms.txt nicht. Googles eigener Leitfaden zur KI-Optimierung sagt, die Datei „wird der Sichtbarkeit oder den Rankings deiner Website in der Google Suche weder schaden noch nützen, da die Google Suche sie ignoriert“. Schreib sie für Agenten-Tools, die diese Konvention lesen, nicht für Rankings.
Stabilisiere das Layout, damit Agenten zielen können
Layout-Verschiebungen sind wichtiger geworden. Ein Agent, der einen Button findet und dann dessen Koordinaten anklickt, verfehlt ihn, wenn Werbung, ein Banner oder ein spät ladendes Bild den Button zwischen diesen beiden Momenten um 200 Pixel nach unten schiebt.
To do: Setze explizite Breite und Höhe (oder aspect-ratio) für Bilder und Einbettungen, reserviere festen Platz für Werbeplätze und Consent-Banner, füge nach dem Laden keinen Inhalt oberhalb bestehender Inhalte ein und animiere mit transform statt mit Eigenschaften, die das Layout neu berechnen.
Erwartetes Ergebnis: Eine kumulative Layout-Verschiebung unter 0,1 im Laborlauf, also derselbe Schwellenwert, den die Core Web Vitals verwenden.
Qualitätsprüfung: Der Abschnitt zu den Ursachen der Layout-Verschiebung im Performance-Bereich des Berichts nennt die genauen Elemente. Fang dort an, statt zu raten.
Entscheide später über WebMCP
Die drei WebMCP-Audits werden nur bewertet, wenn deine Website Tools registriert. Wenn du einen Buchungsablauf, einen Checkout, ein Support-Formular oder irgendeine strukturierte Aufgabe hast, die ein Agent erledigen könnte, lohnt sich ein WebMCP-Prototyp: Er sagt dem Agenten genau, welches Tool er aufrufen soll, statt ihn aus dem DOM raten zu lassen. Chrome liefert die Funktion hinter einem Origin Trial und einem lokalen Test-Flag, es ist also eine echte Option und kein Gedankenspiel.
Wenn du keine Aufgabe hast, die sich zu automatisieren lohnt, lass WebMCP in Ruhe. Drei graue Kreise sind kein Problem. Was du nicht tun solltest: ein dekoratives Tool registrieren, nur damit die Bruchzahl besser aussieht. Die Kategorie ist ein Signal für Bereitschaft, und Trickserei untergräbt ihren Zweck.
Überprüfe die Korrektur
Führe dieselbe URL erneut in PSI aus und vergleiche drei Dinge statt eines: die Bruchzahl, die konkreten Audit-Status und den Gerätetyp. Eine Korrektur kann die Bruchzahl bewegen, ohne das Problem zu lösen, das dich interessiert hat, und Mobil und Desktop liefern getrennte Laborergebnisse.
Für schnellere Iterationen führe Lighthouse lokal aus, statt auf PSI zu warten. Die Kategorie ist ab Lighthouse 13.3 enthalten, eine lokale Installation nimmt sie also mit. Wenn du die Version im DevTools-Panel willst, weist Googles Dokumentation darauf hin, dass das Testen der Kategorie Chrome 150 oder neuer erfordert und die WebMCP-Audits zusätzlich die Registrierung im Origin Trial.
Führe eine kurze Notiz zum Vorher und Nachher. Eine datierte Zeile wie „2026-09-11: Mobil 1/3, Barrierefreiheitsbaum und llms.txt fehlgeschlagen“ reicht. Sie sagt dir, ob eine spätere Verschlechterung echt ist oder nur ein Schwanken zwischen Läufen.
Was diese Prüfung nicht ist
Drei Dinge tut sie nicht, weil die Verwechslung weit verbreitet ist:
- Sie ist kein Ranking-Faktor. Googles Ankündigung bezeichnet die Kategorie als informativ und nicht benchmarkt. Die Rankings in der Google Suche bleiben von deiner Agentic-Browsing-Bruchzahl unberührt.
- Sie ist kein KI-Sichtbarkeitswert. Sie misst, ob ein Agent deine Seite bedienen kann, und sagt nichts darüber aus, ob ChatGPT oder Perplexity dich in einer Antwort zitieren.
- Sie ist kein Bestanden-Durchgefallen-Urteil über deine Website. Eine niedrige Bruchzahl auf einer einfachen Marketingseite heißt meist, dass es wenig zu bewerten gab, und nicht, dass Agenten ausgesperrt sind.
Die Perspektive, die hilft: Diese Kategorie prüft, ob deine Website standhält, wenn der Besucher kein Mensch ist. Alles, was sie belohnt, lohnt sich ohnehin: semantisches HTML, stabile Layouts, beschriftete Bedienelemente. Googles eigener Leitfaden für agentenfreundliche Websites endet mit demselben Punkt: Was eine Website für Agenten bereit macht, macht sie auch für Menschen besser.
Nimm sie in deinen Review-Rhythmus auf
Agentenbereitschaft gehört zu den Bereichen, in denen sich die Plattform schneller bewegt als die Checkliste. Zwei Gewohnheiten halten dich auf dem Laufenden, ohne dass daraus ein Projekt wird:
- Führe die Prüfung nach jeder Änderung an Template, Navigation, Formular oder Checkout erneut aus. Genau diese Änderungen bewegen den Barrierefreiheitsbaum und die Layout-Stabilität.
- Verfolge die Bruchzahl pro Template, nicht pro URL. Zehn Produktseiten mit demselben Ergebnis sind ein Template-Problem, und eine Korrektur löst alle zehn.
Die PSI-Prüfung ist bewusst eng: sechs Audits, eine Seite nach der anderen. Wenn du das größere Bild willst, inklusive der Frage, ob Robots-Regeln, MCP-Server-Karten, OAuth-Discovery und Signale für Agenten-Commerce vorhanden sind, führt Auspia eine kostenlose Agent-Readiness-Prüfung, die eine URL gegen diese Protokollstandards scannt und eine Vergleichstabelle zeigt.
Häufige Fragen
Beeinflusst der Agentic-Browsing-Wert die Google-Rankings? Nein. Google beschreibt die Kategorie als informativ, und sie ist kein Teil der Ranking-Systeme der Suche. Behandle sie als Bereitschaftsprüfung für Agenten, nicht als SEO-Wert.
Warum hat sich meine Bruchzahl zwischen zwei Läufen auf derselben Seite geändert? Dynamische Tool-Registrierung, DOM-Änderungen, die den Barrierefreiheitsbaum verändern, und späte Layout-Verschiebungen erzeugen Schwankungen zwischen Läufen. Teste erneut und vergleiche die Auditliste, nicht nur die Bruchzahl.
Warum zeigen alle drei WebMCP-Audits „nicht zutreffend“? Weil deine Seite keine WebMCP-Tools registriert. Das ist 2026 der erwartete Zustand für die meisten Websites und kein Fehler.
Ist eine fehlende llms.txt ein Problem? Für dieses Audit nicht. Ein 404 gilt als nicht zutreffend. Eine Datei, die existiert, aber fehlerhaft formatiert ist, fällt dagegen durch. Wenn du also eine veröffentlichst, dann richtig.
Kann ich das in CI ausführen? Ja, sobald die Kategorie in deiner Lighthouse-Version enthalten ist. Die Audits sind von Natur aus deterministisch, und genau das macht sie für Pipeline-Prüfungen geeignet. Beachte, dass die WebMCP-Teile von Browser-Unterstützung und Origin-Trial-Teilnahme abhängen, in den meisten CI-Umgebungen also als nicht zutreffend erscheinen dürften.
Brauche ich Chrome 150, um das überhaupt zu nutzen? Nein. PageSpeed Insights führt es serverseitig aus. Die Chrome-150-Anforderung gilt für das lokale Ausführen der Kategorie in den DevTools.
Autorin: Alice Monroe, Analystin für KI-SEO-Tools bei Auspia, wo sie über 150 Tools abdeckt. Sie schreibt über SEO und KI-Suche-Tools, darüber, welche Prüfungen deine Zeit wert sind, und wie man sie in den Arbeitsalltag einbaut.
