Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok

A strukturált adatokról szóló útmutatók többsége fogyasztói webshopokra készül: egy nyilvános ár, csillagos értékelés, ingyenes szállítás. Egy B2B shop ezek többségét felborítja. Az ár az ügyféltől függ, és gyakran csak bejelentkezés után látszik, a termékeket méterre vagy 50 darabos csomagban árulják, egyetlen cikknek több száz változata lehet, és a legértékesebb keresőkifejezések nem terméknevek, hanem gyártói cikkszámok.

Ez a bejegyzés azokat a döntéseket veszi sorra, amelyeket akkor hozok, amikor Nuxtra épülő, commerce vagy PIM backendes B2B shopokba schema.org markupot teszek. Ahhoz tartja magát, amit a Google a termékfunkcióihoz dokumentál, mert ennek a résznek van nyilvános specifikációja, és megmutatja, hol kíván a B2B adat más választ, mint a fogyasztói alapeset.

Miért kell más markup-döntés a B2B termékoldalakhoz

A strukturált adatoknál van egy szabály, amely szinte minden B2B döntést meghatároz. A Google általános irányelvei szerint nem szabad olyan tartalmat megjelölni, amely nem látható az oldal olvasói számára. A markup az oldal leírása, nem mellékcsatorna olyan adatokhoz, amelyeket inkább nem mutatnál. Minden további ebből a kérdésből következik: tulajdonságonként mit lát valójában egy névtelen látogató és a Googlebot.

Termék-snippet vagy kereskedői lista

A Google a Product markupot két funkcióra bontja. A termék-snippet olyan oldalakhoz való, ahol közvetlenül nem lehet vásárolni; ehhez name és legalább egy review, aggregateRating vagy offers kell. A kereskedői lista olyan oldalakhoz, ahol az ügyfelek tőled vásárolhatnak; ehhez name, image és egy price és priceCurrency mezőket tartalmazó offers objektum kell, és a snippettel ellentétben nullánál nagyobb árat követel meg. A Google szerint a kereskedői lista tulajdonságainak megadásával az oldal általában a snippetre is jogosulttá válik.

Egy B2B shopnál a választás abból következik, amit a nyilvános oldal mutat. Ha a névtelen látogató listaárat lát és rendelhet, vagy legalább látja, mennyit fizetne, a kereskedői lista a cél. Ha az árnál az áll, hogy „jelentkezz be az árad megtekintéséhez”, akkor snippet-terepen vagy: jelöld meg a nevet, a képet, az azonosítókat, a márkát és a leírást, az offers mezőt pedig hagyd ki ahelyett, hogy kitalálnál egy számot. A B2B vevők ritkán írnak értékelést a shopban, így ezeknek az oldalaknak a gyakorlatban sokszor egyáltalán nincs rich resultjuk, és ez rendben van; az azonosítók ettől még segítenek a Google-nek a cikkszámos keresésekhez társítani az oldalt.

Melyik árat tedd közzé, és hogyan

Ha árat teszel közzé, az oldalon szereplőt tedd közzé, az oldal pénznemében, az oldalon látható adókezeléssel. Sok B2B shop nettó árat mutat a cégeknek; a markup egyszerűen ezt a számot ismétli. A Google háromféle árat ismer: az aktív árat, a priceType = https://schema.org/StrikethroughPrice jelölésű áthúzott árat és a validForMemberTier jelölésű tagsági árat. A két jelölést nem szabad egy árspecifikációban kombinálni, az aktív ár pedig egyiket sem viseli.

A sávos áraknak, a sok B2B oldalon látható „100 darabtól” táblázatnak nincs külön Google-funkciója. A schema.org az Offer és az árspecifikáció eligibleQuantity tulajdonságával teszi lehetővé annak a mennyiségi intervallumnak a megadását, amelyre egy ár vonatkozik, az eligibleCustomerType pedig azt az ügyféltípust adja meg, amelyre az ajánlat érvényes. Ez érvényes szókészlet, de a Google kereskedői listáról szóló dokumentációja nem sorolja fel, ezért csak akkor teszem bele, ha a PIM-ben tiszta adat van, és látható hatást nem várok tőle. A markupban az aktív ár az az egységár legyen, amelyet az oldal elsőként mutat.

