Kann ein KI-Agent in deinem Shopware-Shop einkaufen? Ein ehrlicher Selbsttest

Ich habe einen frischen Shopware 6.7.14.0 mit den offiziellen Demo-Daten aufgesetzt und eine einzige Frage gestellt: Was sieht ein KI-Agent, der hier einkaufen will?

Die Antwort passt in drei Zeilen. Strukturierte Daten auf der Produktseite: null Treffer. Eigenschaften über die Store API: sieben Hex-Strings ohne Bedeutung. Verfügbarkeit: ein leeres HTML-Element.

Das ist kein kaputter Shop. Das ist der Auslieferungszustand.

Ich habe danach jede dieser Lücken im Admin geschlossen und jeweils nachgemessen, was sich in der Ausgabe ändert. Alle Screenshots und alle Zahlen unten stammen aus diesem Durchlauf.

Was Shopware gerade fordert — und was davon heute trägt

Shopware-Mitgründer Stefan Hamann hat am 21. September bei etailment fünf Schritte für Agentic Commerce benannt. Ganz oben steht nicht Checkout, nicht Bezahlung, sondern Datenpflege:

1. Produktdaten agentenfähig machen — technische Attribute, Kompatibilitäten, Maße, Materialien, Staffelpreise, Verfügbarkeit, Lieferzeiten
2. Echtzeitdaten aus ERP, PIM und Shop verbinden — Preise, Bestände und Liefertermine in Near-Realtime
3. Use-Cases priorisieren — Wiederbestellungen, Ersatzteile, Verbrauchsmaterial, Auftragsstatus
4. Vertrauen und Kontrolle einbauen — Rollenrechte, Budgetgrenzen, Freigabeworkflows, Audit Logs
5. Content für KI optimieren, nicht nur für SEO — Anwendungsfälle, Alternativen, Spezifikationen, Normen

Der Satz, der hängen bleibt: „Für Menschen reicht oft ein Datenblatt. Für Agenten braucht es saubere Datenmodelle, APIs und eindeutige Produktlogik."

Jetzt die nüchterne Seite. Shopwares eigener Blogbeitrag vom 16.09. ist kein Produkt-Announcement, sondern der Abschluss einer siebenteiligen B2B-Serie mit einem Reifegradmodell: Operational AI heute, Assisted Agents in 12 bis 24 Monaten, Autonomous Agents in 24 bis 48 Monaten. Und die konkrete Verkaufsanbindung, die es gibt — ChatGPT-Marketplace-Registrierung und der PayPal-StoreSync-Feed — ist laut Shopware-Dokumentation aktuell US-only: „The feature is not currently available in Europe."

Als EU-Händler kannst du heute also über keinen dieser Kanäle verkaufen. Was du kannst: die Vorarbeit leisten. Und die Vorarbeit ist zufällig genau die Arbeit, die sich ohnehin lohnt — saubere Eigenschaften, gepflegte Lieferzeiten und valide strukturierte Daten zahlen auf Google Shopping, die interne Suche und die Filternavigation ein, völlig unabhängig davon, welches Agentenprotokoll sich am Ende durchsetzt.

Deshalb kein Hype-Artikel, sondern ein Selbsttest. Sechs Fragen, die du in einer halben Stunde beantworten kannst.

Vier davon kannst du direkt hier beantworten, ohne irgendetwas zu installieren:

Meldet der Check bei der robots.txt etwas an, kannst du die Datei direkt im robots.txt-Generator neu bauen — samt der User-agent-Blöcke aus Prüfpunkt 5.

Der Selbsttest in sechs Schritten

Von Hand messen — oder messen lassen

Die sechs Prüfpunkte gleich messe ich mit SQL und curl. Bei 16 Demo-Produkten geht das. Bei 4.000 willst du nicht SELECT COUNT(*) über zwölf Felder tippen und die Ergebnisse von Hand in eine Tabelle übertragen.

Dieselben Befunde liefert das Novastrix Produkt-Dashboard als Audit in der Administration — 21 Kriterien pro Produkt. Links steht, was du sonst selbst tippst, rechts, was das Dashboard daraus macht:

