--- title: "Folge 4 - GEO-Tracking, Progressive Disclosure, Web-Spec-Verzeichnis & AI Agent Experience - Zwischen zwei Stacks" description: "Manuelles GEO-Tracking mit einem einfachen Google-Sheet und den Bing Webmaster Tools, Progressive Disclosure als Token-Spar-Pattern für MCPs, Skills und Payload, Joost de Valks Web-Standards-Verzeichnis specification.website und AI Agent Experience: Websites, Codebases und Tools für KI-Agenten bereit machen." --- episode 04 / 50:55 # GEO-Tracking, Progressive Disclosure, Web-Spec-Verzeichnis & AI Agent Experience Manuelles GEO-Tracking mit einem einfachen Google-Sheet und den Bing Webmaster Tools, Progressive Disclosure als Token-Spar-Pattern für MCPs, Skills und Payload, Joost de Valks Web-Standards-Verzeichnis specification.website und AI Agent Experience: Websites, Codebases und Tools für KI-Agenten bereit machen. mit [Jens Becker](/hosts/jens-becker) & [Christoph Paterok](/hosts/christoph-paterok) 17\. Juni 2026 jetzt anhören auf - [Auf YouTube anhören](https://www.youtube.com/watch?v=mrDtnsylVVM) - [Auf Spotify anhören]() - [Auf Apple Podcasts anhören](https://podcasts.apple.com/us/podcast/folge-4-geo-tracking-progressive-disclosure-specification/id1896309882?i=1000773102177) - [Auf Deezer anhören](https://link.deezer.com/s/33zV9fyMBIRvryVkkDPny) ## 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](https://www.bing.com/webmasters/) 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. [![Screenshot der Bing Webmaster Tools mit dem Bereich AI Performance, der zeigt, wie oft eine Website in Microsoft Copilot und Partnern zitiert wurde.](https://www.zwischenzweistacks.de/media/geo-tracking-bing-webmaster-tools-ai-performance-1024x528.png)](https://www.zwischenzweistacks.de/media/geo-tracking-bing-webmaster-tools-ai-performance-2560x1320.png) 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. [![Screenshot eines einfachen Google-Spreadsheets fuer manuelles GEO-Tracking mit Spielregeln, einer Prompt-Liste und einer woechentlichen Tracking-Tabelle fuer Mentions und Citations.](https://www.zwischenzweistacks.de/media/geo-tracking-spreadsheet-1024x689.png)](https://www.zwischenzweistacks.de/media/geo-tracking-spreadsheet-2560x1722.png) 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. [![Infografik zum Prinzip Progressive Disclosure: Informationen schrittweise enthuellen statt alles auf einmal, mit den Stufen Index und Details.](https://www.zwischenzweistacks.de/media/progressive-disclosure-01-prinzip-1024x576.webp)](https://www.zwischenzweistacks.de/media/progressive-disclosure-01-prinzip-2560x1440.webp) 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. [![Infografik: MCP-Tools on-demand laden. Frueher alle Tools im Kontext, heute laedt das Modell per Tool-Search nur die benoetigten Tools, bis zu 85 Prozent weniger Tokens.](https://www.zwischenzweistacks.de/media/progressive-disclosure-02-mcp-tool-search-1024x576.webp)](https://www.zwischenzweistacks.de/media/progressive-disclosure-02-mcp-tool-search-2560x1440.webp) 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. [![Infografik zu Agent Skills: zusaetzliche Details verlinken statt einbetten, damit das Modell sie nur bei Bedarf laedt.](https://www.zwischenzweistacks.de/media/progressive-disclosure-03-agent-skills-1024x576.webp)](https://www.zwischenzweistacks.de/media/progressive-disclosure-03-agent-skills-2560x1440.webp) 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. [![Infografik zur Payload-MCP-Loesung: generische Tools listEntities, getEntitySchema und create/update statt einer CRUD-Flut pro Entity.](https://www.zwischenzweistacks.de/media/progressive-disclosure-04-payload-mcp-1024x576.webp)](https://www.zwischenzweistacks.de/media/progressive-disclosure-04-payload-mcp-2560x1440.webp) Das ist jetzt als [Pull Request im payload-content-cli-Plugin](https://github.com/jhb-software/payload-content-cli/pull/2) 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](https://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. [![Screenshot der Website specification.website von Joost de Valk, einem Verzeichnis von Web-Standards in zehn Bereichen wie Foundations, SEO, Accessibility, Security und Agent Readiness.](https://www.zwischenzweistacks.de/media/specification-website-directory-1024x604.png)](https://www.zwischenzweistacks.de/media/specification-website-directory-2560x1510.png) 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](https://specification.website) ist dabei ein guter Leitfaden, um sich eine eigene Checkliste zurechtzulegen. [![Infografik Von UX zu AX: Gegenueberstellung von User Experience fuer Menschen und AI Agent Experience fuer Agents, mit den Begriffen Agent-Friendliness und Agent-Readiness.](https://www.zwischenzweistacks.de/media/agent-experience-01-ux-zu-ax-1024x576.webp)](https://www.zwischenzweistacks.de/media/agent-experience-01-ux-zu-ax-2560x1440.webp) 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](https://blog.cloudflare.com/agent-readiness/) und das Tool [isitagentready.com](https://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. [![Infografik: Ist deine Website agent-ready? Cloudflare-Zahlen zur Verbreitung von robots.txt, Content Signals und Markdown sowie die drei Kanaele Screenshot, HTML und Accessibility-Tree.](https://www.zwischenzweistacks.de/media/agent-experience-02-website-readiness-1024x576.webp)](https://www.zwischenzweistacks.de/media/agent-experience-02-website-readiness-2560x1440.webp) 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. [![Infografik: Agent-Readiness betrifft nicht nur Websites, sondern auch Codebase, Docs, Payload-CMS-Setup und Payload-Plugins.](https://www.zwischenzweistacks.de/media/agent-experience-03-ueberall-1024x576.webp)](https://www.zwischenzweistacks.de/media/agent-experience-03-ueberall-2560x1440.webp) 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](https://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.