Agent-friendly Websites: HTML, Accessibility Tree und klare Interaktionen

Browser-Agenten – Systeme, die eine Website eigenständig bedienen, statt sie nur anzuzeigen – sind kein Zukunftsszenario mehr, sondern laufen bereits in Kundensupport-Tools, Preisvergleichs-Plugins und Assistenz-Apps mit. Für Website-Betreiber:innen ändert das die Ausgangslage: Eine Seite muss nicht mehr nur für Menschen und Suchmaschinen funktionieren, sondern auch für ein System, das sie Schritt für Schritt bedient – ein Formular ausfüllt, einen Button anklickt, eine Statusmeldung liest. Die gute Nachricht vorweg: Die technische Grundlage dafür ist nicht neu erfunden. Sie heißt sauberes, semantisches HTML mit einem funktionierenden Accessibility Tree – demselben Fundament, das seit Jahren für Screenreader gilt.

Problem & Zielgruppe: Wenn niemand die Seite mehr „nur ansieht”

Für Geschäftsführung, Operations, IT und Fachbereich in KMU stellt sich damit eine neue Frage neben der klassischen SEO-Optimierung: Kann ein Agent auf unserer Website überhaupt erfolgreich etwas erledigen – ein Angebot anfragen, einen Termin buchen, ein Produkt bestellen? Das betrifft besonders Websites mit Formularen, Checkout-Strecken, Terminbuchung oder Produktkatalogen, bei denen die eigentliche Wertschöpfung nicht im reinen Lesen, sondern in der Interaktion liegt.

Der Denkfehler, der hier häufig passiert: Agent-Freundlichkeit wird mit neuen Spezialformaten verwechselt – eigene KI-Sitemaps, Zusatzdateien, umgeschriebene Texte „für die KI”. Google stellt dazu im eigenen AI-Optimierungsleitfaden klar, dass Dateien wie llms.txt und ähnliches „spezielles” Markup nicht notwendig sind und von der Google-Suche ignoriert werden – ebenso wenig ist es nötig, Inhalte in winzige Häppchen zu zerlegen oder speziell für KI-Systeme umzuschreiben. Der tatsächliche Hebel liegt woanders: in der technischen Struktur, die Agents überhaupt erst verstehen können.

Begriffe kurz geklärt: DOM, Accessibility Tree, Browser-Agent

Drei Begriffe, die im Artikel ständig vorkommen und oft durcheinandergeraten:

• DOM (Document Object Model) ist die Baumstruktur aus HTML-Elementen, wie sie der Browser nach dem Rendern vorhält – inklusive Verschachtelung, IDs, Klassen und Attributen.
• Accessibility Tree ist eine browsereigene, aus dem DOM abgeleitete Struktur, die laut web.dev „das Wichtigste destilliert: Rollen, Namen und Zustände interaktiver Elemente” – eine Karte, die visuelles CSS-„Rauschen” ignoriert. Er ist die Datenquelle, auf die Screenreader seit Langem zugreifen.
• Browser-Agent meint hier ein System, das eine Website automatisiert bedient – klickt, tippt, liest Ergebnisse aus –, im Unterschied zu einem klassischen Suchmaschinen-Crawler, der nur Inhalte indexiert.

Wichtig ist die Abgrenzung nach unten: Agent-Optimierung ist kein Ersatz für klassische technische SEO oder Content-Qualität. Sie kommt obendrauf, sobald auf der Seite tatsächlich etwas zu tun ist, nicht nur zu lesen.

Wie sehen Agents eine Website?

Laut web.dev nutzen Browser-Agents drei sich ergänzende Wahrnehmungswege. Erstens den Screenshot: „The agent takes a snapshot of the rendered page and uses a vision model to identify elements” – der Agent erkennt Buttons, Formularfelder und Text anhand visueller Hinweise wie Farbe, Größe und Nähe zueinander, so wie ein Mensch es täte. Der Haken dabei, wörtlich aus der Quelle: Bildanalyse „can be slow and expensive (in terms of used tokens)”.