So sieht das im selben Demo-Shop aus, über den dieser ganze Artikel geht:

Note D, Katalog-Score 4,7 von 10, 133 Fehler über 16 Produkte. Interessanter als die Note ist die Fehlerliste darunter:

Jede dieser Zeilen taucht weiter unten noch einmal auf — dann als Abfrage, die du selbst laufen lassen kannst. „Beschreibung ohne Formatierung: 15" ist derselbe Befund wie das LIKE '%<%' aus Prüfpunkt 1. Dass bei EAN/GTIN und Herstellernummer 15 statt 16 stehen, liegt daran, dass ich für den Test an einem Produkt bereits beides gesetzt hatte — das siehst du in Prüfpunkt 4.

Wo das Dashboard aufhört. Es prüft Produktdaten, nicht Storefront-Konfiguration:

Die Punkte 2, 5 und 6 bleiben also Handarbeit — dafür einmalig pro Shop und nicht pro Produkt.

Ein Hinweis in eigener Sache, der mir wichtiger ist als die Werbung: Das Kriterium Lieferzeit ist in der Standardkonfiguration deaktiviert, weil es viele Shops gibt, die bewusst ohne Lieferzeiten arbeiten. Nach allem, was in diesem Artikel steht, solltest du es einschalten — es ist nach meiner Messung der einzelne Schalter mit dem größten Effekt auf die Maschinenlesbarkeit. Die Kriterien lassen sich einzeln an- und abschalten; deaktivierte fließen weder in Score noch Note noch Aktionsplan ein.

Das Plugin ist noch nicht im Store. Wenn du es testen willst, trag dich auf der Produktdaten-Seite in die Warteliste ein oder schau in die Vorab-Dokumentation.

Die Handmessung zeige ich trotzdem in voller Länge. Erstens brauchst du sie ohne Plugin, zweitens verstehst du nur so, was hinter einer Note steckt.

1. Stehen deine Fakten in Eigenschaften oder nur im Fließtext?

Ein Agent, der „wasserdichte Jacke in L aus Polyester" sucht, liest keinen Fließtext zwischen den Zeilen. Er liest Felder. Alles, was nur im Beschreibungstext steht, existiert für ihn praktisch nicht.

So prüfst du es. Direkt gegen die Datenbank:

-- Wie viele Produkte haben überhaupt Eigenschaften?
SELECT COUNT(DISTINCT product_id) FROM product_property;
-- Und wie viele Beschreibungen enthalten wenigstens Struktur als HTML?
SELECT COUNT(*) FROM product_translation WHERE description LIKE '%<%';

Im Demo-Shop: 5 von 16 Produkten haben Eigenschaften, insgesamt 20 Zuweisungen über 5 Gruppen mit 23 Ausprägungen. Und von zehn hinterlegten Beschreibungen enthält keine einzige ein HTML-Tag — reiner Lorem-ipsum-Fließtext. Keine Tabelle, keine Liste, keine Spezifikation. meta_description ist überall leer.

So behebst du es. Im Admin unter Kataloge → Eigenschaften → „Eigenschaft anlegen". Die zwei Schalter, auf die es ankommt, heißen nicht so, wie man sie sucht:

• „Im Produktfilter von Produktlisten anzeigen" — das ist filterable, ohne den Haken taucht die Eigenschaft in keinem Filter auf
• „Auf der Produktdetailseite anzeigen" — ohne den Haken steht sie in keinem gerenderten HTML, also auch in nichts, was ein Crawler liest

Ich habe für den Test eine Gruppe „Wasserdicht" mit den Ausprägungen „Ja" und „Nein" angelegt — genau die Art Fakt, die sonst in einem Nebensatz der Produktbeschreibung verschwindet. Dazu „Darstellung der Ausprägungsauswahl" (Text, Dropdown, Farbe, Bild) und „Sortierung" (Alphanumerisch, Numerisch, Individuell). Numerisch ist für Größen und Maße fast immer richtig und fast immer falsch eingestellt.

