So machen Sie Ihre Website mit mehreren Standorten 2026 Agent-Ready

In der Art und Weise, wie Menschen Unternehmen finden, hat sich etwas verändert. Kein schrittweiser Wandel, sondern eine strukturelle Veränderung. ChatGPT allein verzeichnet inzwischen mehr als 5 Milliarden Besuche pro Monat bei 900 Millionen wöchentlich aktiven Nutzern, und Geminis monatlicher Traffic ist im Jahr bis März 2026 um 647 Prozent auf 2 Milliarden Besuche gewachsen. Immer mehr dieser Besuche betreffen lokale Anfragen: “Finde einen Zahnarzt mit guten Bewertungen in der Nähe von Kungsholmen” oder “Welches Autohaus in Göteborg hat die beste Servicebewertung?” Innerhalb von ChatGPT lösen Prompts mit lokaler Suchabsicht inzwischen in 59 Prozent der Fälle eine Live-Websuche aus. Damit wird die Frage “was liefert Ihre Website, wenn ein Agent sie anfragt?” zu einem direkten Treiber für Besuche in Ihren Filialen.

Der KI-Agent durchsucht Ihre Website nicht. Er ruft Protokolle ab, liest strukturierte Daten und nutzt Tools. Wenn Ihre Website auf diese Anfragen nicht reagieren kann, empfiehlt der Agent jemand anderen.

Genau das bedeutet “Agent-Ready”: Ihre Website ist so aufgebaut, dass KI-Systeme sie erkennen, verstehen und mit ihr interagieren können, ohne dass ein Mensch eingreifen muss.

Für Marken mit mehreren Standorten steht mehr auf dem Spiel als für alle anderen. Sie optimieren nicht eine Seite oder einen Standort. Sie sorgen dafür, dass Hunderte oder Tausende von Standorten für eine neue Klasse digitaler Besucher sichtbar werden, die Browser nicht so nutzen wie Menschen.

Wie unterscheidet sich die Erkennung durch KI-Agenten von der klassischen Suche?

Suchmaschinen crawlen HTML, folgen Links und bauen einen Index auf. KI-Agenten tun etwas grundlegend anderes. Sie:

• Lesen strukturierte Daten wie JSON-LD und Markdown, statt unübersichtliches HTML zu parsen
• Rufen Protokolle ab, um zu erkennen, was eine Website bietet, bevor sie damit interagieren
• Nutzen Tools, um Aktionen auszuführen (Buchen, Vergleichen, Suchen), statt nur Seiten zu lesen
• Verbinden sich über standardisierte Protokolle wie MCP mit Diensten, um auf aktuelle Geschäftsdaten zuzugreifen

Dieser Wandel bedeutet, dass sich die Spielregeln geändert haben. Eine Website, die bei Google gut rankt, kann für einen KI-Agenten völlig unsichtbar sein, wenn sie die Erkennungsstandards nicht implementiert, auf die sich diese Agenten stützen.

Die gute Nachricht: Die Standards existieren, sie sind offen und Sie können sie heute umsetzen.

Was ist der Agent-Readiness-Stack?

Agent Readiness ist kein einzelnes Häkchen in einer Checkliste. Es ist ein Stack aus ergänzenden Standards, die jeweils einen anderen Aspekt davon abdecken, wie KI-Agenten mit Ihrer Website interagieren.

Schicht 1: Content Access

Können KI-Agenten Ihre Inhalte effizient lesen?

robots.txt mit expliziten Regeln für KI-Bots ist der Ausgangspunkt. Die großen KI-Crawler geben jeweils eigene User-Agents bekannt, und das Einfachste und am besten Unterstützte, das Sie heute tun können, ist, sie namentlich aufzuführen und für jeden zu entscheiden, ob Sie ihn mit Allow zulassen oder mit Disallow ausschließen:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

Für die meisten Marken mit mehreren Standorten ist es die richtige Entscheidung, all diese Crawler zuzulassen. Sie möchten zitiert werden. Diese Regeln sind Standard-Direktiven nach RFC 9309, die alle genannten Crawler lesen. Diese Schicht ruht also auf einem soliden Fundament.

Content Signals ist eine neuere, feiner gegliederte Schicht oberhalb von robots.txt. Der Content-Signals-Entwurf (ein IETF Internet-Draft von Michael Tremante und Leah Romm bei Cloudflare) fügt Content-Signal-Direktiven hinzu, die festlegen, wie KI Ihre Inhalte verwenden darf, nicht nur ob sie sie abrufen darf:

User-agent: *
Content-Signal: ai-train=yes, search=yes, ai-input=yes
Allow: /

Das signalisiert KI-Crawlern: Sie dürfen unsere Inhalte zum Training von Modellen verwenden (ai-train), für den Aufbau von Suchindizes (search) und zur Erzeugung KI-gestützter Antworten (ai-input). Jeder User-Agent-Block erhält sein eigenes Content-Signal, sodass Sie unterschiedliche Berechtigungen für unterschiedliche Crawler festlegen können.

Der Vorschlag ist vielversprechend und einen Blick wert. Da es sich noch um einen frühen IETF-Entwurf handelt, ist die Verbreitung ungleichmäßig: Cloudflare hat ihn in die robots.txt eingebaut, die für Sites in deren Netzwerk verwaltet wird, während die großen KI-Labore bisher öffentlich nicht bestätigt haben, ob sie die Content-Signal-Direktive auswerten. Sie heute zu ergänzen, ist eher eine Absichtserklärung als eine erzwungene Regel, und das ist eine durchaus sinnvolle Entscheidung.