Zweitens das DOM: Der Agent liest die HTML-Struktur direkt, „versteht, wie Elemente verschachtelt sind, die logische Hierarchie des DOM-Baums, Attribute wie IDs und Klassen, die Struktur definieren”. Drittens der Accessibility Tree als bereinigte, hochwertige Karte der interaktiven Elemente samt ihrer Rollen, Namen und Zustände.

In der Praxis, so web.dev, kombinieren moderne Agents alle drei Wege: DOM und Accessibility Tree liefern eine saubere, strukturierte Liste der interaktiven Elemente, die dann mit der visuellen Darstellung abgeglichen wird. Für Website-Betreiber:innen heißt das: Wer nur an das Bild denkt (schönes Design, hübsche Icons), optimiert für einen von drei Kanälen – und lässt die zwei robusteren Kanäle links liegen.

Warum ist Accessibility relevant?

Das ist der Kernpunkt, der in der Diskussion um „agent-friendly” Websites oft untergeht: Der Accessibility Tree ist keine neue, KI-spezifische Technologie. Es ist dieselbe browsereigene Struktur, die Screenreader für blinde und sehbehinderte Nutzer:innen seit Jahren auslesen. Eine Website, die für Screenreader unbedienbar ist – Buttons ohne erkennbare Rolle, Formularfelder ohne zugeordnetes Label, Statusänderungen, die niemand ankündigt –, ist damit für Browser-Agents ebenso unbedienbar.

Das bedeutet in der Praxis: Wer Barrierefreiheit bereits ernst nimmt, hat einen großen Teil der Agent-Optimierung ohne Zusatzaufwand bereits erledigt. Umgekehrt lässt sich Agent-Freundlichkeit nicht nachträglich als Kosmetik über eine inaccessible Seite legen – sie muss aus derselben strukturellen Disziplin kommen: semantisches HTML statt gestylter div-Suppe.

Konkret empfiehlt web.dev unter anderem: „Prefer <button> and <a> tags over modified <div> and <span> elements. Agents recognize these as interactive.” Und für Formularfelder: „Add the for attribute on <label> tags to link them to inputs. This helps the AI agent understand the purpose of a field.” Als zusätzliches visuelles Signal für Interaktivität nennt die Quelle cursor: pointer in CSS – ein „starkes Signal für Handlungsfähigkeit”, das sowohl Menschen als auch Screenshot-lesende Agents hilft.

Wie gestaltet man Formulare und Status?

Formulare sind der Ort, an dem Agent-Bedienbarkeit am direktesten auf Geschäftsergebnisse einzahlt – jede Anfrage, jede Buchung, jede Bestellung läuft durch eines. Zwei Bausteine sind entscheidend.

Labels korrekt verknüpfen. Jedes Eingabefeld braucht ein <label> mit for-Attribut, das auf die id des Feldes zeigt. Ohne diese Verknüpfung sieht der Accessibility Tree ein Feld ohne erkennbaren Zweck – für Screenreader ebenso ein Problem wie für Agents.

Statusänderungen ankündigen. Formulare erzeugen laufend Zustände, die rein visuell dargestellt oft unsichtbar für DOM- und Accessibility-Tree-basierte Wahrnehmung bleiben: „Feld gesendet”, „Fehler in Zeile 3”, „Bitte warten”. MDN beschreibt dafür ARIA-Live-Regions als Standardlösung: Ein Container mit aria-live="polite" wird von assistiven Technologien vorgelesen, sobald sich sein Inhalt ändert – ohne die laufende Aktivität der Nutzenden zu unterbrechen. Für wirklich dringende Fälle gibt es aria-live="assertive" beziehungsweise die Rolle role="alert", die laut MDN „meist angekündigt werden, auch wenn sie bereits im Markup vorhanden sind” – MDN warnt aber ausdrücklich davor, role="alert" zusätzlich mit aria-live="assertive" zu kombinieren, weil das in manchen Screenreadern zu doppelten Ansagen führt.

