Was braucht eine Website, damit ein KI-Agent sie überhaupt bedienen kann? Die Antwort, die derzeit am häufigsten kursiert, klingt nach Aufwand: ein MCP-Server, eine llms.txt, die Inhalte zusätzlich als Markdown. Google hat auf web.dev einen Leitfaden dazu veröffentlicht – und der liest sich deutlich unspektakulärer.
Drei Wege, wie ein Agent deine Seite liest
Der Leitfaden „Build agent-friendly websites“ von Kasper Kulikowski und Omkar More beschreibt zunächst, wie KI-Agenten technisch auf eine Website zugreifen. Es sind drei Wege [web.dev]:
- Screenshots. Der Agent macht ein Bild vom Viewport und lässt ein Vision-Modell darauf Elemente erkennen. Das funktioniert, ist aber langsam und verbraucht viele Tokens.
- HTML. Der Agent liest das DOM: Struktur, Hierarchie, Attribute.
- Der Accessibility Tree. Die Baumstruktur, die der Browser selbst aus dem DOM ableitet. Google beschreibt sie als API, die „den DOM auf das Wesentliche reduziert: Rollen, Namen und Zustände interaktiver Elemente“ [web.dev].
Der dritte Punkt ist der interessante. Der Accessibility Tree ist keine neue Erfindung für KI. Es ist genau dieselbe Struktur, die ein Screenreader benutzt, seit es Screenreader gibt.
Der Accessibility Tree ist der eigentliche Hebel
Damit fällt eine Trennung weg, die viele Jahre lang gefühlt existiert hat: Barrierefreiheit auf der einen Seite, technische Optimierung auf der anderen. Eine Seite, deren Accessibility Tree sauber ist, wird von einem Screenreader gut vorgelesen und von einem Agenten gut verstanden. Eine Seite, auf der jeder Button ein <div> mit einem Klick-Handler ist, scheitert bei beiden.
Ich sehe das in Audits regelmäßig von der anderen Seite. Wenn ich einen Prüfbericht schreibe, sind die häufigsten Befunde nicht exotische WCAG-Kriterien, sondern genau diese Basics: Elemente ohne zugänglichen Namen, Formularfelder ohne verknüpftes Label, Bedienelemente, die nur mit der Maus erreichbar sind. Dieselben Punkte stehen jetzt in einem Google-Leitfaden für KI-Agenten.
Was Google konkret empfiehlt
Die Empfehlungen sind kurz und überprüfbar [web.dev]:
- Native Elemente vor Nachbauten. „Prefer
<button>and<a>tags over modified<div>and<span>elements.“ - Wenn es nicht anders geht, dann korrekt. Lässt sich semantisches HTML nicht verwenden, braucht das Element die passende
roleund eintabindex. - Labels verknüpfen. Das
for-Attribut auf<label>gehört an das jeweilige Eingabefeld. - Layout stabil halten. Ein Agent, der Screenshots auswertet, kommt bei ständig springenden Layouts durcheinander.
- Keine „Geister“-Elemente. Transparente Overlays, die interaktive Elemente verdecken, sind für Agenten dasselbe Problem wie für Tastaturnutzer.
- Sichtbare Mindestgröße. Interaktive Elemente sollen mindestens 8 Pixel sichtbar sein.
cursor: pointersetzen. Google nennt das ein „strong signal for actionability“ – ein deutliches Signal, dass hier etwas anklickbar ist.- Zustände sichtbar machen. Jede Aktion soll sich in der Oberfläche widerspiegeln, egal ob sie ein Mensch oder ein Agent ausgelöst hat.
Das ist, mit einer Ausnahme, eine Liste, die genauso in einem WCAG-Prüfbericht stehen könnte.
Was in dem Leitfaden nicht steht
Auffällig ist, was fehlt. Von MCP-Servern, llms.txt oder einer Markdown-Ausgabe der Inhalte ist in dem Text keine Rede. Das Branchenmagazin Coywolf hat daraus die Überschrift gemacht, Google sage, man brauche „kein MCP und kein Markdown“, um agentenfreundlich zu sein [Coywolf, Sekundärquelle].
Fair bleiben: Das ist eine Interpretation, keine Google-Aussage. Google sagt nicht, dass diese Formate nutzlos sind – Google spricht schlicht nicht darüber. Aber die Prioritätensetzung ist eindeutig. Bevor du in ein zusätzliches Format investierst, das noch fast niemand ausliest, lohnt sich die Frage, ob dein bestehendes HTML die Grundlagen erfüllt.
Schonmal nachgesehen, ob die Buttons in deinem Bestellprozess echte <button>-Elemente sind? Das ist eine Sache von zwei Minuten mit den Entwicklertools – und in meiner Erfahrung überraschend oft ein Nein.
Der rechtliche Nebeneffekt
Wer die Liste abarbeitet, erledigt gleichzeitig einen Teil seiner gesetzlichen Pflichten. In Deutschland gilt das Barrierefreiheitsstärkungsgesetz (BFSG) seit 28.06.2025, in Österreich das Barrierefreiheitsgesetz (BaFG) seit demselben Datum – beide setzen die EU-Richtlinie 2019/882 um.
Die Schweiz ist nicht in der EU, dort gilt das Behindertengleichstellungsgesetz (BehiG) und verpflichtet aktuell vor allem die öffentliche Hand. Eine Teilrevision für private Anbieter ist ab 1.1.2027 geplant, aber noch nicht in Kraft. Schweizer Unternehmen, die aktiv an Kundschaft in der EU verkaufen, können allerdings schon heute unter BFSG oder BaFG fallen.
Das ist eine Einordnung, keine Rechtsberatung. Ob dein Unternehmen konkret betroffen ist, hängt an Größe, Umsatz und Angebot.
Häufige Fragen
Brauche ich jetzt einen MCP-Server für meine Website?
Für die Bedienbarkeit durch KI-Agenten laut Googles Leitfaden nicht. MCP hat andere Stärken – etwa wenn du Inhalte direkt aus dem Chat pflegen willst. Das ist ein Redaktionsthema, kein Sichtbarkeitsthema.
Und eine llms.txt?
Kostet wenig und schadet nicht. Sie ersetzt aber keine saubere HTML-Struktur, und sie ist bisher kein Standard, auf den sich die großen Anbieter verpflichtet hätten.
Reicht ein Accessibility-Overlay, um den Accessibility Tree zu verbessern?
Nein. Overlays reparieren die zugrundeliegende Struktur nicht, sie legen eine Schicht darüber. Warum das weder rechtlich noch technisch trägt, habe ich in einem eigenen Beitrag zu Accessibility Overlays aufgeschrieben.
Womit fange ich an?
Mit den Formularen und dem Bestell- oder Kontaktprozess. Dort entsteht der Schaden, wenn ein Nutzer – oder ein Agent – nicht weiterkommt. Eine Reihenfolge für WordPress-Projekte habe ich im Praxis-Guide „WordPress barrierefrei machen“ beschrieben.
Gibt es einen Überblick über die relevanten WCAG-Kriterien?
Ja, WCAG 2.2 AA verständlich erklärt geht die wichtigsten Punkte ohne Normsprache durch.
Falls du nicht sicher bist, wie es in deinem Projekt um diese Grundlagen steht: Ich schaue mir das gerne an und sage dir, welche Punkte tatsächlich etwas bringen und welche du dir sparen kannst. Über Ergänzungen und Widerspruch in den Kommentaren freue ich mich – gerade bei einem Thema, das sich gerade erst sortiert.