So machst du deine Produkte für AI lesbar: strukturierte Daten, Schritt für Schritt.

Warum Schema.org der gemeinsame Nenner ist

Jedes AI-System, das das Web liest, hat dasselbe Problem: Prosa ist mehrdeutig. „Jetzt nur 49,90!" kann ein Preis sein, ein Rabatt oder das Banner vom letzten Jahr, das niemand entfernt hat. Um aus einer Seite verwertbare Fakten zu machen, suchen Maschinen nach strukturierten Daten: einem standardisierten, maschinenlesbaren Block, der explizit sagt „das ist ein Produkt, das ist sein Preis, und so steht es um die Verfügbarkeit". Stell dir das Zutatenetikett auf einem Glas vor. Das Regal kann noch so schön dekoriert sein; was wirklich drin ist, steht auf dem Etikett.

Der Standard, auf den sich alle geeinigt haben, ist Schema.org: ein gemeinsames Vokabular aus festen Bezeichnungen für Dinge wie Produkte, Preise und Öffnungszeiten, seit 2011 gemeinsam gepflegt. Google versteht es, Bing versteht es, und auch die Crawler, also die Programme, die Websites für AI-Assistenten und Shopping-Agenten einlesen. Das ist längst keine Nischen-Zielgruppe mehr: Gartner prognostiziert, dass bis 2030 20% der Digital-Commerce-Transaktionen über AI-Plattformen laufen. Diese Bezeichnungen verpackst du am besten in JSON-LD: einen kleinen Script-Block im Quelltext deiner Seite, unsichtbar für menschliche Besucher, eindeutig für Maschinen. Eine Sache noch, bevor du auch nur eine Zeile davon schreibst. Das Markup muss in dem HTML stehen, das dein Server sendet. Baut dein Shop die Seiteninhalte erst im Browser zusammen, lies zuerst, warum die meisten AI-Crawler kein JavaScript lesen. Denn Markup, das erst nach JavaScript existiert, könnte genauso gut nicht existieren.

Schritt 1: Das Product-Markup, vollständig und ehrlich

Hier ist ein vollständiger, valider Product-Block für einen fiktiven Shop. Jedes Feld darin verdient seinen Platz. name, description und sku, also deine interne Artikelnummer, identifizieren das Produkt. brand unterscheidet es von Doppelgängern. Und offers trägt die drei Fakten, die jede Kaufentscheidung braucht: Preis, Währung, Verfügbarkeit.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Keramik Pour-Over-Set, 2 Tassen",
  "description": "Handglasiertes Keramik-Pour-Over-Set mit Dripper, Karaffe und Dosierlöffel. Passend für Standard-Filterpapier Größe 2. Spülmaschinenfest.",
  "sku": "CPO-2041",
  "brand": { "@type": "Brand", "name": "Example Shop" },
  "image": "https://www.example-shop.de/images/cpo-2041.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example-shop.de/products/keramik-pour-over-set",
    "price": "49.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "87"
  }
}
</script>

Ein Feld braucht einen Warnhinweis: aggregateRating. Nimm es nur auf, wenn diese 87 Bewertungen in deinem Shop wirklich existieren und wirklich im Schnitt 4,6 ergeben. Erfundene oder „aufgerundete" Ratings sind kein Growth-Hack. Sie verletzen die Richtlinien jeder Plattform, die diese Daten konsumiert, und ein AI-Assistent zitiert deine fiktiven 4,9 Sterne bereitwillig einem Kunden, der dann drei Bewertungen auf der Seite findet. Hast du noch keine Bewertungen, lass das Feld komplett weg. Weglassen ist ehrlich. Erfinden ist maschinenlesbares Lügen.

Schritt 2: FAQ-Markup für die Fragen, die Käufer wirklich stellen