Ein kleiner Hinweis: Bis Ende Mai 2026 löste das Hinzufügen von Content-Signal-Zeilen eine kosmetische Meldung “robots.txt is not valid” in PageSpeed Insights aus, weil der Validator nur die Direktiven der ursprünglichen robots.txt-RFC kannte. Googles Validator wurde inzwischen aktualisiert, und seit dem 26. Mai 2026 erscheint die Warnung nicht mehr. Manche älteren SEO-Tools melden sie eventuell weiterhin, doch die Direktive bleibt unbedenklich: RFC 9309 weist Crawler an, ihnen unbekannte Zeilen zu ignorieren, sodass weder Ihr Suchranking noch der KI-Zugriff darunter leidet.

Markdown-Content-Negotiation liefert KI-Agenten saubere, strukturierte Inhalte statt rohes HTML. Wenn ein Agent Accept: text/markdown in seiner HTTP-Anfrage sendet, liefert der Server Markdown für dieselbe kanonische URL aus, während Browser weiterhin HTML erhalten. Das Markdown kann entweder zur Laufzeit am Edge erzeugt werden (Cloudflares Ansatz) oder als begleitende .md-Datei am Origin vorab generiert sein (das Muster, das Vercel, Sentry, Sanity und auch diese Website nutzen). In beiden Fällen gibt es eine URL für den Inhalt, und die Antwort variiert anhand des Accept-Headers.

Warum es für Agenten wichtig ist. Der Hauptgrund für Markdown ist Wirtschaftlichkeit. Jeder Token, den ein Agent liest oder erzeugt, kostet Rechenleistung, und das schlägt sich direkt in Latenz, API-Ausgaben und Bandbreite nieder. Eine einfache Markdown-Überschrift kostet rund drei Tokens, das entsprechende HTML-Markup zwölf bis fünfzehn, laut Cloudflares Ankündigung von “Markdown for Agents”. Über eine ganze Seite hinweg ist sauberes HTML typischerweise zwei- bis dreimal so teuer wie derselbe Inhalt in Markdown, und reales HTML mit CSS, JavaScript und Tracking kann auf das Acht- bis Zehnfache anschwellen, laut der HTML-vs-Markdown-Analyse von Beam.ai. Cloudflare hat den eigenen Ankündigungsbeitrag mit 16.180 Tokens als HTML und 3.150 als Markdown gemessen, eine Reduktion um 80 Prozent. Vercel berichtet eine ähnliche Geschichte aus Sicht der Bandbreite: Die HTML-Version einer Seite auf ihrer Website wog rund 500 KB, die Markdown-Version 3 KB, eine Reduktion der Nutzlast um 99 Prozent zusätzlich zur Token-Ersparnis. Die beiden Zahlen messen Unterschiedliches (Tokens vs. Bytes) und stammen von unterschiedlichen Anbietern mit unterschiedlichen Methoden, aber sie zeigen in dieselbe Richtung. Bei den heutigen Preisen großer Modelle summiert sich diese Differenz schnell über eine Sitzung, und die eingesparte Rechenleistung und Bandbreite kann in mehr Reasoning, mehr Tool-Aufrufe oder einfach in eine günstigere Anfrage fließen.

Die Ersparnisse wirken über die reinen Kosten hinaus. Weniger Tokens bedeuten mehr Platz im Kontextfenster des Agenten für die eigentliche Aufgabe, eine schnellere Zeit bis zum ersten Token, weil weniger geladen und geparst werden muss, und ein besseres Signal-Rausch-Verhältnis für den Abruf (keine Navigation, Anzeigen, Modale oder Layout-Wrapper, die mit dem Inhalt konkurrieren). Markdown ist außerdem das Format, auf dem LLMs überwiegend trainiert wurden (GitHub-READMEs, technische Dokumentation, generierte Ausgaben), und damit oft der für sie sprachlich flüssigste Eingang. Cloudflare liefert sogar einen x-markdown-tokens-Response-Header neben dem konvertierten Output aus, dokumentiert in Cloudflare Fundamentals, sodass der Agent die Token-Anzahl im Voraus prüfen und entscheiden kann, ob das Dokument in das Kontextfenster passt oder gestückelt werden muss.

Wer es heute unterstützt. Laut dem Status-Tracker auf acceptmarkdown.com begann die clientseitige Unterstützung in Coding-Tools und breitet sich jetzt auch in allgemeine Arbeitsoberflächen aus. Claude von Anthropic sendet Accept: text/markdown aus Claude Code und aus Cowork in der Claude Desktop App (wir haben das zum Redaktionsschluss in unseren eigenen Request-Logs verifiziert). Damit ist Markdown-Content-Negotiation nicht länger ein reines Coding-Thema: Cowork ist die Oberfläche in der Desktop App für Recherche, Konzeption und Browsing, sodass jedes Geschäftsdokument, jeder Wettbewerbsabgleich und jeder Artikel, den eine Claude-Nutzerin oder ein Claude-Nutzer Cowork zum Abruf gibt, über diesen Pfad läuft. Die reguläre Chat-Oberfläche in der Desktop App und auf claude.ai sendet den Header noch nicht. Cursor, OpenCode und OpenClaw senden ihn ebenfalls. OpenAIs Codex CLI unterstützt ihn teilweise: Es ruft zunächst die kanonische URL als HTML ab und sucht dann im Head nach <link rel="alternate" type="text/markdown">, bevor es die begleitende Markdown-Datei anfordert. Die konsumentenorientierten Oberflächen (ChatGPT Browse, Gemini, Perplexity, Copilot Browse) senden den Header heute meist nicht. Vorerst lässt sich das Ganze also als Optimierung für Coding-Agenten und die Claude-Arbeitsoberflächen verstehen, wobei die Konsumenten-Agenten voraussichtlich nachziehen werden. Es lohnt sich, vor dem Verlass auf einen bestimmten Client selbst nachzumessen, denn diese Verhaltensweisen ändern sich schnell.