Ein technisches Detail, das in der Praxis häufig übersehen wird: „Assistive technologies will generally only announce dynamic changes in the content of a live region”, so MDN. Das heißt konkret: Die Live-Region muss leer im initialen Markup stehen; der eigentliche Inhalt wird erst danach per JavaScript gesetzt. Steht der Erfolgstext von Anfang an im Markup und wird nur unauffällig ausgetauscht, ist die Ankündigung unzuverlässig. Für Meldungen, bei denen der volle Kontext zählt („Das gesetzte Jahr ist: 2026” statt nur „2026”), ergänzt aria-atomic="true" die Live-Region, sodass der komplette Inhalt statt nur der geänderten Teilstring vorgelesen wird.

Meine Erfahrung aus Website-Projekten: Diese Details werden fast nie aus Böswilligkeit weggelassen, sondern weil sie in der Design-Abnahme unsichtbar sind – ein Formular ohne Live-Region sieht für Auftraggeber:innen genauso aus wie eines mit. Genau deshalb gehört ein Accessibility-Check in jeden Formular-Launch, nicht nur in barrierefreiheitspflichtige Projekte.

Welche Interaktionen sind problematisch?

Aus den Empfehlungen von web.dev lässt sich eine Liste von Mustern ableiten, die sowohl Screenshot-basierte als auch DOM-/Accessibility-Tree-basierte Agent-Wahrnehmung stören:

Muster	Warum problematisch	Quelle/Beleg
Klick-Handler auf div/span statt <button>/<a>	Fehlende implizite Rolle im Accessibility Tree; Agent erkennt Element nicht als interaktiv	web.dev: „Agents recognize these as interactive” (bezogen auf Button/Link)
Interaktive Fläche unter 8 Quadratpixeln	Wird laut web.dev aus der Erkennung herausgefiltert	web.dev: „…have a visible area larger than 8 square pixels, to avoid being filtered out”
Transparente/„Ghost”-Overlays über echten Elementen	Verdecken das eigentliche Ziel-Element für Klick/Erkennung	web.dev: „Avoid ‚ghost’ elements or transparent overlays that might hide interactive elements”
Springendes/instabiles Layout während des Ladens	Verwirrt Screenshot-basierte Erkennung, Klick trifft falsches Element	web.dev: „Agents that take screenshots will likely be confused if your website layout is constantly shifting”
Label ohne for-Verknüpfung	Feldzweck im Accessibility Tree nicht erkennbar	web.dev-Empfehlung zum for-Attribut
Statusänderung ohne Live-Region	Erfolg/Fehler bleibt für nicht-visuelle Wahrnehmung unsichtbar	MDN ARIA Live Regions

Eigene Zusammenstellung Philogic Labs auf Basis der oben zitierten Primärquellen.

Eine Kategorie, die in keiner der geprüften Quellen mit Zahlen belegt ist, aber rein strukturell einleuchtet: Interaktionen, die absichtlich Automatisierung verhindern sollen – etwa CAPTCHAs – blockieren per Definition auch legitime Agents, die im Auftrag eines Menschen handeln. Ob das an einer bestimmten Stelle im Nutzerpfad sinnvoll ist (Login, Zahlungsauslösung) oder unnötige Reibung erzeugt (reine Informationsseite, Kontaktformular), ist eine bewusste Abwägung – keine pauschale Antwort, die sich aus den Quellen ableiten lässt.

Wie testet man agentische Nutzung?

Der niedrigschwelligste Einstieg ist laut web.dev der Accessibility Tree direkt in den Chrome DevTools: Er zeigt, was Screenreader und Agents tatsächlich von einer Seite „sehen” – unabhängig vom visuellen Design. Wer prüfen will, ob ein Formularfeld korrekt beschriftet ist oder ein Button als solcher erkannt wird, findet die Antwort dort schneller als über visuelle Inspektion.