Zuweisen dann am Produkt über den Reiter „Eigenschaften zuweisen" → Karte „Eigenschaften" → „Eigenschaften konfigurieren". Bei Varianten gibt es den Schalter „Nutze die Eigenschaften des Hauptprodukts" — den willst du in aller Regel an haben.

Ab ein paar hundert Produkten pflegst du das nicht mehr von Hand; wie wir Produkteigenschaften automatisch mit KI erzeugen, habe ich getrennt beschrieben, inklusive der Stellen, an denen das Verfahren an seine Grenzen kommt.

2. Liefert die Store API mehr als UUIDs?

Die Store API ist der Weg, über den ein Agent deinen Katalog am saubersten liest — kein HTML-Parsing, keine Layout-Abhängigkeit. Ein Access Key genügt, den findest du unter Verkaufskanäle → Kanal → Allgemein → „API-Zugangsschlüssel".

So prüfst du es.

curl -s -X POST "https://dein-shop.de/store-api/product" \
  -H "sw-access-key: DEIN_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit":1}'

Die Antwort hat 94 Felder auf oberster Ebene. Der Bestand ist dabei vollständig und ohne Zutun vorhanden:

{
  "productNumber": "SWDEMO10007",
  "stock": 50,
  "availableStock": 50,
  "available": true,
  "isCloseout": false,
  "ean": null,
  "manufacturerNumber": null,
  "deliveryTime": null,
  "manufacturer": null,
  "properties": null,
  "propertyIds": [
    "41e5013b67d64d3a92b7a275da8af441",
    "5193ffa5de8648a1bcfba1fa8a26c02b",
    "54147692cbfb43419a6d11e26cad44dc"
  ]
}

Das ist der Punkt. properties, manufacturer und deliveryTime sind null — nicht weil die Daten fehlen, sondern weil die Store API sie nicht mitlädt. Was der Agent bekommt, sind nackte ID-Nummern. Er weiß, dass dieses Produkt sieben Eigenschaften hat, und über keine davon irgendetwas.

So behebst du es. Nicht im Admin, sondern im Request — und das ist die Information, die in deine API-Dokumentation gehört:

{
  "limit": 1,
  "associations": {
    "properties": { "associations": { "group": {} } },
    "manufacturer": {},
    "deliveryTime": {}
  }
}

Erst damit kommt Klartext zurück: {"name": "S", "group": {"name": "Size"}}. Wenn du Agenten oder Partnern eine Schnittstelle an die Hand gibst, dokumentiere diesen Block mit. Sonst liest die Gegenseite deinen Katalog technisch korrekt und inhaltlich leer.

Ein Detail, das man kennen sollte: availableStock ist seit dem Stock-API-Umbau von 2023 schreibgeschützt und spiegelt schlicht stock. Die ursprüngliche Bedeutung „Bestand minus offene Bestellungen" gibt es nicht mehr. Wer Agenten verbindliche Verfügbarkeiten zusagt, darf sich auf dieses Feld nicht allein verlassen.

3. Steht am Produkt eine Lieferzeit?

So prüfst du es.

SELECT COUNT(*) FROM product WHERE delivery_time_id IS NOT NULL;
SELECT COUNT(*) FROM delivery_time;

Im Demo-Shop: 0 Produkte mit Lieferzeit — bei 5 sauber definierten Lieferzeiten. Die Stammdaten sind da, angeschlossen ist nichts.

So behebst du es. Die Lieferzeiten selbst pflegst du unter Einstellungen → Lieferzeiten („Name", „Minimum", „Maximum", „Einheit" von Stunde bis Jahr). Zuweisen am Produkt unter Allgemein → Karte „Lieferbarkeit" → Feld „Lieferzeit". In derselben Karte sitzen „Lagerbestand" und „Wiederauffüllzeit in Tagen".

Warum das der teuerste Befund der ganzen Liste ist, steht im nächsten Kapitel. Für einen bestehenden Katalog machst du das nicht einzeln, sondern über den Massen-Editor in der Produktliste oder per Import.

4. Gibt deine Produktseite überhaupt strukturierte Daten aus?

