Agentisches SEO: Türen für Gäste, die kaum kommen

Jede neue Disziplin baut sich irgendwann ihr eigenes Kürzel. SEO, dann GEO, jetzt AEO. Praktisch ist daran wenig, denn AEO meint je nach Autor zwei verschiedene Sachen. Genau da fängt das Missverständnis an.

Die eine Lesart, Answer Engine Optimization, ist im Kern das, was sonst GEO heißt: in KI-Antworten zitiert werden. Diese Schicht habe ich an anderer Stelle auseinandergenommen, Ergebnis kurz, das meiste davon ist klassisches SEO mit Zucker. Die andere Lesart stammt von Addy Osmani und zielt woanders hin. Nicht zitiert werden, sondern benutzt werden. Ein Agent liest deine Seite nicht, er handelt auf ihr.

Darum geht es hier. Ich werfe dazu in den Raum: Die Maschinenschicht dafür wird gerade in hohem Tempo gebaut, und sie bleibt trotzdem vorerst eine Nische. Aus zwei Gründen, die nichts miteinander zu tun haben und sich perfekt ergänzen. Kaum jemand baut die Tür ein. Und kaum jemand schickt einen Agenten hindurch, wenn es um etwas geht.

TL;DR

Agentisches SEO ist die Schicht über GEO: nicht zitiert werden, sondern von einem Agenten benutzt werden. Die Technik dafür steht. Der Verkehr fehlt.

• AEO ist doppelt belegt: Answer Engine Optimization (= GEO, Sichtbarkeit) und Osmanis Agentic Engine Optimization (= Aktion). Hier geht es um das Zweite.
• Die Maschinenschicht ist Opt-in: WebMCP steckt im Origin Trial, einziger Konsument ist Gemini in Chrome. Ohne aktive Mitarbeit der Seite passiert nichts.
• Strukturierte Daten verschieben den Zweck: nicht mehr Article fürs Zitiertwerden, sondern potentialAction und Permission-Manifeste fürs Handeln.
• Die Psychologie deckelt die Nachfrage: teure, schwer umkehrbare Entscheidungen delegiert niemand. Die Protokolle selbst bauen die menschliche Freigabe bewusst ein.
• Reihenfolge: Bots nicht aussperren, HTML sauber halten, Aktions-Schema setzen. WebMCP erst, wenn du messbaren Agenten-Traffic hast.

Drei Kürzel, und das doppelte A

Sortieren wir das Feld, sonst redet jeder über etwas anderes. SEO bringt dich in die klassische Suche. GEO, oft auch Answer Engine Optimization genannt, bringt dich in die generierte Antwort von ChatGPT , Perplexity oder den AI Overviews. Beides dreht sich um Sichtbarkeit. Wirst du gefunden, wirst du zitiert.

Osmanis AEO ist eine andere Baustelle. Search Engine Land warnt eigens davor, dieses agentische AEO mit dem Answer-Engine-AEO zu verwechseln. Der Unterschied ist nicht kosmetisch. Bei der Sichtbarkeit ist der Konsument ein Modell, das eine Antwort formuliert. Beim agentischen Web ist der Konsument ein Agent, der eine Aufgabe abarbeitet. Er füllt ein Formular aus, holt ein Angebot ein, bucht einen Termin. Dafür reicht es nicht, gut lesbar zu sein. Die Seite muss bedienbar sein, und zwar ohne Augen.

Was Osmani wirklich gesagt hat

Im April hat das für einigen Wirbel gesorgt, also lohnt der Blick aufs Original statt auf die Sekundär-Listicles. Addy Osmani, Director of Engineering bei Google Cloud AI, hat am 11. April 2026 das erste operative AEO-Framework veröffentlicht, mitsamt einem Open-Source-Audit-Tool. Fünf Signale: Auffindbarkeit, Verarbeitbarkeit, Token-Effizienz, Fähigkeits-Signalisierung, Zugriffskontrolle. Klingt nach dem nächsten großen Ding, das du sofort umsetzen musst.