Darüber hinaus gilt für Agent-Tests im Grunde dieselbe Logik wie für klassische Accessibility-Audits: automatisierte Prüfwerkzeuge finden strukturelle Fehler (fehlende Labels, falsche Rollen), ersetzen aber keinen echten Durchlauf. In meiner Arbeit ergänze ich automatisierte Checks deshalb um einen praktischen Testlauf entlang der wichtigsten Nutzerpfade – Kontaktformular absenden, Termin buchen, Produkt in den Warenkorb legen – einmal mit ausgeschaltetem CSS (zeigt die reine DOM-Reihenfolge) und einmal mit einem echten Browser-Agent, der die Aufgabe eigenständig zu lösen versucht. Wo der Agent hängen bleibt, hängt oft auch ein Screenreader oder ein Mensch mit Tastaturbedienung.

Wichtig für die Erwartungshaltung: Aus den geprüften Quellen lässt sich keine Erfolgsquote oder Automatisierungsrate für Agent-Tests ableiten – das wäre je nach Agent-System, Aufgabe und Seite zu unterschiedlich. Was sich seriös sagen lässt: Der Accessibility Tree ist ein objektiver, werkzeuggestützter Anhaltspunkt; der praktische Testlauf zeigt, ob die Theorie in der konkreten Umsetzung auch trägt.

Einordnung: Was strukturierte Daten wirklich leisten

Ein verbreitetes Missverständnis ist, dass mehr Schema.org-Markup automatisch zu besserer Agent- oder KI-Sichtbarkeit führt. Google stellt dazu im eigenen AI-Optimierungsleitfaden klar, dass strukturierte Daten für KI-Features nicht zwingend erforderlich sind. Wo sie eingesetzt werden – JSON-LD ist laut Googles Richtlinien zu strukturierten Daten das empfohlene Format, Microdata und RDFa werden ebenfalls unterstützt –, gelten klare Regeln: Markup darf nicht vor dem Googlebot verborgen werden (kein robots.txt- oder noindex-Ausschluss auf Seiten mit strukturierten Daten), es darf ausschließlich für tatsächlich sichtbare Inhalte verwendet werden, und es muss den echten Seiteninhalt widerspiegeln. Google betont zudem ausdrücklich: Auch korrekt eingebundenes Markup garantiert keine Rich-Result-Darstellung.

Für Agent-Freundlichkeit heißt das: Strukturierte Daten sind ein sinnvoller, aber nachrangiger Baustein – nach sauberem HTML und funktionierendem Accessibility Tree, nicht davor.

Umsetzung: Priorisierung in der Praxis

Nicht jede Seite braucht denselben Aufwand. Aus meiner Projekterfahrung hat sich folgende Reihenfolge bewährt, wenn Ressourcen begrenzt sind:

Priorität	Bereich	Typischer Aufwand	Wann besonders wichtig
1	Kernformulare (Kontakt, Anfrage, Checkout): Labels, Live-Regions, semantische Buttons	Gering bis mittel, oft Detailkorrekturen im bestehenden Code	Immer – hier entscheidet sich, ob ein Agent die Aufgabe abschließen kann
2	Accessibility Tree der Hauptnavigation und CTAs prüfen (Chrome DevTools)	Gering, primär Zeit für die Prüfung selbst	Bei Seiten mit vielen Custom-Components (div-Buttons, eigene Dropdowns)
3	Layout-Stabilität beim Laden (kein Content-Shift bei zentralen Interaktionselementen)	Mittel, je nach Ursache (Fonts, nachladende Bilder, Lazy-Loading)	Bei Seiten mit sichtbaren Ladezuständen oder viel clientseitigem Rendering
4	Strukturierte Daten (Product, FAQ, Organization) korrekt und vollständig	Mittel, abhängig von der Seitenzahl	Bei E-Commerce, Stellenanzeigen, FAQ-lastigen Seiten – als Ergänzung, nicht als Ersatz für 1–3

Eigene Priorisierungslogik Philogic Labs, abgeleitet aus Umsetzungsprojekten und den oben zitierten Primärquellen.

Diese Priorisierung ist besonders relevant für Websites mit Produktkatalogen oder Bestellstrecken, bei denen Shopping-Agents zunehmend eigenständig recherchieren und bestellen. Wer diese Zielgruppe technisch ernst nimmt, landet inhaltlich bei denselben Fragen wie beim Thema Agent-Ready für Shopping und Produktdaten: Sind Produktdaten strukturiert, vollständig und für automatisierte Abfragen zugänglich?

