TL;DR: KI-Agenten nehmen Ihre Website durch drei unterschiedliche Linsen wahr (Screenshots, rohes DOM und den Accessibility Tree), und die meisten Sites sind allen drei ungewollt feindlich gesinnt. Die nötigen Korrekturen überschneiden sich mit den Accessibility- und Core-Web-Vitals-Maßnahmen, die Sie ohnehin angehen sollten. Nachfolgend finden Sie eine Prioritätenreihenfolge, einen 5-Minuten-Audit und eine Messschleife, die Sie noch heute starten können.
Vor ein paar Wochen baute ich unser Agent-Readiness-Tool. Ziel war es, echte Kundensites einem Playwright-basierten Agenten vorzusetzen und zu beobachten, wie er sie nutzt. Also richtete ich ihn auf unsere eigene Startseite – die, die ich gefühlt tausendmal veröffentlicht hatte – und bat ihn, die Preisseite zu finden.
Er klickte den falschen CTA. Dann versuchte er, einen Button zu klicken, der gar keiner war (ein hastig gestyltes <div>). Schließlich gab er auf und fragte mich, wo die Preise stünden.
Ich wusste, dass unsere Site Hover-States hatte, die die sekundäre Navigation einblenden. Ein Mensch bewegt den Cursor, das Menü erscheint, Problem gelöst. Der Agent arbeitete jedoch mit einem einzigen Screenshot des Ruhezustands. Es gab keinen Cursor. Die reine Hover-Navigation existierte für ihn schlicht nicht.
An dem Tag hörte ich auf, KI-Agenten als schlauere Crawler zu betrachten, und begann, sie als neue Besucherklasse mit seltsamen Einschränkungen zu sehen. (Nebenbei: Ich war monatelang davon ausgegangen, sie verhielten sich wie Googlebot mit Extraschritten. Damit lag ich ein halbes Jahr lang falsch.) Was folgt, habe ich seither gelernt – vor allem, indem ich Dinge kaputtgemacht und die Reaktionen der Agenten beobachtet habe.
Ein KI-Agent, der auf Ihrer Startseite landet, crawlt nicht für einen Suchindex. Er versucht einen Auftrag zu erledigen, den ihm ein Mensch gegeben hat: Flug buchen, Tarife vergleichen, Produkt in den Warenkorb legen. Er hat Minuten, nicht Stunden, und jeder Fehlklick kostet den Nutzer Geld in Form von Inferenz-Tokens.
Das ändert das Designproblem. Ein Suchbot kann lautlos scheitern und niemand merkt es. Ein Agent scheitert öffentlich, vor einem zahlenden Nutzer, und beim nächsten Mal bittet derselbe Nutzer den Agenten, Ihre Site zu überspringen. KI-Suchmaschinen verhalten sich zunehmend ähnlich: Kann der Crawler keine sichere Antwort aus Ihrer Seite extrahieren, geht die Antwort an diejenige, die sauber parsebar ist. Die Klicks, die Sie früher aus der SERP bekamen, werden durch Zitationen in einer KI-Zusammenfassung ersetzt – und Zitationen gewinnt man durch Lesbarkeit, nicht durch Werbebudget.
Einen längeren Blick auf die Entdeckungsseite dieses Themas liefert der Silo-Beitrag Ask Engine Optimization. Dieser Artikel behandelt die andere Hälfte: was passiert, wenn ein Agent Ihre Site tatsächlich benutzen will.
Das ist der Teil, den ich mir vor einem Jahr gewünscht hätte. Es gibt nicht nur eine Art, wie Agenten Webseiten sehen. Es sind drei, und die großen Anbieter kombinieren sie unterschiedlich.
„Agenten können Ihre Website auf drei primäre Arten betrachten: Screenshots, rohes HTML und den Accessibility Tree. Der Accessibility Tree ist eine browsernative API, die das DOM auf das Wesentliche destilliert: Rollen, Namen und Zustände interaktiver Elemente. Für einen KI-Agenten fungiert er als hochauflösende Karte, die den visuellen ‚Lärm‘ von CSS ignoriert und sich auf reine Funktionalität konzentriert.“
— Kasper Kulikowski & Omkar More, web.dev: Build agent-friendly websites
So verteilt es sich Anfang 2026 nach Anbieter: Claude von Anthropic arbeitet nur mit Screenshots. Das Modell sieht ein Bild 1024×768, interpretiert Pixelkoordinaten und steuert damit die Maus; DOM-Input gibt es nicht. OpenAIs Operator (CUA) legt Screenshots mit DOM- und Accessibility-Tree-Daten übereinander, auch wenn die Launch-Doku vor allem den Screenshot-Loop betont und man das DOM-Layering eher in Third-Party-Reverse-Engineering erkennt. Googles Project Mariner liest sowohl Pixel als auch DOM. Playwright-Frameworks wie browser-use priorisieren den Accessibility Tree und fallen auf Screenshots zurück, wenn das scheitert.
Wichtiger als die Architektur sind hier die Kosten. Ein Snapshot des Accessibility Trees einer typischen Seite wiegt 2 bis 5 KB. Ein Screenshot derselben Seite 100 KB oder mehr. Das ist ein Kostenfaktor von etwa 20- bis 50-fach pro Schritt in Inferenz-Tokens. Agenten, die den Accessibility Tree nutzen können, haben starke Anreize, das zu tun. Sites mit sauberem Accessibility Tree werden benutzt; Sites ohne werden teuer, produzieren mehr Fehlaktionen und werden schließlich übersprungen.
Sie können den Accessibility Tree Ihrer eigenen Site sofort sehen: Chrome DevTools öffnen, in den Reiter „Accessibility“ wechseln, „Enable full accessibility tree“ aktivieren. Unbenannte generische Knoten blendet Chrome standardmäßig aus – genau die Elemente, mit denen Agenten kämpfen.
Zitationen sind die neuen Klicks – zumindest bei manchen Anfragen. Laut Profounds Auswertung entfallen 47,9 % von ChatGPTs Top-10-Quellenanteil auf Wikipedia, Reddit stellt 21 % der Google-AI-Overviews und 46,7 % bei Perplexity. Die Muster ändern sich ständig (per Leapd-Tracking fiel ChatGPTs Reddit-Anteil letzten Winter in sechs Wochen von ~60 % auf 10 %, nachdem Google nur einen Parameter änderte), aber die Richtung bleibt: KI-Engines belohnen Content, den sie sicher parsen können, und verwerfen den Rest.
„Einige LLMs wie ChatGPT und Claude führen kein JavaScript aus (im Gegensatz zu Gemini). Server-Side Rendering (SSR) ist daher entscheidend, damit wichtiger Inhalt in deren Antworten auftaucht.“
— Aleyda Solis, AI Search: Where Are We & What Can We Do About It?
Dieser eine Satz ist konkreter als vieles, was ich zu AI-SEO gelesen habe: Wird Ihr wichtiger Inhalt clientseitig gerendert, sehen ChatGPT und Claude ihn nicht. Gemini schon. Ob Ihnen das gefällt, ist egal – es ist eine überprüfbare technische Anforderung. In unserem Beitrag zum AI-Crawler-Playbook gehen wir tiefer darauf ein, welche Crawler JavaScript ausführen und welche nicht.
Ehrlicherweise wissen wir auch, was wir nicht wissen: Es gibt keine öffentliche Studie, die Accessibility-Scores direkt mit AI-Zitationsraten korreliert. Der Mechanismus ist plausibel (Accessibility Tree wird von Agenten und Screenreadern gleichermaßen genutzt), aber der empirische Beleg fehlt. Die stärksten Indizien kommen von der Accessibility.works-Zusammenfassung einer 10.000-Site-Studie, laut der WCAG-konforme Sites 23 % mehr organischen Traffic und 27 % mehr Rankings hatten als nicht konforme Peers. Die Methodik ist dünn dokumentiert, daher betrachte ich das als Hinweis, nicht als Fundament.
Sie werden in diesem Bereich viele „8 Dinge“-Listicles sehen. Die Liste ist als Ordnungsrahmen hilfreich; sie wird nutzlos, sobald man alle acht für gleich wichtig hält. Das sind sie nicht. Hier der Vergleich.
| Signal | Was ein Agent sieht, wenn es passt | Was bricht, wenn es fehlt | Aufwand |
|---|---|---|---|
| Native semantische Elemente | <button>, <a>, <h1> erscheinen mit impliziten Rollen im a11y-Tree |
Gestylte <div>-Buttons tauchen im a11y-Tree gar nicht auf |
Niedrig |
| Accessible Names bei Inputs | „input, type=email, label='Email address'“ | „input, type=text“ (Placeholder allein erzeugt keinen Namen) | Niedrig |
| Sichtbare interaktive Ziele | Buttons größer als ~8 Quadrat-px (empirische Untergrenze von web.dev), ideal 24×24 CSS-px (WCAG 2.5.8 AA) | Vision-Modelle filtern kleine Ziele aus; Mauskoordinaten-Agenten verfehlen sie | Niedrig |
| Stabiles Layout (niedriger CLS) | Klickkoordinaten treffen das Ziel | Lazy-Load-Bilder verschieben die Seite; Agent klickt daneben | Mittel |
| Servergerenderter Inhalt | ChatGPT und Claude sehen das komplette HTML beim ersten Abruf | Nur clientseitig hydrierter Inhalt ist für Non-JS-Crawler unsichtbar | Mittel-hoch |
| Überschriften-Hierarchie | Ein <h1>, verschachtelte <h2>/<h3> mit Rollen |
Visuelle Überschriften als <p> = keine Dokumentstruktur |
Niedrig |
| Keine Ghost-Overlays / Fokustrappen | Klick-Events erreichen das sichtbare Element | Transparente Layer fangen Klicks ab; Agent scheitert | Mittel |
| Vorhersehbare URLs und Formulare | Agent kann nach Navigation fortsetzen; Felder beschreiben sich selbst | SPA-Routen ohne History verwirren mehrstufige Tasks | Mittel |
Zwei Signale dominieren: native semantische Elemente und Accessible Names. Wenn die fehlen, ist der Rest egal. Unter den paar Hundert Sites, die wir seit Launch durch unseren Agent-Readiness-Check gejagt haben, ist der häufigste Einzelfehler genau das: ein CTA als gestyltes <div>, das im Accessibility Tree verschwindet. Etwa jede zweite Startseite hat mindestens einen. Die 8-Quadrat-Pixel-Untergrenze (web.dev) ist empirisch, kein hartes Modelllimit; Vision-Encoder wie CLIP nutzen 14×14- oder 16×16-Pixel-Patches – ein viel höherer Boden. Behandeln Sie 8 px also als Minimum, nicht als magische Zahl.
Der Teil fehlt in vielen anderen Agent-Readiness-Artikeln. Dort gibt es Checklisten mit 8 bis 30 Punkten, und dann ist man allein. So gehe ich wirklich vor, wenn ich fünf Minuten zwischen Meetings habe.
Minute 1. Unseren kostenlosen Agent-Ready-Check ausführen. Er füttert Ihre Startseite an einen Playwright-Agenten und meldet Dinge wie ein gestyltes <div role="button"> ohne tabindex, ein verstecktes Input, das den Fokus fängt, oder einen CTA, den der Agent im Screenshot sah, aber nicht im Accessibility Tree erreichte. Das Tool haben Lida und ich nach dem Hover-State-Fiasko gebaut (wir stritten über das Timing – sie wollte sauberere Daten, ich shipte die rohe Version). Es ist kostenlos und fragt nicht nach einer E-Mail.
Minute 2. Site in Chrome öffnen, DevTools, Reiter „Accessibility“, kompletten Tree einblenden. Nach Knoten mit Rolle „generic“ und ohne Namen suchen. Jeder davon ist eine Stelle, an der der Agent raten muss.
Minute 3. Den Vibe-Coded-Scanner auf dieselbe URL loslassen. Er erkennt Muster, die Cursor, Copilot und Lovable standardmäßig ausspucken: <div onClick>-Buttons, fehlende Form-Labels, Überschriften als Paragraphen. (Den Scanner baute ich, weil inzwischen die Hälfte der Sites, die wir auditieren, KI-generiert ist – und die Generatoren können noch kein semantisches HTML.)
Minute 4. Einen Lighthouse-Audit fahren. CLS-Wert notieren. Alles über 0,1 ist grenzwertig; über 0,25 klickt der Agent regelmäßig daneben. Accessibility-Score ebenfalls notieren; derselbe Audit meldet fehlende Labels und Kontraste, die Screenreader und Agenten gleichermaßen betreffen.
Minute 5. Das schlimmste Einzelproblem aus den vier Reports heraussuchen und notieren. Morgen genau dieses eine Problem fixen. Nicht die ganze Liste auf einmal.
Fünf Minuten sind das reale Budget der meisten Marketing-Leads. Haben Sie mehr Zeit – großartig. Haben Sie weniger – reicht dieser Loop, um das größte Problem Ihrer Site aufzudecken, und meist ist das alles, was man wissen muss.
Drei Muster verursachen den Großteil der Fehler, die ich sehe. Erstens der gestylte <div> als Button: sieht aus wie ein Button, hat Hover-State, reagiert auf Klick – ist für den Accessibility Tree aber kein Button.
„Verwenden Sie kein
<div>,<span>oder ein anderes nicht interaktives Element. Wenn man es nicht mit der Tastatur an-tabben kann, ist es wahrscheinlich eine schlechte Idee.“— Adrian Roselli, Links, Buttons, Submits, and Divs, Oh Hell
Roselli schrieb das 2016, lange bevor jemand in diesem Kontext „KI-Agent“ sagte. Die Tastatur-Tab-Heuristik passt heute exakt: Wenn man es nicht tabben kann, taucht es nicht im Accessibility Tree auf, und ein Playwright-Agent sieht es nicht. Die Rechnung für ein Jahrzehnt gestylter Div-Buttons wird gerade fällig.
Zweitens Layout-Instabilität. Wir sahen das massiv bei unserer Migration von .io auf .com. Einige neu geladene Hero-Bilder schoben den „Get started“-Button 40 Pixel nach unten, etwa 800 ms nach dem Rendern. Menschen fiel das kaum auf. Playwright-Agenten identifizierten den Button an der Originalposition, warteten einen Schlag und klickten ins Leere. Kein Hypo: Playwright-Issue #6238 dokumentiert Lazy-Load-Shifts, die falsche Klicks auslösen – immer noch offen. CLS aus Lighthouse ist hier meine verlässlichste Kennzahl. Über 0,1 wird’s heikel.
Drittens Ghost-Overlays. Cookie-Banner, die nicht wirklich verschwinden, GDPR-Pop-ups mit transparentem Backdrop, Intercom-Widgets auf z-index 9999 über Ihrem CTA. Jede dieser Schichten fängt Klicks ab, die der Agent für etwas Sichtbares darunter vorgesehen hatte. Web.dev nennt das explizit, unser Vibe-Coded-Scanner markiert es.
„Diese Geräte verlassen sich auf den Accessibility Tree – den Mechanismus, mit dem Computer assistiver Technologie die programmatische Interpretation von UI-Inhalten ermöglichen. Durch bewährtes Markup machen wir unsere Arbeit vielseitig und robust.“
— Eric Bailey, Truths about digital accessibility
Bailey schrieb das 2019 über Screenreader und Assistive Tech. Der Satz, an dem ich hängenbleibe, ist „der Mechanismus, den Computer nutzen“. Er definiert den Accessibility Tree als Programmschnittstelle für Maschinen, nicht speziell für Menschen mit Behinderungen. Mit KI-Agenten verschmelzen drei Jobs (Accessibility, SEO-Crawlability, Agent-Readability) zu einem: eine saubere, maschinenlesbare Beschreibung Ihrer UI liefern.
Eine längere Behandlung der SEO-Seite finden Sie im Beitrag Accessibility for SEO. Kurzfassung: Dieselben Maßnahmen (semantisches HTML, Accessible Names, stabiles Layout) bewegen gleichzeitig drei Metriken.
Wenn Sie aus diesem Artikel nur eines mitnehmen, dann diese Reihenfolge:
<div>/<span>-Buttons durch <button> ersetzen. Höchster Hebel, geringste Kosten.<label for> für jedes Form-Input. Placeholder ≠ Accessible Name.<h1>, saubere Struktur.
Ich habe Teams gesehen, die zwei Wochen an einer llms.txt basteln, bevor sie ihren gestylten-Div-Checkout-Button fixen. Falsche Reihenfolge.
Fixes sind live – und jetzt?
Für Layout-Stabilität ist der Lighthouse-Audit die günstigste verlässliche Messung. Vorher/nachher laufen lassen, CLS, Accessibility-Score und INP beobachten. (Als wir unsere <div>-Buttons ersetzten, stieg der Accessibility-Score um 14 Punkte, CLS fiel von 0,18 auf 0,04.)
Für Agent-Readability konkret erneut den Agent-Ready-Check fahren. Er liefert eine Parseability-Score und listet CTAs, die der Agent erreichen konnte oder nicht. Wichtig: „CTAs erfolgreich erkannt“ – wenn nicht 100 %, rät der Agent noch.
Für KI-Zitationen (das SEO-Ergebnis) unser Backlink-Checker nutzen, um Erwähnungen in KI-Zusammenfassungen zu tracken. Zitationen von ChatGPT, Perplexity und AI Overviews verhalten sich wie Backlinks – nur aus neuen Quellen. Wenn Ihre Fixes greifen, tauchen sie in Wochen, nicht Tagen auf. Unsere AI-Visibility-Audit-Methodik erklärt den langsamen Loop.
Einen oft zitierten Wert von Wil Reynolds via Orbit Media will ich einordnen: „0,8 % Traffic, 10 % Leads“. Reale Zahl, nutzbar, aber eben eine Unternehmenskennzahl aus einem bestimmten Zeitfenster. Reynolds selbst sagt, sie sei kein universeller Multiplikator. Für mich zeigt sie, dass AI-Traffic überproportional konvertiert – nicht mehr, nicht weniger.
WebMCP ist die Spezifikation, die man im Auge behalten sollte. Sie erlaubt einer Website, JavaScript-Tools zu registrieren, die KI-Agenten direkt aufrufen können – die Seite wird zum Model-Context-Protocol-Server. Chrome 146 Canary hat eine Flag-Preview, Edge 147 zog im März 2026 nach. Der W3C-Community-Draft stammt vom 23.04.2026.
Ich mag das Konzept, bin aber realistisch beim Timing. Die Spez sagt selbst: „Kein W3C-Standard, nicht auf dem Standards Track.“ Kein großer LLM-Anbieter hat bisher dokumentiert, WebMCP-Tools zu nutzen. Cloudflare fand weltweit weniger als 15 implementierte MCP Server Cards. Das ist eher eine 2-bis-5-Jahre-Story.
„Der Webbrowser ist für Menschen und Entwickler gebaut, nicht für agentische KI-Systeme. Die meisten Webinhalte sind visuell statt programmatisch strukturiert, mit dynamischen Elementen, komplexen Layouts und interaktiven Komponenten, die sich einfachem Parsing widersetzen.“
— Cobus Greyling, The Future of Web Browsing AI Agents
Greyling argumentiert, dass die Agent-Friendly-Checkliste (dieser Artikel) ein Workaround für ein tieferes Architekturproblem sei, das Standards wie WebMCP lösen wollen. Vielleicht hat er recht. Ob WebMCP gewinnt, llms.txt oder Microsofts NLWeb – keine Ahnung. Sicher ist: Die Prioritätspyramide oben ist jetzt relevant, während die Standardschicht sich sortiert. Unsere Einschätzung dazu lesen Sie in Agentic SEO Workflows.
Eine Site, die von KI-Agenten (Claude Computer-Use, OpenAI Operator, Project Mariner, Playwright-Crawler) ebenso zuverlässig gelesen und genutzt werden kann wie von Menschen. Kernanforderung: Interaktive Elemente müssen sich klar über den Accessibility Tree exponieren, das Layout darf sich während der Agentarbeit nicht verschieben, wichtiger Inhalt muss serverseitig gerendert sein, damit Non-JS-Crawler ihn lesen können.
Agenten nutzen bis zu drei Eingabemodalitäten: Screenshots, rohes HTML oder den Accessibility Tree. Screenshot-Only-Agenten (Anthropic) arbeiten über Pixelkoordinaten und verpassen Ziele unter ~8 px². DOM-Aware-Agenten (Project Mariner, Operator) legen Elementdaten drauf. A11y-Tree-First-Agenten (browser-use, viele Playwright-Crawler) erhalten eine saubere Struktur, übersehen aber alles, was semantisch nicht exponiert ist.
Bing bestätigt, dass Schema Copilot hilft, Inhalte zu verstehen. Google sagt, strukturierte Daten verschaffen einen Vorteil. Harte Belege, dass Schema AI-Zitationen erhöht, sind gemischt: eine Studie fand keine Korrelation, eine andere 61,7 % Zitationsrate bei attributreichem Schema. Für AI-Search hilfreich, aber kein Garant.
Ein vorgeschlagenes Dateiformat (ähnlich robots.txt), das AI-Crawlern zeigt, wo wichtiger Inhalt sauber liegt. Stand Oktober 2025 hatten es über 844.000 Sites. Verbreitung hoch, Nutzung gering: Googles John Mueller und Gary Illyes sagten, kein großes AI-System nutze es operativ. Publizieren lohnt sich, wenn Sie 10 Minuten übrig haben; wichtiger ist aber, gestylte-Div-Buttons zu fixen.
Der schnellste Weg ist ein 5-Minuten-Audit: Agent-Ready-Check ausführen, Chrome-Accessibility-Pane öffnen, Lighthouse-Report fahren, Vibe-Coded-Scan laufen lassen. Diese vier Schritte decken das größte Problem Ihrer Site auf. Erst das schlimmste fixen, dann das nächste.
KI-Agenten lesen Ihre Site über Screenshots, DOM und Accessibility Tree – je nach Anbieter in unterschiedlicher Mischung. Die meisten Fixes sind Accessibility-Maßnahmen, die Sie sowieso erledigen sollten: semantische Elemente, Accessible Names, stabiles Layout, servergerenderter Inhalt. Die Standardschicht (WebMCP, llms.txt, NLWeb) existiert, entwickelt sich aber langsam; die unspektakulären Fixes sind akut.
Führen Sie unseren kostenlosen Agent-Readiness-Check aus, um zu sehen, wie gut ChatGPT, Claude und Perplexity Ihre Site lesen können. Er zeigt, welche CTAs der Agent verpasst, welche Buttons im Accessibility Tree fehlen und welche Layout-Shifts Klicks kosten. Das Tool, das ich mir wünschte, als GPT unsere Hover-States nicht sah.
no credit card required