Hier kommt das Sternchen, und es ist groß. Osmani schreibt für Entwickler. Seine Zielgruppe sind agentische Coding-Tools wie Claude Code , Gemini CLI ( bzw. Antigravity) , Cursor und Copilot , und er nennt seine Position ausdrücklich eine Praktiker-Sicht aus der Developer-Tools-Welt, keine Google-weite Empfehlung. Das ist ein Riesenunterschied zu „so rankt deine Firmenseite besser“. Wie groß, zeigt der hauseigene Widerspruch: Während Osmani aus der Cloud-AI-Ecke den Stack predigt, hält John Mueller aus der Search-Ecke dagegen und rät von Sonderseiten für Maschinen ab. Zwei Google-Leute, zwei Aussagen, ein Publikum, das nur die Schlagzeile hört.

Was vom Framework bleibt, wenn man den Hype abzieht, ist trotzdem brauchbar. Kürzere, klar strukturierte Seiten mit der Antwort weit oben sind für Agenten besser, und für Menschen auch. Die Token-Budgets, die Osmani vorschlägt, sind Lesbarkeitsziele mit anderem Etikett. Eine Doku-Seite, die in Token explodiert, liest auch kein Mensch zu Ende.

llms.txt, zum Zweiten

Dass die llms.txt als GEO-Hebel – freundlich formuliert – deutlich hinter den Erwartungen zurücksteht, hatte ich ebenfalls schon in diesem Blog mal erwähnt. Das werde ich an dieser Stelle nicht noch mal aufdröseln. Interessant wird die Datei erst, wenn man sie aus dem GEO-Frame nimmt und in den agentischen Kontext stellt.

Dann nämlich dreht sich der Befund. In einer Ahrefs-Auswertung von 137.000 Domains blieben 97 Prozent der llms.txt-Dateien im Mai 2026 komplett ungelesen. Die Such- und Answer-Bots ignorieren sie. Wer die Datei abruft, sind die Coding-Agenten. Claude Code zählte neben GPTBot zu den aktivsten Abrufern der Datei. Das passt zu Muellers Einordnung. Er nennt llms.txt eine Krücke, um Tokens zu sparen, gedacht für KI-Coding-Tools, die Entwickler-Doku parsen. Heißt für dich: Wenn du eine technische Dokumentation betreibst, hat die Datei einen kleinen, echten Job. Wenn du einen Marken-Blog oder Shop betreibst, ist sie weiterhin eine günstige Wette ohne belegbaren Effekt. Derselbe File, zwei völlig verschiedene Urteile, je nachdem, wer am anderen Ende liest.

Die eigentliche Maschinenschicht heißt WebMCP

Wenn etwas an dieser Geschichte technisch neu und nicht nur umetikettiert ist, dann WebMCP. Die Idee dreht das Verhältnis um. Bisher schaut ein Agent auf einen Screenshot deiner Seite und rät, wo der Button sitzt. Mit WebMCP sagt die Seite dem Agenten: Hier sind die Dinge, die ich kann, hier die Parameter, ruf sie auf. Statt Klick-Pantomime ein Funktionsaufruf.

So weit die Verheißung. Der Status ist nüchterner. WebMCP wurde am 10. Februar 2026 angekündigt und läuft seit dem zweiten Quartal 2026 als öffentlicher Origin Trial in Chrome 149, über die Schnittstelle navigator.modelContext. Es ist ein Community-Group-Draft, kein offizieller W3C-Standard, und der einzige Agent, der WebMCP-Tools aktuell konsumiert, ist Gemini in Chrome. Microsoft hat die Spec mitgeschrieben, in den offiziellen Edge-147-Release-Notes taucht WebMCP aber nicht auf, der Support gilt als unbestätigt.

