Schema.org-Strukturdaten für B2B-Shops: Preise hinter Logins, Einheiten und Varianten

Die meisten Anleitungen zu Strukturdaten sind für Endkunden-Shops geschrieben: ein öffentlicher Preis, eine Sternebewertung, kostenloser Versand. Ein B2B-Shop bricht die meisten dieser Annahmen. Preise hängen vom Kunden ab und erscheinen oft erst nach dem Login, Produkte werden pro Meter oder in 50er-Packungen verkauft, ein einzelner Artikel kann Hunderte Varianten haben, und die wertvollsten Suchbegriffe sind Herstellerartikelnummern statt Produktnamen.

Dieser Beitrag geht die Entscheidungen durch, die ich treffe, wenn ich B2B-Shops auf Basis von Nuxt mit Commerce- oder PIM-Backend mit schema.org-Markup versehe. Er hält sich an das, was Google für seine Produktfunktionen dokumentiert, weil das der Teil mit einer öffentlichen Spezifikation ist, und zeigt, wo B2B-Daten eine andere Antwort brauchen als der Endkunden-Standard.

Warum B2B-Produktseiten andere Markup-Entscheidungen brauchen

Für Strukturdaten gilt eine Regel, die fast jede B2B-Entscheidung bestimmt. Googles allgemeine Richtlinien sagen: keine Inhalte auszeichnen, die für Leser der Seite nicht sichtbar sind. Markup beschreibt die Seite und ist kein Nebenkanal für Daten, die man lieber nicht zeigt. Alles Weitere folgt aus der Frage, was ein anonymer Besucher und der Googlebot für jede Eigenschaft tatsächlich sehen.

Produkt-Snippet oder Händlereintrag

Google teilt Product-Markup in zwei Funktionen auf. Produkt-Snippets sind für Seiten, auf denen man nicht direkt kaufen kann; sie brauchen einen name und mindestens eines von review, aggregateRating oder offers. Händlereinträge sind für Seiten, auf denen Kunden bei Ihnen kaufen können; sie brauchen name, image und ein offers-Objekt mit price und priceCurrency, und anders als Snippets verlangen sie einen Preis über null. Laut Google macht das Ergänzen der Händlereintrags-Eigenschaften eine Seite meist auch für Snippets geeignet.

Für einen B2B-Shop ergibt sich die Wahl aus dem, was die öffentliche Seite zeigt. Sehen anonyme Besucher einen Listenpreis und können bestellen, oder sehen sie zumindest, was sie zahlen würden, zielt man auf Händlereinträge. Steht beim Preis „Einloggen, um Ihren Preis zu sehen“, ist man im Snippet-Bereich: Name, Bild, Kennungen, Marke und Beschreibung auszeichnen und offers weglassen, statt eine Zahl zu erfinden. B2B-Käufer schreiben im Shop selten Bewertungen, daher haben solche Seiten in der Praxis oft gar kein Rich Result, und das ist in Ordnung; die Kennungen helfen Google trotzdem, die Seite Suchen nach Artikelnummern zuzuordnen.

Welchen Preis man veröffentlicht, und wie

Wer einen Preis veröffentlicht, veröffentlicht den auf der Seite, in der Währung der Seite, mit der steuerlichen Darstellung der Seite. Viele B2B-Shops zeigen Geschäftskunden Nettopreise; das Markup wiederholt einfach diese Zahl. Google kennt drei Arten von Preisen: den aktiven Preis, einen Streichpreis mit priceType gleich https://schema.org/StrikethroughPrice und einen Mitgliederpreis mit validForMemberTier. Die beiden Kennzeichnungen dürfen nicht in einer Preisangabe kombiniert werden, und der aktive Preis trägt keine von beiden.

Staffelpreise, die Tabelle „ab 100 Stück“ auf vielen B2B-Seiten, haben keine eigene Google-Funktion. Schema.org bietet eligibleQuantity an Offer und Preisangaben, um das Mengenintervall eines Preises auszudrücken, und eligibleCustomerType für die Kundenart, für die ein Angebot gilt. Das ist gültiges Vokabular, aber Googles Doku zu Händlereinträgen führt es nicht auf; ich ergänze es daher nur, wenn das PIM saubere Daten hat, und erwarte keine sichtbare Wirkung. Der aktive Preis im Markup sollte der Einzelpreis sein, den die Seite zuerst zeigt.

Kennungen: der Teil, den B2B-Shops geschenkt bekommen

B2B-Käufer suchen nach 6ES7 214-1AG40-0XB0, nicht nach „kleine SPS“. Ihr PIM hält die Kennungen, mit denen solche Suchen funktionieren, schon vor, also veröffentlichen Sie sie: sku für die eigene Artikelnummer, mpn für die Herstellerartikelnummer, gtin (oder gtin8, gtin13, gtin14), wo das Produkt eine hat, und brand als verschachtelte Brand. Google beschreibt mpn als Kennung, die ein Produkt für einen bestimmten Hersteller eindeutig identifiziert. Dieselben Werte auch sichtbar in den Produktdetails zeigen; Markup und Seite müssen übereinstimmen.

