Schema.org Product in 2026: wat verplicht is, wat aanbevolen is, en waar u retouren en verzending declareert

De Google-documentatie over productpagina’s maakt een onderscheid dat veel artikelen door elkaar halen: de eigenschappen die vereist zijn om een pagina in aanmerking te laten komen voor een verrijkt resultaat, en de eigenschappen die dat resultaat verrijken wanneer ze aanwezig zijn. De retour- en verzendinformatie valt in de tweede categorie. Search Central rangschikt ze expliciet onder de resultaatverrijkingen, samen met de scores, de beschikbaarheid en de prijsdalingen.

Dit artikel neemt de Product-markering door zoals ze gedocumenteerd is, sectie per sectie: wat verplicht is, wat niet, en waar u elk blok plaatst op PrestaShop 8/9 en WooCommerce.

De verplichte basis bestaat uit vijf eigenschappen

Op Product:

• name
• image, één of meerdere crawlbare en indexeerbare URL’s
• offers

Op Offer:

• price, of priceSpecification.price
• priceCurrency, of priceSpecification.priceCurrency

Daar komen drie beperkingen bij. De Merchant listing ervaringen vereisen een Offer en geen AggregateOffer, aangezien u de verkoper bent. De prijs moet strikt groter zijn dan nul. En de pagina moet over één product of zijn varianten gaan, niet over een lijst of een categorie.

Google onderscheidt daarnaast twee markeringsfamilies. De product snippet viseert de pagina’s waar men niet rechtstreeks kan kopen, typisch een redactionele test, met extra opties aan reviewzijde. De merchant listing viseert de pagina’s waar de bezoeker bij u koopt, met de maten, de verzending en de retouren. De vereiste eigenschappen van de merchant listing invullen maakt de pagina doorgaans ook geschikt voor de product snippet.

Al de rest is aanbevolen

De tabel met aanbevolen eigenschappen van Offer bevat availability, itemCondition, url, priceValidUntil, validFrom, validThrough, hasMerchantReturnPolicy en shippingDetails. Aan Product-kant: brand.name, sku, mpn, de gtin‘s, description, category, color, size, material, pattern, audience, hasCertification, review, aggregateRating, inProductGroupWithID, isVariantOf en subjectOf.

Deze eigenschappen dienen om weergaven te ontgrendelen: gemiddelde score, verzendkosten en gratis verzending, beschikbaarheid, retourinformatie, prijsdaling. Google preciseert dat deze verrijkingen naar goeddunken van elke ervaring worden getoond en kunnen evolueren, en raadt daarom aan zoveel mogelijk productinformatie te leveren zonder een specifieke weergave te willen viseren.

Het punt dat de knoop doorhakt: de productieprocedure vraagt de kritieke fouten uit de Rich Results Test te corrigeren, en voegt daaraan toe dat de niet-kritieke problemen de kwaliteit van de markering kunnen verbeteren, maar dat het corrigeren ervan niet nodig is om in aanmerking te komen voor verrijkte resultaten. En “Missing field hasMerchantReturnPolicy” en “Missing field shippingDetails” komen precies als niet-kritiek terug in de Search Console.

Retouren en verzending: het juiste niveau is Organization

Voor een retourbeleid dat de hele of vrijwel de hele catalogus dekt, vraagt Google om het één keer te declareren, op de pagina die dat beleid beschrijft, in een MerchantReturnPolicy genest onder Organization (of OnlineStore) via hasMerchantReturnPolicy. Het is niet nodig het op elke pagina van de site te herhalen.

Op dat niveau zijn er twee opties voor een minimale markering:

• Optie A: applicableCountry en returnPolicyCategory. Is de categorie MerchantReturnFiniteReturnWindow, dan wordt merchantReturnDays verplicht.
• Optie B: merchantReturnLink, de URL van de pagina die het beleid aan de klanten beschrijft.

