> Produkt-Markup für B2B-Shops: Snippet oder Händlereintrag, welcher Preis, Artikelnummern, Grundpreise, Varianten, Organization und SSR in Nuxt. > > Web page: https://balazscsorba.com/de/blog/schema-org-structured-data-b2b-shop · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/schema-org-structured-data-b2b-shop.md) · [Magyar](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop.md) > Author: Balázs Csorba · Published: 2026-10-17 · Keywords: schema.org b2b shop, product structured data b2b, merchant listing structured data, product snippet vs merchant listing, unitpricespecification referencequantity, productgroup variants structured data, organization schema vatid, b2b prices behind login seo, json-ld nuxt schema org, merchant return policy structured data, mpn gtin structured data [Blog](https://balazscsorba.com/de/blog)/Web-Engineering # Schema.org-Strukturdaten für B2B-Shops: Preise hinter Logins, Einheiten und Varianten Produkt-Markup für B2B-Shops: Snippet oder Händlereintrag, welcher Preis, Artikelnummern, Grundpreise, Varianten, Organization und SSR in Nuxt. [Balázs Csorba](https://balazscsorba.com/de/about)·17\. Oktober 2026·10 Min. Lesezeit - Schema.org - Structured data - B2B e-commerce - Technical SEO - Nuxt ![Ein Produktrechteck mit dünnem Rahmen und einem kleinen Feld, das eine niedrige Wand verdeckt.](https://balazscsorba.com/images/blog/schema-org-structured-data-b2b-shop/cover.webp?v=4fe3c34bf4) ## Das Wichtigste in Kürze - Google hat zwei Produktfunktionen: Händlereinträge brauchen eine kaufbare Seite mit einem Preis über null, Produkt-Snippets nicht. - Nur auszeichnen, was der Besucher sieht; ein kundenspezifischer Preis hinter einem Login gehört nicht in öffentliches JSON-LD. - Artikelnummern sind der B2B-Vorteil: sku, mpn, gtin und brand ins Markup, aus denselben PIM-Feldern, die die Seite anzeigt. - UnitPriceSpecification mit referenceQuantity für Preise pro Meter, Kilogramm oder Packung verwenden und ProductGroup für echte Variantenfamilien. - JSON-LD auf dem Server rendern; Google warnt, dass per JavaScript erzeugtes Product-Markup Shopping-Crawls seltener und unzuverlässiger macht. Auf dieser Seite 1. [Warum B2B-Produktseiten andere Markup-Entscheidungen brauchen](https://balazscsorba.com/#why-b2b-is-different) 2. [Produkt-Snippet oder Händlereintrag](https://balazscsorba.com/#snippet-or-merchant-listing) 3. [Welchen Preis man veröffentlicht, und wie](https://balazscsorba.com/#which-price) 4. [Kennungen: der Teil, den B2B-Shops geschenkt bekommen](https://balazscsorba.com/#identifiers) 5. [Einheiten, Packungen und Preise pro Meter](https://balazscsorba.com/#units-and-packs) 6. [Varianten, ohne das Markup aufzublähen](https://balazscsorba.com/#variants) 7. [Organization, Rückgabe- und Versandrichtlinien](https://balazscsorba.com/#organization) 8. [JSON-LD in Nuxt serverseitig rendern](https://balazscsorba.com/#nuxt-ssr) 9. [Eine Datenquelle vom PIM bis zum Markup](https://balazscsorba.com/#data-pipeline) 10. [Testen und überwachen](https://balazscsorba.com/#testing-markup) 11. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:000:00 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. B2B-Merkmal Endkunden-Standard B2B-Antwort Preise nach Login Offer mit öffentlichem Preis Snippet ohne Preis oder öffentlicher Listenpreis, falls angezeigt Verkauf pro Meter, kg oder Packung Preis pro Stück UnitPriceSpecification mit referenceQuantity Suche nach Artikelnummer Name und Marke sku, mpn, gtin, brand aus dem PIM Hunderte Varianten Größe und Farbe ProductGroup nur für echte SKU-Varianten Firmenidentität zählt Logo und Social Links Organization mit Firmenname, UID, Rückgaberichtlinie ## 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. **Kundenpreise nie in öffentliches Markup** Serverseitiges Rendering mit eingeloggter Session kann einen verhandelten Preis ins JSON-LD bringen, das ein Cache dann an alle ausliefert. Markup nur aus dem anonymen Preiskontext erzeugen und eingeloggte Antworten von gemeinsamen Caches ausschließen. ## 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](https://balazscsorba.com/de/blog/semantic-product-search-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](https://balazscsorba.com/de/blog/headless-product-configurator-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`. ``` ``` 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](https://balazscsorba.com/de/blog/nuxt-i18n-multilingual-seo-hreflang). ## 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. Markup und sichtbaren Inhalt aus derselben Antwort erzeugen und vor und nach dem Deploy prüfen, ob sie übereinstimmen. 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](https://balazscsorba.com/de/blog/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](https://balazscsorba.com/de/blog/generative-engine-optimization-audit) und den Überblick über [Agentic-Commerce-Protokolle](https://balazscsorba.com/de/blog/agentic-commerce-protocols-ucp-acp-guide), die auf denselben sauberen Produktdaten aufbauen. ## Quellen 1. [Google Search Central: Introduction to Product structured data](https://developers.google.com/search/docs/appearance/structured-data/product) 2. [Google Search Central: Merchant listing (Product, Offer) structured data](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing) 3. [Google Search Central: Product snippet structured data](https://developers.google.com/search/docs/appearance/structured-data/product-snippet) 4. [Google Search Central: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants) 5. [Google Search Central: Organization structured data](https://developers.google.com/search/docs/appearance/structured-data/organization) 6. [Google Search Central: Merchant return policy structured data](https://developers.google.com/search/docs/appearance/structured-data/return-policy) 7. [Google Search Central: General structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) 8. [Google Search Central: Generate structured data with JavaScript](https://developers.google.com/search/docs/appearance/structured-data/generate-structured-data-with-javascript) 9. [Schema.org: Offer](https://schema.org/Offer) 10. [Schema.org: UnitPriceSpecification](https://schema.org/UnitPriceSpecification) 11. [Unhead: Product schema (defineProduct)](https://unhead.unjs.io/docs/schema-org/api/schema/product) 12. [Nuxt SEO: Schema.org identity setup](https://nuxtseo.com/docs/schema-org/guides/setup-identity) ## Häufige Fragen Kann ein B2B-Shop mit Preisen nur nach Login Product-Strukturdaten nutzen? Ja, meist aber als Produkt-Snippets statt als Händlereinträge. Produkt-Snippets brauchen einen Namen und eines von review, aggregateRating oder offers. Händlereinträge brauchen ein Angebot mit einem Preis über null, den der Besucher sieht; eine Seite ohne Preis kommt dafür nicht infrage. Welcher Preis gehört ins Markup? Der Preis, den ein anonymer Besucher auf der Seite sieht, in der angezeigten Währung. Google verlangt, dass das Markup sichtbare Inhalte beschreibt. Verhandelte Preise oder Preise einer Kundengruppe, die erst nach dem Login erscheinen, gehören nicht hinein. Wie zeichne ich einen Preis pro Meter oder pro Packung aus? Den aktiven Preis in eine UnitPriceSpecification setzen und referenceQuantity mit Wert und UN/CEFACT-unitCode ergänzen. Google dokumentiert das für Grundpreise, die in der EU bei Waren nach Volumen, Länge oder Gewicht wichtig sind. Sollte ich ProductGroup für jedes Produkt mit Optionen nutzen? Dann, wenn die Optionen echte Varianten eines Produkts sind, etwa Größen oder Farben mit eigener SKU. Jede Variante braucht eine eindeutige ID wie sku oder gtin, die Gruppe eine productGroupID. Konfigurierbare Produkte mit Tausenden Kombinationen beschreibt man besser als ein Produkt mit einem Ab-Preis. Helfen Strukturdaten KI-Assistenten und Answer Engines? Google dokumentiert, was die eigenen Suchfunktionen nutzen. Andere Systeme lesen womöglich dasselbe JSON-LD, es gibt aber keine öffentliche Spezifikation, wie sie es gewichten. Saubere sichtbare Inhalte und konsistente Kennungen sind der Teil, den man selbst steuert. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [B2B-E-Commerce & PIM →](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Ein KI-Assistent für den Support im B2B-Shop: Tools, Berechtigungen und die Übergabe an Menschen](https://balazscsorba.com/de/blog/ai-assistant-b2b-shop-customer-support) - [Mehrsprachiges SEO mit Nuxt i18n: URL-Strategie, hreflang, Canonicals und Sitemaps](https://balazscsorba.com/de/blog/nuxt-i18n-multilingual-seo-hreflang) - [Denial of Wallet: öffentliche LLM-Endpunkte in einer Nuxt-App absichern](https://balazscsorba.com/de/blog/llm-endpoint-abuse-denial-of-wallet) - [llms.txt versus Markdown Content Negotiation: was Agenten wirklich abrufen](https://balazscsorba.com/de/blog/llms-txt-vs-markdown-content-negotiation) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)