KI-Agenten wie ChatGPT Shopping, Google Gemini oder Perplexity vergleichen seit Ende 2025 nicht mehr nur Texte, sondern Produkte, Preise und Lieferzeiten — über hunderte Shops hinweg, in Sekunden. Für deinen Magento-Shop heißt das: Nicht nur Menschen lesen deine Produktseite, sondern Maschinen, die in Millisekunden entscheiden, ob dein Angebot überhaupt in die engere Auswahl kommt. Und Maschinen lesen keine Verkaufsprosa. Sie lesen strukturierte Daten. In diesem Artikel zeigen wir, welche Felder du in Magento konkret pflegen musst, damit ein Agent deinen Preis findet, ihm vertraut und ihn in den Vergleich aufnimmt — und woran es in der Praxis meistens scheitert.
Warum ein statischer Tagesfeed nicht mehr reicht
Ein KI-Agent vergleicht nicht den nackten Listenpreis. Er bewertet das komplette Angebot: Preis plus Versandkosten, plus Lieferzeit, plus Lagerstatus, plus Rückgabebedingungen. Erst die Summe entscheidet, ob du günstiger bist als die Konkurrenz drei Zeilen weiter unten.
Genau hier wird ein einmal täglich erzeugter Produktfeed zum Risiko. Findet der Agent ein Produkt zu 149 EUR, das beim Sprung in den Warenkorb plötzlich 159 EUR kostet oder als „nicht lieferbar” auftaucht, bricht er ab — und merkt sich den Shop als unzuverlässig. Während ein Mensch nach drei Tabs aufgibt, prüft ein Agent hunderte Angebote pro Sekunde und sortiert Diskrepanzen gnadenlos aus. Die Daten, die dein Shop ausliefert, müssen deshalb nicht nur korrekt sein, sondern in dem Moment korrekt sein, in dem der Agent fragt.
Die Schema.org-Felder, die ein Preisvergleich-Agent wirklich liest
Die gemeinsame Sprache zwischen deinem Shop und den Agenten ist nach wie vor Schema.org, ausgeliefert als JSON-LD im <head> oder direkt am Produkt. Ein Agent interessiert sich nicht für ein hübsches Google-Snippet — er braucht maschinenlesbare Fakten zum Product und zum dazugehörigen Offer. Diese Felder sind die Pflicht, nicht die Kür:
| Feld (Schema.org) | Gehört zu | Wofür der Agent es braucht |
|---|---|---|
price & priceCurrency | Offer | Exakter aktueller Preis und Währung — die Basis jedes Vergleichs |
availability | Offer | InStock / OutOfStock — filtert nicht-lieferbare Angebote sofort raus |
priceValidUntil | Offer | Bis wann der Preis gilt — wichtig bei Aktionen und dynamischen Preisen |
shippingDetails | OfferShippingDetails | Versandkosten und Lieferfenster fließen in den Gesamtpreis ein |
hasMerchantReturnPolicy | MerchantReturnPolicy | Rückgabefrist und -kosten als Vergleichs- und Vertrauenssignal |
aggregateRating & review | Product | Bewertungen als Qualitätssignal neben dem reinen Preis |
gtin / mpn / brand | Product | Eindeutige Produkt-Identität — der Agent erkennt, dass es dasselbe Produkt ist |
Das letzte Feld ist das am häufigsten unterschätzte. Ohne GTIN, MPN oder eine saubere Marken-Angabe kann ein Agent nicht erkennen, dass dein „Laufschuh Modell X” und der „Laufschuh Modell X” bei der Konkurrenz dasselbe Produkt sind — und damit fällt dein Angebot aus dem Preisvergleich heraus, bevor er begonnen hat.
Dazu kommen die technischen Produktattribute: color, size, material. Vage Formulierungen wie „der bequemste Schuh der Welt” sind für eine KI wertlos. „Obermaterial aus 100 % recyceltem Polyester, Sohle mit Pronationsstütze” dagegen sind Datenpunkte, die der Agent einer konkreten Suchanfrage zuordnen kann. In Magento heißt das: Attribute pflegen, nicht in den Beschreibungstext packen.
JSON-LD sauber aus Magento ausliefern
Magento Open Source bringt von Haus aus nur rudimentäres strukturiertes Markup mit — und das oft unvollständig, was Versand, Rückgabe und GTIN angeht. In der Praxis brauchst du entweder eine spezialisierte Structured-Data-Extension oder ein eigenes Block-Template, das die JSON-LD direkt aus den echten Datenquellen zieht: dem Preis-Index für price, der Multi-Source-Inventory (MSI) für availability, den Produktattributen für gtin und Co.
Entscheidend ist, dass diese Daten live aus dem Shop kommen und nicht aus einem nachts erzeugten Export. Für Agenten, die nicht die HTML-Seite crawlen, sondern strukturiert abfragen, ist die GraphQL-API der zentrale Hebel — sie liefert genau die Felder, die der Agent anfragt, in dem Zustand, in dem sie gerade sind. Wer hier ein eigenes Schema sauber modelliert, hat den größten Teil der Arbeit erledigt. Wie wir solche Datenschichten in Magento-Projekten konkret aufsetzen, hängt vom Frontend ab — unter Hyvä sieht das Template anders aus als unter Luma, das JSON-LD-Prinzip bleibt identisch.
Echtzeit: Preis und Lager synchron halten — bis in den Checkout
Der häufigste Grund für einen Kaufabbruch durch einen Agenten ist keine schlechte Bewertung, sondern eine Diskrepanz: Der Preis im Feed weicht vom Preis im Warenkorb ab, oder der Lagerstatus stimmt nicht mit der Realität überein. Für den Agenten ist das ein hartes Stoppsignal.
In Magento bedeutet das vor allem zwei Dinge. Erstens: Die strukturierten Daten, die GraphQL-API und der Checkout müssen aus derselben Quelle lesen — Preis-Index und MSI-Bestand —, damit es keine zweite, veraltete Wahrheit gibt. Zweitens: Wenn dein Bestand aus einem ERP kommt, muss die Schnittstelle den Lagerstatus zeitnah synchronisieren, nicht im Stundentakt. Ein Agent, der um 9:03 Uhr drei verfügbare Stück sieht und um 9:04 Uhr nichts mehr kaufen kann, kommt nicht wieder.
Die gute Nachricht: Wer seinen Shop schon für Performance und Core Web Vitals sauber aufgesetzt hat, hat die Grundlagen meist gelegt. Schnelle, konsistente Antworten sind dieselbe Disziplin, ob der Anfrager ein Browser oder ein Agent ist — der Zusammenhang zwischen Ladezeit und Antwortqualität gilt für beide.
Über die Produktseite hinaus: Protokolle und Zahlung
Strukturierte Daten beantworten die Frage „Was bietest du an?”. Für „Kann der Agent hier auch kaufen?” entstehen gerade eigene Standards. Du musst sie heute nicht alle implementieren, aber kennen solltest du sie:
- Agentic Commerce Protocol (ACP) — von OpenAI und Stripe vorgestellt, regelt, wie ein Agent ein Produkt im Chat entdecken und einen Kauf anstoßen kann.
- Agent Payments Protocol (AP2) — Googles Ansatz für kryptografisch signierte Zahlungs-Mandate, mit denen ein Agent im Rahmen eines Budgets autonom bezahlt.
- Visa Intelligent Commerce / Mastercard Agent Pay — einwilligungsbasierte Zahlungen, die ein Agent im Namen des Käufers auslöst.
So unterschiedlich diese Protokolle sind, der gemeinsame Nenner darunter ist immer derselbe: saubere, maschinenlesbare Produktdaten und ein Checkout, der nicht an Captchas oder nicht-lesbaren Formularen scheitert. Wer die Datenbasis jetzt richtig legt, ist anschlussfähig — egal, welches Protokoll sich am Ende durchsetzt. Das ist der Grund, warum wir Händlern raten, mit Schema.org und Echtzeit-Daten anzufangen und nicht mit dem Protokoll-Layer.
Was du als nächstes tun kannst
Wenn du wissen willst, wie agentenfreundlich dein Magento-Shop heute schon ist, gibt es zwei pragmatische erste Schritte:
- Selbst-Check mit dem Rich-Results-Test: Wirf eine Produkt-URL in Googles Rich Results Test oder den Schema Markup Validator. Tauchen
price,availability,shippingDetailsundgtinauf — oder fehlt die Hälfte? Das ist deine ehrliche Ausgangslage. - Strukturierte-Daten-Audit anfragen: Wir prüfen, welche Felder dein Shop ausliefert, ob sie live aus Preis-Index und Bestand kommen und wo Feed und Checkout auseinanderlaufen. Das ist Teil unserer SEO- und Strukturierte-Daten-Leistung. Kontakt: office@copex.io oder Audit anfragen.
Verwandte Themen aus unserem Blog: Wie KI-Agenten Preise vergleichen, GraphQL als Schlüssel für Agentic Commerce und wie mittelständische Shops von KI-Agenten profitieren.
Strukturierte Daten waren lange eine SEO-Fleißaufgabe für ein schöneres Google-Snippet. Für KI-Agenten sind sie die Eintrittskarte — wer sie nicht ausstellt, steht erst gar nicht auf der Gästeliste.
Quellen / Weiterlesen
- schema.org/Product und schema.org/Offer — die maßgeblichen Vokabular-Definitionen
- Google Search Central — Strukturierte Daten für Produkte
- Adobe Commerce — GraphQL Developer Guide