De rest is aanbevolen en laat toe precies te zijn: returnFees, returnMethod, returnShippingFeesAmount, returnPolicyCountry, refundType, restockingFee, returnLabelSource, itemCondition, de varianten customerRemorse* en itemDefect*, en returnPolicySeasonalOverride om het venster tijdens de feestdagen te beperken.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Mijn shop",
  "url": "https://example.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "@id": "https://example.com/retouren#policy",
    "applicableCountry": ["NL", "BE", "DE"],
    "returnPolicyCountry": "NL",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

Het Offer-niveau dient maar voor twee gevallen: afwijken van het standaardbeleid voor een specifiek product, of helemaal geen standaardbeleid hebben. De daar ondersteunde eigenschappen zijn een deelverzameling van die op shopniveau. Om het globale beleid ondubbelzinnig vanaf een productpagina te refereren, volstaat een eenvoudige @id:

"hasMerchantReturnPolicy": { "@id": "https://example.com/retouren#policy" }

De verzending volgt dezelfde logica. Het standaardbeleid wordt onder Organization gedeclareerd, met een breder set eigenschappen dan op productniveau, en een productpagina kan ernaar verwijzen via hasShippingService:

"shippingDetails": {
  "@type": "OfferShippingDetails",
  "hasShippingService": { "@id": "https://example.com/verzending#policy" }
}

Op Offer-niveau, als u de verzending hard beschrijft, zijn vier eigenschappen vereist voor de verrijking: deliveryTime (met handlingTime en transitTime), shippingDestination (met addressCountry in ISO 3166-1 alpha-2), shippingRate.currency en shippingRate.value of shippingRate.maxValue. Eén tarief per OfferShippingDetails-blok: voor meerdere tarieven meerdere blokken.

De markering komt als laatste in de prioriteitsvolgorde

Google documenteert een precedentievolgorde voor de retourinformatie, van de sterkste naar de zwakste bron:

1. Content API for Shopping, retourinstellingen
2. Instellingen in Merchant Center of in de Search Console
3. Markering op het niveau van de productpagina
4. Markering op Organization-niveau

Twee praktische gevolgen. Zijn uw retouren al geconfigureerd in de Search Console of in Merchant Center, dan wordt die configuratie gebruikt en wordt de markering redundant. En de afwezigheid van markering op een pagina betekent niet “geen retourbeleid”: Google daalt gewoon af in de keten om de informatie te vinden. Voor een catalogus waarvan de verzendkosten vaak wijzigen, suggereert de documentatie overigens om via Merchant Center te gaan in plaats van via de markering.

priceValidUntil is geen datum die u elk jaar moet verlengen

Officiële definitie: de datum en het uur waarna de prijs niet meer beschikbaar zal zijn, in ISO 8601 formaat. De documentatie voegt één enkele waarschuwing toe, en niet degene die men overal leest: de pagina kan mogelijk niet worden weergegeven als priceValidUntil een datum in het verleden aangeeft. Het risico komt van een verlopen datum, niet van een ontbrekende eigenschap.

Sinds de herziening van de sectie over de duur van promoties is de rol van deze eigenschap precies: een korting begrenzen. Het begin wordt gedeclareerd met validFrom, het einde met validThrough of priceValidUntil. Google raadt aan beide grenzen te leveren, te verifiëren dat het begin het einde voorafgaat, en het uur en de tijdzone mee te geven.

"offers": {
  "@type": "Offer",
  "price": 10.00,
  "priceCurrency": "EUR",
  "validFrom": "2026-11-20T08:00:00+01:00",
  "priceValidUntil": "2026-11-30T23:59:59+01:00",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceType": "https://schema.org/StrikethroughPrice",
    "price": 15.00,
    "priceCurrency": "EUR"
  }
}

Let op de plaatsing. Op de Offer-node zijn priceValidUntil en validThrough uitwisselbaar. Op een PriceSpecification-node werkt alleen validThrough: priceValidUntil is daar niet van toepassing.

Heeft uw prijs geen echte einddatum, zet er dan geen priceValidUntil op. Een automatisch gegenereerde datum die een jaar meeschuift, beschrijft niets en komt neer op het aankondigen van een promotie-einde dat niet bestaat.