Azonosítók: amit a B2B shopok ingyen jól csinálhatnak

A B2B vevők 6ES7 214-1AG40-0XB0-re keresnek, nem „kis PLC”-re. A PIM-ed már tartalmazza azokat az azonosítókat, amelyekkel az ilyen keresések működnek, tehát tedd közzé őket: sku a saját cikkszámodhoz, mpn a gyártói cikkszámhoz, gtin (vagy gtin8, gtin13, gtin14), ha a terméknek van ilyen, és brand beágyazott Brandként. A Google szerint az mpn egy adott gyártónál egyedileg azonosítja a terméket. Ugyanezek az értékek látszódjanak a termékadatok között is; a markupnak és az oldalnak egyeznie kell.

A cikkszámok a belső keresést is hajtják. Ha azon az oldalon dolgozol, a szemantikus termékkeresés B2B-ben cikk bemutatja, hogyan illeszkednek egymáshoz a pontos azonosítók és a szemantikus visszakeresés, és mindkettő ugyanazokon a tiszta PIM-mezőkön múlik.

Egységek, csomagok és méterár

Méteráru kábel, 200 darabos dobozban kapható csavar, kilóra mért granulátum: az egységár a B2B mindennapja. A Google a kereskedői listákhoz dokumentálja, és megjegyzi, hogy különösen az EU-ban, Új-Zélandon és Ausztráliában fontos a térfogat, hossz vagy súly szerint értékesített termékeknél. Ha az oldal egységárat mutat, az aktív árat tedd egy UnitPriceSpecification objektumba, és használd a referenceQuantity tulajdonságot egy QuantitativeValue értékkel, ahol a unitCode UN/CEFACT kód, az opcionális valueReference pedig az alapmennyiséget adja meg.

{
  "@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" }
      }
    }
  }
}

A példa azt mondja: egy 100 méteres tekercs 145 euró, méterenként kimutatva. Az oldalnak ugyanezt kell mutatnia: árat, tekercshosszt és méterárat. Ha a shop csak egész tekercset árul, ez kerüljön a névbe és a leírásba, mert az a vevő, aki 7 métert akar rendelni, különben elpattan.

Változatok a markup felrobbantása nélkül

Valódi változatcsaládokhoz, saját cikkszámos méretekhez vagy színekhez a Google a ProductGroup típust támogatja a hasVariant, variesBy és productGroupID tulajdonságokkal. Minden változatnak egyedi azonosító kell, például sku vagy gtin, minden csoportnak egyedi azonosító, és minden változatnak továbbra is kellenek a kereskedői lista szokásos tulajdonságai. Egyoldalas változatválasztónál a csoportnak egyetlen kanonikus URL-je legyen, jellemzően az az oldal, ahol nincs előre kiválasztott változat. A Google a változatok ProductGroup alá ágyazását ajánlja, mert ez a legtömörebb ábrázolás.

A konfigurálható B2B termékek más eset. Egy 12 opciós, több ezer érvényes kombinációjú szelep nem változatcsalád, hanem egy termék konfigurátorral. Jelöld meg egyetlen Productként az oldalon látható kezdőárral, a többit pedig bízd a konfigurátorra, ahogy a headless B2B termékkonfigurátorok cikkben leírtam. Ha a generált kombinációkat változatként sorolod fel, olyan termékekhez készül markup, amelyekhez senki nem talál oldalt.

Organization, visszaküldési és szállítási szabályzat

B2B-ben az eladó ugyanannyit számít, mint a termék. A Google Organization markupjának nincsenek kötelező tulajdonságai, és azt ajánlja, hogy minél több releváns tulajdonságot adj meg. Egy B2B kereskedőnél a hasznosak: legalName, address, vatID vagy taxID, iso6523Code (a Google a 0199 előtaggal a leiCode helyett, a 0060 előtaggal a duns helyett ajánlja), logo, contactPoint és sameAs. Egyszer, az egész webhelyre add meg, jellemzően a kezdő- vagy a „rólunk” oldalon.