Wer den Standard vorantreibt. Es handelt sich um eine Konvention mehrerer Anbieter, nicht um den Vorstoß eines einzelnen Unternehmens. Es gibt keine formelle IETF-Arbeit, sondern ein Muster, das sich auf bestehende Standards stützt (RFC 7231 Content Negotiation und den Medientyp text/markdown aus RFC 7763). Auf der Infrastruktur- und Plattformseite konvertiert Cloudflares “Markdown for Agents” HTML am Edge in Markdown für Sites in den Tarifen Pro, Business und Enterprise, während Vercel inhaltsverhandeltes Markdown auf den eigenen Properties ausliefert und eine Next.js-Implementierungsanleitung veröffentlicht. Auf Origin-Seite häufen sich Implementierungen im CMS- und Dev-Tools-Ökosystem: Sentry liefert Markdown per Accept-Header aus, Sanity hat einen Field Guide zur Auslieferung von Inhalten an Agenten veröffentlicht, DeployHQ dokumentiert das Muster für Laravel, Express, Django und statische Sites, und Roots haben ein WordPress-Plugin veröffentlicht, das die Inhaltsverhandlung auf kanonischen URLs übernimmt. Es gibt zudem eine GitHub-Diskussion bei Next.js, in der Framework-Nutzer die Verkabelung diskutieren, und Implementierungsanleitungen ausdrücklich für den Weg ohne Cloudflare. Auf der Client-Seite haben Anthropic und Anysphere die Verbreitung über Claude Code und Cursor zuerst vorangetrieben. Kein Unternehmen kontrolliert die Konvention, und die Breite der Stacks, die unabhängig voneinander mitziehen, macht die Verteilung erst real.

Wo Google steht. Googles John Mueller ist gegenüber “Markdown für Bots” generell skeptisch und bezeichnete die Idee auf Bluesky als “stupid idea”. Auf Reddit fragte er, warum Agenten eine Seite brauchen sollten, die kein Nutzer sieht, da LLMs seit jeher auf HTML trainiert und HTML parsen. Googles offizieller Leitfaden zur AI Optimization folgt derselben Linie und nennt KI-spezifische Markdown-Dateien unter den Dingen, die Sie nicht ergänzen müssen, damit Ihre Seiten in deren generativen KI-Oberflächen erscheinen. Microsofts Fabrice Canel hat ähnliche Bedenken gegen das Anlegen separater Inhaltsversionen für Crawler geäußert und verweist auf zusätzliche Crawl-Last und das Risiko, dass nicht nutzerseitige Versionen vernachlässigt werden und veralten. Es lohnt sich, ihre Einwände genau zu lesen, denn sie zielen auf ein verwandtes, aber anderes Muster: das Ausliefern komplett unterschiedlicher Markdown-Inhalte unter einer separaten URL anhand von User-Agent-Sniffing. Echte Content Negotiation, bei der dieselbe URL anhand des Accept-Headers entweder HTML oder Markdown für denselben zugrundeliegenden Inhalt ausliefert, ist ein lange etablierter HTTP-Mechanismus (genauso wie Bilder je nach Client als WebP oder JPEG ausgeliefert werden können). Behalten Sie im Hinterkopf, dass Googles Leitfaden davon handelt, in den eigenen KI-Produkten zu erscheinen, während der oben beschriebene Token-Effizienz-Fall davon handelt, effizient für jeden Agenten zu sein, der sich bereits entschieden hat, Ihre Inhalte zu lesen. Die Trennlinie zwischen beidem ist wichtig.

Risiken, die Sie kennen sollten. Das meistdiskutierte Risiko ist eine Cloaking-Variante. Der SEO-Forscher David McSweeney hat gezeigt, dass Cloudflares Edge-Implementierung den Accept: text/markdown-Header an den Origin weiterreicht und damit dem Origin praktisch mitteilt: “Diese Anfrage stammt von einem KI-Agenten.” In seinem Proof of Concept lieferte der Origin Menschen eine Seite und Agenten eine völlig andere aus, und Cloudflare konvertierte pflichtbewusst das auf Agenten zugeschnittene HTML in Markdown. Die vorgeschlagene Gegenmaßnahme besteht darin, dass Edge-Anbieter den Header vor dem Abruf vom Origin entfernen, das ist heute aber noch nicht Standard. Dieselbe Eigenschaft öffnet einen Prompt-Injection-Vektor für Agenten, die im Auftrag eines Nutzers Aktionen ausführen, weil der Nutzer nie sieht, was der Agent liest. Außerdem zu bedenken: Vary: Accept ermöglicht das korrekte Caching beider Repräsentationen, kann aber die Trefferquote senken und das CDN-Verhalten komplizierter machen. Edge-konvertiertes Markdown ist außerdem generisch, sodass für aufwendig gestaltete Marketing- oder Produktseiten eine vom Origin verfasste Markdown-Variante meist besser liest als das, was eine automatische HTML-zu-MD-Konvertierung übriglässt.