Artikelnummern treiben auch die interne Suche. Wer an dieser Seite arbeitet: Semantische Produktsuche für B2B zeigt, wie exakte Kennungen und semantisches Retrieval zusammenpassen, und beides hängt an denselben sauberen PIM-Feldern.

Einheiten, Packungen und Preise pro Meter

Kabel als Meterware, Schrauben in 200er-Schachteln, Granulat pro Kilogramm: Grundpreise sind B2B-Alltag. Google dokumentiert sie für Händlereinträge und weist darauf hin, dass sie in der EU, in Neuseeland und Australien bei Waren nach Volumen, Länge oder Gewicht besonders wichtig sind. Zeigt die Seite einen Grundpreis, den aktiven Preis in eine UnitPriceSpecification setzen und referenceQuantity mit einem QuantitativeValue verwenden, wobei unitCode ein UN/CEFACT-Code ist und ein optionales valueReference die Bezugsmenge angibt.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Control cable 5G1.5, grey, sold by the metre",
  "image": "https://shop.example.at/media/cable-5g15.jpg",
  "sku": "KAB-5G15-GR",
  "mpn": "1119305",
  "brand": { "@type": "Brand", "name": "ExampleCable" },
  "offers": {
    "@type": "Offer",
    "url": "https://shop.example.at/p/kab-5g15-gr",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "price": 145.00,
      "priceCurrency": "EUR",
      "referenceQuantity": {
        "@type": "QuantitativeValue",
        "value": 100,
        "unitCode": "MTR",
        "valueReference": { "@type": "QuantitativeValue", "value": 1, "unitCode": "MTR" }
      }
    }
  }
}

Das Beispiel sagt: Ein 100-Meter-Ring kostet 145 Euro, angezeigt pro Meter. Die Seite muss dasselbe zeigen: Preis, Ringlänge und den Meterpreis. Verkauft der Shop nur ganze Ringe, gehört das in Name und Beschreibung, denn ein Käufer, der 7 Meter bestellen will, springt sonst ab.

Varianten, ohne das Markup aufzublähen

Für echte Variantenfamilien, also Größen oder Farben mit eigener SKU, unterstützt Google ProductGroup mit hasVariant, variesBy und productGroupID. Jede Variante braucht eine eindeutige ID wie sku oder gtin, jede Gruppe eine eindeutige ID, und jede Variante weiterhin die normalen Eigenschaften eines Händlereintrags. Bei Variantenauswahl auf einer Seite muss es eine kanonische URL für die Gruppe geben, typischerweise die Seite ohne vorausgewählte Variante. Google empfiehlt, die Varianten unter der ProductGroup zu verschachteln, weil das die kompakteste Darstellung ist.

Konfigurierbare B2B-Produkte sind ein anderer Fall. Ein Ventil mit 12 Optionen und Tausenden gültigen Kombinationen ist keine Variantenfamilie, sondern ein Produkt mit Konfigurator. Es als ein Product mit dem Ab-Preis auszeichnen, den die Seite zeigt, und den Rest dem Konfigurator überlassen, wie in Headless-Produktkonfiguratoren für B2B beschrieben. Generierte Kombinationen als Varianten aufzulisten erzeugt Markup für Produkte, zu denen niemand eine Seite findet.

Organization, Rückgabe- und Versandrichtlinien

Im B2B zählt der Verkäufer so viel wie das Produkt. Googles Organization-Markup hat keine Pflichtfelder und empfiehlt, so viele passende Eigenschaften wie möglich anzugeben. Für einen B2B-Händler sind nützlich: legalName, address, vatID oder taxID, iso6523Code (Google empfiehlt ihn mit Präfix 0199 statt leiCode und mit Präfix 0060 statt duns), logo, contactPoint und sameAs. Einmal siteweit angeben, üblicherweise auf der Start- oder Über-uns-Seite.

Rückgabe- und Versandrichtlinien können inzwischen auf Organization-Ebene stehen: hasMerchantReturnPolicy mit einer MerchantReturnPolicy und hasShippingService für eine Versandrichtlinie. Google empfiehlt eine globale Versandrichtlinie unter Organization, statt shippingDetails an jedem Angebot zu wiederholen, und behält die Eigenschaften am Angebot für Ausnahmen. B2B-Rückgaberegeln sind oft strenger als im Endkundengeschäft, ohne gesetzliches Widerrufsrecht für Unternehmen; veröffentlichen Sie daher die Richtlinie, die Sie tatsächlich anwenden, mit der echten Anzahl an Tagen und der Art der Gebühren.

JSON-LD in Nuxt serverseitig rendern

