GEO-Tracking, Progressive Disclosure, Web-Spec-Verzeichnis & AI Agent Experience

Begrüßung & eine Idee

Vierte Folge — und vorab ein Dank an alle, die uns Feedback geschickt haben. Noch sind es keine Massen an Hörer:innen, aber es macht Spaß, und wir machen weiter.

Christoph bringt außerdem eine Idee mit: eine Sonderausgabe, in der wir gemeinsam etwas bauen — Jens aus der technischen, Christoph aus der Product- und SEO-Perspektive. Das würde als Video auf YouTube erscheinen, außerhalb der normalen Folgen. Wir blenden dazu eine kleine Umfrage ein (u. a. auf Spotify) und freuen uns über Ideen und Wünsche in den Kommentaren.

GEO-Tracking — erst verstehen, dann automatisieren

Bevor es ums eigentliche Tracking geht, ein Tipp aus der Praxis: In den Bing Webmaster Tools gibt es seit Längerem den Bereich „AI Performance“. Er zeigt, wie oft eine Seite in Microsoft Copilot (und „Partners“) zitiert wurde und über welche Grounding-Queries man dort auftaucht. Spannend, weil dieselbe Funktion in der Google Search Console gerade erst groß angekündigt und langsam ausgerollt wird.

Christophs zweiter Grund für die Bing Webmaster Tools: Die Keyword-Daten sind ungefiltert. Anders als in der Search Console, wo vieles aggregiert und gefiltert ist, sieht man hier die echten Long-Tail-Suchanfragen — richtig wertvoll aus SEO-Sicht.

Der Kern der Folge ist aber ein einfaches Google-Sheet für manuelles GEO-Tracking. Bewusst manuell, denn das Ziel ist, zu verstehen, was die ganzen kaufbaren Sichtbarkeits-Tools eigentlich messen. Zweck: eine wöchentliche Momentaufnahme der eigenen Sichtbarkeit in LLMs.

Drei Spielregeln liegen dem zugrunde:

1. abgemeldet messen — im Incognito- bzw. temporären Chat (Claude, ChatGPT, Gemini), damit Historie und Personalisierung das Ergebnis nicht verfälschen.
2. Mention ≠ Citation — die bloße Erwähnung der Marke und der tatsächliche Link sind zwei verschiedene KPIs.
3. Eine Antwort ist nur eine Stichprobe — Ergebnisse variieren, deshalb den Ankerprompt zwei-, dreimal laufen lassen und ein Durchschnittsbild bilden.

Aufgebaut ist das Sheet als Anleitung, Prompt-Liste, Tracking-Tabelle und Dashboard. Als realistisches Beispiel dienen „Kaffeevollautomaten fürs Büro“: ein Ankerprompt plus ein paar Variationen. In der Tracking-Tabelle wird pro Kalenderwoche und Engine (ChatGPT, Perplexity, Claude, Gemini) notiert: Wurde ich genannt? Wurde ich verlinkt? Ist der Hauptwettbewerber dabei? Welche anderen Anbieter tauchen auf? Schon nach wenigen Wochen entsteht so ein gutes Gefühl dafür, wo man steht und wo man ansetzen sollte. Das Sheet kann über folgenden Link für das eigene Projekt dupliziert werden:

[TODO Google Sheet Link]

Auf Jens’ Frage nach der Modellauswahl: am besten immer gleich messen und sich an der Zielgruppe orientieren. Wer eher Endkund:innen adressiert, sollte die aktuellen Default-Modelle der kostenlosen Accounts verwenden — das ergibt das ehrlichste Bild. Tenor der Runde: Sowas erst im Kleinen manuell verstehen, bevor man es automatisiert oder ein Tool dafür kauft.

Progressive Disclosure

Progressive Disclosure stammt eigentlich aus der User Experience: ein Informationsarchitektur-Pattern, das Komplexität schrittweise enthüllt, statt alles auf einmal zu zeigen. Auf Sprachmodelle übertragen heißt das vor allem: Tokens sparen und das Kontextfenster schonen. Man unterscheidet zwei Stufen — eine Index-Stufe (Überblick, Metadaten) und eine Detail-Stufe, die nur bei Bedarf nachgeladen wird.

Beispiel 1 — MCP: Früher wurden beim Start einer Session alle Tools eines MCP-Servers in den Kontext geladen, was von Anfang an viele Tokens verbraucht hat. Heute gibt es eine Tool-Search: Das Modell sucht sich selbst die Tools, die es braucht, und lädt nur diese. Laut Anthropic spart das bis zu 85 % Tokens — und je mehr MCPs wir künftig nutzen, desto wichtiger wird das.

Beispiel 2 — Agent Skills: Die Empfehlung aus der Claude-Plattform-Doku lautet, Details nicht in den Skill einzubetten, sondern zu verlinken. Der Skill bleibt kurz und verweist auf weitere Markdown-Dateien (im PDF-Skill etwa auf Dateien zu Advanced Processing und zu Formularen), die das Modell nur liest, wenn es sie wirklich braucht. Nebenbei der Austausch, wo solche Docs liegen: Claude.md/Context.md im Root, dazu Ordner wie docs/ und plans/ sowie das Skill-Verzeichnis mit Unterordnern für Skripte und Referenzen.

