Ausgabe pro Seitentyp
Das Plugin rendert genau einen konsolidierten application/ld+json-Block in den <head> jeder Storefront-Seite. Alle Knoten dieser Seite leben unter einem gemeinsamen @context/@graph und verweisen über stabile @id-Referenzen aufeinander — das ist Googles empfohlene Form und maximiert die Entitäts-Kohärenz für Rich Results, AI Overviews und agentischen Handel (UCP/WebMCP).
Knoten je Seitentyp
| Seitentyp | Knoten im @graph |
|---|---|
| Startseite | Organization · WebSite + SearchAction · LocalBusiness (mit Abteilungen) |
| Produktdetail (Vater) | Organization · BreadcrumbList · ProductGroup + AggregateOffer + hasVariant[] |
| Produktdetail (Kind) | Organization · BreadcrumbList · Product + Offer + isVariantOf |
| Produktdetail (einzeln) | Organization · BreadcrumbList · Product + Offer |
| Kategorie / Suche | Organization · BreadcrumbList · ItemList (nur URLs, max. 30) |
| News-Detail | Organization · BreadcrumbList · Article (Headline, datePublished, author, image, publisher) |
| CMS-Seite (mit Marker) | Organization · BreadcrumbList · FAQPage (Q/A-Paare) |
| Sonstige | Organization · BreadcrumbList |
Organisation ist immer dabei
Der Organization-Knoten erscheint auf jeder Seite. Dadurch bleibt immer mindestens eine strukturierte Datenquelle erhalten — selbst wenn du einzelne Seitentyp-Schalter im Tab Allgemein deaktivierst.
Die drei Offer-Unterknoten
Jedes Offer und AggregateOffer trägt die drei agenten-relevanten Unterknoten:
| Unterknoten | Quelle |
|---|---|
shippingDetails | Tab Versand |
hasMerchantReturnPolicy | Tab Rückgabe |
acceptedPaymentMethod | Tab Zahlungsmethoden |
priceCurrency wird aus der aktiven Shop-Währung abgeleitet. seller wird gemäß schema.org-Regeln nur auf Offer gesetzt, niemals auf AggregateOffer. priceValidUntil liegt immer mindestens ein Jahr in der Zukunft — das verhindert „läuft bald ab”-Warnungen in der Search Console.
Varianten: Vater, Kind, Einzelartikel
Das Plugin bildet die JTL-Variantenstruktur sauber ab: Der Vaterartikel wird zur ProductGroup mit AggregateOffer und einer hasVariant[]-Liste; jeder Kindartikel ist ein Product mit eigenem Offer und isVariantOf-Rückverweis. Ein Einzelartikel ohne Varianten wird zum schlichten Product mit Offer.
Saubere Varianten brauchen saubere Stammdaten
Damit die Variantenausgabe stark wird, sollten Variations-Merkmale konsistent gepflegt sein. Die Empfehlungen dazu findest du unter Datenpflege.
GTIN / EAN
cBarcode wird vor der Ausgabe durch einen GS1-Mod-10-Prüfziffernvalidator geschickt. Ungültige oder leere Barcodes werden stillschweigend ausgelassen — es erreicht also kein kaputtes gtin13 Google.
| Artikeltyp | Verhalten |
|---|---|
| Vaterartikel | ProductGroup ohne gtinXX (kein einzelnes Trade-Item) |
| Kindartikel | gültiger Barcode → gtin13 an jedem hasVariant-Eintrag |
| Einzelartikel | gtin13, wenn ein gültiger Barcode vorhanden ist |
Beschreibung & Bewertungen
Für die Produktbeschreibung nutzt das Plugin vorrangig die Kurzbeschreibung (cKurzBeschreibung). Ist sie leer, fällt es auf eine HTML-bereinigte, an der Satzgrenze gekürzte Langbeschreibung zurück — bis zum im Tab Allgemein gesetzten Zeichenlimit (Standard 2000, 0 = kein Fallback).
Bei Bewertungen steuert die Einstellung „Max. Einzel-Reviews pro Produkt”, wie viele einzelne Review-Knoten zusätzlich zum AggregateRating ausgegeben werden (0 = nur die Aggregat-Bewertung).
FAQPage auf CMS-Seiten aktivieren
Ein FAQPage-Knoten wird nur erzeugt, wenn der CMS-Inhalt den Marker <!--msd:faq--> enthält — das verhindert Fehlinterpretationen auf normalen Inhaltsseiten. Ist der Marker gesetzt, parst das Plugin jede <h2>/<h3>, die auf ? endet, und paart sie mit dem direkt folgenden <p>-Absatz als Antwort.
So strukturierst du eine FAQ-CMS-Seite
Setze den Marker <!--msd:faq--> irgendwo in den HTML-Inhalt der Seite. Schreibe deine Fragen als Überschrift mit Fragezeichen am Ende und die Antwort als unmittelbar folgenden Absatz. Ohne Marker wird kein FAQPage-Knoten ausgegeben.
CSP-Nonce-Unterstützung
Läuft dein Shop mit einer strikten Content-Security-Policy (strict-dynamic) und stellt die Nonce über den DI-Container-Schlüssel csp_nonce oder die Smarty-Variable {$cspNonce} bereit, übernimmt das gerenderte <script type="application/ld+json"> diese automatisch. Ohne Nonce wird der Tag unverändert ausgegeben.
Eine Datenquelle: Microdata wird entfernt
Damit eine Seite nicht zwei konkurrierende Datenquellen ausliefert, entfernt das Plugin die von NOVA/JTL erzeugten Microdata-Hüllen (itemscope/itemtype). Alle itemprop bleiben erhalten, sodass die NOVA-Preislogik und PayPal Express weiterhin funktionieren. Details und die Tragweite dieser Option findest du im Tab Allgemein.