So wählst du ein Agent-Readiness-Audit

Woher wir das wissen: Methodik hinter diesem Leitfaden

Geschrieben von Stephan Lucka, Gründer von agenticux.de, basierend auf zwei Messläufen, die ich durchgeführt und veröffentlicht habe.

Lauf im Juni 2026 (veröffentlicht am 30. Juni 2026): 89 deutsche Online-Shops aus mehreren Branchen, gemessen mit einem Agenten, der ausgeliefertes HTML liest, so wie es Agenten ohne vollständige Browser-Ausführung tun. 68 waren maschinell erreichbar, 21 haben den Agenten blockiert. Von den 68 erreichbaren: 41 Produkt-Schema im ausgelieferten HTML (60%), 53 eine erreichbare oder deklarierte Sitemap (78%), 65 ein Preissignal im HTML (96%), 53 ein maschinenlesbares Add-to-Cart-Signal (78%), 23 eine llms.txt (34%).

Lauf am 7. Juli 2026: 100 mittelgroße deutsche Fashion-Shops. 90 waren erreichbar, 10 haben den Agenten blockiert. Von den 90: 70 Produkt-Schema (78%), 83 eine Sitemap (92%), 87 ein Preissignal (97%), 75 ein Add-to-Cart-Signal (83%), 55 eine llms.txt (61%).

Eine Messregel dient mir zugleich als erster Test für jeden Anbieter: Ein Signal, das nicht verifiziert werden konnte, wurde nie als fehlend gezählt, und blockierte Shops wurden separat ausgewiesen. Vollständige Daten und Kriterien: agenticux.de/report.

Die 7 Kriterien zur Bewertung eines Audit-Anbieters

1. Es misst das HTML, das dein Server ausliefert

Warum das zählt: Viele Shopping-Agenten und KI-Crawler führen kein JavaScript aus, also kann ein Shop in Chrome vollständig aussehen, während das ausgelieferte HTML ein Template ohne Preis, ohne Varianten, ohne Produktdaten ist. In unserem Juni-Lauf konnten 22 von 68 erreichbaren Shops nicht abschließend auf Produkt-Schema geprüft werden, weil die Daten erst nach dem Ausführen von JavaScript erschienen; ein Audit mit gerendertem Browser hätte alle 22 als in Ordnung markiert.

Selbst testen (fünf Minuten): Öffne eine deiner wichtigsten Produktseiten, Rechtsklick, Seitenquelltext anzeigen (das rohe HTML, vor JavaScript), und suche nach "schema.org" und deinem Preis, oder füge die URL in validator.schema.org ein. Gut sieht so aus: ein Product-Knoten mit Name, Preis und Verfügbarkeit im rohen Quelltext. Eine nahezu leere App-Shell bedeutet, dass Agenten, die JavaScript überspringen, nichts sehen.

So prüfst du den Anbieter: Frag, ob sie beim Messen JavaScript ausführen und beide Zustände melden. Eine gute Antwort zeigt ausgeliefertes HTML und gerendertes DOM nebeneinander.

Warnsignal: Browser-Screenshots als Nachweis. Das beweist, dass die Seite für Menschen funktioniert, was du bereits wusstest.

2. Es meldet "nicht verifizierbar" als eigene Kategorie

Warum das zählt: Das ist der Ehrlichkeitstest. Wenn eine Prüfung nicht abgeschlossen werden kann, hat ein Anbieter einen wirtschaftlichen Anreiz, sie als Fehlschlag zu zählen, weil ein größeres Problem eine größere Lösung verkauft. In beiden veröffentlichten Läufen wurden nicht eindeutige Prüfungen (22 im Juni, 17 im Juli) als nicht eindeutig ausgewiesen. Im Juni sind "60% hatten verifizierbares Schema" und "nur 5 Shops hatten verifizierbar keines" beide wahr; ein seriöser Report gibt dir beides.

