Agentic Commerce: Shops, die von KI-Agenten gefunden und gekauft werden

1. Wenn der Agent die Vorauswahl trifft

Der Umbau im Handel läuft leiser ab, als die Schlagzeilen zum autonomen Einkauf vermuten lassen. Der vollautomatische Kaufabschluss durch einen Agenten ist heute auf wenige Plattformen begrenzt und wirtschaftlich noch eine Randerscheinung. Die Stufe davor ist es längst nicht mehr: Die Recherche, der Vergleich und die Vorauswahl finden zunehmend im Chatfenster statt.

Der Unterschied zur klassischen Shop-Suche ist grundlegend. In einem Shop formuliert der Kunde eine Suche und filtert selbst. Im Chat formuliert er eine Anforderung: „Ich brauche eine Ersatzpumpe für ein Gerät Baujahr 2018, Anschluss 3/4 Zoll, muss bis nächsten Dienstag da sein.“ Diese Anfrage enthält vier prüfbare Bedingungen. Ein System, das sie beantworten soll, braucht zu jedem Artikel maschinenlesbare Angaben zu Kompatibilität, Anschlussmaß, Verfügbarkeit und Lieferzeit.

Genau hier entscheidet sich die Sichtbarkeit — und zwar nicht im Marketing, sondern in der Datenpflege. Steht das Anschlussmaß nur im Beschreibungstext oder auf einem Datenblatt-PDF, fällt der Artikel aus der Auswahl. Nicht weil er ungeeignet wäre, sondern weil seine Eignung nicht feststellbar ist. Ein einzelnes fehlendes Attribut macht einen Artikel für eine ganze Klasse von Anfragen unsichtbar.

Das ist eine unbequeme, aber im Kern gute Nachricht: Der Hebel liegt bei Arbeit, die man selbst kontrolliert, und nicht bei einem Algorithmus, dessen Verhalten man nur erraten kann. Wer saubere Produktdaten pflegt, gewinnt gleichzeitig in der Shop-Suche, in Preisvergleichen, in Marktplätzen und in KI-Antworten. Die Investition zahlt in alle Kanäle gleichzeitig ein.

2. Produktdaten sind der neue Rankingfaktor

Produktdatenqualität ist ein unpopuläres Thema, weil sie keine sichtbaren Erfolge produziert. Sie lässt sich trotzdem in vier klar benennbare Dimensionen zerlegen.

Vollständigkeit

Jedes Attribut, das für eine Kaufentscheidung relevant sein kann, existiert als eigenes Feld mit definiertem Wertebereich. Der praktische Test ist einfach: Man nimmt die zwanzig häufigsten Fragen aus dem Kundenservice und prüft, ob jede davon aus den strukturierten Daten beantwortbar ist. In den meisten Shops sind es weniger als die Hälfte.

Eindeutigkeit

Werte gehören normalisiert: „3/4 Zoll“, „0,75 Zoll“ und „19,05 mm“ sind für einen Menschen dasselbe und für ein System drei verschiedene Dinge. Einheiten gehören in ein eigenes Feld, Aufzählungen in eine feste Werteliste. Stabile Kennungen — GTIN, MPN, Herstellerartikelnummer — erlauben die Zuordnung desselben Produkts über Anbieter hinweg. Ohne sie ist ein Artikel kaum vergleichbar und taucht in Vergleichen entsprechend selten auf.

Aktualität

Bestand und Preis müssen der Realität entsprechen, und zwar in allen Ausspielungen gleichzeitig. Ein Artikel, der im Feed als lieferbar gemeldet wird und im Shop seit drei Wochen ausverkauft ist, beschädigt nicht nur diesen einen Verkauf — er senkt die Verlässlichkeit der gesamten Datenquelle. Nächtliche Vollexporte sind dafür zu langsam; Änderungen gehören als Ereignis verteilt.

Kontext