Google kann Strukturdaten verarbeiten, die JavaScript in das DOM einfügt, aber der JavaScript-Leitfaden enthält eine spezielle Warnung für Product-Markup: Dynamisch erzeugtes Markup kann Shopping-Crawls seltener und unzuverlässiger machen, was sich schnell ändernden Daten wie Preis und Verfügbarkeit schadet. In Nuxt heißt das: JSON-LD beim SSR rendern, aus denselben Daten, die das Template nutzt. Das Nuxt-Schema.org-Modul (auf Basis von Unhead) erledigt das mit useSchemaOrg und Helfern wie defineProduct; die Site-Identität gehört in die nuxt.config.ts.

<!-- pages/p/[slug].vue -->
<script setup lang="ts">
const route = useRoute()
// anonymous price context only: never the logged-in customer's price list
const { data: p } = await useFetch(`/api/catalog/${route.params.slug}`, { query: { priceContext: 'public' } })

useSchemaOrg([
  defineProduct({
    name: p.value.name,
    image: p.value.images.map(i => i.url),
    sku: p.value.sku,
    mpn: p.value.mpn,
    ...(p.value.gtin ? { gtin: p.value.gtin } : {}),
    brand: { '@type': 'Brand', name: p.value.brand },
    // publish an offer only when the page shows a public price
    ...(p.value.publicPrice ? {
      offers: {
        price: p.value.publicPrice.net,
        priceCurrency: 'EUR',
        availability: p.value.inStock ? 'https://schema.org/InStock' : 'https://schema.org/BackOrder',
      },
    } : {}),
  }),
])
</script>

Die wichtige Zeile ist der Preiskontext. Katalogdaten für das Markup ausdrücklich mit der öffentlichen Preisliste abrufen und sicherstellen, dass CDN und Route-Caching nie eine Antwort speichern, die für einen eingeloggten Kunden gerendert wurde. Unhead prüft Googles Eignungsregeln nicht zur Laufzeit, die Validierung gehört also weiterhin in die eigene Pipeline. Hat der Shop mehrere Sprachen, zeichnet jede Locale ihre eigene URL und Währungsdarstellung aus, passend zur Einrichtung von hreflang und Canonicals.

Eine Datenquelle vom PIM bis zum Markup

Markup-Fehler in B2B-Shops sind selten Schemafehler. Es sind Datenfehler: ein GTIN-Feld mit einer internen Nummer, ein Preis im Markup aus einer anderen Liste als auf der Seite, eine Verfügbarkeit aus dem ERP-Export von gestern. Die Lösung ist architektonisch: sichtbare Seite und JSON-LD aus derselben API-Antwort erzeugen und Daten an der Quelle korrigieren statt im Template.

Das ist dieselbe Disziplin wie bei jeder Integration von PIM und Shop; kommen die Produktdaten per Delta-Sync aus SAP oder Infor, gelten die Hinweise aus Pimcore-ERP-Delta-Sync direkt, denn ein veralteter Preis im Markup ist einfach ein veralteter Preis.

Testen und überwachen

Googles eigener Ablauf ist der Test für Rich Results für einzelne URLs, dann das URL-Prüftool, um zu sehen, wie Google eine veröffentlichte Seite rendert, dann die Berichte in der Search Console. Für einen Shop mit Zehntausenden Produkten ergänze ich eine automatisierte Schicht, die diese Werkzeuge nicht bieten: einen CI-Job, der eine Stichprobe von Produktseiten rendert und das JSON-LD mit dem sichtbaren DOM vergleicht.

• Der Preis im Markup entspricht dem sichtbaren Preis, und die Währung stimmt.
• Auf Seiten mit „Einloggen für Preis“ gibt es kein Angebot.
• sku und mpn erscheinen in den sichtbaren Produktdetails.
• GTIN-Werte haben eine gültige Prüfziffer; interne Nummern in GTIN-Feldern sind ein häufiger PIM-Fehler.
• Eine mit Login-Cookie gerenderte Seite wird nie aus dem gemeinsamen Cache ausgeliefert.

Strukturdaten retten keine dünnen Produktseiten und lassen einen Katalog nur für eingeloggte Nutzer nicht wie einen Endkunden-Shop ranken. Was sie leisten: Sie beschreiben Ihre Produkte in einem Format, das Suchmaschinen und andere Maschinen ohne Raten auswerten können. Zur größeren Frage, wie KI-Systeme Ihre Seiten lesen, siehe mein GEO-Audit und den Überblick über Agentic-Commerce-Protokolle, die auf denselben sauberen Produktdaten aufbauen.

Quellen

1. Google Search Central: Introduction to Product structured data
2. Google Search Central: Merchant listing (Product, Offer) structured data
3. Google Search Central: Product snippet structured data
4. Google Search Central: Product variant structured data
5. Google Search Central: Organization structured data
6. Google Search Central: Merchant return policy structured data
7. Google Search Central: General structured data guidelines
8. Google Search Central: Generate structured data with JavaScript
9. Schema.org: Offer
10. Schema.org: UnitPriceSpecification
11. Unhead: Product schema (defineProduct)
12. Nuxt SEO: Schema.org identity setup