llms.txt ist eine Markdown-Datei im Stammverzeichnis Ihrer Website, die einen kuratierten Überblick über Ihre Website für KI-Systeme bereitstellt. Die Konvention wurde 2024 vorgeschlagen und von einigen Websites übernommen, aber bisher behandelt kein großer KI-Crawler sie offiziell als Erkennungssignal. Googles AI-Optimization-Leitfaden ordnet llms.txt ausdrücklich unter den Dingen ein, die Sie nicht anlegen müssen, mit dem Argument, dass KI-Systeme normales HTML problemlos parsen können. Allerdings hat Googles eigener Lighthouse-Auditor eine Kategorie “Agentic Browsing” in v13.2 (April 2026) eingeführt und in v13.3 in der Folgewoche zur Standardkonfiguration gemacht. Die Kategorie sucht ausdrücklich nach einer llms.txt im Stammverzeichnis, das Bild ist also gemischt. Die Kategorie wird bewusst nicht auf einer gewichteten Skala von 0 bis 100 bewertet, solange sich die Standards noch entwickeln, sodass die llms.txt-Prüfung informativ und kein Ranking-Signal ist. Mit etablierter Markdown-Content-Negotiation erhalten Agenten bereits sauberes Markdown für jede Seite, die sie abrufen, was den größten Teil des ursprünglichen Anwendungsfalls überflüssig macht. llms.txt ist am ehesten für Websites mit dichter technischer Dokumentation nützlich, wo eine kuratierte Karte den Agenten den richtigen Einstiegspunkt zeigt. Für Marken mit mehreren Standorten, deren Standorte und Blogbeiträge jeweils unabhängig über die Sitemap und Markdown-Content-Negotiation auffindbar sind, ist der Nutzen geringer.

Schicht 2: Strukturierte Daten

Können KI-Agenten verstehen, was Ihre Inhalte bedeuten?

Strukturierte Daten mit JSON-LD liefern KI-Agenten explizite, standardisierte Beschreibungen Ihres Unternehmens. Für Marken mit mehreren Standorten nennt das LocalBusiness-Schema auf jeder Standortseite Name, Adresse, Telefonnummer, Öffnungszeiten, Bewertungen und Leistungen in einem Format, das Agenten verarbeiten können, ohne raten zu müssen.

Ergänzen Sie FAQPage, Product, Article und BreadcrumbList dort, wo es passt. Je mehr strukturierte Daten Sie bereitstellen, desto zuverlässiger kann ein KI-Agent Sie zitieren und empfehlen.

Schicht 3: Protokollerkennung

Können KI-Agenten Ihre Tools und Funktionen finden?

Das ist die neueste Schicht und diejenige, die sich am schnellsten entwickelt. Drei aufkommende Standards decken verschiedene Aspekte der Tool-Erkennung ab:

MCP Server Cards (SEP-2127, vorgeschlagen vom MCP-Team unter Leitung von David Soria Parra bei Anthropic) erlauben es Ihnen, Ihren Model-Context-Protocol-Server unter /.well-known/mcp-server-card bekannt zu machen. Wenn Ihr Unternehmen über einen MCP-Server verfügt, erfahren KI-Clients darüber genau, wie sie ihn finden und sich verbinden können.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "com.example/my-location-mcp",
  "version": "1.0.0",
  "description": "Query location data across all business locations"
}

Agent Skills (Cloudflare RFC) veröffentlichen einen Katalog der Funktionen Ihrer Website unter /.well-known/skills/index.json. Jeder Skill ist eine Markdown-Datei, die beschreibt, was Agenten mit Ihrer Website tun können, von der Suche in Ihrer Wissensdatenbank bis zum Vergleich Ihrer Produkte mit dem Wettbewerb.

WebMCP (eine W3C-Community-Group-Spezifikation, betreut von Engineers bei Google und Microsoft) registriert Tools über navigator.modelContext.registerTool(), die browserbasierte KI-Agenten direkt aufrufen können. Statt dass ein Agent rät, ob irgendwo auf Ihrer Seite ein “Demo anfordern”-Button existiert, registrieren Sie ein request_demo-Tool mit Beschreibung, Parametern und einem Ausführungs-Callback.

navigator.modelContext.registerTool({
  name: "request_demo",
  description: "Book a personalized demo of the platform",
  execute: async () => {
    window.location.href = "/requestademo/";
    return { navigated: "/requestademo/" };
  }
});

Google beschreibt WebMCP als “direkten Kommunikationskanal”, der “Mehrdeutigkeit beseitigt und schnellere, robustere Agent-Workflows ermöglicht”.

Schicht 4: Zugriffskontrolle

Welche Agenten dürfen was tun?

Content Signals (siehe Schicht 1) regeln die Inhaltsberechtigungen. Sie können die Indexierung durch Suchmaschinen erlauben, das Training aber untersagen, oder alles zulassen. Die Verbreitung ist noch jung. Verstehen Sie es als Erklärung Ihrer Präferenz, nicht als garantierte Durchsetzung.

Regeln für KI-Bots in der robots.txt erlauben es Ihnen, bestimmte Crawler gezielt zuzulassen oder zu blockieren: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended und andere. Für die meisten Marken ist es sinnvoll, alle KI-Crawler zuzulassen. Sie möchten schließlich auffindbar sein.

Warum profitieren Marken mit mehreren Standorten am stärksten von Agent Readiness?

Ein einzelnes Café wird vielleicht allein über Google Maps gefunden. Eine Marke mit 500 Standorten in 12 Ländern steht jedoch vor einer grundlegend anderen Herausforderung. Jeder Standort muss für KI-Agenten einzeln auffindbar sein, und die Daten aller Standorte müssen konsistent, strukturiert und maschinenlesbar sein.

Skaleneffekte verstärken den Vorteil. Wenn ein einzelner Standort eines Wettbewerbers Agent-Ready ist und Ihrer nicht, verlieren Sie diese eine Empfehlung. Wenn Sie 500 Agent-Ready-Standorte haben und Ihr Wettbewerber keinen, gewinnen Sie 500 Empfehlungen.

Lokale Anfragen gehen zuerst an Agenten. “Finde einen … in meiner Nähe” gehört zu den häufigsten Anfragen, die Menschen an KI-Assistenten richten. Genau diese Anfragen führen direkt zu Besuchen im Geschäft, und sie benötigen strukturierte Standortdaten, Bewertungen und Geschäftsinformationen, auf die Agenten programmatisch zugreifen können.

