Date structurate pentru magazine online: Product, Offer si Merchant Listings explicate practic

Datele structurate pentru un magazin online devin repede complicate daca sunt privite doar ca o lista de proprietati schema.org. O implementare buna trebuie sa descrie acelasi produs pe care il vede cumparatorul, la acelasi pret, cu aceeasi disponibilitate si cu o relatie clara intre produs, oferta si eventualele variante.

Confuzia apare frecvent intre Product, Offer, product snippets, Merchant Listings si Merchant Center. Nu sunt termeni interschimbabili. Unele reprezinta tipuri de date structurate, altele sunt experiente Google sau sisteme separate de furnizare a datelor despre produse.

Product, Offer si Merchant Listings nu inseamna acelasi lucru

Product si Offer sunt tipuri si proprietati folosite pentru a descrie produse si oferte intr-un format pe care sistemele automate il pot interpreta. Merchant Listings reprezinta una dintre experientele Google pentru care paginile comerciale cu date structurate corespunzatoare pot deveni eligibile.

Google separa in documentatia sa doua cazuri importante:

• Product snippets sunt potrivite inclusiv pentru pagini despre produse unde utilizatorul nu cumpara neaparat direct de la autorul paginii, cum ar fi anumite pagini editoriale sau agregatoare.
• Merchant Listings sunt orientate spre paginile in care comerciantul vinde efectiv produsul.

Pentru un magazin online clasic, diferenta este importanta deoarece cerintele Merchant Listings sunt mai apropiate de informatia comerciala necesara unei tranzactii: oferta curenta, pret, moneda, disponibilitate si, unde este cazul, informatii despre livrare sau retur.

Nu trebuie sa cauti un @type numit MerchantListing. Pagina comerciala foloseste in principal date structurate Product si Offer, iar Google decide eligibilitatea pentru experientele Merchant Listings pe baza datelor si a regulilor sale.

Product descrie ce vinzi

Obiectul Product reprezinta produsul. Aici se afla informatii precum numele, imaginile, descrierea, marca si identificatorii produsului atunci cand acestia exista.

Un principiu practic este sa separi mental doua intrebari:

• Ce este produsul? - raspunde Product.
• Cum este vandut acum? - raspunde Offer.

De exemplu, modelul, marca si SKU-ul apartin identitatii produsului. Pretul curent de vanzare si moneda apartin ofertei.

SKU, GTIN si MPN nu trebuie inventate

Daca produsul are un GTIN real atribuit, acesta poate fi furnizat. Daca magazinul foloseste SKU-uri interne, acestea trebuie sa identifice corect produsul sau varianta respectiva. Nu este util sa generezi identificatori fictivi doar pentru a completa schema.

Pentru Google Merchant Center, corespondenta dintre identificatorii folositi pe pagina si cei din datele de produs poate fi importanta atunci cand Google incearca sa asocieze oferta din pagina cu produsul trimis prin Merchant Center.

Offer descrie oferta comerciala curenta

Offer este asociat produsului prin proprietatea offers. Pentru Merchant Listings, Google cere o oferta individuala, deoarece comerciantul trebuie sa fie vanzatorul produsului. Documentatia Google diferentiaza aici Merchant Listings de unele cazuri Product snippets, unde poate fi folosita si o oferta agregata.

In forma de baza, oferta contine pretul activ si moneda. Google documenteaza pentru Merchant Listings ca pretul activ trebuie sa fie mai mare decat zero si ca moneda trebuie transmisa in formatul standard corespunzator, de exemplu RON, EUR sau USD.

Ce poate descrie un Offer

• pretul curent;
• moneda;
• disponibilitatea;
• starea produsului;
• URL-ul ofertei;
• anumite informatii despre livrare;
• anumite informatii despre retur;
• preturi speciale sau structuri de pret acceptate de Google, atunci cand sunt implementate conform documentatiei.

Nu toate proprietatile sunt obligatorii in orice situatie. Este mai sigur sa pornesti de la cerintele actuale Google pentru Merchant Listings si sa adaugi doar date pe care magazinul le poate mentine corect.

Pretul si disponibilitatea trebuie sa descrie oferta pe care o vede clientul

Aici apar unele dintre cele mai costisitoare erori de implementare. Daca pagina afiseaza 149,90 RON, iar JSON-LD transmite 169,90 RON, markup-ul nu mai descrie fidel continutul vizibil.

Google precizeaza ca datele structurate trebuie sa corespunda valorilor prezentate utilizatorului. Merchant Center foloseste de asemenea datele structurate pentru functii precum actualizarea automata a anumitor informatii despre produse, dar Google mentioneaza explicit ca actualizarile automate nu inlocuiesc actualizarea regulata a datelor furnizate in Merchant Center.

Pretul activ