Doorgestreepte prijs, ledenprijs, prijs per liter

Drie prijstypes worden herkend, gecodeerd in priceSpecification onder Offer:

• Actieve prijs: geen priceType en geen validForMemberTier. Hij kan ook op offerniveau blijven, in price.
• Doorgestreepte prijs: priceType op https://schema.org/StrikethroughPrice. Die triggert de promotionele weergave, waarbij de actieve prijs de kortingsprijs wordt.
• Ledenprijs: validForMemberTier die verwijst naar een MemberProgramTier gedefinieerd in Merchant Center of in een MemberProgram onder Organization.

De twee markers combineren niet: een prijsspecificatie die zowel priceType als validForMemberTier draagt, wordt genegeerd. Vult u zowel offers.price als offers.priceSpecification in voor de actieve prijs, dan houdt Google offers.price aan.

Voor producten die per volume, gewicht of lengte worden verkocht, loopt de eenheidsprijs via referenceQuantity in een UnitPriceSpecification. De documentatie signaleert dat dit formaat bijzonder telt in de Europese Unie, Nieuw-Zeeland en Australië.

Varianten: ProductGroup, twee mogelijke structuren

Slechts één eigenschap is vereist op ProductGroup: name. De identificatie van de groep wordt gedeclareerd ofwel via productGroupID op de ProductGroup (de ouder-SKU), ofwel via inProductGroupWithID op elke variant. Vult u beide in, dan moeten ze overeenkomen. variesBy lijst de variatieassen op, met zes ondersteunde waarden: color, size, material, pattern, suggestedAge en suggestedGender.

Twee structuren zijn gedocumenteerd. Ofwel zijn de varianten genest in de ProductGroup via hasVariant, ofwel worden ze ernaast gedeclareerd en verwijzen ze naar de ouder via isVariantOf en een @id. Google beveelt de eerste aan, beschreven als de compactste en natuurlijkste representatie. De tweede is vaak eenvoudiger te genereren vanuit een CMS.

De technische beperkingen tellen evenzeer als de markering. Elke variant heeft een unieke identificatie nodig (sku of gtin) en een aparte URL die haar voorselecteert, met de juiste afbeelding, de juiste prijs, de juiste beschikbaarheid en de mogelijkheid haar aan de winkelwagen toe te voegen. Op een site waar alles op één pagina gebeurt, vertegenwoordigt één canonieke URL de groep. Op een site met meerdere pagina’s moet elke pagina een volledige en autonome markering dragen, met de definitie van de ProductGroup herhaald.

Energielabeling: hasCertification

Voor huishoudapparaten, lampen of schermen die in de Europese Unie worden verkocht, is de te gebruiken eigenschap hasCertification, met een Certification-object:

• issuedBy.name: EC of European_Commission voor de EU-energielabels, ADEME en BMWK voor de CO2-klassen van voertuigen.
• name: EPREL, Vehicle_CO2_Class of Vehicle_CO2_Class_Discharged_Battery.
• certificationIdentification: de EPREL-code, vereist voor de Europese energielabels.
• certificationRating: te gebruiken wanneer de EPREL-code niet bestaat (Noorwegen, Zwitserland, Verenigd Koninkrijk) of voor de CO2-klassen. ratingValue is vereist, en voor de energie-efficiëntie zijn bestRating en worstRating dat ook.

Tot tien certificeringen per product. De oude eigenschap hasEnergyConsumptionDetails wordt nog gelezen, maar de documentatie raadt aan over te schakelen naar hasCertification.

En de AI Overviews?

Geen enkele publieke Google-documentatie koppelt het verschijnen in de AI Overviews aan hasMerchantReturnPolicy, shippingDetails of een andere Product-eigenschap. Deze eigenschappen zijn gedocumenteerd voor de Merchant listing ervaringen: Shopping knowledge panel, Popular products, Google Afbeeldingen, Google Lens, product snippets.

Een nette markering helpt de systemen van Google de pagina te begrijpen, wat een goede reden blijft om er zorg aan te besteden. Maar zolang geen enkele documentatie of reproduceerbare studie het aantoont, kunt u beter geen budgettaire afweging bouwen op een oorzakelijk verband tussen deze eigenschappen en de generatieve antwoorden.