Hier kommt der Befund, den ich vorher selbst nicht geglaubt hätte.

So prüfst du es.

curl -s https://dein-shop.de/dein-produkt | grep -c 'ld+json'

Im Demo-Shop auf drei verschiedenen Produktseiten: 0, 0, 0.

Shopware 6.7.14 liefert ab Werk kein JSON-LD aus. Stattdessen inline Microdata — itemscope/itemprop — und zwar sparsam. Tatsächlich ausgeliefert werden productID, sku, url, price, priceCurrency, releaseDate, aggregateRating und die Reviews. Auf 0 Treffer kommen dagegen: availability, gtin13, mpn, itemCondition, shippingDetails, hasMerchantReturnPolicy, priceValidUntil und seller.

Der Grund ist ein Feature-Flag:

docker exec dein-container bin/console feature:list | grep JSON_LD
# JSON_LD_DATA   Replace inline microdata ... with JSON-LD    Disabled

In feature.yaml steht:

- name: JSON_LD_DATA
  default: false
  major: true
  toggleable: true

JSON-LD gibt es seit 6.7.9.0 vom 16.04.2026 — aber hinter einem Schalter, der auf false steht. major: true heißt: Mit 6.8 wird es zum Standard. Alle Microdata-Stellen im Storefront-Theme tragen bereits @deprecated tag:v6.8.0.

Wie du den Schalter umlegst, steht weiter unten in einem eigenen Kapitel — das ist kein Ein-Klick-Ding.

5. Kennt deine robots.txt die KI-Crawler?

So prüfst du es.

curl -s https://dein-shop.de/robots.txt | \
  grep -ciE 'GPTBot|ClaudeBot|PerplexityBot|CCBot|Google-Extended|OAI-SearchBot'

Demo-Shop: 0. Das ist kein Versäumnis deiner Konfiguration — Shopware kennt diese User-Agents nirgends im Code. Eine Suche über vendor/shopware/core und vendor/shopware/storefront nach diesen Namen liefert null Dateien.

Warum das mehr zählt als man denkt: Retail macht 2026 rund 31 Prozent des gesamten KI-Crawler-Traffics aus — der mit Abstand größte Anteil, getrieben von Produktdaten, Preisen und strukturierten Katalogen. Wenn irgendeine Branche eine Haltung zu diesen Bots braucht, dann deine.

Der Konsens unter Publishern ist inzwischen differenziert und heißt „block training, allow search": Trainings-Crawler werden mehrheitlich geblockt (GPTBot im Verhältnis 2,33:1, ClaudeBot 2,39:1, Bytespider 5,80:1), Such-Crawler mehrheitlich erlaubt (OAI-SearchBot 0,94:1 — also häufiger zugelassen als gesperrt). Die Logik dahinter: Training bringt dir nichts zurück, Suche bringt Besucher.

So behebst du es. Ohne Plugin, ohne Template-Override, ohne Entwickler. Seit 6.7 gibt es dafür eine eigene Karte in den Grundeinstellungen: Einstellungen → Grundeinstellungen → „Regeln für robots.txt".

In das Textfeld schreibst du robots.txt-Zeilen, so wie sie später ausgegeben werden. User-agent-Blöcke gelten über alle Domains, reine Allow/Disallow-Zeilen nur für den Pfad der jeweiligen Domain. Ein Verkaufskanal-Umschalter über der Seite steuert, für welchen Kanal die Regeln gelten.

Für „block training, allow search" schreibst du also:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Speichern, und die Zeilen stehen in /robots.txt. Ich habe das im Demo-Shop gemessen — kein Cache-Kommando nötig, kein Deployment.

Die Falle dabei, und sie ist teuer. Das Feld ist ein Ersatz, keine Ergänzung. Shopware liefert dort ab Werk fünf Zeilen aus, die du im Screenshot oben siehst:

Disallow: /account/
Disallow: /checkout/
Disallow: /widgets/
Allow: /widgets/cms/
Allow: /widgets/menu/offcanvas