A visszaküldési és szállítási szabályzat ma már Organization szinten is megadható: hasMerchantReturnPolicy egy MerchantReturnPolicy objektummal, és hasShippingService a szállítási szabályzathoz. A Google azt ajánlja, hogy a globális szállítási szabályzat az Organization alatt legyen, ne ismételd a shippingDetails mezőt minden ajánlatnál, az ajánlatszintű tulajdonságokat pedig tartsd meg a kivételekre. A B2B visszaküldési szabályok gyakran szigorúbbak a fogyasztóiaknál, a cégeknek nincs törvényes elállási joguk, ezért azt a szabályzatot tedd közzé, amelyet ténylegesen alkalmazol, valós napszámmal és díjtípussal.

JSON-LD renderelése Nuxtban, szerveroldalon

A Google feldolgozza a JavaScripttel a DOM-ba illesztett strukturált adatot is, de a JavaScript-útmutatója külön figyelmeztet a Product markupra: a dinamikusan generált markup ritkábbá és megbízhatatlanabbá teheti a Shopping-feltérképezést, ami a gyorsan változó adatoknak, például az árnak és a készletnek árt. Nuxtban ez azt jelenti, hogy a JSON-LD SSR közben renderelődjön, ugyanabból az adatból, amelyet a template használ. A Nuxt Schema.org modul (Unhead alapon) ezt a useSchemaOrg és az olyan segédfüggvények révén végzi, mint a defineProduct; a webhely identitása a nuxt.config.ts-be kerül.

<!-- 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>

A fontos sor az árkontextus. A markuphoz szükséges katalógusadatot kifejezetten a nyilvános árlistával kérd le, és gondoskodj róla, hogy a CDN és a route-cache soha ne tároljon bejelentkezett ügyfélnek renderelt választ. Az Unhead futásidőben nem ellenőrzi a Google jogosultsági szabályait, így a validálás továbbra is a saját pipeline-od dolga. Ha a shop többnyelvű, minden locale a saját URL-jét és pénznem-megjelenítését jelölje, összhangban a hreflang és canonical beállításokkal.

Egyetlen igazságforrás a PIM-től a markupig

A B2B shopok markup-hibái ritkán sémahibák. Adathibák: egy GTIN-mező, amelyben belső szám van, egy markupbeli ár, amely más listából jön, mint az oldalon látható, egy tegnapi ERP-exportból származó készletadat. A megoldás architekturális: a látható oldalt és a JSON-LD-t ugyanabból az API-válaszból generáld, és az adatot a forrásnál javítsd, ne a templateben.

Ez ugyanaz a fegyelem, mint bármely PIM–shop integrációnál; ha a termékadat delta-szinkronnal érkezik SAP-ból vagy Inforból, a Pimcore ERP delta-szinkron cikk megállapításai közvetlenül érvényesek, mert a markupban elavult ár egyszerűen elavult ár.

Tesztelés és monitorozás

A Google saját munkafolyamata: Rich Results Test az egyes URL-ekhez, aztán az URL-ellenőrző eszköz, hogy lásd, hogyan rendereli a Google a telepített oldalt, végül a Search Console jelentései. Egy több tízezer termékes shopnál hozzáadok egy automatizált réteget, amelyet ezek az eszközök nem adnak: egy CI-feladatot, amely termékoldalak egy mintáját rendereli, és összeveti a JSON-LD-t a látható DOM-mal.

• A markupbeli ár megegyezik a látható árral, és a pénznem is egyezik.
• Az „árért jelentkezz be” feliratú oldalakon nincs ajánlat.
• Az sku és az mpn szerepel a látható termékadatok között.
• A GTIN-értékek ellenőrző számjegye érvényes; a GTIN-mezőben lévő belső szám gyakori PIM-hiba.
• Bejelentkezési sütivel renderelt oldal soha nem kerül ki a megosztott cache-ből.

A strukturált adat nem menti meg a sovány termékoldalakat, és egy csak bejelentkezéssel elérhető katalógust sem fog úgy rangsoroltatni, mint egy fogyasztói shopot. Amit tesz: olyan formában írja le a termékeidet, amelyet a keresőmotorok és más gépek találgatás nélkül fel tudnak dolgozni. Arról a tágabb kérdésről, hogyan olvassák az AI-rendszerek az oldalaidat, a GEO-auditom és az agentic commerce protokollok áttekintése szól, amelyek ugyanerre a tiszta termékadatra épülnek.

Források

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