So prüfst du das: Frag, was im Report passiert, wenn eine Prüfung nicht abgeschlossen werden kann. Eine gute Antwort nennt eine separate Kategorie mit einer Anzahl und rechnet sie nie in die Fehlerquote ein.

Warnsignal: Dutzende Prüfungen und null "unbekannt"-Ergebnisse. Echte Messung hat immer einen Rest.

3. Es behandelt eine blockierte Messung als Befund, nicht als fehlende Daten

Warum das zählt: Im Juni-Mix blockierte etwa einer von vier Shops den Mess-Agenten vollständig; im Juli-Fashion-Lauf 1 von 10. Ein Block ist der folgenreichste Audit-Befund, weil eine blockierte Anfrage nie deine Tag-Skripte lädt, sodass der Fehler in deiner Analytics unsichtbar ist. Ein WAF-Dashboard zeigt vielleicht blockierten Bot-Traffic, aber es kann nicht zeigen, welche Empfehlung dich der Block gekostet hat.

Selbst testen: Lade deinen Shop aus einem Netzwerk außerhalb jeder Allowlist (ein mobiler Hotspot genügt), oder prüfe, ob die Standardeinstellung deines Bot-Schutzes eine Kategorie "KI-Agenten" blockiert. Gut sieht so aus: Du kannst benennen, welche Agenten-Kategorien dein Setup zulässt.

So prüfst du das: Frag, wie sie Blockierung erkennen und ob sie deine Produktivkonfiguration ohne Whitelist testen. Eine gute Antwort meldet einen Block als zentrales Ergebnis.

Warnsignal: Ein Anbieter, der dich bittet, seinen Crawler vor der Messung auf die Whitelist zu setzen. Das löscht den wertvollsten Datenpunkt.

4. Es geht vollständige Kaufpfade von Anfang bis Ende durch

Warum das zählt: Ein Agent kommt mit einer Aufgabe an: die richtige Variante finden, die Aussage verifizieren, die Lieferregel prüfen, Richtung Checkout gehen. Jeder Schritt kann für sich brechen: Ein Shop kann einen Startseiten-Scan bestehen und trotzdem am Warenkorb scheitern, wo Service-Level-Regeln oder Bundle-Bedingungen erst im letzten Schritt auflösen. Unser durchgearbeitetes Beispiel cartpilot ("Beispiel - Fallstudie" auf der Website, kein Kundenergebnis) modelliert diese Klasse: Produktnachweise, die auf der Listenseite halten und entlang des Pfads auseinanderfallen.

So prüfst du das: Frag, welche konkreten Kaufaufgaben sie von Anfang bis Ende durchspielen. Eine gute Antwort benennt Aufgaben in der Sprache deines Katalogs ("ein kompatibles Ersatzteil mit Expressversand finden") und zeigt, an welcher Stelle des Pfads jeder Fehler auftrat.

Warnsignal: Ein Ergebnisdokument, das nach Seitentyp gegliedert ist. Agenten scheitern an Entscheidungen, nicht an Seiten.

5. Es prüft, ob deine Regeln zu einer einzigen Version auflösen

Warum das zählt: Das ist die Fehlerklasse, die keine Signalprüfung erfassen kann, weil jede Fläche für sich korrekt aussieht: Die Produktseite nennt ein Lieferversprechen, die Richtlinienseite ein anderes, der Warenkorb ein drittes. Ein Agent muss entscheiden, welche Version er zitiert; seine sicheren Optionen sind: die vorsichtigste Version wählen, sich absichern oder den Käufer an den Support weiterleiten. Unser durchgearbeitetes Beispiel verity-goods ("Beispiel - Fallstudie"; illustrativ, kein Kundenergebnis) modelliert diesen Bruch, der Urteilsvermögen über mehrere Flächen hinweg erfordert, um ihn zu finden.

Selbst testen: Leg das Lieferversprechen einer Produktseite, deiner Versandrichtlinien-Seite und deines Warenkorbs nebeneinander. Gut sieht so aus: ein Wert, in allen dreien identisch angegeben. Zwei unterschiedliche Tageszahlen sind der Widerspruch, den ein Agent durch Absichern auflöst.