O implementare simpla poate folosi offers.price impreuna cu offers.priceCurrency. Google accepta si anumite structuri cu priceSpecification, utile pentru scenarii de pret mai complexe.

Daca sunt furnizate simultan un pret activ direct in offers.price si unul prin priceSpecification, documentatia Google precizeaza ca pentru pretul activ Google foloseste valoarea din offers.price.

Disponibilitatea

Pentru disponibilitate se folosesc valori definite de schema.org, cum ar fi https://schema.org/InStock, OutOfStock, BackOrder sau alte stari suportate.

Nu transforma automat orice produs care poate fi comandat in InStock. Daca magazinul diferentiaza intre stoc fizic, precomanda, backorder sau indisponibilitate, acea logica trebuie transpusa consecvent in frontend, backend si datele structurate.

Mai multe monede

Google recomanda URL-uri distincte pentru monede diferite atunci cand acelasi produs este oferit spre vanzare in mai multe monede. Aceasta abordare reduce ambiguitatea dintre continutul paginii, pretul transmis si oferta pe care Google incearca sa o inteleaga.

Merchant Listings: ce inseamna practic pentru un magazin

Google arata ca paginile cu Product markup pot deveni eligibile pentru experiente Merchant Listings care pot utiliza informatii precum pretul, disponibilitatea, livrarea si politica de retur.

Eligibilitatea nu inseamna afisare garantata. Google precizeaza in regulile generale pentru date structurate ca o implementare valida nu garanteaza aparitia unui rezultat imbunatatit.

Pentru Merchant Listings, pagina trebuie sa fie una de unde cumparatorul poate achizitiona produsul. O pagina care doar trimite utilizatorul catre alt magazin nu indeplineste aceasta conditie pentru experienta Merchant Listings documentata de Google.

Datele structurate nu inlocuiesc automat Merchant Center

Datele structurate se afla pe pagina produsului. Merchant Center este un sistem separat prin care comerciantul poate furniza Google informatii comerciale despre produse.

Google recomanda combinarea celor doua atunci cand este posibil: date structurate pe paginile de produs si date de produs furnizate prin Merchant Center. Pentru anumite suprafete Google, participarea in Merchant Center poate fi necesara.

Daca magazinul sincronizeaza produse cu un ERP, sistem de gestiune sau alte platforme, problema devine una de arhitectura a datelor, nu doar de SEO. In astfel de proiecte merita stabilit clar cine este sursa principala pentru pret, stoc si identificatorii produsului. Vezi si ghidul despre ce trebuie stabilit inainte de o integrare API intre platforme.

Variantele nu trebuie tratate ca produse fara legatura intre ele

Un tricou disponibil in trei marimi si patru culori sau un laptop disponibil cu mai multe configuratii nu ar trebui modelat fara nicio relatie intre variante.

Google documenteaza pentru astfel de cazuri tipul ProductGroup impreuna cu proprietati precum variesBy, hasVariant si productGroupID. Fiecare varianta trebuie sa aiba la randul ei un identificator unic, de exemplu prin sku sau gtin.

Exemplu: acelasi produs in trei culori

Produsul de baza poate fi grupul, iar variantele individuale pot reprezenta combinatiile concrete pe care clientul le poate selecta. Fiecare varianta poate avea propriul SKU, propriul URL si propria disponibilitate.

Daca varianta albastra este in stoc, iar cea neagra nu mai este, datele structurate nu ar trebui sa comunice aceeasi stare pentru ambele doar pentru ca apartin aceluiasi model.

URL-urile variantelor trebuie gandite impreuna cu canonical-ul

Google suporta atat implementari in care variantele au URL-uri distincte, cat si anumite structuri de tip single-page. Pentru o implementare single-page, documentatia pentru variante precizeaza ca trebuie sa existe un singur URL canonical distinct pentru grupul de produse din care fac parte variantele.

Aceasta decizie nu ar trebui luata exclusiv la nivelul JSON-LD. URL-urile, canonical-urile, selectoarele de variante, continutul vizibil si datele structurate trebuie proiectate impreuna.

Exemplu simplificat de Product + Offer

Un produs simplu, vandut direct de magazin, poate avea conceptual o structura de forma:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Produs demonstrativ",
  "image": [
    "https://example.com/produs.jpg"
  ],
  "sku": "SKU-123",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/produs/",
    "price": 149.90,
    "priceCurrency": "RON",
    "availability": "https://schema.org/InStock"
  }
}

Exemplul este intentionat minimal. O implementare reala trebuie construita dupa datele efective ale magazinului si dupa proprietatile curente cerute sau recomandate de Google pentru situatia respectiva.

Schema nu trebuie completata cu valori hardcodate daca pretul, stocul sau produsul se schimba dinamic. Ideal, aceeasi sursa de date care genereaza informatia vizibila pentru client genereaza si JSON-LD-ul corespunzator.