KI-Agenten benötigen Echtzeit-Daten. Ein MCP-Server kann aktuelle Bewertungsnoten, laufende Öffnungszeiten und tagesaktuelle Leistungsangebote ausliefern. Statische HTML-Seiten können das nicht. Marken, die ihre Live-Daten über MCP verfügbar machen, liefern Agenten die aktuellsten und genauesten Informationen, was die Wahrscheinlichkeit einer Empfehlung deutlich erhöht.

Umsetzungspriorität für Marken mit mehreren Standorten

Nicht alle Standards sind heute gleich wichtig. Hier ist die Reihenfolge, die Ihnen mit dem geringsten Aufwand die größte Sichtbarkeit bringt:

Hier starten

1. robots.txt aktualisieren mit expliziten Regeln für KI-Bots (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended)
2. JSON-LD-strukturierte Daten verifizieren auf allen Seitentypen (LocalBusiness für Standorte, Product, FAQPage, Article)

Nächste Schritte

3. Markdown-Content-Negotiation implementieren, damit KI-Agenten saubere Inhalte erhalten

Fortgeschritten

4. MCP Server Card veröffentlichen, falls Sie einen MCP-Server betreiben
5. WebMCP-Tools implementieren für zentrale Aktionen (Demo-Anfragen, Standortsuche, Produktnavigation)
6. Agent Skills veröffentlichen, die die Funktionen Ihrer Website auflisten

Wenn Sie Zeit und Ressourcen haben, kann das zusätzlich helfen

7. llms.txt und llms-full.txt ergänzen, aber nur, wenn Sie dichte technische Dokumentation pflegen. Für die meisten Marken mit mehreren Standorten lohnt sich das nicht. Die Verbreitung unter den großen KI-Crawlern ist uneinheitlich, Googles AI-Optimization-Leitfaden sagt ausdrücklich, dass Sie es nicht brauchen, und Markdown-Content-Negotiation deckt für jede abgerufene Seite ohnehin denselben Bereich ab. Das Muster mit der kuratierten Übersicht ist am nützlichsten, wenn Agenten in tiefen Entwicklerdokumentationen den richtigen Einstiegspunkt finden müssen, und nicht, wenn jeder Standort und jeder Blogbeitrag bereits unabhängig über Ihre Sitemap auffindbar ist.
8. Content-Signals-Direktiven in robots.txt ergänzen, um zu erklären, wie KI Ihre Inhalte verwenden darf. Der IETF-Entwurf bewegt sich und ist es wert, ihn weiterzuverfolgen. Die Verbreitung unter den großen KI-Crawlern ist noch früh, aber die Direktive ist unbedenklich zu ergänzen (Crawler ignorieren unbekannte Direktiven) und eine schöne Möglichkeit, schon heute eine klare Haltung zu markieren.

Alles testen

Führen Sie Ihre Website durch isitagentready.com, den offiziellen Agent-Readiness-Scanner von Cloudflare (eingeführt im April 2026), um zu sehen, welche Prüfungen bestanden werden. Das Tool bewertet denselben vierschichtigen Stack, der diesen Artikel gliedert (Discoverability, Content Accessibility, Bot Access Control und Capabilities), und zeigt Ihnen genau, was fehlt.

Für eine zweite Einschätzung ist der Agent Readiness Score von GEO Metrics ebenfalls kostenlos und deckt dieselben vier Dimensionen ab. Hinzu kommt eine zusätzliche redaktionelle Dimension für strukturierte Daten, Autorensignale und weitere KI-Zitiersignale. Eine nützliche Gegenprobe, wenn Sie sehen möchten, ob Ihre Ergebnisse auch unter einer anderen Methodik stabil bleiben.

Darüber hinaus hat Lighthouse eine neue Kategorie “Agentic Browsing” hinzugefügt in v13.2 (April 2026), in v13.3 standardmäßig aktiviert, mit Audits zu WebMCP-Tool-Registrierung, Schema-Gültigkeit, einer llms.txt im Stammverzeichnis und einigen Signalen zur Barrierefreiheit für Agenten. Die Kategorie wird bewusst nicht auf einer gewichteten Skala von 0 bis 100 bewertet (“die Standards für das agentische Web entwickeln sich noch”), behandeln Sie sie also eher als Checkliste denn als Zahl, die es zu optimieren gilt. Die Audits laufen in den Chrome DevTools und sind dadurch eine schnelle Ergänzung zu den oben genannten Agent-Readiness-Scannern.

Die Standards (Mai 2026)

Diese Standards entwickeln sich schnell weiter. So ist der aktuelle Stand:

Das gemeinsame Merkmal: Es sind offene Standards, die von großen Technologieunternehmen getragen werden. Keiner ist an einen einzelnen Anbieter gebunden. Wer sie heute umsetzt, baut auf Fundamenten auf, auf die die gesamte Branche zusteuert.

Welche Agent-Readiness-Standards kommen als Nächstes?

Die Standards rund um Agent Readiness entwickeln sich weiterhin sehr schnell. Einige Dinge, die Sie im Blick behalten sollten:

Agent Card (aus dem AI-Card-Projekt) soll ein protokollunabhängiges Erkennungsformat unter /.well-known/ai-catalog.json werden. Stellen Sie es sich als Telefonbuch für KI-Dienste auf einer Domain vor.

Commerce-Protokolle sind von “im Entstehen” zu “im Rollout” geworden. Am 11. Januar 2026 hat Google das Universal Commerce Protocol (UCP) eingeführt, einen offenen Standard für agentischen Handel, gemeinsam entwickelt mit Shopify, Etsy, Wayfair, Target und Walmart und unterstützt von mehr als 20 weiteren Unternehmen, darunter Best Buy, The Home Depot, Macy’s, Adyen, Stripe, Visa, Mastercard, Flipkart und Zalando. UCP ist ausdrücklich kompatibel mit MCP, A2A und AP2, sodass die in diesem Artikel beschriebene Arbeit an strukturierten Daten und Protokollen wiederverwendbar ist und nicht verloren geht. Stripes und OpenAIs Agentic Commerce Protocol (ACP) deckt dasselbe Problem von der Zahlungsseite ab, und x402 bleibt eine Option für Mikrozahlungen. Wenn Sie online verkaufen, ist agentischer Handel der nächste Umsetzungsmeilenstein nach dem Erkennungs-Stack, kein “beobachten und abwarten”.