So prüfst du das: Frag, ob sie Aussagen über Produktseite, Richtlinien, Warenkorb, FAQ und Support-Inhalte hinweg vergleichen. Eine gute Antwort zeigt ein Aussagen-Inventar mit Quelle und Konsistenzstatus je Regel.

Warnsignal: Ein Audit, das nur die Markup-Syntax validiert. Schema, das selbstbewusst einen widersprochenen Wert angibt, ist schlimmer als gar kein Schema.

6. Das Ergebnis ist priorisierte Arbeit mit Bestehenskriterien, kein Score

Warum das zählt: Ein Score sagt dir, dass etwas nicht stimmt, ungefähr wie viel, und sonst nichts. Dein Team kann "62 von 100" nicht ausliefern. Ein brauchbares Ergebnis benennt den Bruch, den Nachweis, die Aufgabe (UX, Content oder Schema), den Verantwortlichen und das Kriterium, das "fertig" definiert, sortiert nach Umsatzrisiko, denn unpriorisierte Reports führen dazu, dass zuerst eine selten gekaufte Kategorie repariert wird.

So prüfst du das: Frag nach einem Beispiel-Befund. Ein guter liest sich wie das Beispiel unten: Nachweis, Mechanismus, Aufgabe, Bestehenskriterium. Ein schlechter liest sich wie ein Lint-Log.

Warnsignal: Ein 60-seitiges PDF, in dem jeder Befund dasselbe Gewicht hat. Ein langer Report kann trotzdem flach sein.

7. Es endet mit einem Test, den du ohne den Anbieter wiederholen kannst

Warum das zählt: Jedes Theme-Update, jeder Produkt-Launch und jede Richtlinienänderung schreibt das ausgelieferte HTML neu und kann stillschweigend einen Bruch wieder einführen. Das dauerhafte Ergebnis ist ein wiederholbarer Satz von Agenten-Aufgaben, der vor jedem Release läuft, idealerweise in CI; ein Dokument allein hat eine Haltbarkeit von einem Release-Zyklus. Auf Shopify oder Shopware ohne Engineering-Team zählt eine dokumentierte manuelle Testliste genauso; die Anforderung ist Wiederholbarkeit.

So prüfst du das: Frag, was ihr selbst ausführt, nachdem der Anbieter weg ist. Eine gute Antwort ist eine konkrete Übergabe (Suite oder schriftliche Checkliste) mit einer definierten Bestehensschwelle.

Warnsignal: Ein Retest-Angebot nach dem Motto "bucht uns nächstes Quartal wieder" mit nichts dazwischen. Das ist ein Abo, verkleidet als Audit.

DIY-Checkliste vs. automatisiertes Tool vs. gründergeführtes Audit

Alle drei sind legitim. Jedes hat Grenzen, die man klar benennen sollte.

Die ehrliche Reihenfolge: eine Checkliste zur Orientierung, ein Audit, um die echten Brüche zu finden und zu priorisieren, dann sein wiederholbarer Test, plus optional ein Tool gegen Drift. Ein Tool-Score, der als Audit verwendet wird, übersieht die teuren Brüche: Blocks, Widersprüche, spät auflösende Regeln.

Was ein echtes Ergebnis enthält

Ein Befund, auf den du reagieren kannst, hat fünf Teile: Bruch, Nachweis, Mechanismus, Aufgabe, Bestehenskriterium. Das folgende Beispiel ist unseren drei veröffentlichten, durchgearbeiteten Beispielen nachempfunden, cartpilot, verity-goods und northstar, jeweils auf der Website als "Beispiel - Fallstudie" gekennzeichnet. Es ist ein illustratives Szenario, kein Kundenergebnis.

> Befund: Varianten ohne Anker (Schweregrad: hoch, betrifft umsatzstärkste Kategorie)

>

