Sichta · Guides

Strukturierte Daten für KI-Shopping-Agenten: die Felder, die über Zitierbarkeit entscheiden

Veröffentlicht 17. August 2026

Die meisten Shops, die bei der Agent-Readiness durchfallen, scheitern am Gleichen: Preis, Verfügbarkeit und Produktname, die ein Kunde sieht, werden von JavaScript im Browser zusammengesetzt — und im rohen HTML, das ein Agent abruft, steht davon nichts. Serverseitig gerenderte strukturierte Daten machen eine Produktseite beantwortbar, und das lässt sich mit einem Befehl prüfen. Dieser Leitfaden behandelt, was Agenten tatsächlich lesen, welche Felder zählen und wie man eigene Seiten prüft.

Was ein Agent sieht, ist nicht das, was Sie sehen

Öffnen Sie eine Produktseite im Browser, ist alles da. Rufen Sie dieselbe URL mit einem einfachen HTTP-Client ab, erhalten Sie möglicherweise eine Hülle: ein Seitengerüst, ein paar Skripte und leere Container, die der Browser gefüllt hätte.

Assistenten und Crawler führen JavaScript in unterschiedlichem Maß aus, und die, die es tun, sind langsamer, leichter zu überspringen und weniger verlässlich. Auf Rendering zu setzen ist eine Wette, die man leise verliert — nichts schlägt fehl, Ihr Produkt kommt nur in der Antwort nicht vor.

Die entscheidende Prüfung:

curl -s https://ihrshop.de/products/ihr-produkt | grep -c "application/ld+json"

Liefert das 0, hat ein Agent auf Ihrer Seite keine strukturierte Produktbeschreibung. Danach prüfen, ob das rohe HTML Produkttitel und Preis wirklich als Text enthält — nicht als Template-Platzhalter.

Die Felder, die über Zitierbarkeit entscheiden

Produkt-JSON-LD hat viele optionale Felder und eine Handvoll, die wirklich arbeiten. Grob nach Wirkung:

  • name — der Produktname, übereinstimmend mit der Seite. Eine Abweichung zwischen JSON-LD und sichtbarem Text ist ein Qualitätssignal gegen Sie.
  • offers.price und offers.priceCurrency — eine Zahl und ein ISO-Währungscode. Ein Preis ohne Währung ist unbrauchbar, und eine Währung, die der Seite widerspricht, ist schlimmer als kein Preis.
  • offers.availability — ein ausdrücklicher Wert InStock / OutOfStock. Fehlende Verfügbarkeit heißt: Ein Assistent lässt Ihr Produkt bei „kann ich das jetzt kaufen" weg oder rät.
  • image — mindestens eines, mit echter URL. Agenten bauen zunehmend visuelle Vergleiche.
  • description — die echte Produktbeschreibung, nicht der Shop-Slogan auf jedem Produkt.
  • sku / gtin — Kennungen erlauben es, Ihr Angebot demselben Produkt anderswo zuzuordnen. So erscheinen Sie in Vergleichen statt als unzuordenbarer Posten.
  • brand — günstig anzugeben, häufig zum Filtern genutzt.

Bei Varianten wird es in den meisten Katalogen unscharf. Hat ein Produkt echte Varianten mit unterschiedlichen Preisen, gibt ein einzelnes Angebot mit einem Preis die Seite falsch wieder. Entweder die Spanne mit AggregateOffer abbilden (lowPrice, highPrice, priceCurrency) oder die Varianten als eigene Angebote mit eigenen SKUs auflisten. Den Preis einer Variante als Produktpreis auszugeben ist der Anfang von „auf der Seite stand 19 EUR".

Verfügbarkeit ehrlich halten

Die Verfügbarkeit ist das Feld, das am ehesten falsch ist, weil es sich ändert. Zwei Gewohnheiten halten es brauchbar:

  • Den echten Bestandszustand abbilden, auch „bestellbar, aber nicht am Lager", wenn das gemeint ist — schema.org hat Werte für Nachbestellung und Vorbestellung, und sie zu nutzen ist besser als ein pauschales InStock, aus dem eine Stornomail wird.
  • Nicht in die Veraltung cachen. Wird Ihre Seite mit langem Cache ausgeliefert, während der Bestand sich bewegt, erhält ein Agent eine selbstbewusste Antwort, die vor einer Stunde stimmte. Bei diesem Feld lohnt das Nachdenken über die Cache-Lebensdauer.