Technisch hast du zwei Wege. Den deklarativen, ein paar Attribute auf bestehende HTML-Formulare. Und den imperativen, Tools in JavaScript registrieren. So sieht der imperative Weg aus, wenn du einem Agenten erlaubst, ein unverbindliches Angebot anzufordern:

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: "angebotAnfordern",
    description: "Fordert ein unverbindliches Angebot für eine Leistung an.",
    inputSchema: {
      type: "object",
      properties: {
        leistung: { type: "string" },
        email:    { type: "string" }
      },
      required: ["leistung", "email"]
    },
    async execute({ leistung, email }) {
      const res = await fetch("/api/angebot", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ leistung, email })
      });
      return res.ok ? { status: "angefragt" } : { status: "fehler" };
    }
  });
}

Zwei Punkte, die man nicht überliest. Erstens braucht der Aufruf einen offenen Tab, headless geht nicht, weil die Tool-Calls im JavaScript der sichtbaren Seite laufen. Zweitens das Sicherheitsthema. Ein Agent erbt die Sitzung des angemeldeten Nutzers, also auch dessen Rechte. Die Spec begegnet dem mit Herkunftsisolierung. Die Permissions Policy für Tools steht per Default auf self, und Cross-Origin-iFrames müssen allow="tools" explizit deklarieren. Das ist kein Detail. Ein bösartiges Tool auf einer fremden Seite, das im Hintergrund deine Bank-Session anzapft, ist genau das Szenario, das man hier verhindern will.

Strukturierte Daten, aber diesmal fürs Handeln

Im GEO-Kontext ging es bei Schema.org um Entitäten und Inhalte, also Organization, Article, FAQPage. Damit machst du dich zitierfähig. Für Agenten zählt ein anderer Teil des Vokabulars, der bisher kaum jemanden interessiert hat, nämlich die Aktionen. potentialAction sagt nicht, wer du bist. Es sagt, was man bei dir tun kann. Ein Termin reservieren zum Beispiel:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Erstberatung",
  "provider": { "@type": "Organization", "name": "Beispiel GmbH" },
  "potentialAction": {
    "@type": "ReserveAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/api/termin?slot={slot}",
      "httpMethod": "POST",
      "contentType": "application/json"
    },
    "result": { "@type": "Reservation" }
  }
}

Daneben kursiert ein zweiter Baustein, zugegeben noch ein Entwurf ohne verabschiedeten Standard und ohne nennenswerte Adaption: agent-permissions.json. Die Datei legt fest, welche Agenten welche Aktionen ausführen dürfen, und wo strukturierte API-Alternativen liegen. Reizvoll ist daran weniger der heutige Nutzen als die Logik. Du erlaubst das Suchen und Reservieren, du verbietest das Kaufen:

{
  "allowed_agents": [
    {
      "user_agent": "Claude-User",
      "allowed_actions": ["SearchAction", "ReserveAction"],
      "rate_limit_per_minute": 60
    }
  ],
  "disallowed_actions": ["BuyAction"],
  "api_endpoints": {
    "availability_check": "https://api.example.com/v1/slots"
  }
}

Genau dieses disallowed_actions: ["BuyAction"] ist die Brücke zum eigentlichen Punkt. Es ist kein technischer Krampf. Es ist eine Haltung.

Die Bremse ist schon eingebaut

Ob Menschen einem Agenten teure oder physische Entscheidungen überlassen, und ob eine klicklose Erwähnung am Ende überhaupt etwas konvertiert, habe ich an anderer Stelle für einen konkreten Kunden durchgerechnet. Kurzfassung: bei hochwertigen Leads zuletzt, im DACH-Raum mit extra Vertrauensvorschuss, und die Agenten brechen ohnehin am Captcha ab. Das ist die Nachfrageseite.