Problema reala nu este generarea JSON-LD, ci sincronizarea lui

Este relativ simplu sa generezi un bloc JSON-LD valid. Este mai dificil sa te asiguri ca ramane corect dupa modificarea pretului, epuizarea stocului, activarea unei promotii sau schimbarea unei variante.

Intr-o implementare robusta, traseul datelor poate arata astfel:

1. sistemul comercial stabileste pretul si stocul curent;
2. pagina produsului afiseaza acele valori;
3. acelasi backend construieste Product si Offer;
4. feedul sau integrarea Merchant Center primeste valori compatibile;
5. modificarile de stoc si pret se propaga fara actualizari manuale separate.

Daca pretul este administrat intr-un loc, stocul in altul si JSON-LD-ul este hardcodat intr-un template, diferentele sunt aproape inevitabile.

Atentie la JSON-LD generat doar dupa incarcarea paginii

Google poate procesa date structurate generate cu JavaScript, dar pentru produsele comerciale documentatia sa avertizeaza ca markup-ul generat dinamic poate duce la crawling Shopping mai rar sau mai putin fiabil, ceea ce este relevant mai ales pentru date care se schimba rapid, precum pretul si disponibilitatea.

Pentru comerciantii care urmaresc toate tipurile de rezultate comerciale, Google recomanda includerea datelor Product in HTML-ul initial atunci cand este posibil.

Validarea trebuie facuta pe pagina reala, nu doar pe un fragment de cod

Google recomanda Rich Results Test pentru verificarea eligibilitatii markup-ului pentru rezultatele imbunatatite pe care le suporta. Pentru validarea generala schema.org exista si Schema Markup Validator.

Un test fara erori de sintaxa nu este insa suficient. Dupa implementare trebuie verificata si corespondenta cu pagina:

• numele din schema este produsul afisat;
• pretul este cel activ;
• moneda este corecta;
• disponibilitatea reflecta starea reala;
• varianta selectata este reprezentata corect;
• URL-ul ofertei duce la pagina potrivita;
• identificatorii nu se schimba accidental;
• datele nu descriu continut ascuns sau inexistent pentru utilizator.

Ce urmaresti in Search Console

Google Search Console poate raporta separat problemele asociate Merchant Listings si Product snippets. Google explica aceasta separare prin faptul ca cele doua experiente au cerinte diferite.

Dupa modificarea template-ului unui magazin, merita urmarite din nou aceste rapoarte. O schimbare aparent minora in componenta de pret sau intr-un modul de variante poate modifica datele structurate pentru sute sau mii de URL-uri.

Daca magazinul are erori recurente de schema, canonical, indexare sau template, un audit SEO tehnic si remedierea problemelor de indexare poate analiza implementarea la nivel de template si tipuri de pagini, nu doar cateva URL-uri izolate.

Greseli frecvente care fac markup-ul fragil

1. Pretul este hardcodat in template

Produsul intra in promotie, frontend-ul afiseaza noul pret, dar JSON-LD-ul continua sa transmita valoarea veche. Datele trebuie generate din aceeasi sursa operationala ori sincronizate sigur.

2. Toate variantele sunt marcate InStock

Daca fiecare combinatie are stoc propriu, disponibilitatea trebuie calculata pentru varianta corespunzatoare, nu la nivel generic.

3. Product exista, dar oferta comerciala lipseste

Pentru Merchant Listings, Offer este esential deoarece pagina reprezinta oferta comerciantului, nu doar descrierea abstracta a produsului.

4. Schema contine mai multe informatii decat pagina

Datele structurate trebuie sa reprezinte continutul paginii. Nu adauga artificial ratinguri, preturi, disponibilitate sau alte proprietati doar pentru a obtine un rezultat mai bogat.

5. Testul este verde, deci rezultatul trebuie sa apara

Nu. Validarea confirma ca implementarea indeplineste anumite cerinte tehnice, dar Google spune explicit ca datele structurate valide nu garanteaza afisarea unui rich result.

6. Schema este tratata ca inlocuitor universal pentru Merchant Center

Cele doua canale se completeaza. Google recomanda furnizarea datelor prin ambele metode acolo unde este fezabil, iar pentru unele suprafete comerciale Merchant Center este necesar.

Checklist practic inainte de lansare

Cea mai buna implementare nu este cea cu cele mai multe proprietati, ci cea care descrie corect si stabil produsul pe care magazinul il vinde in acel moment.

Daca produsul, stocul, preturile si integrarile provin din mai multe sisteme, datele structurate trebuie incluse in arhitectura tehnica a magazinului, nu adaugate la final ca un fragment SEO independent. Pentru proiecte in care datele trebuie sincronizate intre magazin, ERP, facturare sau alte platforme, vezi serviciul de integrari API intre website si sistemele business.