Über die Produktseite hinaus

Produkt-Markup bringt Sie in Produktantworten. Zwei weitere Typen entscheiden, ob Sie in die Fragen davor und danach kommen:

  • Organization auf der Startseite — wer Sie sind, Logo, URL und sameAs-Verweise auf Ihre weiteren Präsenzen. Damit kann ein Modell Ihren Shop mit Ihren anderen Auftritten zusammenführen, statt jeden als eigene unbekannte Entität zu behandeln.
  • FAQPage auf Seiten, die wirklich Fragen beantworten — Versand, Rückgabe, Größen, Kompatibilität. Ein Assistent, der „liefert das nach Österreich" beantwortet, bevorzugt eine strukturierte Antwort gegenüber einem Absatz, den er deuten muss.

Beides ist günstig, und bei beidem geht es um Auflösbarkeit, nicht nur um Vorhandensein. Ein Agent, der nicht erkennen kann, ob zwei Nennungen Ihrer Marke dasselbe Unternehmen sind, wird vage.

Regeln, die Markup vertrauenswürdig halten

Strukturierte Daten, die der Seite widersprechen, sind schlimmer als keine — Suchmaschinen behandeln das als Spam, und Modelle lernen, der Quelle zu misstrauen.

  • Nur auszeichnen, was sichtbar ist. Ein Preis im JSON-LD, der auf der Seite nirgends steht, ist ein Verstoß, keine Abkürzung.
  • Ein Produkt pro Produktseite. Eine ganze Kollektion als ein Produkt auszuzeichnen verwirrt alles Nachgelagerte.
  • Keine erfundenen Bewertungen. AggregateRating mit nicht belegbaren Zahlen ist der schnellste Weg, das Markup ganz zu verlieren — und der, der manuelle Maßnahmen auslöst.
  • Im HTML halten. JSON-LD, das ein Tag-Manager nach dem Laden einfügt, ist genauso unsichtbar wie der Rest Ihres clientseitigen Renderings.

Den ganzen Katalog prüfen, nicht eine Seite

Eine gute Produktseite beweist, dass das Theme es kann. Sie beweist nicht, dass der Katalog konsistent ist — und Inkonsistenz ist normal: Produkte zu verschiedenen Zeiten importiert, Varianten später ergänzt, Bilder im Long Tail fehlend.

Prüfungen, die man über eine Stichprobe statt über eine Seite laufen lässt:

  • Rendert jedes geprüfte Produkt Titel und JSON-LD im rohen HTML?
  • Trägt jedes Angebot einen Preis und eine Währung?
  • Ist die Verfügbarkeit vorhanden und konkret?
  • Existieren Bilder, und haben sie Alt-Texte? Fehlender Alt-Text ist Barriere und verlorene Beschreibung zugleich.
  • Sind Produkttyp und Kategorie gesetzt, damit ein Agent den Artikel in eine Taxonomie einordnen kann?

Sichta führt diese Prüfungen deterministisch über eine Stichprobe Ihres Live-Katalogs aus und meldet jedes durchgefallene Produkt — was handlungsfähiger ist als eine einzelne Punktzahl. Es geht nicht um die Zahl, sondern um die Liste der Produkte, die man reparieren muss.

Kurzfassung

Rufen Sie die eigene Produktseite mit curl ab, bevor Sie irgendetwas über Agent-Readiness glauben. Name, Preis mit Währung und konkrete Verfügbarkeit gehören in serverseitig gerendertes JSON-LD; Varianten als Spanne oder als eigene Angebote abbilden statt eine auszuwählen; Kennungen ergänzen, um in Vergleichen zuordenbar zu sein; Organization und FAQPage dort platzieren, wo sie hingehören. Niemals auszeichnen, was nicht auf der Seite steht — und eine Stichprobe des Katalogs prüfen, nicht das beste Produkt.

In sechzig Sekunden wissen Sie es.

Starten Sie den kostenlosen Scan und sehen Sie genau, wie bereit Ihr Shop für KI-Shopping-Agenten ist.

Shop jetzt prüfen — kostenlos