Die vierte Dimension wird am häufigsten übersehen. Ein Agent, der eine Anforderung beantworten soll, braucht nicht nur die Eigenschaften eines Artikels, sondern seinen Verwendungszusammenhang: Wofür ist er geeignet, wofür ausdrücklich nicht, womit ist er kompatibel, was wird zusätzlich benötigt. Diese Angaben stehen in vielen Shops im Beschreibungstext — dort sind sie für Menschen lesbar und für Maschinen nur eingeschränkt verwertbar. Als eigenes Attributfeld werden sie zum Auswahlkriterium.

3. Headless: wann es sich rechnet und wann nicht

Headless Commerce wird häufig als notwendige Modernisierung dargestellt. Tatsächlich ist es eine Abwägung mit klaren Bedingungen auf beiden Seiten.

Dafür spricht es, wenn dieselben Produktdaten über mehrere Kanäle ausgespielt werden — Shop, App, Marktplätze, Händlerportal —, wenn das Frontend deutlich von dem abweicht, was das Shopsystem vorsieht, oder wenn die Ladegeschwindigkeit der Produktseiten mit dem monolithischen System nicht mehr in den Griff zu bekommen ist.

Dagegen spricht es, wenn ein einziger Kanal bedient wird, wenn das Team klein ist und wenn die Anforderungen an das Frontend im Rahmen dessen liegen, was das Shopsystem ohnehin bietet. Headless verdoppelt in dieser Situation die Zahl der zu betreibenden Systeme und verlagert Funktionen, die vorher eingebaut waren — Warenkorb, Checkout, Suche, Kundenkonto — in die eigene Verantwortung.

Für die KI-Sichtbarkeit ist die Architekturfrage weitgehend neutral, mit einer wichtigen Ausnahme: Der Inhalt muss im ausgelieferten HTML stehen. Ein Headless-Frontend, das Produktdaten erst im Browser nachlädt, ist für Crawler ohne JavaScript-Ausführung leer. Wer Headless baut, braucht serverseitiges Rendering oder statische Generierung für alle Produkt- und Kategorieseiten — sonst erkauft man sich mit dem Umbau genau den Nachteil, den man vermeiden wollte.

4. Technische Umsetzung: Feeds, Schema, Performance

Drei technische Bausteine entscheiden darüber, ob gepflegte Daten auch ankommen.

Strukturierte Daten auf der Produktseite

Das Product-Markup ist der direkteste Weg, Produktdaten maschinenlesbar bereitzustellen. Entscheidend sind die Felder, die über die Pflichtangaben hinausgehen:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Umwälzpumpe XY-40",
  "sku": "PMP-XY40-034",
  "gtin13": "4012345678901",
  "mpn": "XY40-34",
  "brand": { "@type": "Brand", "name": "Beispielwerk" },
  "isAccessoryOrSparePartFor": [
    { "@type": "Product", "name": "Heizmodul H-2018" }
  ],
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Anschluss",   "value": "3/4", "unitText": "Zoll" },
    { "@type": "PropertyValue", "name": "Förderhöhe",  "value": 6,     "unitCode": "MTR" },
    { "@type": "PropertyValue", "name": "Baujahr-Kompatibilität", "value": "2016–2021" }
  ],
  "offers": {
    "@type": "Offer",
    "price": "189.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "businessDays": { "@type": "OpeningHoursSpecification",
                          "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"] },
        "transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 3, "unitCode": "DAY" }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30
    }
  }
}

Die drei Blöcke, die in der Praxis fehlen und den Unterschied machen, sindadditionalProperty für technische Eigenschaften mit Einheit,shippingDetails für die tatsächliche Lieferzeit undhasMerchantReturnPolicy für die Rückgabebedingungen. Genau danach wird in natürlichsprachlichen Anfragen regelmäßig gefragt.

Feeds als zweiter Kanal

