Magento-productvarianten en structured data: parent, simple product en ProductGroup

Goede productmarkup begint daarom niet met een Schema.org-plugin. Eerst moet duidelijk zijn wat het parentproduct vertegenwoordigt, welke gegevens bij de varianten horen en welke variant een bezoeker daadwerkelijk kan selecteren en kopen.

Goed om vooraf te weten: MagentoSEO.nl bouwt of wijzigt geen structured-data-module en past geen Magento-template aan. Wij analyseren producttypen en databronnen, maken de gewenste mapping en testcases, briefen de webbouwer of implementatiepartner en valideren daarna de zichtbare pagina, JSON-LD en productfeed.

Waarom Magento-producttypen SEO-technisch relevant zijn

Magento kent meerdere producttypen. Die zijn commercieel handig, maar ze hebben niet allemaal dezelfde relatie tussen pagina, SKU, prijs en voorraad.

Producttype	Praktische betekenis	Belangrijk SEO- en datavraagstuk
Simple product	Eén rechtstreeks verkoopbare uitvoering	Kloppen SKU, GTIN, prijs, voorraad en URL voor precies dit artikel?
Configurable product	Een parent met selecteerbare simple varianten	Wordt de groep plus iedere relevante variant juist beschreven?
Grouped product	Een presentatie van losse producten die apart gekocht kunnen worden	Zijn de onderdelen zelfstandige producten en URL’s?
Bundle product	De klant stelt een combinatie samen	Welke prijs en beschikbaarheid zijn vooraf werkelijk te beloven?
Virtual product	Niet-fysiek product zonder verzending	Zijn levering, voorraad en producteigenschappen logisch weergegeven?
Downloadable product	Digitaal product met downloadbare onderdelen	Sluiten aanbod, prijs en leveringsinformatie aan op het digitale product?

De grootste valkuil is doen alsof ieder Magento-producttype hetzelfde is. Een configurable parent is vaak niet het voorraadartikel dat wordt geleverd. De simple variant is dat wel. Een bundle kan geen vaste prijs hebben wanneer keuzes de totaalprijs veranderen. Een grouped product is eerder een verzameling losse aanbiedingen dan één klassieke variantgroep.

Structured data moet de werkelijkheid van de pagina beschrijven, niet de gewenste eenvoud van de implementatie.

Parent en child: wie bezit welke informatie?

Bij een configureerbaar product kun je de gegevens grofweg verdelen.

Gegevens die vaak op parentniveau horen

• merk;

• algemene productnaam;

• algemene beschrijving;

• materiaal als dit voor alle varianten gelijk is;

• reviews als die werkelijk voor de hele productfamilie gelden;

• de eigenschappen waarop het product varieert;

• parent-SKU of productgroep-ID;

• algemene categorie en toepassing.

Gegevens die vaak op variantniveau horen

• unieke SKU;

• GTIN, EAN of ander artikelnummer;

• kleur, maat, uitvoering of capaciteit;

• variantafbeelding;

• actuele prijs wanneer varianten verschillen;

• voorraadstatus;

• variant-URL of selecteerbare URL-state;

• variant-specifieke naam of beschrijving.

De woorden “vaak” zijn belangrijk. De echte eigendomsmatrix hangt af van het assortiment en de inrichting. Wanneer materiaal een variantkeuze is, hoort het materiaal op variantniveau. Wanneer alle maten dezelfde prijs hebben, mag de prijs nog steeds per Offer worden geleverd, zolang die gelijk blijft en actueel is.

Wat ProductGroup oplost

Google ondersteunt structured data voor productvarianten met ProductGroup en onderliggende Product-entiteiten. De officiële richtlijn voor productvarianten beschrijft ProductGroup als de groep met gemeenschappelijke eigenschappen en Product als iedere variant.

Belangrijke onderdelen zijn:

• name: de algemene productnaam;

• productGroupID: de identifier van de groep, vaak de parent-SKU;

• variesBy: de eigenschappen waarop varianten verschillen, zoals kleur of maat;

• hasVariant: de onderliggende Product-varianten;

• sku: de unieke variant-SKU;

• gtin: de unieke productidentifier van de variant;

• offers: prijs, valuta, beschikbaarheid en aankoop-URL van de variant.

Google noemt voor een single-page variantopzet het nesten van varianten onder ProductGroup een compacte en natuurlijke representatie. Dat is geen verplicht technisch recept voor iedere Magento-shop. De keuze hangt af van de URL- en paginavorm.

Eerst kiezen: één productpagina of meerdere variantpagina’s

Model A: alle varianten op één URL

