Eine Website für KI-Agenten bereitest du vor allem mit Grundlagen vor, die auch Menschen helfen: eindeutig beschriftete Buttons, Links und Formularfelder, ein Layout, das beim Laden nicht springt, und klar aufgebaute Formulare. Wer weiter gehen will, beschreibt wichtige Formulare zusätzlich mit WebMCP, einem neuen Vorschlag von Google und Microsoft, über den Agenten Aktionen gezielt statt per Klick-Simulation ausführen. Ob deine Seite das schon kann, zeigt die experimentelle Lighthouse-Kategorie „Agentic Browsing“.
In dieser Anleitung erfährst du, was Lighthouse genau prüft, in welcher Reihenfolge du die Punkte angehst und wo die Grenzen liegen. Wichtig vorab: Die Kategorie ist laut Google noch in Entwicklung, und WebMCP läuft derzeit als Testphase in Chrome. Nichts davon ist Pflicht – die ersten beiden Schritte lohnen sich aber unabhängig von KI.
Wie bedienen KI-Agenten eine Website?
KI-Agenten im Browser sollen Aufgaben für Nutzer erledigen: ein Formular ausfüllen, ein Produkt konfigurieren, einen Termin anfragen. Dafür müssen sie verstehen, welche Elemente auf einer Seite bedienbar sind und was sie bewirken. Google nennt in der Lighthouse-Dokumentation zur Barrierefreiheit für Agenten den Barrierefreiheitsbaum (Accessibility Tree) als zentrale Informationsquelle: Fehlt einem Button ein verständlicher Name, scheitert der Agent ähnlich wie ein Screenreader-Nutzer.
Viele Agenten arbeiten zusätzlich mit Screenshots und Bildschirmkoordinaten. Verschiebt sich das Layout nach dem Laden, berechnen sie laut Googles Hinweisen zur Layout-Stabilität die Position eines Buttons falsch, und die Aktion schlägt fehl.
Der dritte Weg ist neu: Mit WebMCP bietet eine Website Agenten selbst definierte Werkzeuge an, etwa „Supportanfrage senden“ mit festgelegten Feldern. Der Agent muss dann nicht mehr raten, welches Feld wofür da ist. Die Spezifikation entsteht in der Web Machine Learning Community Group des W3C; die Editoren arbeiten laut aktuellem Entwurf der WebMCP-Spezifikation bei Microsoft und Google. Ein offizieller W3C-Standard ist WebMCP damit noch nicht.
Abzugrenzen ist das von KI-Crawlern, die Inhalte für Training oder Suche abrufen. Wie du diese steuerst, steht im Beitrag KI-Crawler in der robots.txt steuern. Hier geht es um Agenten, die deine Seite im Auftrag eines Nutzers aktiv bedienen.
Was prüft die Lighthouse-Kategorie „Agentic Browsing“?
Google hat die Kategorie mit Lighthouse 13.3 im Mai 2026 in die Standardkonfiguration aufgenommen, wie die Lighthouse-Versionshinweise auf GitHub zeigen. Im Quelltext ist sie als „still under development and subject to change“ gekennzeichnet. Sie bündelt folgende Prüfungen:
| Prüfung | Was Lighthouse kontrolliert | Ohne Umsetzung |
|---|---|---|
| Barrierefreiheitsbaum wohlgeformt | 33 Regeln aus den Barrierefreiheitsprüfungen, z. B. Namen von Buttons, Links und Auswahllisten, Formular-Labels, gültige ARIA-Rollen und -Attribute | Fehlschlag mit Liste der betroffenen Elemente |
| Layout-Stabilität (CLS) | Unerwartete Verschiebungen beim Laden | Fehlschlag bei schlechtem Wert |
| WebMCP-Formularabdeckung | Ob Formulare deklarative WebMCP-Angaben haben | in der Regel „nicht zutreffend“ |
| Registrierte WebMCP-Werkzeuge | Liste aller per HTML oder JavaScript angebotenen Werkzeuge | in der Regel „nicht zutreffend“ |
| Gültigkeit der WebMCP-Schemas | Ob die Werkzeugbeschreibungen dem erwarteten Schema entsprechen | in der Regel „nicht zutreffend“ |
| llms.txt | Ob eine Datei im Hauptverzeichnis liegt und Grundregeln erfüllt (Überschrift, Umfang, Links) | „nicht zutreffend“ bei 404 |
Die Liste der 33 Regeln steht im Quelltext des Lighthouse-Audits für den Barrierefreiheitsbaum. Einen Wert von 0 bis 100 gibt es nicht. Laut Googles Dokumentation zur Bewertung zeigt der Bericht einen Bruch aus bestandenen Prüfungen, dazu Bestanden oder Fehlgeschlagen je Prüfung. Nicht zutreffende Prüfungen zählen nicht gegen dich – wer keine KI-Funktionen eingebaut hat, verliert nach der Auswertung von DebugBear keine Punkte.
So rufst du die Prüfung auf
- Chrome DevTools: Laut Google setzt die Kategorie Chrome 150 oder neuer voraus. Öffne die Entwicklertools, wechsle zum Tab „Lighthouse“ und wähle die Kategorie aus.
- PageSpeed Insights: Seit Lighthouse 13.4.1 ist die Kategorie auch für die PageSpeed-Insights-Schnittstelle freigeschaltet.
- Kommandozeile: Mit einer aktuellen Lighthouse-Version (npm-Paket
lighthouse) läuft die Kategorie standardmäßig mit.
Für die WebMCP-Prüfungen verlangt Google zusätzlich die Teilnahme am WebMCP-Origin-Trial, also der zeitlich begrenzten Testphase in Chrome. Ohne diese Anmeldung bleiben die Prüfungen in der Regel „nicht zutreffend“.
Schritt für Schritt: So bereitest du deine Website für KI-Agenten vor
Die Reihenfolge folgt dem Nutzen: Zuerst kommen die Punkte, die auch Besuchern, Screenreader-Nutzern und deinen Core Web Vitals helfen. WebMCP und llms.txt sind optionale Ergänzungen.
1. Bedienelemente eindeutig beschriften
Prüfe zuerst, ob jeder Button, jeder Link und jedes Formularfeld einen zugänglichen Namen hat. Typische Fehler sind Symbol-Buttons ohne Text (Lupe, Warenkorb, Menü), Links mit „hier“ oder „mehr“, Eingabefelder ohne verknüpftes label und Auswahllisten ohne Beschriftung.
- Verknüpfe jedes Feld über
forundidmit einem sichtbaren Label. - Gib Symbol-Buttons ein
aria-label, etwa „Suche öffnen“ statt nur einer Lupe. - Formuliere Linktexte so, dass sie ohne Umgebung verständlich sind.
- Setze ARIA-Rollen nur dort ein, wo kein passendes HTML-Element existiert, und prüfe sie auf Gültigkeit.
- Achte auf eindeutige IDs – doppelte IDs brechen die Zuordnung von Labels.
Wie du die Bedienung ohne Maus testest, zeigt der Beitrag Tastaturbedienung der Website prüfen. Was dort funktioniert, hilft fast immer auch Agenten.
2. Layout-Verschiebungen beseitigen
Die Prüfung übernimmt den bekannten Messwert Cumulative Layout Shift. Als gut gilt laut web.dev-Leitfaden zu CLS ein Wert von 0,1 oder weniger, als schlecht ein Wert über 0,25. Häufige Ursachen sind:
- Bilder und Videos ohne
width– undheight-Angaben, - nachträglich eingeblendete Hinweisleisten, Anzeigen oder Widgets ohne reservierten Platz,
- Webfonts, die deutlich anders laufen als die Ersatzschrift,
- Inhalte, die oberhalb bereits sichtbarer Elemente eingefügt werden.
Für WordPress-Seiten findest du die Diagnose im Beitrag WordPress-Website schneller machen.
3. Wichtige Formulare mit WebMCP beschreiben
Die einfachste WebMCP-Variante ist die deklarative API: Du ergänzt ein bestehendes HTML-Formular um wenige Attribute. Das Attribut toolname am Formular vergibt einen eindeutigen Werkzeugnamen – fehlt es, wird kein Werkzeug registriert. tooldescription beschreibt, was das Formular tut. An einzelnen Feldern erklärt toolparamdescription den Zweck; fehlt es, nutzt der Browser das zugehörige Label.
<form toolname="kontaktanfrageSenden" tooldescription="Sendet eine Kontaktanfrage an das Team." action="/kontakt/" method="post">
<label for="name">Name</label>
<input id="name" name="name" required>
<label for="nachricht">Nachricht</label>
<textarea id="nachricht" name="nachricht" toolparamdescription="Anliegen in eigenen Worten"></textarea>
<button type="submit">Absenden</button>
</form>Ruft ein Agent dieses Werkzeug auf, füllt der Browser die Felder sichtbar vor. Absenden muss der Nutzer laut Google selbst. Erst das zusätzliche Attribut toolautosubmit lässt das Formular automatisch absenden. Verzichte darauf bei Bestellungen, Zahlungen oder anderen folgenreichen Aktionen.
Für eigene Tests aktivierst du in Chrome das Flag chrome://flags/#enable-webmcp-testing. Damit normale Besucher mit Chrome davon profitieren, ist derzeit die Anmeldung zum Origin Trial nötig, den Google ab Chrome 149 anbietet. Google weist ausdrücklich darauf hin, dass sich die Schnittstellen noch ändern können.
4. Komplexere Aktionen per JavaScript anbieten
Für Abläufe ohne klassisches Formular – etwa einen Produktkonfigurator oder eine Verfügbarkeitsabfrage – gibt es die imperative API. Über document.modelContext.registerTool() registrierst du ein Werkzeug mit Name, Beschreibung, einem JSON-Schema für die Eingaben und einer Funktion, die die Aktion ausführt.
Wichtig sind die optionalen Kennzeichnungen: readOnlyHint markiert Werkzeuge, die nur Daten lesen. consequentialHint kennzeichnet folgenreiche oder nicht umkehrbare Aktionen, bei denen Agenten eine Bestätigung des Nutzers einholen können. Kennzeichne ehrlich – ein Werkzeug, das etwas bestellt oder löscht, ist nie „nur lesend“.
Diese Variante lohnt sich vor allem für Shops und Webanwendungen mit eigenem Entwicklungsteam. Für eine klassische Unternehmenswebsite reichen saubere Formulare meist aus.
5. llms.txt nur bewusst einsetzen
Die llms.txt ist ein Vorschlag von Jeremy Howard: eine kurze Markdown-Datei im Hauptverzeichnis mit einer H1-Überschrift (der einzige Pflichtteil), einer kurzen Zusammenfassung und Abschnitten mit Linklisten zu wichtigen Seiten. Lighthouse wertet eine fehlende Datei laut Dokumentation zum llms.txt-Audit als „nicht zutreffend“, meldet aber Serverfehler beim Abruf.
Für die Google-Suche brauchst du die Datei nicht. Google schreibt in seiner Dokumentation zu KI-Funktionen in der Suche, dass für KI-Übersichten und den KI-Modus keine neuen maschinenlesbaren Dateien, KI-Textdateien oder besonderes Markup nötig sind. Legst du eine llms.txt an, halte sie aktuell – eine veraltete Datei mit toten Links schadet mehr, als sie nützt.
Wo liegen Grenzen und Risiken?
- Kein bekannter Rankingfaktor: Google beschreibt die Kategorie als experimentell. Eine Aussage, dass sie die Suche beeinflusst, gibt es in der Dokumentation nicht.
- Bewegliches Ziel: Zwischen Lighthouse 13.3 und 13.4.1 hat Google die WebMCP-Prüfung bereits umgestellt. Rechne damit, dass sich Prüfungen und Schnittstellen weiter ändern.
- Sicherheit: Jede Aktion, die ein Agent auslösen kann, sollte serverseitig genauso abgesichert sein wie bei einem Menschen – mit Validierung, Spam-Schutz und Bestätigung bei folgenreichen Schritten. Wie du Agenten im eigenen Betrieb begrenzt, beschreibt der Beitrag KI-Agenten sicher einsetzen.
- Menschen zuerst: WebMCP ergänzt eine gut bedienbare Oberfläche, ersetzt sie aber nicht. Ein Formular, das Besucher verwirrt, wird durch Werkzeugattribute nicht besser.
Checkliste: Website für KI-Agenten
- Lighthouse-Bericht mit Kategorie „Agentic Browsing“ erstellt (DevTools ab Chrome 150, PageSpeed Insights oder Kommandozeile)
- Alle Buttons, Links, Felder und Auswahllisten haben einen zugänglichen Namen
- Symbol-Buttons mit
aria-labelbeschriftet, keine doppelten IDs - CLS bei 0,1 oder darunter, Bilder mit festen Maßen, Platz für Banner reserviert
- Wichtigste Formulare identifiziert (Kontakt, Terminanfrage, Suche)
- Optional: WebMCP-Attribute ergänzt, mit Testflag geprüft, kein automatisches Absenden bei folgenreichen Aktionen
- Optional: llms.txt mit H1, Kurzbeschreibung und aktuellen Links
- Serverseitige Validierung und Spam-Schutz für alle Formulare unverändert aktiv
Häufige Fragen
Muss ich meine Website jetzt für KI-Agenten umbauen?
Nein. Die Lighthouse-Kategorie ist experimentell, und WebMCP befindet sich in der Testphase. Sinnvoll ist es, Beschriftungen und Layout-Stabilität jetzt zu verbessern, weil das Besuchern und der Barrierefreiheit sofort hilft.
Senkt eine fehlende llms.txt meinen Lighthouse-Wert?
Nein. Liefert dein Server für /llms.txt einen 404-Status, wertet Lighthouse die Prüfung als „nicht zutreffend“. Probleme gibt es erst, wenn der Abruf mit einem Serverfehler endet oder eine vorhandene Datei die Grundregeln nicht erfüllt.
Können Agenten mit WebMCP ohne mein Wissen Bestellungen auslösen?
Bei deklarativen Formularen muss der Nutzer standardmäßig selbst absenden. Automatisches Absenden aktivierst nur du mit toolautosubmit. Bei JavaScript-Werkzeugen kennzeichnest du folgenreiche Aktionen mit consequentialHint. Absichern musst du jede Aktion trotzdem serverseitig.
Funktioniert WebMCP auch in anderen Browsern?
Derzeit testet Chrome die Schnittstelle im Origin Trial. Die Spezifikation wird gemeinsam von Google- und Microsoft-Mitarbeitern in einer W3C-Community-Group entwickelt. Wann und ob weitere Browser folgen, ist offen.
