Was maschinenlesbare Produktdaten wirklich heißen

"Macht eure Produktdaten maschinenlesbar." Diesen Satz hört man gerade oft, und er stimmt auch. Nur bleibt er meistens abstrakt. Was genau soll da lesbar sein, für wen, und woran merkt ihr, ob es funktioniert? Dieser Artikel macht den Satz konkret.

Welche Felder ein Agent wirklich braucht

Ein KI-Agent, der für einen Kunden einkaufen soll, trifft an einer Produktseite eine Reihe von Entscheidungen. Passt das Produkt zur Anfrage, ist es verfügbar, was kostet es, in welcher Variante, wann kommt es an. Für jede dieser Entscheidungen braucht er ein Datenfeld, das er sicher auslesen kann.

Fünf Felder sind dabei entscheidend. Der Produktname und die Beschreibung, damit der Agent überhaupt versteht, worum es geht. Der Preis, und zwar der aktuelle, nicht der von letzter Woche. Die Verfügbarkeit, denn ein Agent schlägt ungern etwas vor, das nicht lieferbar ist. Die Varianten, also Größe, Farbe, Ausführung. Und die Lieferzeit, weil sie bei einer Kaufentscheidung oft den Ausschlag gibt.

Fehlt eines dieser Felder oder ist es unklar hinterlegt, fällt das Produkt für den Agenten entweder ganz raus oder wird falsch eingeordnet.

Daten haben ist nicht Daten ausliefern

Der häufigste Irrtum ist der Gedanke, die Daten seien ja vorhanden, also müsse ein Agent sie auch sehen. Vorhanden im Shop-System heißt aber nicht ausgeliefert im HTML. Viele Shops halten ihre Produktdaten sauber gepflegt in der Datenbank und laden sie erst per JavaScript in die Seite, wenn ein Browser sie öffnet. Ein Agent, der das rohe HTML liest, bekommt davon nichts mit.

Maschinenlesbar heißt deshalb: Die entscheidenden Felder stehen schon im ausgelieferten HTML, in einer Form, die eine Maschine eindeutig zuordnen kann. In der Praxis ist das meist strukturiertes Markup nach dem Standard von schema.org, eingebettet als JSON-LD direkt in der Seite. Dort steht dann nicht einfach die Zahl 149. Es steht dabei, dass 149 der Preis in Euro ist, dazu die Verfügbarkeit und die Variante.

Wie ihr prüft, ob es ankommt

Der schnellste Test kostet zwei Minuten. Öffnet eine Produktseite, klickt mit der rechten Maustaste und wählt "Seitenquelltext anzeigen". Das ist das HTML, bevor JavaScript läuft. Sucht darin nach dem Preis, dann nach der Verfügbarkeit, dann nach einer Variante.

Findet ihr alle drei, seid ihr gut aufgestellt. Findet ihr den Preis, aber keine Verfügbarkeit, habt ihr eine typische Teillücke. Findet ihr gar nichts, obwohl der Browser alles anzeigt, liegen eure Daten hinter JavaScript und ein Agent sieht sie nicht.

Für einen genaueren Blick prüft ein Readiness Check dieselben Felder systematisch und zeigt, wo die Lücken sitzen.

Feed und Schnittstelle als nächste Stufe

Strukturierte Daten in der Seite sind die Grundlage. Wer weiter denkt, stellt seine Produktdaten zusätzlich als Feed oder über eine Schnittstelle bereit, sodass ein Agent den Katalog abfragen kann, ohne jede Seite einzeln zu lesen. Das ist noch nicht für jeden nötig, aber es ist die Richtung, in die sich der Standard bewegt. Wer die Grundlage jetzt sauber legt, hat es später leichter.

Warum das gerade jetzt zählt

Morgan Stanley rechnet damit, dass KI-Agenten bis 2030 zwischen 190 und 385 Milliarden Dollar im US-Onlinehandel ausmachen könnten. In derselben Analyse benennt die Bank die Voraussetzung dafür ausdrücklich: Händler müssen Bestand, Preise, Varianten und Lieferzeiten maschinenlesbar und abrufbar bereitstellen. Das ist genau die Liste von oben.

Die gute Nachricht ist, dass der Weg dahin selten ein Neubau ist. Meist geht es darum, die entscheidenden Felder serverseitig auszuliefern, statt sie per JavaScript nachzuladen. Für die gängigen Shop-Systeme ist das ein überschaubarer Schritt.

Die Felder, die ein Agent braucht, habt ihr fast alle schon. Die Frage ist nur, ob sie an der richtigen Stelle stehen.