Authentifizierung verifizierter Bots wird derzeit erforscht. Dabei können KI-Agenten ihre Identität nachweisen und unterschiedliche Zugriffsebenen erhalten. So ließen sich verifizierten Agenten reichhaltigere Daten bereitstellen, während unbekannte Bots eingeschränkt bleiben.

Markenagenten in der Suche: Google Business Agent

Im Januar 2026 hat Google Business Agent eingeführt, einen konfigurierbaren virtuellen Vertriebsassistenten, den Marken aus dem Merchant Center aktivieren und der direkt in der Google Suche erscheint. Laut Googles Ankündigung sind berechtigte US-Händler wie Lowe’s, Michael’s, Poshmark und Reebok mit dem ersten Rollout live gegangen. Die händlerspezifische Schulung auf eigenen Daten, Angebote für verwandte Produkte und der agentische Checkout sind als Folgefunktionen positioniert. Diese Schulungs-, Empfehlungs- und Checkout-Funktionen hängen am Rollout-Plan von Google. Prüfen Sie also im Merchant Center, was aktuell für Ihren Account verfügbar ist, bevor Sie gegenüber Stakeholdern konkrete Termine zusagen.

Begleitend zu Business Agent hat Google Dutzende neuer Merchant-Center-Datenattribute eingeführt, die für AI Mode, Gemini und Business-Agent-Oberflächen konzipiert sind. Diese Attribute reichen über reine Keywords hinaus und umfassen Antworten auf häufige Produktfragen, kompatibles Zubehör und Alternativen.

Für Marken mit mehreren Standorten ist die Konsequenz einfach. Dieselben strukturierten Daten, dasselbe FAQ-Schema und dieselben Live-Standort-Feeds, die Sie für den Agent-Readiness-Stack veröffentlichen, speisen die konversationelle Oberfläche, an der Käufer zunehmend ihre Recherche beginnen. Wenn ein Wettbewerber FAQ-Attribute im Merchant Center veröffentlicht und Sie nicht, ist es wahrscheinlicher, dass der Business Agent, der die Frage einer Kundin beantwortet, dessen Marke surfaces und nicht Ihre.

Wie setzen Sie Agent Readiness über Hunderte von Standorten hinweg um?

Die Umsetzung dieser Standards auf einer einzelnen Website ist überschaubar. Sie über Hunderte oder Tausende Standorte hinweg umzusetzen, ist eine völlig andere Herausforderung. Jeder Standort benötigt konsistente strukturierte Daten, korrekte Öffnungszeiten, aktuelle Bewertungsnoten und sauber formatiertes Schema-Markup. Wenn diese Daten auseinanderlaufen, und das werden sie, erhalten KI-Agenten widersprüchliche Signale und verlieren das Vertrauen in Ihre Marke.

Genau hier werden Plattformen für Standortmanagement unverzichtbar. PLACES AI von PinMeTo verwaltet strukturierte Daten über mehr als 100 Listing-Netzwerke hinweg und verbindet Live-Standortdaten über den PinMeTo Location MCP mit KI-Assistenten. So erhalten Agenten einen direkten Echtzeit-Feed Ihrer Geschäftsinformationen statt veralteter HTML-Inhalte.

Wenn Sie tiefer einsteigen möchten, wie KI-Suche die lokale Erkennung verändert, lesen Sie unseren vollständigen GEO-Leitfaden für Marken mit mehreren Standorten sowie unsere Glossareinträge zu AI Overviews und Generative Engine Optimization.

Aktualisierungen

Dieses Thema bewegt sich schnell, daher überarbeiten wir den Beitrag, sobald sich Standards verfestigen. Aktuelle Änderungen:

• 2026-05-27: Hinweis auf die neue Lighthouse-Kategorie “Agentic Browsing” (WebMCP, llms.txt, Agenten-Barrierefreiheit, Layout-Stabilität) ergänzt. Die Bewertung erfolgt bewusst noch nicht als gewichteter Score von 0 bis 100, solange sich die Standards entwickeln, daher sind die Prüfungen derzeit informativ. Im llms.txt-Abschnitt und in der Tools-Liste ergänzt.
• 2026-05-26: Googles PageSpeed-Insights-Validator erkennt nun die Content-Signal-Direktive, sodass das Hinzufügen von Content Signals zur robots.txt keine “robots.txt is not valid”-Warnung mehr auslöst. Der Abschnitt zum Content Access und die Implementierungs-Checkliste wurden entsprechend angepasst.
• 2026-05-22: Kontext zu Google Business Agent und ein FAQ-Eintrag zum Universal Commerce Protocol (UCP) ergänzt, anschließend an die Google-Ankündigungen vom Januar 2026.

Häufig gestellte Fragen

Wie teste ich, ob meine Website Agent-Ready ist?

Besuchen Sie isitagentready.com, den offiziellen Agent-Readiness-Scanner von Cloudflare, und geben Sie Ihre URL ein. Der Scanner prüft alle aktuellen Standards und liefert Ihnen einen Bestanden-/Nicht-bestanden-Bericht mit konkreten Handlungsempfehlungen. Für eine zweite Einschätzung mit zusätzlicher redaktioneller Dimension lohnt sich der ebenfalls kostenlose Agent Readiness Score von GEO Metrics.