Schreibst du deine KI-Regeln auf Verkaufskanal-Ebene in das Feld, ersetzen sie diesen geerbten Wert vollständig. In meinem Test verschwanden alle fünf Zeilen aus der robots.txt — Kundenkonto und Checkout waren damit für jeden Crawler freigegeben, ohne dass irgendwo eine Warnung erscheint. Kopier die fünf Zeilen also mit in dein Feld, oberhalb deiner User-agent-Blöcke. Danach steht beides in der Ausgabe; auch das habe ich gegengeprüft.

Den Schalter „Standard-Regeln für robots.txt deaktivieren" brauchst du dafür nicht. Er betrifft nur den oberen Block (User-agent: *, Allow: /, Disallow: /*?), nicht diese fünf Zeilen.

Ein Nebenbefund, der zu Prüfpunkt 1 zurückführt: Die Standard-robots.txt enthält Disallow: /*?. Damit ist jede gefilterte Listing-URL gesperrt — also genau die ?properties=…-Seiten, die durch die Eigenschaftspflege aus Schritt 1 entstehen. Wer Filterseiten extern auffindbar machen will, muss diese Zeile bewusst anfassen.

Wie die Regeln in dieser Datei tatsächlich gelesen werden — warum Disallow: /*/checkout/ auf vielen Shops gar nichts sperrt und warum robots.txt keine Seite aus dem Index nimmt — habe ich im robots.txt-Generator für Shopware Zeile für Zeile aufgeschrieben. Dort baut dir ein Generator die fertige Datei samt dieser User-agent-Blöcke.

6. Liefert dein Shop llms.txt und ai-catalog.json?

So prüfst du es.

for p in /llms.txt /AGENTS.md /.well-known/ai-catalog.json; do
  echo "$p $(curl -s -o /dev/null -w '%{http_code}' https://dein-shop.de$p)"
done

Solange du die Dateien nicht aktiviert hast, kommt dreimal 404 — so auch im Demo-Shop. Shopware liefert die drei Templates seit 6.7.12.1 mit, schaltet sie aber pro Verkaufskanal einzeln frei.

Achtung bei der Schreibweise: Die Datei heißt /AGENTS.md in Großbuchstaben, /agents.md läuft ins Leere.

So behebst du es. Verkaufskanäle → Kanal → Reiter „Agentic-Dateien" → Kontextmenü der Datei → „Aktivieren" → speichern. Ich habe das für llms.txt gemacht:

Danach liefert /llms.txt statt 404 eine 200 mit brauchbarem Inhalt — Startseite, Suche, Sitemap, Impressum, Datenschutz, AGB, dazu der Hinweis an Agenten, Preise und Verfügbarkeit vor der Ausgabe zu verifizieren.

Ein Detail, das man leicht übersieht: Die generierte llms.txt verlinkt selbst auf /AGENTS.md. Solange du nur eine der drei Dateien aktivierst, zeigt dein Agenten-Index auf einen toten Link. Entweder alle drei einschalten oder den Verweis über „Eigene Hinweise" anpassen.

Und jetzt die ehrliche Einordnung, weil das Thema gerade überverkauft wird: llms.txt hat rund 10 Prozent Verbreitung, aber in einer Auswertung von über 500 Millionen KI-Bot-Events in 90 Tagen kamen nur wenige hundert Requests auf /llms.txt. Google hat öffentlich bestätigt, die Datei nicht zu unterstützen und das auch nicht zu planen. Der Aufwand ist zwei Klicks, der messbare Nutzen heute nahe null. Mach es, weil es zwei Klicks sind — nicht, weil es Traffic bringt. Der wirksamere Hebel ist Prüfpunkt 5.

Die Kettenreaktion: ein fehlendes Dropdown kippt die Verfügbarkeit

Jetzt zu der Stelle, an der die sechs Prüfpunkte aufhören, unabhängig voneinander zu sein.

In component/delivery-information.html.twig hängt die Verfügbarkeitsangabe an dieser Bedingung:

{% elseif (product.stock >= product.minPurchase
    or (isDigitalProduct and not product.isCloseout))
    and product.deliveryTime %}
    <link itemprop="availability" href="https://schema.org/InStock">

