SEO
Build agent-friendly websites: Wenn der Bot nicht mehr nur liest, sondern klickt
Sven Giese / 18. Mai 2026
- Home
- Blog
- Build agent-friendly websites: Wenn der Bot nicht mehr nur liest, sondern klickt
Google hat seine web.dev-Dokumentation um das Kapitel „Build agent-friendly websites“ erweitert. Der Text ist kein klassischer SEO‑Guide. Trotzdem steckt darin eine ziemlich klare Botschaft für SEO, GEO, UX und Webentwicklung: Websites müssen künftig nicht nur für Menschen nutzbar und für Suchmaschinen crawlbar sein. Sie sollten auch für AI‑Agents verständlich und bedienbar werden.
Google beschreibt AI‑Agents als autonome Systeme, an die Menschen zielgerichtete Aufgaben delegieren. Diese Agenten interpretieren Eingaben, planen Schritte und führen Aktionen auf Websites aus. Gleichzeitig weist Google darauf hin, dass viele Websites für Agenten funktional problematisch sind, etwa durch komplexe Hover-Zustände, instabile Layouts oder visuelle Effekte, die für Menschen nett aussehen, aber maschinell schwer zu interpretieren sind. (web.dev)
Für SEO ist das mehr als ein technisches Randthema. Es verschiebt den Blick von der reinen Auffindbarkeit zur funktionalen Nutzbarkeit. D.h., eine Seite muss nicht nur erklären, was ein Unternehmen anbietet, sondern einem Agenten auch ermöglichen, eine passende Aktion zuverlässig zu erkennen und auszuführen.
TL;DR
- Google rückt mit agentengerechten Websites (englisch: agent-friendly websites) eine neue Nutzungssituation in den Fokus: KI-Agenten sollen auf Websites gezielt Aufgaben erledigen, ohne dass ein Mensch jeden Schritt vorgibt.
- KI-Agenten analysieren Websites über drei Zugänge: Screenshots, HTML/DOM und den Accessibility Tree (Quelle: Google web.dev, April 2026). Wer seine Seite für Menschen und Screenreader technisch sauber baut, ist für Agenten bereits gut aufgestellt.
- Für SEO und GEO kommt ein neuer Audit-Blick hinzu: Welche geschäftskritischen Aktionen kann ein Agent auf dieser Website zuverlässig erkennen und ausführen?
- WebMCP (Early Preview, ab Februar 2026) geht über strukturiertes HTML hinaus: Websites können KI-Agenten direkt definierte Funktionen bereitstellen, etwa für Produktsuche, Buchungen oder Support-Tickets.
- Der sinnvolle Einstieg ist ein Agent-Readiness-Audit für Kontaktseiten, Produktseiten, Formulare und interaktive Elemente. Viele Probleme lassen sich direkt in Entwickler-Tickets übersetzen, kein Relaunch nötig.
Wie KI-Agenten Websites analysieren
AI Agenten nutzen Websites anders als Menschen und benötigen maschinenlesbare Signale. Google nennt diesbezüglich drei zentrale Zugänge (Kulikowski & More, web.dev, April 2026):
- Screenshots helfen Agenten, visuelle Elemente zu erkennen. Ein großes Suchfeld, ein prominenter CTA oder ein Formularbereich lassen sich darüber einordnen. Gleichzeitig ist diese Analyse langsam und teuer, weil sie mehr Tokens verbraucht.
- HTML und DOM zeigen dem Agenten, wie Inhalte und Elemente logisch zusammenhängen. Wenn ein „Jetzt kaufen“-Button innerhalb eines Produktcontainers liegt, kann der Agent ableiten, dass sich diese Aktion auf genau dieses Produkt bezieht.
- Der Accessibility Tree reduziert die Seite auf Rollen, Namen und Zustände interaktiver Elemente. Für Screenreader ist das ohnehin zentral. Für AI Agents wird es zur funktionalen Karte der Website.
Damit wird ein alter Grundsatz wieder sehr aktuell: Was semantisch sauber gebaut ist, lässt sich besser verstehen. Sowohl für Menschen als auch für Maschinen.
Agent-friendly: Was sich für SEO und GEO ändert
Viele Empfehlungen aus Googles Dokumentation klingen für erfahrene SEOs und Entwickler vertraut.
- Echte <button>– und <a>-Elemente statt zweckentfremdeter <div>– oder <span>-Konstruktionen.
- Klare Formularlabels.
- Stabile Layouts.
- Keine unsichtbaren Overlays, die interaktive Elemente verdecken.
- Ausreichend sichtbare Klickflächen. Google nennt sogar konkret, dass interaktive Elemente, die für die User Journey nötig sind, eine sichtbare Fläche von mehr als acht Quadratpixeln haben sollten, damit sie bei visueller Analyse nicht herausgefiltert werden (Kulikowski & More, web.dev, April 2026).
Diese Aspekte liefern ein weiteres starkes Argument, weshalb Technical SEO, Barrierefreiheit und UX nicht getrennt voneinander geplant werden sollten. Bisher stand bei vielen Audits die Frage im Vordergrund, ob Google den Inhalt crawlen, rendern und indexieren kann. Diese Frage gilt es zukünftig um eine weitere Perspektive zu erweitern: Kann ein Agent auf Basis der vorhandenen Struktur eine sinnvolle Aufgabe ausführen?
Und genau an dieser Stelle machen wir das Thema praktisch.
Der Agent-Readiness-Audit
Ein sinnvoller Einstieg ist eine einfache Liste der wichtigsten Nutzeraktionen. Jede Website hat Aktionen, die wirtschaftlich oder redaktionell besonders wichtig sind.
Typische Beispiele sind hier:
- Kontakt aufnehmen
- Beratungstermin anfragen
- Produkt suchen
- Produkt konfigurieren
- Verfügbarkeit prüfen
- Kauf starten
- Standort finden
- Support-Ticket erstellen
- Datei herunterladen
- Newsletter abonnieren
- Rechner oder Tool nutzen
Für jede dieser Aktionen lässt sich prüfen, ob ein Agent die Aufgabe zuverlässig verstehen und ausführen könnte. Dabei geht es um sehr bodenständige technische Fragen.
- Ist der CTA ein echtes interaktives Element?
- Ist der Button klar benannt?
- Sind Formularfelder sauber beschriftet?
- Sind Pflichtfelder verständlich?
- Bleibt das Layout stabil?
- Verdecken Pop-ups wichtige Funktionen?
- Sind Fehlermeldungen direkt dem betroffenen Feld zugeordnet?
- Sind Inhalte im HTML vorhanden oder nur visuell nachgerendert?
- Sind Zustände wie „ausgewählt“, „nicht verfügbar“ oder „aktiv“ semantisch erkennbar?
Aus diesen Fragen entsteht ein Audit, das sich direkt in Tickets übersetzen lässt. Cloudflare hat im April 2026 einen automatisierten Agent Readiness Score eingeführt, der genau diese Prüfpunkte maschinenlesbar auswertet (Jesus & Morrison, blog.cloudflare.com, April 2026).
Praxisbeispiel 1: Kontaktformular auf einer B2B-Website
Ein Agent soll eine passende Agenturleistung prüfen und eine Anfrage stellen. Auf vielen B2B-Websites klingt das einfach. In der Praxis wird es oft unnötig schwer.
Google gibt in seiner web.dev-Dokumentation an, dass fehlende oder inkorrekt verknüpfte Labels zu den häufigsten Gründen zählen, warum Agenten Formularfelder nicht zuverlässig befüllen können (Kulikowski & More, web.dev, April 2026). Der Cloudflare Agent Readiness Score wertet dieselben Kriterien automatisiert aus. [Cloudflare-Daten prüfen: Anteil der Websites mit unvollständigen Formular-Labels aus dem Report vom 17.04.2026 ergänzen]
Typische Stolperstellen:
- Der CTA ist nur als grafisches Element umgesetzt.
- Das Formular erscheint erst nach einer Animation oder in einem Overlay.
- Pflichtfelder sind nur über Farbe markiert.
- Der Absende-Button ist kein echter Button, sondern ein JavaScript-Element.
- Fehlermeldungen stehen irgendwo auf der Seite, aber nicht beim jeweiligen Feld.
- Der Button heißt nur „Senden“, obwohl die eigentliche Aktion eine Beratungsanfrage ist.
Besser ist eine saubere, semantisch eindeutige Struktur:
<label for="email">E-Mail-Adresse</label>
<input id="email" name="email" type="email" required>
<label for="topic">Worum geht es?</label>
<select id="topic" name="topic" required>
<option value="">Bitte auswählen</option>
<option value="seo-audit">SEO-Audit</option>
<option value="geo">GEO / AI Search Visibility</option>
<option value="technical-seo">Technical SEO</option>
</select>
<button type="submit">Beratungstermin anfragen</button>
Der Unterschied liegt in der Eindeutigkeit. Ein Agent erkennt, welche Eingabe erwartet wird, welche Optionen verfügbar sind und welche Aktion mit dem Button ausgelöst wird.
Ein gutes SEO-Ticket sollte dementsprechend wie folgt formuliert werden:
„Kontaktformular: generischen Absende-Button durch eindeutig beschrifteten <button type=“submit“>Beratungstermin anfragen</button> ersetzen und alle Eingabefelder mit sichtbaren Labels verbinden.“
Das kann geprüft werden, umsetzen und abnehmen.
Praxisbeispiel 2: Produktdetailseite im E-Commerce
Im E-Commerce wird agent-friendly schnell geschäftskritisch. Ein Agent soll ein passendes Produkt finden, Varianten vergleichen, Verfügbarkeit prüfen und den Kaufprozess vorbereiten.
Typische Probleme auf Produktseiten:
- Varianten sind nur als farbige Kacheln umgesetzt.
- Größen, Farben oder technische Optionen haben keine klaren Namen.
- Verfügbarkeit wird nur über einen grünen oder roten Punkt angezeigt.
- Der Warenkorb-Button sitzt je nach Kategorie an anderer Stelle.
- Produktdaten liegen in Akkordeons, die erst nach Interaktion geladen werden.
- Ein Rabatt-Pop-up verdeckt den Warenkorb.Chrome nennt E-Commerce in seiner WebMCP-Dokumentation ausdrücklich als primären Use Case (Bandarra, developer.chrome.com, Februar 2026): Produktfinder, Variantenkonfiguration und Checkout-Flows gehören zu den Interaktionstypen, bei denen strukturierte Agenten-Schnittstellen den größten messbaren Nutzen bringen.
- Zubehör und Hauptprodukt sind visuell ähnlich, aber semantisch nicht klar getrennt.
Besser:
- Varianten haben sprechende Namen und erkennbare Zustände.
- Verfügbarkeit wird als Text ausgegeben, etwa „Auf Lager“, „Lieferbar in 3–5 Werktagen“ oder „Derzeit nicht verfügbar“.
- Der Warenkorb-Button bleibt an einer stabilen Position.
- Produktdaten stehen im HTML und nicht nur in nachgeladenen Interface-Komponenten.
- Störende Overlays blockieren keine zentralen Aktionen.
Ein mögliches Audit-Ticket lautet dann:
„Produktdetailseite: Varianten-Auswahl semantisch auszeichnen, sichtbare Variantennamen ergänzen und Verfügbarkeitsstatus als Text im HTML ausgeben.“
Genau in diese Richtung geht auch WebMCP. Chrome nennt E-Commerce ausdrücklich als Use Case: Agenten könnten Produkte besser finden, Optionen konfigurieren und Checkout-Flows präziser bedienen, wenn Websites strukturierte Interaktionen bereitstellen (Bandarra, developer.chrome.com, Februar 2026).
Praxisbeispiel 3: Lokale Dienstleisterseite
Bei lokalen Dienstleistern geht es oft um klare Basisdaten und eine konkrete nächste Aktion. Ein Agent soll Öffnungszeiten prüfen, einen Standort erkennen oder einen Termin vorbereiten.
Laut Googles Dokumentation sind Öffnungszeiten, Adressen und Kontaktdaten in Bildern oder eingebetteten Karten für Agenten vollständig unlesbar — unabhängig davon, welchen der drei Zugänge (Screenshot, DOM, Accessibility Tree) der Agent nutzt (Kulikowski & More, web.dev, April 2026). Das semantische Grundproblem ist damit für diesen Seitentyp besonders gravierend.
Typische Probleme:
- Öffnungszeiten stehen nur in einem Bild oder Slider.
- Die Adresse ist nur in einer eingebetteten Karte sichtbar.
- Telefonnummer und E-Mail-Adresse sind nicht sauber ausgezeichnet.
- Der Termin-CTA ist unspezifisch benannt.
- Die Buchung öffnet sich in einem schlecht beschrifteten iFrame.
- Leistungsbereiche sind nur als Kacheln mit Icons umgesetzt.
Besser:
- Adresse, Telefonnummer, Öffnungszeiten und Leistungen stehen als echter Text auf der Seite.
- Der Termin-CTA beschreibt die Aktion eindeutig.
- Das Buchungsformular hat klare Labels.
- Leistungen sind mit echten Überschriften und erklärenden Kurztexten strukturiert.
- FAQ-Bereiche beantworten konkrete Entscheidungsfragen.
Beispielhafte Verbesserung:
<section aria-labelledby="opening-hours">
<h2 id="opening-hours">Öffnungszeiten</h2>
<p>Montag bis Freitag: 8:00 bis 18:00 Uhr</p>
<p>Samstag: 9:00 bis 13:00 Uhr</p>
</section>
<a href="/termin-buchen/">Termin online buchen</a>
Praxisbeispiel 4: Publisher- und Ratgeberseiten
Für Publisher und Ratgeberseiten geht es weniger um Kaufprozesse, aber stark um Struktur, Zitierfähigkeit und Handlungsorientierung.
Ein Agent soll aus einem Artikel eine belastbare Antwort generieren oder eine konkrete Anleitung finden. Lange Fließtexte ohne klare Abschnittslogik machen das unnötig schwer. Für GEO ist dieser Punkt doppelt relevant: Nicht nur Agenten, auch KI-Antwortmaschinen wie ChatGPT und Perplexity extrahieren bevorzugt Passagen, die als eigenständige Antwort auf eine Frage verstanden werden können. Artikel ohne klare H-Hierarchie und ohne isoliert verständliche Schlüsselsätze werden von KI-Systemen seltener zitiert. Das ist kein GEO-spezifisches Problem, sondern dasselbe strukturelle Defizit, das auch Agenten ausbremst.
Typische Probleme:
- Der Artikel ist lang, aber schlecht gegliedert.
- Handlungsempfehlungen stehen verstreut im Text.
- Hintergrundwissen, Warnhinweise und konkrete Schritte vermischen sich.
- Interne Links heißen „hier klicken“ oder „mehr erfahren“.
- FAQ-Blöcke beantworten keine echten Nutzerfragen.
- Wichtige Aussagen sind nur im Kontext mehrerer Absätze verständlich.
Besser:
- Der Artikel trennt sauber zwischen Definition, Ursache, Risiko, Sofortmaßnahme und weiterführender Lösung.
- Konkrete Handlungsschritte stehen in Listen.
- Interne Links beschreiben das Ziel.
- Wichtige Aussagen sind auch als einzelne Passage verständlich.
- FAQ-Fragen greifen reale Such- und Entscheidungsfragen auf.
Ein konkretes Beispiel anhand eines SEO-Klassikers:
Schwacher Ankertext: „Weitere Informationen dazu finden Sie hier.“ Deutlich zielführender: „Weitere Informationen liefert die Anleitung zur richtigen Kellerlüftung im Winter.“
Das ist klassische Linktext-Optimierung, bekommt aber im Agenten-Kontext zusätzlich Gewicht. Ein Agent kann über den Linktext besser einschätzen, ob das Ziel zur aktuellen Aufgabe passt.
Praxisbeispiel 5: SaaS- und Support-Websites
Bei Support- und SaaS-Websites können Agenten besonders hilfreich werden. Sie können Fehler beschreiben, technische Details sammeln und Support-Anfragen vorbereiten.
Chrome nennt vier konkrete WebMCP-Tool-Parameter für Support-Workflows: Produktname, Problemtyp, Fehlercode und Problembeschreibung als strukturierte Eingaben, Ticketnummer und Status als definierte Ausgaben (Bandarra, developer.chrome.com, Februar 2026). Websites, die diese Felder semantisch korrekt auszeichnen, schaffen damit gleichzeitig die Basis für eine spätere WebMCP-Implementierung.
Typische Probleme:
- Das Supportformular fragt unklare Kategorien ab.
- Fehlercodes, Versionen oder Systemeinstellungen haben keine Hilfetexte.
- Dateiuploads sind schlecht erklärt.
- Nach dem Absenden gibt es keine klare Bestätigung.
- Die Ticketnummer ist nur kurz sichtbar und nicht auffindbar.
- Hilfetexte liegen in Tooltips, die ohne Hover nicht sichtbar sind.
Besser:
- Kategorien sind eindeutig benannt.
- Jedes technische Feld hat eine verständliche Beschreibung.
- Dateiformate und Größenlimits werden direkt am Upload-Feld erklärt.
- Nach dem Absenden erscheint eine klare Bestätigung mit Ticketnummer.
- Der nächste Schritt wird beschrieben.
Chrome nennt Customer Support ebenfalls als WebMCP-Use-Case: Agenten könnten detaillierte Support-Tickets erstellen und notwendige technische Details automatisch ergänzen (Bandarra, developer.chrome.com, Februar 2026).
Ein mögliches Audit-Ticket:
„Supportformular: Felder für Produktversion, Betriebssystem, Fehlercode und Problembeschreibung mit sichtbaren Labels und Hilfetexten ergänzen. Bestätigungsseite mit Ticketnummer und Status ausgeben.“
WebMCP: Wenn Websites Agenten direkte Werkzeuge anbieten
Agent-friendly Websites beginnen mit sauberer Semantik. WebMCP geht einen Schritt weiter.
Chrome beschreibt WebMCP als Möglichkeit, die Lücke zwischen Webanwendungen und Agenten zu schließen. Mit WebMCP können Websites strukturierte Tools Funktionen wie Suche, Checkout, Formularbefüllung oder Diagnoseprozesse als klar definierte Tools bereitstellen . Ziel ist, dass Agenten Aktionen schneller, zuverlässiger und präziser ausführen können, statt sich nur durch den DOM zu klicken. Diese Tools besitzen definierte Eingaben und erwartete Ausgaben, etwa über JSON-Schemas (Bandarra, developer.chrome.com, Februar 2026 und Klepper, developer.chrome.com, Mai 2026).
Für Menschen bleibt die Website weiterhin eine normale Website. Für Agenten entsteht zusätzlich eine strukturierte Handlungsebene.
Der aktuelle Stand von WebMCP im Mai 2026
WebMCP ist noch kein etablierter Webstandard für den produktiven Regelbetrieb. Es wird aber konkreter. Chrome stellt WebMCP inzwischen in der offiziellen Entwicklerdokumentation vor. Für lokale Tests lässt sich WebMCP über ein Chrome-Flag aktivieren. Ein Origin Trial ist für Chrome 149 angekündigt. Chrome beschreibt zwei Wege, um WebMCP-Tools auf einer Website bereitzustellen:
| Ansatz | Geeignet für | Kurz erklärt |
|---|---|---|
| Declarative API | Formulare und einfache Interaktionen | Bestehende HTML-Formulare können durch zusätzliche Annotationen als Tool beschrieben werden. |
| Imperative API | Komplexere Anwendungen | Tools werden per JavaScript definiert, inklusive Eingaben, Ausgaben, Status und Funktionslogik. |
Für SEO und GEO ist dieser Schritt relevant, weil Websites damit eine neue maschinenlesbare Ebene erhalten. Bisher ging es primär darum, Inhalte verständlich, crawlbar, indexierbar und zitierfähig zu machen. Mit WebMCP kommt die Frage hinzu, ob eine Website bestimmte Aufgaben für Agenten sauber beschreiben und ausführbar machen kann.
Warum WebMCP zu Agent-Friendly Websites passt
KI-Agenten arbeiten heute häufig über die zuvor skizzierten Umwege. Für Websites mit einer einfachen Informationsarchitektur funktioniert dies in der Regel auch zuverlässig, bei komplexeren Interfaces entstehen aber schnell Probleme.
Ein paar Beispiele:
- Ein Hover-Menü kann für Menschen selbstverständlich wirken, für Agenten aber schwer erreichbar sein.
- Ein Formularfeld kann optisch eindeutig erscheinen, semantisch jedoch unklar bleiben.
- Ein Button kann „Weiter“ heißen, obwohl mehrere unterschiedliche Prozessschritte denkbar sind.
WebMCP setzt an dieser Stelle an. Die Website beschreibt nicht nur, was zu sehen ist. Sie erklärt auch, welche Aktion möglich ist und welche Eingaben dafür gebraucht werden. Wichtig für das eigene Verständnis ist nun, dass die Website ihre möglichen Aktionen strukturiert erklärt. Der Agent muss nicht mehr ausschließlich aus Oberfläche, DOM und visueller Darstellung ableiten, was möglich ist.
Der SEO-Kollege Chris Long macht diese Idee mit einem WebMCP-Demo zur Flugsuche greifbarer (Long, nectivdigital.com, Mai 2026). Die Demo definiert mehrere Tools, darunter searchFlights, listFlights, setFilters und resetFilters. Diese Tools enthalten unter anderem Namen, Beschreibungen, Input-Schemas, Output-Schemas und eine Execute-Funktion. Am Ende werden die Tools über navigator.modelContext registriert, damit ein Agent weiß, welche Aktionen auf der Seite verfügbar sind.
Zwei Varianten, die aktuell unter WebMCP laufen
Bei WebMCP ist eine begriffliche Unterscheidung wichtig. Derzeit werden zwei verschiedene Ansätze unter demselben Namen diskutiert.
- Browser-native WebMCP-Implementierung rund um Chrome und die WebMCP-API, die primär für Tests, Demos und frühe Experimente gedacht ist. Sie arbeitet mit navigator.modelContext und soll Websites ermöglichen, Tools direkt im Browserkontext zu registrieren. Chrome dokumentiert dafür die declarative und imperative API sowie ein Sicherheitsmodell über die tools Permissions Policy.
- Offene JavaScript-Library von Jason McGhee, die als praktischer Experimentieransatz gedacht ist, um heute schon Tool-Logiken auf einer Website auszuprobieren. Zum Beispiel über ein Widget für die Website, mit dem sich Nutzer per Token und über ihren MCP-Client direkt mit der Website verbinden können. Die Tools laufen clientseitig über eine lokale WebSocket-Bridge. (Mohanadasan, suganthan.com, Mai 2026)
Für einen Agent-Readiness-Audit ist diese Trennung wichtig. Die Chrome-Variante zeigt, wohin sich Browser und Webplattform entwickeln können. Die Widget-Variante eignet sich eher für Prototypen, interne Tests und erste Learnings.
Welche WebMCP-Use-Cases wären aus SEO-Sicht spannend?
Für die meisten Websites dürfte ein sauberer Agent-Readiness-Audit genügen. WebMCP wird dort interessant, wo komplexe Aktionen regelmäßig und strukturiert ausgeführt werden sollen.
| Website-Typ | WebMCP-Tool-Idee | Mögliche Eingaben | Mögliche Ausgabe | SEO-/GEO-Relevanz |
|---|---|---|---|---|
| B2B-Website | requestConsultation | Name, Unternehmen, E-Mail, Thema, gewünschter Zeitraum | Bestätigung, nächste Schritte, optional Terminlink | Ein Agent könnte nach einer Recherche direkt eine qualifizierte Anfrage vorbereiten, statt nur die Kontaktseite zu öffnen. |
| E-Commerce | findCompatibleProducts | Gerätetyp, Modellnummer, Einsatzbereich, Budget | Passende Produkte, Varianten, Verfügbarkeit, Zubehör | Produktfinder und Konfiguratoren werden agententauglich, wenn Optionen nicht erraten werden müssen. |
| Travel | searchTrips | Startort, Ziel, Datum, Anzahl Reisende, Präferenzen | Verfügbare Optionen, Preise, Filtermöglichkeiten | Agenten können komplexe Such- und Filteraufgaben übernehmen, ohne sich durch mehrere Interface-Zustände zu hangeln. |
| SaaS-Support | createSupportTicket | Produkt, Problemtyp, Fehlercode, Beschreibung, Priorität | Ticketnummer, Status, erwarteter nächster Schritt | Support-Inhalte, Dokumentation und konkrete Problemlösung rücken enger zusammen. |
| Publisher mit Tools | findGuide oder calculateResult | Nutzerproblem, Kategorie, Parameter | Passende Anleitung, Ergebnis, weiterführende Inhalte | Ratgeberseiten werden nicht nur zitierfähig, sondern stärker handlungsfähig. |
Aber auch für Content-Websites ist der Ansatz interessant. Ein Blog, ein Ratgeber- oder Magazinbereich oder ein Knowledge Hub könnte Agenten strukturierte Funktionen anbieten. Folgende Beispiele:
| Tool-Idee | Zweck | Mögliche Eingabe | Mögliche Ausgabe |
|---|---|---|---|
| search_articles | Artikel oder Posts zu einem Thema finden | Keyword, Thema, Kategorie | Passende Beiträge mit Titel, Teaser und URL |
| get_article | Einen Beitrag strukturiert abrufen | Slug oder URL | Bereinigter Artikeltext, Autor, Datum, Themen |
| list_latest_articles | Neue Inhalte anzeigen | Kategorie oder Zeitraum | Aktuelle Beiträge mit Metadaten |
| get_site_info | Kontext zur Website liefern | Optionaler Themenfilter | Themenfelder, Autorität, Ansprechpartner, Quellenhinweise |
| find_service | Passende Leistung finden | Problem, Branche, Ziel | Empfohlene Leistungsseite mit kurzer Begründung |
Für SEO und GEO entsteht hier ein interessanter Übergang. Inhalte müssen weiterhin gut strukturiert, verständlich und zitierfähig sein. Zusätzlich kann eine Website agentenlesbare Funktionen anbieten, die bestimmte Aufgaben zuverlässiger machen.
Tool-Beschreibungen werden zur Optimierungsfläche
Mit WebMCP entsteht eine neue Ebene der Optimierung. Denn ein Agent muss verstehen, wann dieses Tool passt, welche Eingaben benötigt werden und welche Ausgabe zu erwarten ist. Damit werden mehrere Elemente wichtig:
- eindeutige Tool-Namen
- präzise Beschreibungen
- klare Parameter
- verständliche Fehlermeldungen
- saubere Rückgabeformate
- Bestätigungsschritte bei sensiblen Aktionen
Chrome weist ausdrücklich darauf hin, dass sensible Aktionen wie Käufe eine Nutzerbestätigung auslösen können. Außerdem werden WebMCP-APIs über eine tools Permissions Policy abgesichert, die standardmäßig auf self beschränkt ist. Cross-Origin-Iframes benötigen eine explizite Freigabe. Aus SEO-Sicht lässt sich das als neue Form von „Agentic CRO“ verstehen, die neben dem sichtbaren Conversion-Pfad für Menschen auch den maschinenlesbaren Handlungspfad optimieren muss..
Was WebMCP aktuell noch nicht löst
WebMCP macht Interaktionen strukturierter. Die Auffindbarkeit der Tools bleibt ein offener Punkt. Chrome nennt Tool Discoverability ausdrücklich als Limitierung. Denn Clients und Browser müssen eine Website direkt besuchen, um zu erkennen, ob dort aufrufbare Tools vorhanden sind.
Für die Praxis einer Website ist das nicht trivial. So kann eine Website zwar gute Tools anbieten, trotzdem außerhalb relevanter Agentenpfade bleiben, wenn sie nicht gefunden, nicht verstanden oder nicht als passende Quelle ausgewählt wird.
Dementsprechend sind die klassischen SEO-Grundlagen nach wie vor relevant:
- indexierbare Inhalte
- klare Informationsarchitektur
- saubere interne Verlinkung
- verständliche Überschriften
- strukturierte Daten
- belastbare Entitäten
- starke Themen- und Quellenautorität
WebMCP erweitert diesen Stack. Es macht eine Website handlungsfähiger für Agenten, sobald diese die Website erreicht haben.
Für viele Websites wird WebMCP kurzfristig noch kein Pflichtprogramm sein. Als Denkrichtung ist es aber bereits heute wertvoll. Es verschiebt den Blick von „Kann ein Agent diese Website irgendwie bedienen?“ zu „Welche Aufgaben kann diese Website einem Agenten strukturiert anbieten?“
Genau diese Frage wird für SEO, GEO, UX und Webentwicklung wichtiger. Eine agentenfreundliche Website ist lesbar, sauber strukturiert, semantisch verständlich und technisch so gebaut, dass Maschinen relevante Aufgaben möglichst zuverlässig erkennen und ausführen können.
Der Agent-Readiness-Workflow
Für einen ersten Agent-Readiness-Audit reicht ein schlanker Prozess.
1. Seitentypen priorisieren
Nicht jede URL muss sofort geprüft werden. Relevant sind Seitentypen mit hoher geschäftlicher oder redaktioneller Bedeutung:
- Startseite
- Leistungsseiten
- Kontaktseiten
- Produktdetailseiten
- Kategorie-Seiten
- Ratgeberartikel
- Termin- oder Buchungsseiten
- Supportbereiche
- Tools und Rechner
2. Aufgaben je Seitentyp definieren
Für jeden Seitentyp wird eine konkrete Agenten-Aufgabe formuliert.
Beispiele:
- „Finde heraus, ob diese Agentur GEO anbietet, und starte eine Anfrage.“
- „Finde ein kompatibles Ersatzteil für Modell X.“
- „Prüfe, ob ein Termin am Freitag möglich ist.“
- „Finde die Anleitung zur Lösung dieses Problems.“
- „Erstelle ein Support-Ticket mit Fehlercode und Produktversion.“
3. Interface und Semantik prüfen
Danach folgt die technische Prüfung:
- Sind zentrale CTAs echte Links oder Buttons?
- Sind Formulare verständlich ausgezeichnet?
- Sind Labels korrekt mit Feldern verbunden?
- Sind Zustände und Fehlermeldungen maschinenlesbar?
- Sind zentrale Informationen im HTML enthalten?
- Sind Pop-ups, Overlays oder Layout-Shifts im Weg?
- Ist der Accessibility Tree sauber?
Google empfiehlt ausdrücklich, den Accessibility Tree zu prüfen, weil er die maschinenlesbare Hierarchie und Funktionalität der Seite sichtbar macht.
4. Probleme in klare Tickets übersetzen
Schwache Tickets erzeugen schwache Umsetzungen. Daher sollten schon die To-dos in den jeweiligen Tickets sehr spezifisch benannt werden. Das gilt grundsätzlich immer, bekommt im Kontext der KI-Agenten aber nochmals eine zusätzliche Dringlichkeit. Exemplarisch:
- Kontaktformular: Alle Pflichtfelder mit sichtbaren Labels und required-Attribut versehen.
- Produktseite: Verfügbarkeitsstatus zusätzlich als Text im HTML ausgeben.
- CTA-Kacheln: klickbare <div>-Elemente durch echte Links ersetzen.
- Buchungsformular: Fehlermeldungen direkt am jeweiligen Eingabefeld ausgeben.
- Ratgeberartikel: Handlungsschritte als echte Liste strukturieren.
- Overlay: Newsletter-Pop-up darf Warenkorb-Button nicht verdecken.
- Interne Links: generische Linktexte durch beschreibende Zieltexte ersetzen.
5. WebMCP-Kandidaten separat bewerten
Erst wenn die Basis sauber ist, lohnt sich ein Blick auf WebMCP. Gute Kandidaten sind Prozesse mit klaren Eingaben und Ausgaben:
- Produktsuche
- Produktkonfiguration
- Terminbuchung
- Support-Ticket
- Standortsuche
- Rechner
- Leadformular
- Buchungsstrecke
- Datenbank- oder Katalogsuche
Für die praktische Bewertung einer Website kann WebMCP also als zusätzlicher Prüfbereich in den Agent-Readiness-Audit aufgenommen werden.
Wichtige Fragen sind:
- Welche wiederkehrenden Aufgaben könnten Agenten auf der Website sinnvoll erledigen?
- Gibt es Formulare, Suchfunktionen, Filter, Buchungsstrecken oder Content-Bereiche, die sich als Tool abbilden lassen?
- Welche Eingaben benötigt der Agent für diese Aufgabe?
- Welche Ausgabe hilft dem Nutzer wirklich weiter?
- Gibt es sensible Aktionen, die eine Bestätigung benötigen?
- Wie werden Fehler verständlich zurückgegeben?
- Wie erfährt ein Agent, dass diese Funktion existiert?
- Wie lässt sich später messen, ob Agenten das Tool erfolgreich nutzen?
Was bedeutet Agent-Readiness für SEO und GEO?
Googles Dokumentation zu agent-friendly Websites ist ein deutlicher Hinweis darauf, wohin sich technische Website-Qualität zukünftig entwickelt (Kulikowski & More, web.dev, April 2026).
Für klassische SEO bleibt die Grundlage gleich. Inhalte müssen auffindbar, crawlbar, indexierbar, schnell, verständlich und intern gut verlinkt sein. Ohne diese Basis hilft auch kein Agenten-Glitzer. GEO erweitert diese Perspektive. Es geht nicht nur darum, ob eine Marke in AI Overviews, AI Mode, ChatGPT, Perplexity oder anderen Systemen genannt und zitiert wird. Es geht auch darum, ob die empfohlene Website anschließend sinnvoll nutzbar ist.
- Bei informationsorientierten Seiten bedeutet das: klare Struktur, zitierfähige Passagen, eindeutige Antworten und gute interne Anschlussfähigkeit. Siehe hierzu auch unseren Beitrag zur Content-Struktur für KI.
- Transaktionale Seiten benötigen: klare Aktionen, verständliche Formulare, saubere Produktdaten, erkennbare Zustände und stabile Conversion-Strecken.
- Für komplexe Anwendungen heißt das perspektivisch: strukturierte Schnittstellen für Agenten, etwa über Ansätze wie WebMCP.
In der Realität scheitern aber viele Websites auch noch genau an diesen Grundlagen. Der pragmatische nächste Schritt ist deshalb kein WebMCP‑Großprojekt, sondern ein Agent-Readiness-Audit für die wichtigsten Seitentypen und Conversion-Strecken.
Oder kurz gesagt:
SEO stellt künftig zwei Fragen: Wird die Seite gefunden und verstanden? Kann ein KI-Agent auf ihr sinnvoll arbeiten?
Häufige Fragen und Antworten zu agentenfreundlichen Webseiten
Was ist ein KI-Agent im Web-Kontext?
Ein KI-Agent ist ein autonomes System, das zielgerichtete Aufgaben auf Websites ausführt. Es interpretiert Eingaben, plant Schritte und klickt, scrollt oder füllt Formulare aus, ohne Schritt-für-Schritt-Anweisungen zu benötigen. Typische Aufgaben: eine Kontaktanfrage stellen oder ein Produkt konfigurieren.
Was bedeutet agentengerecht (englisch: agent-friendly) konkret?
Eine agentengerechte Website ist so aufgebaut, dass ein KI-Agent ihre Struktur und Interaktionsmöglichkeiten maschinell versteht. Das setzt echte HTML-Elemente, klare Labels, stabile Layouts und einen sauberen Accessibility Tree voraus. Google hat den Begriff in seiner web.dev-Dokumentation im April 2026 geprägt.
Was ist der Unterschied zwischen „agentengerecht“ und „barrierefrei“?
Die Anforderungen überschneiden sich erheblich. Beide setzen auf semantisches HTML und einen sauberen Accessibility Tree. Wer barrierefreien Webseiten technisch ernst nimmt und umsetzt, hat die Grundlage für agentengerechte Seiten bereits gelegt. Der Unterschied liegt im Fokus: Barrierefreiheit denkt vom Menschen mit Assistenztechnologie her, Agentenoptimierung vom autonomen System, das eine Aufgabe erledigen soll.
Wann lohnt sich ein Agent-Readiness-Audit?
Immer dann, wenn Seiten mit hoher Conversion-Relevanz betroffen sind: Formulare, Produktdetailseiten, Buchungsmasken, Support-Bereiche. Cloudflare hat im April 2026 einen Agent Readiness Score eingeführt, mit dem sich die Agentenfähigkeit einer Seite systematisch messen lässt. Der Audit selbst ist kein Großprojekt, er liefert konkrete Tickets für die Entwicklung.
Was ist WebMCP?
WebMCP ist ein Chrome-Vorschlag im Early Preview (ab Februar 2026). Websites können damit KI-Agenten strukturierte Funktionen direkt bereitstellen. Zwei API-Varianten: Declarative API für HTML-Formulare, Imperative API für JavaScript-Interaktionen. Google nennt E-Commerce und Customer Support als zentrale Anwendungsfälle.
Muss ich meine Website für KI-Agenten komplett neu aufbauen?
In den meisten Fällen nicht. Die häufigsten Probleme entstehen aus konkreten technischen Fehlentscheidungen: JavaScript-only Buttons oder fehlende Formular-Labels. Ein gezielter Audit der wichtigsten Seitentypen reicht als Einstieg. WebMCP-Implementierungen für komplexe Interaktionen sind ein späterer Schritt, wenn die semantische Basis stimmt.
Weitere Informationen und Quellen
- Google Live Demo für WebMCP-Anwendung in Form eines Suchformulars für Flüge (englisch)
- Alexandra Klepper: WebMCP – auf developer.chrome.com am 18. Mai 2026 (englisch/mehrsprachig)
- Chris Long: How To Implement WebMCP: A Breakdown Of Google’s Live Demo – auf: nectivdigital.com am 13. Mai 202 (englisch)
- Suganthan Mohanadasan· WebMCP: I Made My Website AI Agent Ready (Here’s How) – auf: suganthan.com am 12. Mai 2026 (englisch)
- Matt G. Southern: Google Tells Developers To Build For AI Agents, Not Just Humans – auf: searchenginejournal.com am 1. Mai 2026 (englisch)
- André Jesus und Vance Morrison: Introducing the Agent Readiness score. Is your site agent-ready? – auf: blog.cloudflare.com am 17. April 2026 (englisch)
- Kasper Kulikowski und Omkar More: Build agent-friendly websites – auf: web.dev am 1. April 2026 (englisch/mehrsprachig)
- Leigh McKenzie: WebMCP: What It Is, Why It Matters, and What to Do Now – auf semrush.com am 11. März 2026 (englisch)
- Vinicius Stanula: WebMCP: The Standard That Lets AI Agents Call Website Functions Directly – auf: locomotive.agency am 18. Februar 2026 (englisch)
- André Cipriani Bandarra: WebMCP is available for early preview – auf: developer.chrome.com am 10. Februar 2026 (englisch/mehrsprachig)
- Marco Casalaina: The Future of AI: Optimize Your Site for Agents – It’s Cool to be a Tool – microsoft.com am 23. Juli 2025 (englisch)
- Alexandra Klepper, Kasper Kulikowski und Rachel Lee Nabors: Introduction to agents – auf: web.dev am 25. Februar 2025 (englisch/mehrsprachig)
