Eine neue Art Besucher
Ein Kunde sagt zu ChatGPT „bestell mir das Druckerpapier nach", und der Agent erledigt es: Shop suchen, Papier in den Warenkorb, durch den Checkout. Auf deiner Seite, ohne dass ein Mensch die Maus anfasst.
Bisher kannten Websites zwei Sorten Besucher: Menschen, die etwas tun, und Bots, die lesen. KI-Agenten sind eine dritte Sorte — Bots, die etwas tun. Sie suchen, vergleichen, füllen Formulare aus und kaufen, im Auftrag echter Nutzer.
Für deine Seite trennt sich das in zwei Fragen, die wenig miteinander zu tun haben. Empfiehlt die KI dich überhaupt? Das ist GEO, ein eigenes Feld und hier nicht das Thema. Und: Kann der Agent deine Seite bedienen, wenn er da ist? Darum geht es. Der zweite Teil lohnt sich nur, wenn der erste sitzt, denn der Agent überlegt zuerst wie bei einer normalen Chat-Frage, wohin überhaupt, und landet nur dort, wo die KI ihn hinschickt.
GEO, AEO, AIO – kurz erklärt
Die Abkürzungen schwirren durcheinander. GEO (Generative Engine Optimization) heißt, in KI-Antworten vorzukommen — also gefunden zu werden. AEO meint hier Agentic Engine Optimization: dass ein Agent deine Seite auch bedienen kann. (Älter stand AEO auch für „Answer Engine Optimization", praktisch ein Synonym zu GEO.) AIO und LLMO sind weitere Spielarten fürs Gefunden-werden. Dieser Artikel behandelt den agentischen Teil.
Die eine Frage: Wie fasst der Agent deine Seite an?
Daran hängt alles. Du kannst in der KI-Antwort ganz oben stehen und den Verkauf trotzdem verlieren, wenn der Agent an deinem Checkout, dem Variantenwähler oder einem unbeschrifteten Button scheitert. Es gibt zwei Wege, wie er deine Seite anfasst.
Der Agent klickt wie ein Mensch
Es schaut sich die gerenderte Seite an und klickt so, wie es ein Mensch tun würde. Der Standardfall heutzutage.
Was du optimierst: Bedienbarkeit — Accessibility-Tree, semantisches HTML, server-gerendete Inhalte.
Der Agent ruft eine Schnittstelle an
Hier klickt er nicht, sondern ruft einen definierten Endpunkt auf. Kein Browser, keine Oberfläche.
Was du optimierst: die Schnittstellen selbst — aufrufbare Aktionen, Protokoll-Implementierung.
Pfad A: Wie der Browser läuft
Unterschieden wird nur, wo der Browser läuft:
Eigener KI-Browser
Der Agent ist selbst ein Browser. ChatGPT Atlas, Perplexity Comet, Dia, Opera Neon.
Browser-Erweiterung
Ein Add-on macht den vorhandenen Chrome/Edge agentisch. Claude for Chrome, Gemini „auto browse".
Cloud Sandbox
Der Agent steuert einen entfernten Browser. Der ursprüngliche ChatGPT Agent.
Amazon „Buy for Me"
Geschlossene Variante, die fremde Shops browser-gesteuert abfährt und das normale Checkout-Formular mit hinterlegten Kundendaten ausfüllt.
Was du hier optimierst, ist die Bedienbarkeit. Agenten lesen vor allem den Accessibility-Tree, denselben, an dem Screenreader hängen. Semantisches HTML, beschriftete Buttons, server-gerenderte Kerninhalte statt einer Seite, die bis zum JavaScript leer bleibt: solche Dinge entscheiden, ob ein Agent den Kauf abschließt oder abbricht.
CAPTCHAs auf jeder Interaktion, Hover-only-Menüs und Endlos-Scroll ohne Paginierung. Weil fast alle Agenten heute so arbeiten, ist das der kurzfristig wichtigste Hebel.
WebMCP: ein erster Weg, dem Agenten aktiv zu helfen, statt ihn nur nicht zu behindern. Neben sauberer Accessibility deklariert die Seite hier ihre Aktionen direkt, sodass der Agent nicht raten muss, welcher Button was tut. Noch früh, aber die Richtung, in die es geht.
Pfad B: Der Agent ruft eine Schnittstelle auf
Commerce-Protokolle
UCP (Google), ACP (OpenAI) und das Autorisierungsprotokoll AP2 regeln Entdeckung, Warenkorb und Bezahlung jenseits der UI. Bezahlt wird über agent-spezifische Token, sodass der Agent nie echte Kartendaten sieht.
Direkte HTML-/API-Abrufe
Der Agent zieht Inhalte schlicht über HTTP, ganz ohne Browser. Zuverlässig, aber heute kaum produktiv.
Ob du ihn überhaupt siehst, hängt vom Typ ab
Wie gut du einen Agenten erkennst, hängt davon ab, womit er kommt.
Browser-Erweiterung
Praktisch unsichtbar — gleiche Sitzung, gleiche IP, normaler Chrome
Eigener KI-Browser
Grober Anhaltspunkt — Installation deutet auf agentische Nutzung hin
Cloud-Agent
Am einfachsten erkennbar — Datacenter-IPs, teils eigener User-Agent
Läuft er als Erweiterung im Browser des Nutzers (Claude for Chrome, Gemini), verschwindet er praktisch komplett: Der agentische Teil ist vom normalen Surfen desselben Menschen nicht zu trennen, und der Referrer hilft kaum, weil er je nach Fall fehlt, „direct" ist oder von der KI-Plattform kommt.
Hilft nicht zuverlässig
- Standard-Analytics
- Referrer-Auswertung
- Installations-Zahlen allein
Hilft tatsächlich
- Logfile-Analyse
- Verhaltensanalyse
- Web Bot Authentifizierung (von außen)
- WebMCP (von innen)
Womit du anfängst
Sobald die Sichtbarkeit gegeben ist:
Schlüssel-Pfade bedienbar machen und testen
Suche, Warenkorb, Buchung, Anfrage sauber und robust halten. Schau dir die Accessibility dieser Pfade an, und teste sie vor allem real: Lass einen KI-Browser wie Comet die Aufgaben durchspielen. Das lässt sich sogar automatisieren, dann siehst du, in wie vielen Fällen der Agent durchkommt und welcher Schritt hakt.
Schnittstellen im Blick behalten
Wer nicht selbst bauen kann oder will, wartet ab, was Shop-System und Zahlungsdienstleister an UCP/ACP mitbringen. Wer die Ressourcen hat, kann früh einsteigen und sich als First Mover positionieren. Das kann ein Vorteil sein, muss aber nicht.
Anfangen zu messen
Den gesamten Agenten-Traffic sichtbar zu machen, geht heute schlicht nicht. Aber du kannst erste Schritte gehen: WebMCP ausprobieren, loggen, was sich loggen lässt, und so wenigstens den Anlauf des Kanals mitbekommen.
English 
German