Beeinträchtigt die Einführung von Agent-Readiness-Standards mein bestehendes SEO?

Nein. Agent Readiness baut auf bestehenden SEO-Best-Practices auf. robots.txt, strukturierte Daten und Sitemaps sind ohnehin Teil von SEO. Die neuen Standards (Content Signals, MCP Server Cards, WebMCP) sind ergänzend. Sie verändern nicht, wie Suchmaschinen mit Ihrer Website interagieren.

Benötige ich einen Entwickler für die Umsetzung?

Die Grundlagen (robots.txt-Regeln, strukturierte Daten mit JSON-LD, Content-Signals-Direktiven) kann jede Person umsetzen, die mit dem Bearbeiten von Text- und Konfigurationsdateien vertraut ist. Markdown-Content-Negotiation lässt sich per Knopfdruck aktivieren, wenn Ihre Website hinter Cloudflare Pro oder höher läuft. Andernfalls muss ein Entwickler entweder eine begleitende .md-Datei im Build erzeugen oder eine Origin-Weiterleitung einrichten. WebMCP und MCP Server Cards erfordern JavaScript- und JSON-Kenntnisse. Für Enterprise-Implementierungen über Hunderte von Standorten hinweg sollte Ihr Entwicklungsteam oder Ihr Plattformpartner die Umsetzung übernehmen.

Was ist Google Business Agent und muss ich dafür etwas Neues tun?

Business Agent ist ein konfigurierbarer virtueller Vertriebsassistent, den Google im Januar 2026 eingeführt hat. Marken aktivieren ihn aus dem Merchant Center, und er erscheint direkt in der Google Suche, um Käuferfragen im Namen der Marke zu beantworten. Berechtigte US-Händler wie Lowe’s, Michael’s, Poshmark und Reebok waren beim Start live. Für Marken mit mehreren Standorten besteht der praktische Schritt darin, die neuen Merchant-Center-Datenattribute zu pflegen, die Google zusammen mit Business Agent eingeführt hat (Antworten auf häufige Produktfragen, kompatibles Zubehör, Alternativen), denn diese Attribute speisen Business Agent, AI Mode und Gemini. Die in diesem Leitfaden behandelte Agent-Readiness-Arbeit (strukturierte Daten, FAQ-Schema, Live-Standort-Feeds) liefert genau diese Eingaben, sodass sich der größte Teil des Aufwands direkt überträgt.

Was passiert, wenn sich diese Standards ändern?

Das werden sie. Das liegt in der Natur neu entstehender Spezifikationen. Die Kernprinzipien (strukturierte Daten, maschinenlesbare Inhalte, standardisierte Erkennung) sind jedoch bereits gut etabliert. Änderungen werden schrittweise erfolgen, nicht als grundlegende Neuentwicklung. Wer heute auf diesen Fundamenten aufbaut, muss in Zukunft nur kleine Anpassungen vornehmen, statt neu zu starten.

Ist Agent Readiness nur für Websites relevant, oder gilt das auch für Apps und andere Plattformen?

Die hier behandelten Standards sind web-orientiert und für Inhalte konzipiert, die über HTTP ausgeliefert werden. Mobile Apps, Sprachassistenten und IoT-Geräte haben eigene Mechanismen zur Erkennung. MCP als Protokoll funktioniert jedoch über jeden Client, der es unterstützt. Die Daten, die Sie für Ihre Website strukturieren, können also auch KI-Agenten außerhalb des Webs versorgen, sofern diese über MCP-Server angebunden sind.

Wie passt Googles Universal Commerce Protocol (UCP) in die Agent Readiness?

UCP ist die Transaktionsschicht über der Erkennungsschicht, auf die sich dieser Leitfaden konzentriert. Es ist ein offener Standard, den Google im Januar 2026 zusammen mit Shopify, Etsy, Wayfair, Target und Walmart als Co-Entwickler eingeführt hat, und er ist kompatibel mit MCP, A2A und AP2. Wenn Sie bereits strukturierte Produkt- und Standortdaten veröffentlichen, Tools über MCP bereitstellen und dem Agent-Readiness-Stack folgen, sind Sie gut aufgestellt, um sich an UCP anzubinden. Beim Start hat Google angekündigt, dass UCP den Checkout für berechtigte Produkteinträge in AI Mode und Gemini für US-Händler unterstützen wird, mit anschließender internationaler Ausweitung. Prüfen Sie den aktuellen Rollout-Status bei Google, bevor Sie Verfügbarkeit in Ihrem Markt voraussetzen.

Sie möchten Ihre Standorte für KI-Agenten sichtbar machen? Demo buchen und sehen, wie PLACES AI Marken mit mehreren Standorten dabei unterstützt, sowohl in der klassischen Suche als auch in KI-gestützter Erkennung auffindbar zu bleiben.

Quellen und Referenzen