De klant opent bijvoorbeeld /wollen-jas.html en kiest kleur en maat. De pagina herlaadt niet; afbeelding, prijs en voorraad kunnen dynamisch veranderen.

Dan kan de structured data bestaan uit:

• één ProductGroup voor de jas;

• variesBy voor kleur en maat;

• meerdere Product-varianten onder hasVariant;

• per variant een eigen SKU, GTIN, afbeelding en Offer;

• een variantselectie in de Offer-URL, bijvoorbeeld met queryparameters, als die URL de selectie betrouwbaar kan herstellen.

De HTML hoeft niet bij iedere klik volledig nieuwe markup in de DOM te schrijven om het concept geldig te maken. Wel moet de initiële markup de aangeboden varianten correct representeren en mag de zichtbare pagina die informatie niet tegenspreken.

Model B: varianten hebben eigen indexeerbare URL’s

Een kleur of uitvoering heeft een afzonderlijke pagina, bijvoorbeeld:

• /wollen-jas-groen.html;

• /wollen-jas-lichtblauw.html.

Dan moet je bepalen of die URL’s zelfstandig nuttig en indexeerbaar zijn. De Google-documentatie laat ook een multi-page opzet zien. De ProductGroup wordt dan op variantpagina’s herhaald en de relatie met andere varianten wordt via hasVariant, isVariantOf of URL-verwijzingen duidelijk gemaakt.

Dit model vraagt extra discipline:

• iedere pagina heeft een logische self-canonical als zij zelfstandig mag indexeren;

• variantpagina’s mogen niet allemaal naar een generieke parent canonicaliseren als je juist zelfstandige indexatie verwacht;

• titel, afbeelding, zichtbare selectie, prijs en voorraad horen bij de geopende variant;

• interne links moeten de relevante variant-URL gebruiken;

• sitemap en feed moeten dezelfde URL-strategie volgen.

Model C: één pagina, maar iedere selectie krijgt een URL-state

De pagina blijft conceptueel één productpagina, terwijl een parameter of fragment een gekozen variant kan openen. Dit kan prettig zijn voor delen, feeds en campagnes. Test dan of:

• de geselecteerde variant server-side of na rendering betrouwbaar zichtbaar is;

• de URL in een nieuwe sessie dezelfde variant activeert;

• Google de state kan begrijpen waar dat nodig is;

• de canonicalstrategie bewust gekozen is;

• Merchant Center op de juiste variant landt.

Een URL die ?kleur=groen&maat=l bevat maar altijd de standaard zwarte maat M toont, is geen bruikbare variantlink.

Een vereenvoudigd JSON-LD-model

Onderstaand voorbeeld laat de relatie zien. Het is geen kant-en-klare implementatie voor iedere Magento-shop; veldnamen, variantdekking en Offer-details moeten aansluiten op de werkelijke output.

{ "@context": "https://schema.org", "@type": "ProductGroup", "name": "Wollen herenjas", "productGroupID": "JAS-4400", "brand": { "@type": "Brand", "name": "Voorbeeldmerk" }, "variesBy": [ "https://schema.org/color", "https://schema.org/size" ], "hasVariant": [ { "@type": "Product", "name": "Wollen herenjas groen maat M", "sku": "JAS-4400-GRN-M", "gtin13": "8712345678901", "color": "Groen", "size": "M", "image": "https://shop.nl/media/jas-groen.jpg", "offers": { "@type": "Offer", "url": "https://shop.nl/wollen-herenjas.html?kleur=groen&maat=m", "price": "149.95", "priceCurrency": "EUR", "availability": "https://schema.org/InStock" } } ] }

De kwaliteit zit niet in het aantal velden. De kwaliteit zit in de overeenkomst met de werkelijkheid.

De productdatamatrix: één waarheid per veld

Maak vóór implementatie een matrix met de bron en het gewenste niveau.

Veld	Parent of variant?	Mogelijke bron	Kritische controle
Productnaam	Beide	Magento of PIM	Variantnaam is specifieker dan groepsnaam
SKU	Variant, plus groeps-ID voor parent	ERP, PIM of Magento	Uniek en stabiel
GTIN/EAN	Variant	ERP of PIM	Hoort bij de werkelijk geleverde uitvoering
Merk	Meestal parent	PIM of Magento-attribuut	Exacte schrijfwijze blijft gelijk
Kleur en maat	Variant	Magento-attributen	Waarden zijn zichtbaar en semantisch bruikbaar
Prijs	Variant of berekend aanbod	Magento-prijslogica	Komt overeen met zichtbare prijs en checkout
Voorraad	Variant	MSI, ERP of voorraadbron	Selecteerbare variant heeft actuele status
Afbeelding	Variant waar mogelijk	DAM, PIM of Magento	De gekozen variant toont dezelfde uitvoering
URL	Parent of variantmodel	Magento storefront	Herstelt de juiste productselectie
Reviews	Parent of variant	Reviewplatform	Aggregatie past bij wat zichtbaar wordt getoond