Ein gepflegter Produktdaten-Feed bleibt sinnvoll — nicht nur für Preisvergleiche, sondern weil er zur Datendisziplin zwingt: Pflichtfelder sind Pflichtfelder, und fehlerhafte Werte fallen bei der Validierung auf. Wichtig ist, dass Feed und Seitenmarkup aus derselben Quelle erzeugt werden. Zwei getrennt gepflegte Datenstände driften garantiert auseinander, und die Abweichung fällt erst auf, wenn Angebote aus Vergleichen verschwinden.

Performance

Ladegeschwindigkeit wirkt an zwei Stellen. Crawler mit begrenztem Zeitbudget erfassen bei langsamen Seiten weniger Artikel — bei großen Katalogen entscheidet das darüber, ob der Longtail überhaupt bekannt ist. Und Besucher, die aus einer KI-Empfehlung kommen, haben eine überdurchschnittliche Kaufabsicht; eine Produktseite, die drei Sekunden braucht, verschenkt genau die wertvollsten Sitzungen. Die üblichen Hebel — Bildformate, Caching, serverseitiges Rendering, Verzicht auf überflüssige Skripte — sind unverändert wirksam.

5. Vergleich: WooCommerce, Shopify, JTL-Shop

Für die hier behandelte Frage ist die Systemwahl zweitrangig. Alle drei können vollständige, maschinenlesbare Produktdaten ausliefern. Was sich unterscheidet, ist der Aufwand dafür und die Frage, wo die Daten geführt werden. Ein Systemwechsel ist selten die Antwort auf schlechte Datenqualität — er transportiert sie meist mit.

6. Fehler, die Shops unsichtbar machen

Eigenschaften nur im Fließtext. Der häufigste und folgenreichste Fehler. Maße, Kompatibilität und Materialangaben stehen in der Beschreibung statt in Attributfeldern und sind damit für die Auswahl praktisch nicht vorhanden.

Datenblätter ausschließlich als PDF. Technische Daten in einem verlinkten Dokument sind für die meisten Auswertungen unerreichbar. Die wichtigsten Werte gehören zusätzlich als HTML-Attribute auf die Seite — das PDF darf bleiben.

Abweichungen zwischen den Kanälen. Preis im Feed, Preis im Markup, Preis auf der Seite: Weichen sie voneinander ab, wird das Angebot als unzuverlässig behandelt und fällt aus Vergleichen heraus. Eine automatisierte tägliche Konsistenzprüfung über alle drei Quellen ist mit geringem Aufwand einzurichten und deckt genau diesen Fall auf.

Varianten als getrennte Artikel ohne Beziehung. Fünf Größen als fünf unabhängige Produkte ohne gemeinsame Elterneinheit erzeugen fünf schwache Einträge statt eines vollständigen. Die Variantenbeziehung gehört ausgezeichnet.

Fehlende Kennungen. Ohne GTIN oder MPN ist ein Artikel nur über seinen Namen identifizierbar — und Namen unterscheiden sich zwischen Händlern. Der Artikel taucht dann in Vergleichen schlicht nicht als dasselbe Produkt auf.

Ausverkaufte Artikel entfernen. Eine gelöschte Produktseite verliert alle aufgebauten Signale. Besser ist es, die Seite mit korrektem Verfügbarkeitsstatus, einem erwarteten Datum und einem Verweis auf Alternativen bestehen zu lassen.

7. Roadmap in fünf Schritten