Implementatie op PrestaShop 8 en 9

Het Classic-thema produceert een JSON-LD Product met offers, maar noch de retour- en verzendbeleidsregels, noch de ProductGroup-structuur voor de varianten. Twee aparte werven, niet te verwarren.

Aan catalogusszijde. Ofwel overschrijft u de template die de JSON-LD uitstuurt in uw childthema, met het onderhoud dat dat bij elke versie-upgrade meebrengt, ofwel gaat u via een module. Verifieer in beide gevallen dat er per pagina één enkel Product-blok wordt uitgestuurd: twee tegelijk actieve SEO-modules produceren twee concurrerende markeringen.

Aan shopzijde. Het retourbeleid en het verzendbeleid worden één keer gedeclareerd, op de overeenkomstige CMS-pagina’s, in een Organization-blok. Het eenvoudigst blijft een custom codeveld dat in de head van die twee pagina’s wordt geïnjecteerd.

De module DataFirefly All in One SEO dekt de eerste werf: JSON-LD graaf met Organization, WebSite, BreadcrumbList, Product inclusief offers, priceValidUntil en de AggregateRating uit productcomments, plus FAQPage en LocalBusiness. Hij levert ook de custom codevelden voor head en einde body, waarin u het beleid op shopniveau declareert.

Implementatie op WooCommerce

WooCommerce stuurt native een Product met offers uit, aanpasbaar via de filter woocommerce_structured_data_product. Yoast SEO en Rank Math genereren elk hun eigen graaf en bieden hun eigen uitbreidingspunt. Kies één van deze drie bronnen: ze cumuleren komt neer op meerdere Product-blokken op dezelfde URL publiceren.

Voor het beleid is de logica identiek aan PrestaShop: een Organization-blok op de retourpagina en op de verzendpagina, vanuit de productpagina’s gerefereerd met @id als u elke dubbelzinnigheid wilt wegnemen. De plugin llms.txt + AEO Schema WooCommerce beheert dat graaf- en FAQ-gedeelte voor de agents.

Het resultaat verifiëren

1. Rich Results Test. Corrigeer de kritieke fouten. De niet-kritieke waarschuwingen blijven uw keuze: weeg af naargelang de verrijkingen die u wilt krijgen.
2. Schema.org-validator. Syntaxis van de JSON-LD en coherentie van de @type‘s, los van de Google-regels.
3. Search Console, rapport Merchant listings. De echte staat in productie, zodra de pagina’s opnieuw zijn gecrawld. Reken op meerdere dagen na publicatie.
4. Merchant Center of Search Console, retourinstellingen. Verifieer dat een bestaande configuratie niet al voorrang heeft op uw markering.

Waar te beginnen

1. Verifiëren dat name, image, offers, price en priceCurrency aanwezig en correct zijn op 100% van de productpagina’s. Het enige werkelijk blokkerende punt.
2. availability, itemCondition, sku, brand.name toevoegen, en de GTIN wanneer die bestaat.
3. Het retourbeleid en het verzendbeleid één keer declareren, op Organization-niveau, op de daarvoor bestemde pagina’s.
4. priceValidUntil alleen zetten op prijzen die een echte einddatum hebben, met validFrom ertegenover.
5. De varianten met ProductGroup behandelen, nadat u zich ervan heeft verzekerd dat elke variant een eigen URL heeft.

Eén regel overkoepelt het geheel: de markering moet beschrijven wat de pagina toont. Een gemarkeerde gratis retour moet op de site worden aangekondigd, een gemarkeerde termijn van 30 dagen moet een effectieve termijn van 30 dagen zijn. Dat principe, en niet het aantal eigenschappen, verklaart de meeste handmatige acties op gestructureerde data.

Lees ook: de complete gids voor e-commerce SEO en het FAQ schema en de rich snippets.

Om in actie te komen: onze modulesselectie om uw productpagina’s te optimaliseren.