Als twee systemen “eigenaar” van hetzelfde veld zijn, is er geen eigenaarschap. Kies per veld één primaire bron en beschrijf welke systemen alleen doorgeven of presenteren.

Configurable products: de belangrijkste controles

Iedere verkoopbare variant heeft een unieke identifier

Gebruik geen parent-EAN voor alle maten en kleuren. Een GTIN identificeert een concreet handelsartikel. Wanneer de geleverde uitvoering een eigen barcode heeft, hoort die bij de variant.

Niet-selecteerbare varianten worden niet als beschikbaar verkocht

Een variant kan administratief bestaan maar niet verkoopbaar zijn in de betreffende website, voorraadbron of klantgroep. De markup mag niet InStock zeggen terwijl de gebruiker die variant niet kan kiezen.

Prijsbereik is geen variantprijs

“Vanaf € 99” kan op groepsniveau nuttig zijn, maar een Offer voor maat XL moet de prijs van maat XL beschrijven. Controleer ook klantgroepsprijzen, catalog price rules, staffelprijzen en storeviewvaluta. De openbare markup moet passen bij wat een gewone bezoeker op die URL werkelijk kan kopen.

Afbeeldingen volgen de gekozen variant

Wanneer blauw wordt geselecteerd maar structured data en feed de rode hoofdafbeelding gebruiken, ontstaat een inhoudelijk conflict. Dat kan ook conversie schaden doordat Shopping-verkeer op een andere uitvoering denkt te landen.

Variant-URL’s zijn reproduceerbaar

Open de URL in een incognitovenster, op mobiel en zonder bestaande cookies. Dezelfde variant moet geselecteerd zijn. Dit is een simpele maar zeer waardevolle acceptatietest.

Grouped en bundle products zijn niet hetzelfde als varianten

Grouped product

Een grouped product kan meerdere zelfstandige producten presenteren die apart worden toegevoegd. Denk aan drie formaten van een opslagbak die ook elk een eigen productpagina hebben. Dat is niet per definitie één ProductGroup met klassieke varianten. Beoordeel:

• hebben de onderdelen zelfstandige SKU’s en URL’s?

• worden ze los gekocht en geleverd?

• verschillen ze alleen op één variantdimensie of zijn het afzonderlijke producten?

• welke entiteit toont de prijs en beschikbaarheid?

Bundle product

Bij een bundle kiest de klant onderdelen. De uiteindelijke prijs en voorraad kunnen afhangen van de gekozen combinatie. Vermijd een Offer die een vaste volledige prijs of beschikbaarheid claimt wanneer dat vóór de selectie niet waar is.

Breng eerst in kaart:

• vaste of dynamische prijs;

• verplichte en optionele onderdelen;

• minimale en maximale totaalprijs;

• voorraadlogica van ieder onderdeel;

• URL waarop de gekozen configuratie kan worden hersteld;

• wat Magento, feed en checkout als verkoopartikel registreren.

Structured data, zichtbare pagina en feed moeten overeenkomen

Google legt in de inleiding tot Product structured data uit dat productinformatie zowel via structured data als via Merchant Center-feeds kan worden aangeleverd. Beide gebruiken vergroot de mogelijkheden en helpt Google informatie te begrijpen en verifiëren.

Dat maakt consistentie belangrijker. Vergelijk per variant:

• zichtbare productnaam;

• geselecteerde kleur, maat of uitvoering;

• SKU en GTIN;

• zichtbare prijs;

• voorraadstatus;

• hoofdafbeelding;

• canonical en Offer-URL;

• structured data;

• productfeed;

• uiteindelijke checkoutregel.

Een Rich Results Test die groen wordt, bewijst alleen dat de markup syntactisch kan worden verwerkt. Het bewijst niet dat de data commercieel correct is.

Testcases voor een Magento-variantimplementatie

Neem minimaal de volgende gevallen op:

Testcase	Verwachte uitkomst
Standaardvariant opent	Zichtbare data, JSON-LD en feedregel beschrijven dezelfde variant
Andere kleur wordt gekozen	Afbeelding, selectie en relevante data blijven logisch
Duurdere maat wordt gekozen	Variant-Offer toont de juiste prijs
Variant is uitverkocht	Niet selecteerbaar of duidelijk uitverkocht; markup zegt niet InStock
Variant staat in backorder	Zichtbare levertijd en availability sluiten op elkaar aan
Variant-URL wordt los geopend	Precies dezelfde variant wordt hersteld
Product staat in meerdere storeviews	Valuta, taal, URL en beschikbaarheid passen bij de storeview
Klant is niet ingelogd	Publieke markup gebruikt geen verborgen klantgroepsprijs
Parent heeft geen eigen voorraad	Groepsmarkup doet geen onjuiste voorraadclaim
GTIN ontbreekt bij enkele varianten	Geen verzonnen of gekopieerde identifier

