Wie lesen KI-Agenten und Browser-Assistenten meine Website?

Was Sie Agenten erlauben, entscheiden Sie an denselben Stellen wie für Menschen

Ein Agent, der im Auftrag eines Kunden handelt, füllt Formulare aus, legt Artikel in den Warenkorb und schließt Käufe ab. Die Sicherungen, die die WCAG für Menschen verlangen, wirken dabei auch für ihn: eine Übersicht vor dem Abschluss, eine Bestätigung vor dem Löschen, ein Weg zurück. Der WebMCP-Entwurf nennt als Risiko, dass Seiten ihre Werkzeuge so anlegen könnten, dass sie private Angaben ohne ausdrückliche Zustimmung abfragen und daraus Nutzerprofile bilden; für folgenreiche Vorgänge sieht er die Kennzeichnung vor, mit der der Browser eine Bestätigung verlangen kann. Für Ihre Website heißt das heute: Halten Sie Bestellabschlüsse, Zahlungen und Löschungen hinter einer ausdrücklichen Bestätigung, so wie es das Kriterium 3.3.4 der WCAG 2.2 zur Fehlervermeidung bei rechtlichen und finanziellen Vorgängen verlangt.

Werkzeuge wie Playwright MCP arbeiten auf diesem Baum, andere auf Bildschirmfotos

Microsoft veröffentlicht mit Playwright MCP ein Werkzeug, mit dem Sprachmodelle einen Browser steuern. Die Beschreibung des Projekts auf GitHub sagt, wie es das tut: Es lässt Sprachmodelle über strukturierte Abbilder des Barrierefreiheitsbaums mit Seiten arbeiten, nutzt diesen Baum statt bildbasierter Eingaben, braucht kein Bildmodell und arbeitet rein auf strukturierten Daten. Als Vorteil nennt Microsoft eine vorhersagbare Ausführung ohne die Mehrdeutigkeit bildbasierter Ansätze. Das Projekt zählte am 4. November 2026 rund 39.000 Sterne auf GitHub, ein Maß für Verbreitung unter Entwicklern, nicht für Nutzung durch Endkunden. Microsofts Playwright-Dokumentation zeigt, wie so ein Abbild aussieht: eine Liste mit Zeilen wie „heading „Title“ [level=1]“, „link „Read more about Accessibility““ oder „button „Toggle“ [pressed=true]“, also je Element Rolle, Name und Zustand. Andere Agenten arbeiten mit Bildschirmfotos und einem Bildmodell; Microsoft grenzt sein Werkzeug ausdrücklich von diesen Ansätzen ab. Welcher Weg sich durchsetzt, ist im November 2026 offen. Sicher ist, dass der strukturierte Weg genau das liest, was auch ein Vorleseprogramm liest.

Was ein Agent sieht, wenn Name, Rolle oder Zustand fehlen

Die Folgen lassen sich am Abbild ablesen. Eine Schaltfläche, die nur ein Symbol enthält und keinen hinterlegten Namen hat, erscheint als Schaltfläche ohne Text; der Agent weiß nicht, ob sie sucht, sendet oder löscht. Ein klickbarer Textabsatz, den ein Skript zur Schaltfläche macht, erscheint als Text, denn er hat keine Rolle. Ein Bild ohne Alternativtext erscheint ohne Namen. Ein Formularfeld ohne verknüpfte Beschriftung erscheint als Eingabefeld ohne Angabe, was hineingehört. Ein Link mit dem Text „hier“ erscheint als Link „hier“. Ein aufklappbares Menü, dessen Zustand nicht im Code steht, erscheint als geschlossen oder gar nicht. Das sind dieselben Stellen, an denen die WCAG-Kriterien Name, Rolle, Wert (4.1.2), Beschriftung im Namen (2.5.3), Nicht-Text-Inhalte (1.1.1), Beschriftungen (3.3.2) und Linkzweck (2.4.4) ansetzen. Wer diese Kriterien für Menschen erfüllt, erfüllt sie für Agenten mit, ohne einen zweiten Code zu schreiben. Ein Agent, der rein auf dem Baum arbeitet, hat an diesen Stellen keine zweite Quelle.

Google verlangt für KI-Antworten nichts Besonderes, nur indexierbaren Inhalt

Für seine KI-Übersichten und den KI-Modus in der Suche schreibt Google in seiner Dokumentation, dass es keine zusätzlichen Anforderungen und keine besonderen Optimierungen gibt. Eine Seite muss indexiert sein und für einen Textauszug in Frage kommen; auch besondere strukturierte Daten nach schema.org braucht es dafür nicht. Wer Inhalte aus KI-Antworten heraushalten will, nutzt dieselben Steuerungen wie für Textauszüge in der Suche. Zur Bildersuche sagt Google, dass es den Alternativtext zusammen mit Bilderkennung und dem Seiteninhalt nutzt und dass gewöhnliche HTML-Bildelemente dem Crawler helfen. Für Ihre Website folgt daraus: Was für die Suche gilt, gilt für Googles KI-Antworten mit. Inhalte, die nur in Bildern, in Skripten ohne Text oder hinter Klicks stehen, kommen in beiden nicht an.

Der nächste Schritt: Ihre Website bietet Agenten eigene Werkzeuge an

Unter dem Namen WebMCP arbeitet eine Gruppe beim W3C, mit Herausgebern von Microsoft und Google, an einer Schnittstelle, über die Websites Agenten eigene Werkzeuge anbieten: eine Funktion „Termin buchen“ mit beschriebenen Eingaben, statt dass der Agent sich durch das Formular klickt. Der Entwurf vom 2. November 2026 ist ein Community Group Report, kein Standard des W3C und nicht auf dem Weg dorthin; die Schnittstelle kann sich noch ändern. Der Entwurf nennt als mögliche Nutzer neben Agenten im Browser ausdrücklich auch Hilfstechnik und beschreibt im Sicherheitsteil eine Kennzeichnung für folgenreiche Werkzeuge, etwa das Buchen eines Flugs oder eine Überweisung, mit der ein Browser vor der Ausführung eine Bestätigung des Nutzers verlangen kann. Stand November 2026 ist das ein Ausblick, keine Aufgabe für Ihre Website. Was Ihre Website heute schon maschinenlesbar beschreibt, ist der Barrierefreiheitsbaum.

Tipps aus der Praxis

• Die Playwright-Dokumentation zeigt das Abbild als Liste aus Rolle und Name. Wer die eigene Seite so sieht, versteht in einer Minute, was ein Vorleseprogramm und ein Agent gemeinsam haben.
• Sprachsteuerung findet ein Element über den sichtbaren Text (Kriterium 2.5.3); ein Agent, der den Baum liest, sieht nur den hinterlegten Namen. Ein Name, der den sichtbaren Text nicht enthält, trifft beide.
• Zahlen zu Sternen auf GitHub zeigen, was Entwickler ausprobieren, nicht, was Ihre Kunden nutzen. Nehmen Sie sie als Hinweis auf die Richtung, nicht als Marktanteil.