> Nachweis: Produktseiten nennen im Marketing-Text eine "Pro"-Version; das ausgelieferte HTML gibt nie an, welche SKU das ist oder wie sich Varianten in Spannung, Passform oder Kapazität unterscheiden. In wiederholten Aufgaben wählten Agenten zwischen Varianten nach Versandgeschwindigkeit und trafen oft eine, die mit dem System des Käufers inkompatibel war.

>

> Warum ein Agent hier bricht: Die unterscheidenden Fakten existieren nur als Fließtext und Bilder. Ein Agent, der Varianten nicht eindeutig unterscheiden kann, rät entweder oder gibt die Empfehlung auf.

>

> Aufgabe: Führe ProductGroup-Markup mit variesBy für die Varianten-Achsen ein, plus Product-Knoten je Variante, die die unterscheidenden Eigenschaften als strukturierte Werte tragen. Verantwortlich: Engineering; Content liefert die Fakten je Achse.

>

> Bestehenskriterium: Eine Agenten-Aufgabe ("finde die 110-V-Variante, die mit System X kompatibel ist") wird ohne Schlussfolgern über die Kategorie hinweg abgeschlossen, vor dem Release verifiziert durch die übergebene Suite oder manuelle Checkliste.

Ein vollständiges Ergebnis ist eine priorisierte Liste von Befunden in dieser Form, plus das Aussagen-Inventar aus Kriterium 5 und die Test-Übergabe aus Kriterium 7. Ein Anbieter-Beispiel, das sich wie eine Einstellungs-Checkliste liest, ist ein Tool-Report zum Beratungspreis.

Was es kostet und was den Preis treibt

Ich veröffentliche keine Preistabelle, weil der Umfang die Zahl stärker bewegt als jede Preisliste. Prüfe jedes Angebot anhand dieser Treiber:

• Kaufpfade im Umfang. Jede End-to-End-Aufgabe wird separat gemessen und dokumentiert; drei Pfade kosten weniger als zehn.
• Katalogkomplexität. Viele Varianten-Achsen und Kompatibilitätsregeln bedeuten mehr Nachweisarbeit, unabhängig von der Anzahl der SKUs.
• Flächen im Umfang. Nur Produktseiten, oder auch Richtlinien, Warenkorb, Checkout, FAQ, Support-Inhalte. Die flächenübergreifende Arbeit ist, wo die Stunden hingehen.
• Retest enthalten oder nicht. Ein verifizierter Retest, nachdem die Fixes ausgeliefert sind, kostet mehr als die Messung allein; fehlt er in einem Angebot, frag warum.
• Übergabe und Begleitung. Agenten-Aufgaben, übergeben als Suite oder Checkliste, die dein Team behält, und nur Befunde gegenüber Zusammenarbeit mit deinem Team, während die Fixes ausgeliefert werden.

Ein billiges Audit ohne Retest und Übergabe ist oft die teure Option: Du zahlst dieselben Engineering-Kosten und kannst nicht verifizieren, dass die Fixes gewirkt haben.

Entscheidungsrahmen

Wähle eine DIY-Checkliste, wenn du diese Woche Orientierung willst und akzeptierst, dass du nur Lücken findest, nach denen du zu suchen weißt. Beginne mit Erreichbarkeit, Sitemap, Preis im ausgelieferten HTML und Produkt-Schema, den Signalen, die unser Report misst.

Wähle ein automatisiertes Tool, wenn die großen Brüche behoben sind und dein Problem Drift ist: Du lieferst wöchentlich aus und willst Regressionen günstig bemerken. Bestehe darauf, dass es "nicht verifizierbar" von "fehlt" unterscheidet, sonst führt dich seine Trendlinie in die Irre.

Wähle ein gründergeführtes Audit, wenn du vermutest, dass Agenten-Traffic dort scheitert, wo du es nicht sehen kannst, du wissen musst, welche von zwanzig möglichen Fixes zählen, oder du den zwei Problemklassen gegenüberstehst, die Tools nicht erfassen können: Blockierung (einer von vier in unserer Juni-Stichprobe, einer von zehn im Juli-Fashion-Lauf) und flächenübergreifende Widersprüche.