Für die Infrastruktur-Frage ist etwas anderes interessant. Dieselbe Skepsis steckt schon in den Standards. Die Leute, die das agentische Bezahlen bauen, trauen dem autonomen Agenten den großen Griff selbst nicht zu. Googles AP2 arbeitet mit signierten Mandaten, das Intent-Mandate fixiert den Rahmen, und der Agent kann ihn nicht ohne erneute Rückfrage überschreiten. Stripes Wallet leitet jede Ausgabe zur Freigabe an den Menschen zurück. WebMCP sieht für sensible Aktionen einen Bestätigungsdialog vor. Und das agent-permissions.json von oben verbietet BuyAction per Default.

Diese Decke liegt nicht im Nutzerverhalten, sie liegt im Design. Wer die Maschinenschicht baut, baut die menschliche Bremse gleich mit ein, weil sonst niemand mitspielt. Der adressierbare Raum für vollautonomes Handeln ist von vornherein das risikoarme Ende. Anfragen, reservieren, vergleichen. Nicht kaufen, nicht abschließen.

Selbst da ist die Realität ernüchternd. OpenAI hat sein Instant Checkout am 5. März 2026 wieder eingestellt und auf händlerbetriebene Apps umgeschwenkt, nachdem rund dreißig Shopify-Händler integriert hatten. Der direkte Kauf im Chat, das Vorzeigeszenario, wurde zurückgebaut.

Agentisches SEO: ab wann sich der Aufwand lohnt

Kein Hexenwerk, eher eine Reihenfolge. Und die meisten Schritte zahlen ohnehin auf klassisches SEO ein, was die Sache angenehm risikoarm macht.

Zuerst die Hausaufgabe, die fünf Minuten kostet: Sperr in der robots.txt nicht versehentlich die Bots aus, die du eigentlich willst. Viele Seiten haben 2024 reflexhaft alles geblockt. Die robots.txt mit expliziten User-Agent-Regeln ist der Hebel, der heute tatsächlich steuert. Danach das Fundament, das ich im GEO-Stück ausführlich behandelt habe. Inhalte gehören ins initiale HTML, sauber gerendert, semantisch korrekt ausgezeichnet. Ein Agent, der deine Produktdaten erst nach Client-Side-Rendering sieht, sieht sie gar nicht.

Erst dann wird es agentenspezifisch. Setz das Aktions-Schema dort, wo eine echte Aktion dranhängt, also potentialAction an Buchung, Anfrage, Verfügbarkeit. Wenn du eine Entwickler-Doku betreibst, nimm llms.txt und AGENTS.md dazu, letzteres hat inzwischen eine Linux-Foundation-Spec, während Claude Code weiter CLAUDE.md bevorzugt. WebMCP kommt zuletzt und nur unter einer Bedingung: Du kontrollierst beide Enden, oder du misst bereits echten Agenten-Traffic in deinen Logs. Solange dort nur Gemini in Chrome vereinzelt vorbeischaut, baust du eine Tür für einen Gast, der noch nicht klingelt.

Die ehrliche Antwort auf „ab wann lohnt sich AEO“ ist zweigeteilt. Die Hygiene lohnt sofort, weil sie ohnehin SEO ist. Die spezifische Maschinenschicht lohnt sich, sobald deine Logs sagen, dass Agenten kommen. Ob sich der ganze Aufwand am Ende in Anfragen übersetzt, ist eine eigene Rechnung. Vorher ist es eine Wette, und Wetten platziert man in der Höhe, die man verschmerzen kann.

Was bleibt

Das agentische Web ist kein Hype im Sinne von „gibt es nicht“. Es gibt es, die Protokolle sind real, das Tempo ist hoch. Es ist ein Hype im Sinne von „kommt später und kleiner, als die Pitches behaupten“. Die Tür lässt sich bauen. Ob jemand hindurchgeht, entscheidest nicht du allein, sondern die Adaption auf Browser-Seite und die Bereitschaft der Menschen, Kontrolle abzugeben. Beides bewegt sich langsam, und das zweite vielleicht nie ganz.

Steile These zum Schluss: Agentisches SEO wird nicht an der Technik scheitern, sondern an der Vertrauensfrage. Die löst kein agent-permissions.json.