Produkt-Fakten beantworten „was ist es und was kostet es". Das Zweite, was Käufer und ihre AI-Assistenten fragen, ist alles rund um den Kauf: Passt es, wie funktioniert die Rückgabe, wie lange dauert der Versand. Wenn diese Antworten als FAQPage-Block auf deiner Seite existieren, kann ein Assistent sie in deinen Worten beantworten, statt zu raten:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Passt das Pour-Over-Set zu Standard-Filterpapier?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Ja. Der Dripper nimmt Standard-Filterpapier in Größe 2, erhältlich in jedem Supermarkt."
      }
    },
    {
      "@type": "Question",
      "name": "Wie funktioniert die Rückgabe?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Du kannst unbenutzte Artikel innerhalb von 30 Tagen nach Lieferung zurückgeben. Der Rückversand innerhalb Deutschlands ist kostenlos."
      }
    }
  ]
}
</script>

Die Regel, die hier über allem steht: Das Markup spiegelt die sichtbare Seite. Dieselben Fragen und Antworten, die ein Mensch lesen kann, gehören in den Block, keine Extras, keine Behauptungen, die nur im Markup existieren. Womit wir bei den Arten wären, wie das schiefgeht.

Schritt 3: Die Fehler, die aktiv schaden

Schritt 4: Teste, was du ausgeliefert hast

Zwei Prüfungen, zwei Ebenen der Wahrheit:

• Syntax: Gib deine Produkt-URL in den Schema.org-Validator oder Googles Rich-Results-Test ein. Sie finden kaputtes JSON, fehlende Pflichtfelder und Typ-Fehler.
• Realität: Öffne die Seite, Rechtsklick, „Seitenquelltext anzeigen", und finde den JSON-LD-Block. Ist er überhaupt da (siehe Fehler 01)? Passen Preis und Verfügbarkeit zu dem, was die Seite sichtbar sagt? Das kann kein Validator beantworten, nur der Vergleich mit der echten Seite.

Wenn du denselben Check über deinen ganzen Shop willst statt Seite für Seite: Der kostenlose Klariton-Check liest deine Seiten so, wie Crawler es tun, und zeigt dir, was maschinenlesbar ist und was fehlt.

Schritt 5: Warum das bei 500 Produkten von Hand nicht mehr geht

Alles oben ist für fünf Produkte problemlos machbar. Bei 500 Produkten mit wöchentlichen Preis-Updates, saisonaler Verfügbarkeit und einem wachsenden FAQ ist handgepflegtes JSON-LD kein Disziplin-Problem, sondern eine strukturelle Unmöglichkeit. Jede Preisänderung hat jetzt zwei Stellen, die aktualisiert werden müssen, und die zweite ist unsichtbar, wenn sie vergessen wird. Genau so entstehen Fehler 02 und 03 im großen Maßstab: nicht durch Nachlässigkeit, sondern durch eine Architektur, die von Menschen verlangt, zwei Kopien synchron zu halten.

Die einzige tragfähige Antwort ist, das Markup automatisch aus deinen Shop-Daten zu generieren, aus derselben Quelle, die auch die Seite rendert. Dafür gibt es mehrere Wege: Manche Shopsysteme und Plugins decken Basis-Product-Markup ab, und Shops mit selbst gebautem Frontend können es direkt auf dem Server erzeugen. Der Schema-Export von Klariton ist genau für diesen Job gebaut. Er generiert Product-, FAQ- und Service-Markup aus deinen Shop-Daten und liefert es dort aus, wo Crawler es lesen können: entweder auf einer agent-lesbaren Subdomain, einer zusätzlichen Adresse deines Shops nur für Maschinen, die du ohne Code aktivierst, mit einer einzigen Zeile in deiner robots.txt, der kleinen Textdatei, die Crawlern sagt, was sie lesen dürfen. Oder über deine eigene Server-API, also eine direkte Schnittstelle deines Systems, in rund zehn Zeilen Code. Egal wie du dorthin kommst, das Ziel ist dasselbe: eine Quelle der Wahrheit, null handeditiertes JSON, und Markup, das sich in dem Moment ändert, in dem deine Daten es tun. Auf dieser Basis baut Agentic Reach auf. Und wenn du Dienstleistungen statt Produkte verkaufst, gilt dasselbe Playbook mit noch höherem Einsatz: Hier liest du, warum Dienstleister und B2B-Unternehmen strukturierte Daten noch dringender brauchen als Shops.

Häufige Fragen