1. Attribut-Audit an den Top-Artikeln (Woche 1–2)Die fünfzig umsatzstärksten Artikel gegen die zwanzig häufigsten Kundenfragen prüfen: Welche Frage ist aus den strukturierten Daten beantwortbar, welche nicht? Das Ergebnis ist die Aufgabenliste für alles Weitere.
2. Attributmodell festlegen (Woche 2–3)Fehlende Felder definieren, Einheiten und Wertelisten normieren, Zuständigkeit für die Pflege benennen. Erst das Modell, dann die Massenpflege — umgekehrt wird zweimal gearbeitet.
3. Markup und Feed aus einer Quelle (Woche 3–5)Product-Markup um additionalProperty, shippingDetails und Rückgabebedingungen erweitern. Feed aus derselben Datenquelle erzeugen. Tägliche Konsistenzprüfung zwischen Seite, Markup und Feed einrichten.
4. Auslieferung prüfen (Woche 5–6)Sicherstellen, dass Produktdaten ohne JavaScript im HTML stehen, Ladezeiten der Produkt- und Kategorieseiten messen und die größten Bremsen beseitigen. Crawler-Zugriffe in den Server-Logs kontrollieren.
5. Messen und ausrollen (ab Woche 6)Einen festen Satz produktnaher Fragen monatlich gegen mehrere KI-Systeme testen und protokollieren, ob die eigenen Artikel genannt werden. Bei belegter Wirkung das Attributmodell auf den restlichen Katalog ausrollen.

8. Fazit und Quick-Check

Agentic Commerce klingt nach einer Zukunftsfrage und ist in Wahrheit eine Datenfrage der Gegenwart. Der Teil, der heute schon über Umsatz entscheidet, ist nicht der autonome Kauf, sondern die Vorauswahl — und die trifft ein System, das ausschließlich mit dem arbeiten kann, was maschinenlesbar vorliegt.

Das Angenehme daran: Die Arbeit ist unstrittig sinnvoll, unabhängig davon, wie schnell sich agentische Kaufprozesse durchsetzen. Vollständige, eindeutige und aktuelle Produktdaten verbessern die Shop-Suche, senken die Retourenquote, entlasten den Kundenservice und wirken in jedem Vergleichsdienst. Es gibt nur wenige Investitionen im E-Commerce, bei denen so viele Kanäle gleichzeitig profitieren — und keine, die so zuverlässig aufgeschoben wird, weil sie nach innen wirkt statt nach außen zu glänzen.

Wer diese sieben Punkte erfüllt, ist für die maschinelle Vorauswahl vorbereitet — unabhängig davon, welches Shopsystem darunter läuft und wie sich die Oberflächen in den nächsten Jahren verändern.

Häufige Fragen

Fachglossar

Agentic Commerce

Handelsmodell, bei dem ein KI-Agent im Auftrag eines Nutzers Produkte sucht, vergleicht, vorauswählt und in fortgeschrittener Form auch bestellt. Die Kaufentscheidung wird damit teilweise an Software delegiert, die maschinenlesbare Daten benötigt.

Headless Commerce

Architektur, bei der die Shop-Logik über APIs bereitgestellt und die Darstellung von einem eigenständigen Frontend übernommen wird. Erlaubt mehrere Ausspielkanäle und maximale Freiheit im Frontend, erhöht aber Betriebs- und Wartungsaufwand.

PIM

Product Information Management — zentrales System für Produktattribute, Texte, Medien und Kanalzuordnungen. Führendes System für alles, was ein Produkt beschreibt, im Unterschied zum ERP als führendem System für Preis und Bestand.

GTIN

Global Trade Item Number, die weltweit eindeutige Artikelkennung. Sie erlaubt es Vergleichsdiensten und KI-Systemen, ein Angebot demselben Produkt zuzuordnen wie das eines Wettbewerbers — ohne sie ist ein Artikel nur schwer vergleichbar.

Attributtiefe

Anzahl und Genauigkeit der maschinenlesbaren Eigenschaften eines Produkts. Sie entscheidet darüber, für wie viele konkrete Anfragen ein Artikel überhaupt als passend erkannt werden kann.

Composable Commerce

Aufbau einer Handelsplattform aus austauschbaren Einzeldiensten für Katalog, Warenkorb, Zahlung und Suche statt aus einer Gesamtlösung. Erhöht Flexibilität, verlagert aber Integrationsverantwortung in das eigene Haus.