Das letzte Glied der Kette ist product.deliveryTime. Fehlt es, greift keiner der Zweige und der Block fällt in den leeren Default. Im gerenderten HTML steht dann wörtlich das hier:

<div class="product-delivery-information">
    
</div>

Ein leeres Element. Kein „Sofort lieferbar", kein Lieferzeittext, kein availability. Und zwar für Mensch und Maschine gleichzeitig — der Kunde sieht an der Stelle nichts, wo sonst die Verfügbarkeit steht, und der Agent bekommt keine Aussage darüber, ob er das Produkt überhaupt kaufen kann.

Ein nicht ausgefülltes Dropdown im Produkteditor kippt damit die komplette Verfügbarkeitsaussage deines Shops. Das Google-Merchant-Listing wird ungültig, weil availability ein Pflichtfeld ist. Und ein Agent, der zwischen zwei Anbietern wählt, nimmt im Zweifel den, bei dem „lieferbar" maschinenlesbar dasteht.

Der Gegenbeweis in drei Feldern

Damit das nicht Theorie bleibt, habe ich an genau dem Produkt mit dem leeren Element drei Felder gefüllt: Lieferzeit „1-3 days", GTIN/EAN und Hersteller-Produktnummer.

Wichtig für die Suche im Admin: GTIN/EAN und Hersteller-Produktnummer liegen in 6.7.14 nicht bei den Maßen, sondern auf dem Reiter „Allgemein" in der Karte „Auszeichnung", zusammen mit dem Erscheinungsdatum. Die Versandmaße — Breite, Höhe, Länge, Gewicht — findest du dagegen unter „Spezifikationen".

Danach dieselbe Seite noch einmal abgerufen:

curl -s http://localhost:8080/Main-product-with-reviews/SWDEMO100013 \
  | grep -o 'itemprop="availability"[^>]*'
# itemprop="availability" href="https://schema.org/InStock"

Aus dem leeren Element ist geworden:

<div class="product-delivery-information">
    <link itemprop="availability" href="https://schema.org/InStock">
    <p class="delivery-information delivery-available">
        <span class="delivery-status-indicator bg-success"></span>
        Available, delivery time: 1-3 days
    </p>
</div>

Und gtin13 sowie mpn, die vorher gar nicht im Markup vorkamen, stehen jetzt drin:

<meta itemprop="gtin13" content="4006381333931">
<meta itemprop="mpn" content="SW-CHOCO-500">

Drei Felder, drei neue maschinenlesbare Aussagen — ohne eine Zeile Code, ohne Feature-Flag, ohne Plugin. Das ist der Grund, warum Punkt 3 in der To-do-Liste ganz oben steht, obwohl er der langweiligste ist.

JSON-LD einschalten — Schritt für Schritt

Der Schalter aus Prüfpunkt 4 ist ein Environment-Flag, keine Admin-Einstellung.

Schritt 1. In der .env.local des Shops setzen:

FEATURE_JSON_LD_DATA=1

Bei Docker gehört der Wert stattdessen unter environment: in die Compose-Datei — ein Eintrag in der .env allein wird vom Container nicht zwangsläufig übernommen.

Schritt 2. Prozess neu starten. Das ist nicht optional und die häufigste Stolperfalle: Ein docker exec -e FEATURE_JSON_LD_DATA=1 … bin/console setzt die Variable nur für diesen CLI-Prozess. Der Worker, der die HTTP-Requests beantwortet, sieht davon nichts — die Storefront bleibt unverändert, und man sucht den Fehler an der falschen Stelle.

Schritt 3. Caches leeren und Theme neu bauen:

bin/console cache:clear
bin/console theme:compile

Schritt 4. Gegenprüfen — derselbe Befehl wie in Prüfpunkt 4, jetzt mit einem Treffer statt null.

