Was ist eine agentenfreundliche Website?
Von Philipp Kant 6 Min. Lesezeit
Eine agentenfreundliche Website ist eine Website, die KI-Agenten im Auftrag eines Nutzers bedienen können: Sie finden die Bedienelemente, verstehen, was jedes davon tut, füllen die Formulare aus und erledigen eine Aufgabe, ohne zu raten. Das Chrome-Team von Google hat im April 2026 die ersten Leitlinien dazu veröffentlicht, und Lighthouse misst es seit Chrome 150.
Gemeint sind Browser-Agenten wie ChatGPT Agent, Gemini in Chrome, Claude für Chrome und Comet von Perplexity. Jemand sagt „buch den Termin um 9:30“ oder „frag ein Angebot für 200 Stück an“, und der Agent öffnet die Website und klickt. Google führt dafür einen eigenen Crawler, Google-Agent, der laut Dokumentation von Agenten auf Googles Infrastruktur genutzt wird, „um im Web zu navigieren und auf Wunsch des Nutzers Aktionen auszuführen“.
Agenten lesen eine Seite auf drei Wegen
Googles Leitfaden Build agent-friendly websites (web.dev, April 2026) beschreibt, wie Agenten eine Seite wahrnehmen. Die meisten kombinieren alle drei Wege und gleichen sie ab.
| Sicht | Was der Agent bekommt | Wo es scheitert |
|---|---|---|
| Screenshot | Layout, Größe, Farbe, Position, gelesen von einem Bildmodell | Langsam und teuer in Tokens; zeigt nicht, was ein Element tut |
| HTML (DOM) | Elementtypen, Verschachtelung, IDs, Klassen | Ein gestyltes <div> sagt nicht, dass es ein Button ist |
| Accessibility Tree | Rollen, Namen und Zustände, vom Browser berechnet | Leer, wenn Elemente keinen Namen oder die falsche Rolle haben |
Der Accessibility Tree entscheidet die meisten Aufgaben. Es ist dieselbe
Struktur, die ein Screenreader nutzt, und sie macht aus einer Seite eine
Liste wie button "In den Warenkorb", link "Preise",
textbox "E-Mail". Ein Element, das in dieser Liste fehlt oder keinen
Namen hat, muss der Agent erraten.
Sechs Regeln aus Googles Leitfaden
Jede Regel ist alte Barrierefreiheits-Praxis. Neu ist, wer zahlt, wenn sie fehlt.
| Regel | Warum ein Agent sie braucht |
|---|---|
<button> und <a href> statt klickbarer Divs |
Agenten erkennen semantische Elemente als bedienbar; ein Div mit Klick-Handler ist für sie kein Bedienelement |
Jedes <label> per for mit seinem Feld verbinden |
Agenten füllen Formulare, indem sie den Label-Text mit ihren Daten abgleichen |
| Keine transparenten Ebenen über Bedienelementen | Die Bildanalyse verwirft womöglich, was unter einer „Geister-Ebene“ liegt, und der Klick landet auf der Ebene |
cursor: pointer auf klickbaren Elementen |
Ein visuelles Signal, dass ein Element bedienbar ist |
| Bedienelemente größer als 8 Quadratpixel | Kleinere Ziele fallen aus der Bildanalyse heraus |
| Ein Layout, das nicht springt | Ein Button, der sich zwischen Screenshot und Klick verschiebt, wird verfehlt |
Der Leitfaden nennt noch eine siebte, neuere Regel: die Aktionen der Website als WebMCP-Tools deklarieren.
Lighthouse misst jetzt die Agenten-Tauglichkeit
Im Juni 2026 hat das Chrome-Team eine Kategorie Agentic browsing für Lighthouse angekündigt, verfügbar ab Chrome 150 und als experimentell markiert. Sie vergibt keinen Wert von 0 bis 100, sondern zählt bestandene Prüfungen, in drei Gruppen:
- Barrierefreiheit für Agenten. Jedes bedienbare Element hat einen programmatischen Namen, Rollen und Eltern-Kind-Beziehungen sind gültig, und kein bedienbarer Inhalt ist im Accessibility Tree versteckt.
- Stabilität und Auffindbarkeit. Cumulative Layout Shift, und ob die
Domain im Stammverzeichnis eine
llms.txtveröffentlicht. - WebMCP-Integration. Registrierte Tools, Formulare ohne deklaratives WebMCP-Markup und gültige Tool-Schemas.
Die Chrome DevTools für Agenten spielen außerdem die Schritte nach, die ein Agent gehen würde, und zeigen den Accessibility Tree, den er liest.
Mit WebMCP deklariert eine Website ihre eigenen Tools
WebMCP ist ein vorgeschlagener Webstandard des Chrome-Teams. Eine Seite sagt dem Browser, welche Aktionen sie anbietet, mit Name, Beschreibung und Eingabeschema. Ein Agent ruft die Aktion dann direkt auf, statt sich durch die Oberfläche zu klicken. Chrome testet das ab Version 149 als Origin Trial.
Ein Tool lässt sich auf zwei Arten deklarieren:
- Deklarativ, mit Attributen an einem vorhandenen HTML-Formular. Chrome macht daraus ein Tool; die Felder werden zu Parametern.
- Imperativ, mit
document.modelContext.registerTool()in JavaScript, für Aktionen, die kein einzelnes Formular sind.
Jedes Tool-Formular auf kant.dev trägt das deklarative Markup. Das Formular des Website Speed Check, gekürzt:
<form toolname="checkWebsiteSpeed"
tooldescription="Test page speed in a real browser: Core Web Vitals,
page weight, and third-party cost for mobile and desktop."
toolautosubmit>
<input name="url"
toolparamdescription="The public web page or website to check.">
<button type="submit">Check speed</button>
</form>
Mit toolautosubmit sendet der Agent das Formular ab, sobald es
ausgefüllt ist. Ohne das Attribut füllt der Browser die Felder und wartet
auf das Absenden. Bei Formularen, die kaufen, buchen oder etwas
verschicken, sollte es fehlen, damit ein Mensch bestätigt.
Was das für einen Shop oder ein Anfrageformular heißt
Bei den meisten Unternehmen sind es wenige Seiten, die Agenten bedienen: Suche, Produktseiten, Angebots- oder Kontaktformular, Buchung, Checkout. Genau dort kostet ein kaputtes Bedienelement Geld.
- Ein Fake-Button beendet die Aufgabe. Ist „Angebot anfordern“ ein Div, das der Agent nicht als Button erkennt, meldet er zurück, die Seite biete keine Anfrage an. Der Käufer geht zum nächsten Anbieter, den der Agent gefunden hat.
- Felder ohne Label bekommen falsche Daten. Ein Agent, der Lieferdatum und Bestelldatum nicht unterscheiden kann, füllt das falsche Feld oder bricht ab.
- Das Cookie-Banner ist das erste Hindernis. Auf jeder europäischen Website muss der Agent zuerst ein Banner schließen. Echte, benannte Buttons machen das zu einem Klick; ein Banner aus Divs kann den Besuch beenden.
- Tempo und Stabilität zählen doppelt. Layout-Verschiebungen kosten schon bei den Core Web Vitals; bei Agenten kosten sie zusätzlich Fehlklicks.
Agenten ersetzen keinen Suchverkehr, sie bringen eine neue Art Besuch, der entweder gelingt oder scheitert. Ob ChatGPT und Perplexity die Inhalte überhaupt lesen können, ist eine eigene Frage; siehe Können KI-Crawler JavaScript lesen?
So prüfen Sie eine Seite in zwei Minuten
- Lassen Sie den kostenlosen AI Agent Readiness Check über die wichtigste Seite laufen. Er meldet Fake-Buttons, Elemente ohne Namen, fehlende Labels, unsichtbare Ebenen, Layout-Verschiebungen, WebMCP-Tools und llms.txt, und er zeigt die ersten Bedienelemente des Accessibility Tree so, wie ein Agent sie liest.
- Öffnen Sie in den Chrome DevTools den Bereich Elements, Reiter Accessibility, und sehen Sie sich den Baum für Checkout oder Formular an. Jedes Element sollte eine Rolle und einen Namen haben, den Sie auch ohne die Seite verstehen.
- Lassen Sie Lighthouse mit der Kategorie Agentic browsing laufen, ab Chrome 150.
- Beheben Sie zuerst die semantischen Bedienelemente. Das behebt auch die meisten Barrierefreiheits-Befunde, die in der EU ohnehin zählen; siehe die besten kostenlosen Barrierefreiheits-Checker.
FAQ
Ist eine agentenfreundliche Website dasselbe wie eine barrierefreie? Größtenteils. Semantische Bedienelemente, Namen, Labels und ein gültiger Accessibility Tree helfen Screenreadern und Agenten gleichermaßen. Agenten bringen zwei Punkte dazu: unsichtbare Ebenen und Layout-Verschiebungen, die das Klicken nach Screenshot stören, und WebMCP, das keine assistive Technik nutzt.
Brauche ich WebMCP schon jetzt? Noch nicht. Es ist ein Origin Trial in Chrome, und die Attributnamen können sich noch ändern. Die deklarativen Attribute an zwei, drei wichtigen Formularen kosten eine Stunde und nichts, falls sich der Standard noch ändert; die semantischen Korrekturen kommen zuerst.
Halten sich KI-Agenten an robots.txt? Google dokumentiert, dass seine nutzerausgelösten Fetcher, darunter Google-Agent, robots.txt in der Regel ignorieren, weil ein Mensch den Besuch angefordert hat. robots.txt regelt das Crawling, nicht einen Agenten, der für einen Nutzer handelt.
Wirkt sich Agenten-Tauglichkeit auf SEO aus? Nicht als Rankingfaktor. Die Korrekturen decken sich mit dem, was die Suche ohnehin belohnt (schnelle, stabile, semantische Seiten), und sie entscheiden, ob ein Agent, der über ein Suchergebnis kommt, seine Aufgabe zu Ende bringt.
Was ist llms.txt? Eine vorgeschlagene Markdown-Datei im Stammverzeichnis einer Domain, die die Website zusammenfasst und ihre wichtigsten Seiten für Sprachmodelle verlinkt. Die Lighthouse-Kategorie Agentic browsing prüft, ob es sie gibt; die von kant.dev entsteht aus den Inhalten der Seite.
Prüfen Sie Ihre eigene Seite mit dem kostenlosen AI Agent Readiness Check. Shops, Formulare und Buchungsstrecken, die auch für die Agenten Ihrer Kunden funktionieren, sind Teil dessen, was wir bauen.
Diesen Artikel mit einer KI besprechen