Verzichte jetzt auf jedes Audit, wenn du nächstes Quartal die Plattform wechselst (dann auditiere stattdessen die neue Plattform) oder niemand Kapazität hat, Befunde umzusetzen. Ein Audit, auf das du nicht reagieren kannst, ist ein Dokument; Dokumente ändern nicht, was Agenten zitieren können.

FAQ

Was ist ein Agent-Readiness-Audit?

Eine strukturierte Messung, ob KI-Agenten (Shopping-Agenten, KI-Suche, Assistenten) deinen Shop erreichen, Produktfakten aus dem ausgelieferten HTML extrahieren, Aussagen und Richtlinien verifizieren und einen Kaufpfad ohne Raten abschließen können. Ein SEO-Audit untersucht Seiten und Rankings; ein Agent-Readiness-Audit untersucht Aufgaben und Entscheidungen.

Kann ich meinen Shop nicht einfach selbst mit ChatGPT testen?

Ja, und das solltest du: echte Käuferfragen zu stellen und zu lesen, was zitiert wird, ist ein nützliches kostenloses Signal. Es kann dir nicht sagen, warum eine Antwort scheiterte, ob Bot-Schutz den Abruf blockiert hat oder was das ausgelieferte HTML enthielt. Du siehst das Symptom ohne den Mechanismus.

Wir blockieren Bots aus guten Gründen. Ist das ein Problem?

Es kann zugleich gerechtfertigt und teuer sein. Bot-Schutz, der Agenten-Traffic pauschal blockiert, blockiert auch Agenten, die dich empfehlen würden: In unserer Messung im Juni 2026 waren 21 von 89 Shops für den Mess-Agenten nicht erreichbar. Ein Audit macht die Abwägung bewusst; heute ist es meist eine Standardeinstellung, die niemand gewählt hat.

Warum zeigt meine Analytics nichts über Agenten-Probleme?

Weil die Fehler vor oder ohne dein Tracking passieren: Eine blockierte Anfrage lädt nie deine Tag-Skripte, und ein Agent, der ausgeliefertes HTML liest, führt sie vielleicht nie aus. Dashboards können stabile menschliche Conversion zeigen, während Agenten-Sessions an Erreichbarkeit oder Extraktion scheitern. Diese Lücke ist das stärkste Argument für ein Audit von außen nach innen.

Reicht llms.txt aus, um agent-ready zu sein?

Nein. Es ist eine freiwillige Konvention zur Anleitung von Agenten. Die Verbreitung unterschied sich stark zwischen unseren Stichproben: 34% der erreichbaren Shops im branchenübergreifenden Juni-Mix gegenüber 61% im Juli-Fashion-Lauf. Unterschiedliche Grundgesamtheiten, also stützt die Differenz keine Trendaussage. Es ergänzt eine Sitemap und Produkt-Schema; ein blockierter Shop gewinnt nichts durch eine perfekte llms.txt.

Schadet die Optimierung für Agenten meiner menschlichen Conversion?

Weitgehend nein: Die Änderungen helfen auch sorgfältigen menschlichen Käufern. Ein konsistentes Lieferversprechen, sichtbare Bedingungen neben den Aussagen, explizite Kompatibilität. Die Arbeit liegt in strukturierten Daten und Informationsarchitektur; deine Markenstimme bleibt unberührt. Sei vorsichtig bei einem Anbieter, der Überzeugungstexte streichen will; das Ziel ist, Beweis von Überzeugung zu trennen.

Daten: agenticux-Messläufe, Juni 2026 (89 Shops, branchenübergreifend, veröffentlicht am 30. Juni 2026) und 7. Juli 2026 (100 Fashion-Shops): [agenticux.de/report](https://agenticux.de/report). Autor: Stephan Lucka.