Risiken & Grenzen

Ein paar ehrliche Einschränkungen gehören dazu. Erstens: Es gibt keine allgemeingültige Checkliste, die „100 % agent-ready” garantiert – Agent-Systeme unterscheiden sich in ihrer Implementierung, und keine der geprüften Quellen liefert eine verbindliche Zertifizierung oder Erfolgsmetrik dafür. Zweitens: Agent-Optimierung ersetzt keine klassische technische SEO und keine Content-Qualität – Google weist im AI-Optimierungsleitfaden ausdrücklich darauf hin, dass der Fokus auf hilfreichen, für Menschen gedachten Inhalten bleibt („helpful, reliable, and people-first”), nicht auf Tricks für KI-Systeme.

Drittens, und das ist rechtlich relevant, aber keine Rechtsberatung (Stand Juli 2026): Nicht jede Website unterliegt einer gesetzlichen Barrierefreiheitspflicht, aber die technischen Mittel für Agent-Freundlichkeit und für gesetzliche Barrierefreiheit (etwa nach dem Barrierefreiheitsstärkungsgesetz für bestimmte Angebote) überschneiden sich stark. Wer aus Agent-Gründen investiert, investiert meist gleichzeitig in Rechtssicherheit – das ersetzt aber keine eigene rechtliche Prüfung im Einzelfall.

Viertens: Kein Umbau macht eine Seite „unsichtbar sicher” gegen fehlerhafte Agent-Interaktionen. Wenn ein Agent im Auftrag eines Kunden ein Formular ausfüllt, trägt am Ende weiterhin ein Mensch die Verantwortung für das, was abgeschickt wird – technische Zugänglichkeit ist eine Voraussetzung für zuverlässige Bedienung, keine Garantie dagegen, dass etwas schiefgeht.

Checkliste: Agent-friendly Website

1. Interaktive Elemente nutzen <button> und <a> statt gestylter div/span-Konstruktionen.
2. Jedes Formularfeld hat ein <label> mit korrektem for-Attribut.
3. Statusänderungen (Erfolg, Fehler, Laden) laufen über ARIA-Live-Regions mit leerem Initial-Markup.
4. role="alert" und aria-live="assertive" werden nicht gleichzeitig auf demselben Element verwendet.
5. Interaktive Flächen sind größer als 8 Quadratpixel und klickbare Elemente signalisieren das per cursor: pointer.
6. Keine transparenten Overlays oder „Geister”-Elemente über echten Interaktionszielen.
7. Das Layout bleibt beim Laden stabil, insbesondere bei zentralen Buttons und Formularfeldern.
8. Der Accessibility Tree in den Chrome DevTools wurde für die wichtigsten Journeys geprüft.
9. Mindestens ein Nutzerpfad wurde praktisch mit einem Browser-Agent durchgespielt.
10. Strukturierte Daten (falls vorhanden) sind sichtbar, vollständig und blockieren nicht per robots.txt oder noindex.
11. Es gibt keine unnötigen Sonderformate „nur für die KI” (z. B. exzessives llms.txt-Vertrauen) – der Fokus liegt auf der eigentlichen HTML-Struktur.
12. Kein Nutzerpfad verlässt sich darauf, dass Menschen etwas rein visuell erkennen, das strukturell nicht hinterlegt ist.

Wenn du unsicher bist, wo deine Website in dieser Liste steht: Ein kostenloses Erstgespräch klärt in kurzer Zeit, ob sich eine tiefere technische Prüfung lohnt – im Rahmen unseres Beratungsangebots prüfen wir Websites und Content-Prozesse auch gezielt auf Agent- und KI-Zugänglichkeit. Wer die Grundlagen dazu im Team verankern will, findet passende Formate in unseren Schulungen. Weitere Themen rund um Web, SEO und GEO für KMU sammelt die Kategorieseite Web, SEO & GEO.