Veelvoorkomende fouten

Eén generieke Product met parent-SKU

De pagina heeft vijftig varianten, maar JSON-LD noemt alleen de parent als één Product met één prijs en één voorraadstatus. Daarmee verdwijnt precies de informatie die de koopbare artikelen onderscheidt.

Alle varianten dezelfde GTIN geven

Dit maakt de data niet completer, maar fout. Laat een identifier weg wanneer die werkelijk ontbreekt en los de brondata afzonderlijk op.

Frontend en JSON-LD gebruiken andere prijsbronnen

De zichtbare prijs wordt berekend na promoties, terwijl JSON-LD een basistarief uit een ander veld gebruikt. Controleer prijsregels, belastingen, valuta, klantgroepen en cache.

Alleen de eerste beschikbare variant markeren

Een implementatie kan technisch makkelijk de standaardvariant pakken, maar dat is onvoldoende wanneer andere varianten eigen URL’s of Feedregels hebben.

Markup na JavaScript onvolledig of dubbel

Een thema, tagmanager en extensie kunnen ieder Product-markup toevoegen. Dan staan er meerdere entiteiten met afwijkende prijzen of SKU’s. Inventariseer alle bronnen en kies één beheerste implementatie.

Varianten indexeren zonder unieke waarde

Eigen URL’s voor iedere maat leveren zelden sterke landingspagina’s op wanneer titel, tekst, afbeeldingen en zoekintentie vrijwel gelijk zijn. Kies zelfstandige variantpagina’s alleen wanneer ze gebruikers en zoekmachines echt iets afzonderlijks bieden.

Zo brief je de webbouwer of implementatiepartner

Een goede briefing bevat:

• overzicht van gebruikte Magento-producttypen;

• keuze voor single-page, multi-page of URL-state per productgroep;

• parent-childmapping per veld;

• bronhouder van SKU, GTIN, prijs, voorraad, afbeelding en URL;

• gewenste ProductGroup, Product en Offer-relatie;

• regels voor uitverkochte en niet-zichtbare varianten;

• storeview-, valuta- en klantgroepsgedrag;

• relatie met canonical, sitemap en productfeed;

• testproducten met bekende uitzonderingen;

• acceptatiecriteria voor broncode, gerenderde HTML en variantselectie;

• proces voor monitoring na releases en data-imports.

Vraag ook welke component de markup genereert en hoe updates worden getest. Is dat het thema, een extensie, een server-side module, een headless storefront of tagmanager? Zonder dit antwoord is onderhoud na de eerste oplevering kwetsbaar.

Valideren in vier lagen

Laag 1: syntaxis

Gebruik de Rich Results Test en een Schema.org-validator. Controleer fouten én waarschuwingen, maar voeg niet blind ieder aanbevolen veld toe.

Laag 2: inhoud

Vergelijk de entiteiten met de zichtbare pagina. Controleer handmatig verschillende varianten, prijzen, voorraadstanden en afbeeldingen.

Laag 3: dataketen

Volg een variant van PIM of ERP via Magento naar storefront, JSON-LD, feed en checkout. Zoek waar waarden worden getransformeerd of gecachet.

Laag 4: productiegedrag

Monitor na implementatie Search Console, Merchant Center-diagnostiek, feedafkeuringen, prijs- en voorraadmismatches en wijzigingen na deployments.

De kern: beschrijf wat de klant werkelijk koopt

De parent maakt het assortiment begrijpelijk. De simple variant is vaak het concrete artikel dat wordt verkocht, geleverd en op voorraad gehouden. Structured data moet die twee niveaus verbinden zonder de commerciële werkelijkheid plat te slaan.

Begin daarom met producttypen, identifiers en eigenaarschap. Kies daarna een URL- en variantmodel. Laat pas vervolgens de markup bouwen en controleer die naast de zichtbare pagina en de feed.

Wil je weten of jouw Magento-productvarianten correct worden begrepen en of prijs, voorraad, SKU, GTIN en URL overal overeenkomen? Vraag een Magento-analyse aan. Wij maken de parent-childmapping, leggen de gewenste output vast voor je webbouwer en valideren de implementatie met representatieve producten en uitzonderingen.