Die Risiken, bevor du das produktiv machst. Das Flag ersetzt die Microdata, es ergänzt sie nicht: Alle itemprop-Attribute verschwinden aus dem Markup. Wenn dein Theme eigene Overrides auf buy-widget, buy-widget-price oder delivery-information mitbringt — und das tun die meisten gewachsenen Themes — können die ins Leere laufen oder doppelte Auszeichnung erzeugen. Dazu kommt, dass major: true bedeutet, dass hier ein Verhalten vorgezogen wird, das offiziell erst mit 6.8 kommt.

Also: erst auf Staging, und den Google-Rich-Results-Test vorher und nachher laufen lassen. Wenn die Zahl der erkannten Felder hinterher kleiner ist als vorher, hast du ein Theme-Problem und keinen Fortschritt.

Was auch mit JSON-LD noch fehlt

Ich habe das Template layout/structured-data/json-ld-product.html.twig durchgesehen. Es ist deutlich besser als die Microdata — ProductGroup mit hasVariant bei Varianten ist sauber gelöst, gtin8/12/13/14 werden längenabhängig aus der EAN gesetzt, AggregateOffer bei mehreren Preisen. Aber es ist nicht vollständig:

Der letzte Punkt ist der, über den ich am längsten nachgedacht habe. Die Eigenschaften, die du in Prüfpunkt 1 mühsam gepflegt hast, landen in keinem einzigen schema.org-Feld. Weder additionalProperty noch color, size oder material kommen im Template vor. Größe, Material und Zielgruppe sind sauber im System — und tauchen im strukturierten Datensatz nicht auf.

Für einen Agenten heißt das: Über die Storefront bekommt er deine Eigenschaften nur, wenn er die gerenderte Eigenschaftstabelle im HTML parst. Sauber und verlässlich bekommt er sie ausschließlich über die Store API mit dem associations-Block aus Prüfpunkt 2. Das macht die API-Route zum eigentlichen Agentenkanal, nicht die Produktseite — ein Punkt, der in der aktuellen Debatte um strukturierte Daten meist untergeht.

Dass itemCondition fest auf „neu" steht, ist übrigens nicht nur kosmetisch: Wer B-Ware und Mängelartikel verkauft, meldet Google und jedem Agenten damit eine falsche Tatsache über seine Ware.

Beides — Rückgabebedingungen und priceValidUntil — bekommst du über ein Template-Override in dein JSON-LD. Das ist überschaubare Arbeit, aber es ist Arbeit, die du selbst machen musst.

Der Verkaufskanal, den du vor 6.8 noch umbauen musst

Shopware 6.7 bringt einen eigenen Verkaufskanal-Typ „Agentic Commerce" mit — mit OpenAI-Einstellungen, Produktexport und Tracking-Codes. Wer ihn angelegt hat, bekommt seit Kurzem diesen Hinweis zu sehen:

Die integrierte Agentic-Commerce-Funktion wird in Shopware 6.8 entfernt. Dein Verkaufskanal läuft vorerst weiter. Installiere die „Agentic Commerce" Erweiterung, damit es zu keiner Unterbrechung kommt.

Der Nachfolger ist die kostenlose Erweiterung „Agentic Commerce (Beta)" von Shopware selbst, kompatibel von 6.5.8.0 bis 6.7.14.2. Sie bringt den Agentic-Commerce-Sales-Channel, den OpenAI-JSONL-Feed, den Google-Shopping-XML-Feed und Capability-Controls mit, über die du festlegst, was ein Agent darf — Katalog lesen, Warenkorb füllen, Rabatte anwenden, bestellen.

Wichtig zu wissen, weil es oft verwechselt wird: Dieses Plugin implementiert UCP, nicht OpenAIs ACP.

Protokolle in drei Absätzen

UCP (Universal Commerce Protocol) ist das für Shopware relevante. Angekündigt von Google und Shopify im Januar 2026, Governing Council aus Google, Shopify und Stripe, aktuelle Spec vom 25.08.2026. Es regelt Katalog, Warenkorb und Bestellung zwischen Agent und Händler.