• Content Signals for Automated Processing - IETF Internet-Draft von Michael Tremante und Leah Romm zu Direktiven für KI-Inhaltsberechtigungen
• SEP-2127: MCP Server Cards - Vorschlag des Model Context Protocol zur Bekanntmachung von MCP-Servern über Well-Known-URIs
• WebMCP Specification - Spezifikation der W3C Web Machine Learning Community Group für browserbasierte KI-Agent-Tools
• WebMCP: An API for the Agentic Web - Überblick von Chrome for Developers zu WebMCP und seiner Rolle in Agent-Workflows
• Agent Skills Discovery RFC - Von Cloudflare vorgeschlagener Standard zur Veröffentlichung von Website-Funktionen für KI-Agenten
• Introducing the Model Context Protocol - Ankündigung von Anthropic zu MCP als offenem Standard für die KI-Tool-Integration
• Introducing Markdown for Agents - Cloudflares Hauptankündigung mit dem Token-Benchmark 16.180 vs. 3.150 und dem Kostenvergleich pro Element
• Markdown for Agents (Cloudflare Fundamentals Docs) - Offizielle Dokumentation, inklusive des x-markdown-tokens-Response-Headers
• HTML vs Markdown for AI Agents (Beam.ai) - Vergleich, der sauberes HTML auf das 2- bis 3-Fache und reales HTML auf das 8- bis 10-Fache der Token-Kosten von Markdown beziffert
• Cloudflare Markdown for Agents: Complete Technical Guide (ALM Corp) - Sekundäre technische Aufarbeitung des 80-Prozent-Benchmarks und der SEO-Implikationen
• Making agent-friendly pages with content negotiation (Vercel) - Vercels Hauptbeitrag zur Auslieferung von Markdown per Accept-Header, inklusive der Reduktion von 500 KB auf 3 KB auf der eigenen Website
• Make your documentation readable by AI agents (Vercel) - Vercels Knowledge-Base-Leitfaden zur Content Negotiation für Dokumentationsseiten
• Allow pages to be served in markdown for AI Agents (Next.js Discussion #90579) - Community-Diskussion zur Umsetzung der Markdown-Content-Negotiation in Next.js
• How to serve content to agents: a field guide (Sanity) - Sanitys Leitfaden zur direkten Auslieferung von Inhalten an KI-Agenten
• Content Negotiation for AI Agents: Why Sentry Serves Markdown Over HTML - Fallstudie zur Sentry-Umsetzung der Markdown-Content-Negotiation
• How to Make Your Documentation AI-Friendly (DeployHQ) - Implementierungsleitfaden für Laravel, Express, Django und statische Sites
• Serve Your WordPress Posts as Markdown (Roots) - Roots-Walkthrough zur Auslieferung von Markdown aus WordPress per Accept-Header
• post-content-to-markdown WordPress-Plugin (Roots, GitHub) - Open-Source-WordPress-Plugin, das Post-Inhalte per Accept-Header und .md-URLs als Markdown ausliefert
• Implementing Markdown for Agents Without Cloudflare (Pragmate) - Implementierungsleitfaden ausdrücklich für den Weg ohne Cloudflare
• AI Statistics and Trends - Nutzungsdaten zum Wachstum und zur Verbreitung von KI-Chatbots (2024-2025), behalten als historischer Kontext
• Generative AI Statistics for 2026 (Similarweb) - Aktuelle Zahlen zu monatlichen Besuchen und wöchentlich aktiven Nutzern für ChatGPT und andere führende Chatbots
• AI Search Market Share 2026: ChatGPT, Gemini & Perplexity Stats (Stackmatix) - Geminis Wachstum um 647 Prozent gegenüber dem Vorjahr und die Marktanteilsverschiebungen bis März 2026
• New Data Study: What Queries Is ChatGPT Using Behind The Scenes? (Nectiv) - Nectivs Analyse von mehr als 8.500 ChatGPT-Prompts vom Oktober 2025, die Primärquelle für die Auslöserate von 59 Prozent für Live-Websuche bei lokal motivierten Prompts in ChatGPT
• Is Your Site Agent Ready? - Offizieller Agent-Readiness-Scanner von Cloudflare zum Testen Ihrer Website gegen aktuelle Standards
• Introducing the Agent Readiness Score (Cloudflare) - Cloudflares Ankündigung des isitagentready.com-Scanners (April 2026) inklusive des vierdimensionalen Bewertungsmodells
• Agent Readiness Score (GEO Metrics) - Unabhängiger kostenloser Scanner, der redaktionelle und KI-Zitiersignale zusätzlich zum selben vierschichtigen technischen Stack bewertet
• Model Context Protocol - Offizielle MCP-Dokumentation und Spezifikation
• robots.txt RFC 9309 - IETF-Standard für das Robots-Exclusion-Protokoll
• New tech and tools for retailers to succeed in an agentic shopping era - Google Ads & Commerce Blog, 11. Januar 2026, zu UCP, Business Agent, neuen Merchant-Center-Attributen und Direct Offers
• Universal Commerce Protocol - Offizielle UCP-Spezifikation und Partnerverzeichnis
• Business Agent in Merchant Center - Google-Merchant-Center-Dokumentation zur Aktivierung und Konfiguration von Business Agent
• Agent Payments Protocol (AP2) - Offenes Protokoll von Google Cloud für agentengesteuerte Zahlungen, von UCP referenziert
• Agent2Agent Protocol (A2A) - Offenes Protokoll für die Interoperabilität zwischen KI-Agenten, von UCP referenziert
• Agentic checkout for the holiday shopping season - Frühere Ankündigung von Google zum agentischen Shopping, auf der UCP aufbaut
• acceptmarkdown.com Status - Community-gepflegter Tracker dazu, welche KI-Clients Accept: text/markdown senden
• AI features and your website (Google Search Central) - Googles offizieller AI-Optimization-Leitfaden, inklusive der Mythbusting-Sektion, die ausdrücklich sagt, dass Sie für das Erscheinen in deren generativen KI-Suchoberflächen kein llms.txt, keine KI-Textdateien und kein Markdown benötigen
• Google’s Mueller Calls Markdown-For-Bots Idea ‘A Stupid Idea’ - Search Engine Journal über John Muellers öffentliche Kritik an bot-spezifischen Markdown-Seiten
• Google & Bing don’t recommend separate markdown pages for LLMs - Search Engine Land über die breitere Branchendebatte inklusive User-Agent-Sniffing und Cloaking-Bedenken
• HTTP Content Negotiation (RFC 7231) - Standardgrundlage für die Accept-Header-Verhandlung zwischen Client und Server
• text/markdown Media Type (RFC 7763) - IETF-Registrierung des Medientyps text/markdown, der in der Content Negotiation verwendet wird