Beispiel 3 — Payload MCP: Der Payload-MCP-Server legt per Default pro Entity eigene Find-, Create-, Update- und Delete-Tools an — bei größeren Projekten eine riesige Tool-Liste, jeweils mit vollem Schema. Jens’ Lösung: generischere Custom-Tools — listEntities, getEntitySchema sowie Find/Create/Update. Statt die ganze Tool-Liste zu durchforsten, listet das Modell bei Bedarf die Entities auf, holt sich das Schema einer bestimmten Entity und nutzt dann ein CRUD-Tool. Drei Tools ersetzen so die Flut — und das Setup skaliert mit der Anzahl der Entities.

Das ist jetzt als Pull Request im payload-content-cli-Plugin umgesetzt, sodass sich diese MCP-Tools jeder zum eigenen Projekt hinzufügen kann.

specification.website — ein Verzeichnis der Web-Standards

Christophs zweites Thema ist ein Fund: specification.website von Joost de Valk, dem Gründer von Yoast SEO. In über 15 Jahren Plugin-Arbeit hat er viele Best Practices gesehen und festgestellt, dass es kein Verzeichnis gibt, das die relevanten Web-Standards an einem Ort bündelt — WHATWG/HTML, WCAG, schema.org, web.dev, Google Search Central und mehr.

Das Directory unterteilt das Ganze in zehn Bereiche: Foundations, SEO, Accessibility, Security, Well-known URLs/URIs, Agent Readiness, Privacy, Resilience und Internationalization. Es gibt sogar einen MCP, um die Inhalte direkt z. B. in Claude Code zu laden. Wichtig bei der Einordnung: Die Markierung als „Required“ oder „Recommendation“ ist teils Joosts Sicht — eher als Ideensammlung lesen, nicht blind übernehmen.

Ein gutes Beispiel ist llms.txt: Christoph hat seine Bot-Logs ausgewertet — in sieben Tagen rund 600 Requests auf die robots.txt, aber nur 3 auf die llms.txt. Und die wenigen llms.txt-Zugriffe kamen von Datensammlern wie BuiltWith oder dataprovider.com, nicht von echten AI-Agents. Der Eindruck: Das Format setzt sich (noch) nicht durch. Jens’ Idee dazu: So ein Verzeichnis einem Agent als Audit geben — was setzt meine Seite schon um, wo sind Lücken? Und Christophs Beobachtung: Der Absender zählt. Eine klar mit AI gebaute, aber substanzielle Seite wie diese nimmt man ernst; eine generische Tailwind-Landingpage weniger.

AI Agent Experience (AX)

UX (User Experience) und DX (Developer Experience) kennen wir — AX steht für AI Agent Experience. Der Hintergrund: Durch KI-Agenten bekommen unsere Produkte eine weitere Nutzergruppe. Dazu zwei Begriffe: Agent-Friendliness (wie gut lässt sich ein System von Agents bedienen?) und Agent-Readiness (wie weit ist es schon dafür vorbereitet?). Joosts specification.website ist dabei ein guter Leitfaden, um sich eine eigene Checkliste zurechtzulegen.

Bei Websites bringt es ein Cloudflare-Zitat auf den Punkt: Das Web lernte, mit Browsern zu sprechen, dann mit Suchmaschinen — jetzt muss es lernen, mit KI-Agenten zu sprechen. Cloudflare hat dazu einen Blogpost und das Tool isitagentready.com veröffentlicht: Man gibt seine URL ein und sieht, welche Standards die Seite umsetzt — robots.txt, Sitemap, Link-Header, Markdown-Negotiation und mehr. Google steuert über web.dev die Grundkonzepte bei: semantisches HTML, stabiles Layout — und der Hinweis, dass Agents über drei Kanäle arbeiten: Screenshot, HTML und Accessibility-Tree.

AX betrifft aber nicht nur Websites, sondern auch Codebases, Dokumentation, das eigene Payload-CMS-Setup und selbst gebaute Payload-Plugins. Bei Payload war die primäre Schnittstelle lange die UI; künftig wird wichtiger, dass ein CMS auch von einem Agent über MCP bedient werden kann. Themen, auf die Jens in kommenden Folgen genauer eingehen will.

Ganz konkret auf unserer eigenen Seite: Wir haben eine Markdown-Negotiation eingebaut. Über den Accept-Header oder einfach das Suffix .md in der URL lässt sich von jeder Seite die Markdown-Version abrufen — für Agents viel effizienter als das HTML. isitagentready.com erkennt das und vergibt aktuell einen Score von 100; senkt man einzelne Standards, sinkt er entsprechend. Nicht jeder Standard (etwa WebMCP) ergibt für jedes Projekt Sinn — man sollte auswählen, was wirklich passt. Jens’ Schlusssatz: Überall, wo heute ein Mensch arbeitet, arbeitet morgen auch ein Agent mit — deshalb wird Agent Experience immer wichtiger.