ACP (Agentic Commerce Protocol) kommt von OpenAI und Stripe, Spec-Stand 17.04.2026, Status Beta. Fünf REST-Endpunkte für Checkout-Sessions, die der Händler bereitstellt. Die wichtigere Nachricht dazu ist strategisch: OpenAI hat Instant Checkout im März 2026 aus dem ChatGPT-Prompt-Flow herausgenommen und nach Apps verschoben — mit der Begründung, man priorisiere erst einmal Suche und Produktentdeckung. Händler hatten Bedenken bei Bestandsführung, Umsatzsteuer und Preisaktualität angemeldet.

AP2 (Agent Payments Protocol) von Google, Version 0.2.0, regelt nicht den Katalog, sondern die Zahlung: Ein „Mandate" ist eine signierte Erklärung, was ein Agent ausgeben darf, wofür, mit welchem Limit und wie lange. Es ist als Ergänzung zu UCP und ACP gedacht, nicht als Konkurrenz.

Für deine Arbeitsplanung ist die Frage, welches Protokoll gewinnt, erstaunlich unwichtig. Alle drei setzen dieselben sauberen Daten voraus. Eigenschaften, Lieferzeiten, EANs und valide strukturierte Daten brauchst du in jedem Szenario — und in dem Szenario, in dem sich gar kein Agentenprotokoll durchsetzt, auch.

Welche Version du brauchst

Bei den Agentic Files unbedingt 6.7.12.1 und nicht 6.7.12.0 — die .0 hat einen Breaking Bug.

Aktueller Stand sind 6.7.14.2 vom 23.09. und 6.6.10.27 vom 24.09.; die 6.6 bekommt weiterhin Patches. Und wer auf 6.8 wartet, um „das dann richtig zu machen": 6.8 ist auf 2027 verschoben. Das ist kein Grund zu warten, sondern einer, es jetzt in 6.7 zu erledigen.

Kurzer Hinweis

Alle Befunde in diesem Beitrag stammen aus einem frischen Shopware 6.7.14.0 mit den offiziellen Demo-Daten, erhoben am 29.09.2026. Dein Shop wird andere Zahlen liefern — die Prüfbefehle sind so gewählt, dass du sie unverändert übernehmen kannst.

Agentic Commerce bewegt sich schnell, und mehrere der oben genannten Bausteine sind ausdrücklich als Beta oder experimentell gekennzeichnet. Versionsangaben und Verfügbarkeit in deiner Region bitte vor der Umsetzung gegenprüfen.

Shopware betreibt außerdem einen öffentlichen Agentic Readiness Scanner, der einer beliebigen Storefront einen Score von 0 bis 100 gibt. Als Startpunkt ganz nett — er ersetzt die sechs Prüfschritte nicht, weil er von außen weder deine Store-API-Konfiguration noch deine Datenpflegequote sehen kann.

Nächster Schritt

In dieser Reihenfolge, sortiert nach Wirkung pro Aufwand:

1. Lieferzeit an jedem Produkt setzen. Der größte Effekt für den kleinsten Aufwand — ohne sie fehlt die Verfügbarkeit im Markup komplett.
2. Eigenschaften anlegen und zuweisen, mit beiden Haken: Produktfilter und Produktdetailseite.
3. EAN und Hersteller-Produktnummer unter „Allgemein → Auszeichnung" nachtragen — ohne GTIN kein gtin13 im Markup und kein Google-Shopping-Export.
4. Versandmaße und Gewicht unter „Spezifikationen" ergänzen, sonst bleibt shippingDetails auch nach dem JSON-LD-Umstieg leer.
5. JSON-LD auf Staging aktivieren, Rich-Results-Test vorher und nachher vergleichen.
6. robots.txt um eine KI-Crawler-Haltung ergänzen — block training, allow search.
7. Agentic-Dateien im Verkaufskanal einschalten. Zwei Klicks, geringer Nutzen, aber erledigt.

Wenn du wissen willst, wie viele deiner Produkte an Punkt 1 bis 4 scheitern, ohne sie einzeln durchzuklicken: Genau das zählt das Produktdaten-Audit über den gesamten Katalog aus.

Und wenn ihr den Katalog nicht von Hand aufräumen wollt, sondern die Pflege automatisieren — meldet euch.

→ Zum Kontaktformular