Der Agent klickt wie ein Mensch - und ist schnell überfordert
ChatGPT Atlas, Perplexity Comet, Claude for Chrome: Diese Agenten betrachten die gerenderte Seite und klicken sich durch, wie ein Mensch es täte. Das ist flexibel, aber fehleranfällig. Ein einziger missverständlicher Button, ein Formularfeld ohne Beschriftung, ein Layout, das springt, und die Aufgabe bricht ab. Du kannst in der KI-Antwort ganz oben stehen und den Verkauf trotzdem verlieren, weil der Agent im Checkout hängenbleibt.
Die Fehlerquellen sind bekannt und wiederholen sich. Die meisten Fixes sind kleine, gezielte Eingriffe, kein Relaunch.
Wie der Agent genau vorgeht
"Wie ein Mensch" stimmt nur beim Ergebnis, nicht bei der Methode. Der Agent sieht deine Seite nicht so wie ein Mensch – er liest sie. Er macht einen Screenshot und ruft parallel dazu den Accessibility-Tree ab: die browser-eigene Struktur aus Rollen, Namen und Zuständen für jedes interaktive Element. Daran ermittelt er, welches Element zur Aufgabe passt, und feuert dann ein gezieltes Ereignis ab – einen Klick oder eine Eingabe.
Seite lesen
Screenshot und Accessibility-Tree, parallel abgerufen
Element zuordnen
„Das Feld heißt E-Mail, da gehört die Adresse rein"
Event auslösen
ein gezielter Klick oder eine Eingabe auf diesem Element
Den Accessibility-Tree nutzt er bevorzugt, weil er am eindeutigsten ist. Was strukturell sauber ausgezeichnet ist, findet er zuverlässig. Was nur visuell „nach Button aussieht", strukturell aber keiner ist, bleibt ein Ratespiel über den Screenshot, langsamer und fehleranfälliger. Genau dort entstehen die meisten Stolperfallen.
Orientierung nur nach Screenshot
- Elemente, die wie ein Button "aussehen", aber nicht als solcher ausgezeichnet sind
- Layouts, die sich verschieben, sodass eine gemerkte Position nicht mehr übereinstimmt
- Text, der in Bildern versteckt ist, oder schweres clientseitiges JS
Über den Accessibility-Tree gefunden
- Native Elemente mit klaren Rollen und States
- Felder, die mit beschreibenden, programmatischen Bezeichnungen verknüpft sind
- Es geht um den Inhalt der Struktur, nicht nur um die Pixel
Die häufigsten Fehler
Im April 2026 veröffentlichte Google Empfehlungen für agentenfreundliche Websites. Zusammen mit den Mustern, an denen Agenten in der Praxis scheitern, ergibt das diese Liste:
Instabiles Layout
Elemente, die beim Laden hin und her springen, oder Schaltflächen, die je nach Seitentyp an unterschiedlichen Stellen liegen: Ein auf Screenshots basierender Bot klickt dann in den leeren Bereich. Fix: einheitliche Layouts und ein niedriger CLS-Wert (feste Bildabmessungen, Platzhalter).
<div onclick> anstatt <button>/<a>
Selbst erstellte anklickbare Elemente tauchen in der Struktur kaum auf. Fix: Verwende native Elemente; wo das nicht möglich ist, setze zumindest role und tabindex.
Unbeschriftete Buttons und Felder
Ein Icon-Button ohne Label, oder ein Feld ohne ist für den Agenten namenlos. Fix: beschreibende Beschriftungen, Formularfelder programmatisch verknüpfen.
Transparente Overlays
Unsichtbare Schichten über interaktiven Elementen machen diese unbrauchbar. Fix: vermeiden oder sauber schließbar machen.
Aufwändiges Client-side-Rendering
Eine Seite, die bis zum JavaScript leer ist, ist für viele Bots leer. Fix: Rendere die Kerninhalte auf dem Server oder platziere sie weit oben im HTML-Code.
Maus- und Hover-only-Bedienung
Menüs, die sich nur beim Hovern öffnen, oder Drag-and-Drop ohne Alternative sind für den Agenten unerreichbar. Fix: per Fokus und Klick bedienbar machen.
Endlos-Scroll ohne Paginierung
Der Agent weiß nicht, wann er fertig ist. Fix: Biete Paginierung oder einen klaren Endpunkt an.
CAPTCHAs bei jeder Interaktion, harte Bot-Blockierung
Das trifft legitime Agenten im Auftrag von Nutzern genauso wie Missbrauch. Fix: gezielt an empfindlichen Stellen statt pauschal anwenden.
Einen Schritt weiter: WebMCP
Stolpersteine aus dem Weg zu räumen bedeutet, dem Agenten nicht in die Quere zu kommen. WebMCP geht noch einen Schritt weiter: Anstatt den Agenten die Benutzeroberfläche interpretieren zu lassen, deklarierst du deine wichtigsten Aktionen direkt. So versteht der Agenten, was ein bestimmter Button macht. Das macht die Interaktion verlässlicher, besonders bei komplexen Abläufen.
WebMCP ist noch ziemlich neu und nicht breit verfügbar, aber es ist das aktive Gegenstück zu derselben Arbeit – es deklariert Aktionen, anstatt den Agenten raten zu lassen. Wie das technisch funktioniert und wie du den Zugriff des Agenten dabei misst, wird in einem separaten Artikel behandelt.
Wie viel das ausmacht
Eine Studie der UC Berkeley und der University of Michigan (A11y-CUA, CHI 2026) hat einen Agenten der aktuellen Generation 60 Alltagsaufgaben erledigen lassen und dabei zwei Interaktionswege verglichen.
~78% Erfolgsquote
Der Agent klickte nach Sicht, so wie er es heute standardmäßig auf den meisten Websites tut.
~42% Erfolgsquote
Der nicht-visuelle Pfad – derselbe, den Screenreader und der Accessibility-Tree nutzen.
Die Erfolgsquote wurde fast halbiert, einfach weil sich der Agent auf die strukturelle Navigation verlassen musste, anstatt nach Sicht zu klicken. Struktur ist kein nettes Extra – sie entscheidet oft, ob die Aufgabe ausgeführt wird.
Testen statt raten
Ist deine Website bereit für KI-Agenten? So testest du sie:
Mit echten Agenten durchspielen
Der Agentenmodus von Perplexity Comet ist kostenlos. Lass ihn deine kritischen Abläufe durchgehen: Suche, Warenkorb, Buchung, Anfrage. Im beruflichen Kontext lohnt es sich, das über die gängigen Agenten hinweg zu testen, anstatt bei einem Browser zu bleiben, da sich ihre Verhalten unterscheiden.
Einen festen Testfall einrichten
Anstatt es nur einmal zu probieren, bau deine wichtigsten Aufgaben in einen wiederholbaren, automatisierten Test ein, der regelmäßig läuft. So merkst du sofort, wenn ein Relaunch oder ein neues Feature einen Weg für Agents kaputtmacht – im Grunde ein Regressionstest für die Usability.
Behalte das Agentic Browsing Audit im Auge
Google bringt einen eigenen Audit für Lighthouse heraus, der eine Seite auf ihre KI-Agenten-Tauglichkeit prüft – von der semantischen Struktur bis hin zu typischen Blockern. Das Ganze kommt mit Chrome 150 – also noch nicht in der aktuellen Version 149 – und lässt sich vorerst nur vorab über Chrome Canary testen.
Schau dir den Accessibility-Tree an
In den Chrome DevTools (Elements → Accessibility) siehst du genau die Struktur, auf die der Agent trifft – dort erkennst du, wo Namen oder Rollen fehlen.
Nebenbei: Derselbe Aufwand zahlt sich mehrfach aus
Der praktische Bonus: Fast all diese Verbesserungen — semantisches HTML, klare Beschriftungen, servergerenderten Inhalt, einen niedrigen CLS-Wert — sind genau dieselben, die deine Website auch für Screenreader und Suchmaschinen besser machen. Den CLS trackst du zum Beispiel schon über die Core Web Vitals, in PageSpeed Insights und der Search Console. Google sagt im Grunde, dass KI-freundlich und menschenfreundlich hier verschmelzen. Du baust also nicht für irgendeine exotische neue Zielgruppe — du optimierst Grundlagen, die sich ohnehin schon über mehrere Kanäle auszahlen.
English 
German