Unui cumpărător îi sunt de obicei suficiente câteva secunde ca să găsească pe o pagină de produs informațiile importante pentru el. Reiese rapid despre ce produs e vorba, cât costă, dacă e disponibil, cine e producătorul și, în multe cazuri, chiar și când poate ajunge. Ceea ce pentru om e evident, motorului de căutare îi e însă mult mai greu să identifice cu certitudine.
Pe o pagină de produs pot apărea simultan preț de listă, preț promoțional, cost de livrare, cod de articol, informație de stoc, nume de marcă și multe alte date; sarcina Google e să recunoască dintre acestea care informație ce înseamnă și cum se leagă de produs. În asta ajută datele structurate. Măreția lor constă în faptul că nu adaugă conținut nou paginii, ci fac mai clare, într-o formă standardizată, informațiile deja existente.
La magazinele online, asta are o importanță deosebit de mare. Cu marcajele Product și Offer se pot specifica precis, printre altele, numele produsului, prețul, moneda, disponibilitatea, codul de articol sau identificatorul GTIN. Google poate folosi aceste date și în diferite afișări de produse, astfel că, printr-o implementare corectă, o pagină de produs poate apărea cu informații mai detaliate decât un rezultat clasic.
Acesta e motivul pentru care datele structurate nu merită tratate ca o sarcină tehnică SEO separată. Într-un webshop modern fac parte din același sistem de date de produs ca numele produsului, prețul sau starea stocului și, în plus, pot contribui direct la faptul că motorul de căutare înțelege mai precis și afișează mai bine oferta.
Product și Offer: descriu două lucruri diferite
La prima vedere, cele două noțiuni pot părea identice sau cu scop asemănător, deși au roluri complet diferite în descrierea datelor de produs.
Product identifică produsul în sine; aici pot intra numele produsului, descrierea, imaginea, marca, codul de articol, identificatorul producătorului sau GTIN-ul – adică toate datele din care devine clar exact despre ce produs e vorba.
Offer, în schimb, descrie deja oferta concretă a comerciantului. Aici apar prețul, moneda, starea stocului, starea produsului și pagina unde poate fi efectiv cumpărat.
Diferența e importantă pentru că același produs poate fi vândut de numeroase webshopuri în condiții diferite. O bormașină Bosch e același produs la fiecare comerciant, dar într-un loc e disponibilă imediat la 42 990 de forinți, iar în altul costă 39 990 de forinți, însă poate fi livrată doar peste două săptămâni. Product spune deci ce e produsul, iar Offer spune în ce condiții poate fi cumpărat în webshopul respectiv.
Poate părea un detaliu tehnic, dar în realitate tocmai această separare face datele structurate cu adevărat utile în mediul comercial.
Merchant listingul nu e încă un tip de schema
Pe lângă Product și Offer apare des și expresia merchant listing, așa că e ușor de crezut că e vorba de un al treilea tip de date structurate. E însă o neînțelegere frecventă, pentru că nu vorbim de un nou tip de schema, ci de una dintre posibilitățile de afișare comercială ale Google.
Pentru astfel de rezultate, informațiile necesare le pot furniza, printre altele, datele Product și Offer. Google tratează separat cerințele pentru product snippetul clasic și pentru merchant listing, deoarece acesta din urmă se referă în mod specific la paginile unde vizitatorul chiar poate cumpăra produsul. De aceea, pe lângă preț și stoc pot apărea chiar și informații de livrare sau de retur.
Despre diferență merită vorbit puțin, pentru că poate da naștere la confuzii. Să vedem un exemplu... O revistă de specialitate poate scrie un test detaliat despre un telefon și poate folosi pentru el date structurate Product, dar nu devine prin asta magazin online. Pe pagina de produs a unui webshop există însă deja și o ofertă comercială concretă, de aceea și datelor Offer le revine un rol important. În cazul merchant listingului nu e deci suficient să-i comunici Google doar despre ce produs e vorba. Motorul de căutare trebuie să înțeleagă și în ce condiții îl oferă comerciantul respectiv.
În căutare, deja și prețul poate influența clicul
SEO-ul clasic s-a învârtit multă vreme în jurul titlului și al meta descrierii cu care apare o pagină în lista de rezultate. La webshopuri, azi pot ajunge în fața cumpărătorului mult mai multe informații înainte chiar să viziteze pagina.
Dacă Google cunoaște precis prețul, stocul sau alte date de produs, le poate folosi în anumite afișări de căutare. Funcțiile de merchant listing pot apărea, printre altele, în căutarea Google, pe interfața Google Images, în rezultate de tip produs și în medii de tip Shopping.
Dacă cineva vede mai multe produse similare unul lângă altul, prețul și statusul disponibilității pot influența deja între rezultatele căutării pe ce magazin dă clic. Nu e deloc sigur că rezultatul cu cea mai frumoasă meta description e cel care atrage vizitatorul. E absolut posibil să fie avantajat cel la care se vede imediat că produsul e în stoc și poate fi comandat la un preț acceptabil.
E important totodată că datele structurate nu reprezintă o garanție automată pentru nimic. Markupul corespunzător poate face pagina potrivită pentru afișarea anumitor informații, dar Google nu promite că le va și afișa la fiecare căutare. Indiferent de asta, în era motoarelor de căutare AI recomandăm din toată inima fiecărui magazin online folosirea consecventă a datelor structurate.
Prețul greșit e mai rău decât data lipsă
La datele structurate există un principiu de bază care nu merită scăpat din vedere: ceea ce îi dăm motorului de căutare trebuie să coincidă cu ceea ce cumpărătorul vede efectiv pe pagină.
Dacă prețul produsului e 49 990 de forinți, nici în markup nu poate figura altă sumă. Același lucru e valabil și pentru stoc: la un produs epuizat nu poate rămâne starea InStock doar pentru că datele structurate nu au fost actualizate la timp. Așteptarea Google e clară: datele din marcaj trebuie să fie în concordanță cu conținutul paginii de produs, tocmai de aceea la un webshop nu e deloc recomandat să creezi manual un bloc JSON-LD și apoi să-l lași de izbeliște luni întregi. Datele de produs se schimbă continuu: se poate modifica prețul, un produs se poate epuiza sau poate redeveni disponibil, poate porni o promoție sau se pot schimba condițiile de vânzare.
Dacă datele structurate nu sunt în legătură directă cu datele de produs reale ale webshopului, mai devreme sau mai târziu apare o discrepanță – am paria pe sume mari pe asta, dacă am avea cu cine. Atunci nu mai vorbim de optimizare tehnică, ci de o problemă de calitate a datelor. În acest punct devine deosebit de important cum gestionează și actualizează aceste informații însuși motorul magazinului online.
Datele structurate și feedul Merchant Center nu sunt același lucru
În cercurile de webshopuri apare des întrebarea: dacă există feed Merchant Center, mai e nevoie deloc de date structurate, sau invers: dacă Google poate citi informațiile și de pe pagina de produs, de ce trebuie trimis un feed separat?
Spunem de multe ori că în practică nu merită să alegi între cele două. Datele structurate se află direct pe pagina de produs, așa că Google poate interpreta de acolo informațiile actuale de preț, stoc și alte date de produs. Merchant Center, în schimb, primește datele comerciale ca sursă de date separată, pe care le poate folosi, printre altele, pentru anunțuri Shopping și afișări gratuite de produse.
Cele două surse se pot, în plus, completa reciproc. Actualizările automate ale Merchant Center pot folosi, în anumite cazuri, și datele structurate de pe site pentru a detecta schimbarea prețului, a stocului sau a prețului promoțional. Asta nu înlocuiește actualizarea regulată a feedului, dar poate reduce șansa să rămână informații învechite în sistem.
Dacă, de exemplu, seara se schimbă prețul unui produs, în Merchant Center poate figura încă valoarea anterioară, în timp ce pagina de produs și datele structurate arată deja noua valoare. În astfel de situații, Google e capabil în anumite cazuri să recunoască diferența și să ia în considerare data mai proaspătă.
Asta arată bine că rolul datelor structurate depășește azi cu mult felul în care apare o pagină între rezultatele organice, devenind tot mai mult parte organică a ecosistemului de date de produs al webshopului.
Nici identificatorii de produs nu sunt corvezi administrative
Într-un magazin online care gestionează mii de produse e ușor să privești EAN-ul, GTIN-ul, SKU-ul sau codul de articol al producătorului ca pe simple câmpuri obligatorii de completat. În realitate, acești identificatori ajută ca webshopul, Google și alte sisteme comerciale să vorbească sigur despre același produs.
E posibil ca la un produs propriu, unic, deseori deja denumirea să diferențieze bine articolul, dar la un televizor Samsung sau la o sculă Bosch pot exista nenumărate modele asemănătoare între ele, de aceea un GTIN sau MPN precis e un reper mult mai sigur decât numele produsului în sine. Nu întâmplător, și Google Merchant Center folosește direct mai mulți astfel de identificatori la interpretarea datelor de produs. Un catalog de produse ordonat nu e deci doar o chestiune administrativă, ci o valoare și din punct de vedere tehnic și SEO. Dacă data de bază e greșită sau lipsește, niciun generator de schema nu o poate suplini ulterior cu informație reală.
Și ce se întâmplă cu multele mărimi, culori, variante de ambalare?
La un produs simplu situația e ușoară: există un produs, un preț și o stare de stoc. În multe webshopuri însă, dintr-un produs sunt disponibile mai multe mărimi, culori, variante de ambalare sau versiuni tehnice, de aceea devine important și cum se leagă între ele aceste variații.
Pe lângă Product, Google oferă soluții de date structurate și pentru gestionarea variantelor de produs și a ProductGroup. Scopul nici aici nu e să ajungă cât mai mult markup pe pagină, ci ca descrierea tehnică să urmeze precis structura reală de produse a webshopului.
În acest punct se vede deja bine diferența dintre un magazin online construit de la început pe o structură de date ordonată și un sistem peticit ulterior, cu soluții separate.
Datele structurate trebuie să vină din sistem
E foarte important de spus și de înțeles că în Sellvio gestionarea datelor structurate nu se bazează pe un supliment SEO instalat separat, ci e parte organică, integrată, a sistemului tehnic SEO/GEO/AEO al platformei. Se încadrează în același sistem de fundal ca indexabilitatea, sitemapul XML, URL-urile canonical sau gestionarea hreflang.
Asta e foarte important pentru că astfel operatorul webshopului nu trebuie să creeze date structurate separat pentru fiecare produs – ceea ce, spus delicat, ar fi o sarcină imposibilă la o ofertă mai mare de produse. Așa însă, sistemul se poate sprijini pe acele date de produs care stau oricum la baza funcționării magazinului online. Dacă, de exemplu, se schimbă prețul sau stocul, nu trebuie introdusă din nou aceeași informație. La un catalog de produse mai mare, asta nu mai e o simplă funcție de confort, ci condiția ca datele să poată fi gestionate consecvent și pe termen mai lung.
Sistemul tehnic poate lucra totodată doar cu ce primește din catalogul de produse. Dacă lipsește producătorul, nu e specificat EAN-ul, numele produsului e imprecis sau informația de stoc e greșită, nici datele structurate nu pot fi perfecte. Calitatea se decide de fapt deja la încărcarea și întreținerea datelor de produs.
Canalele de produse Sellvio sunt părți ale aceluiași sistem de date
Prin canalele de produse Sellvio, datele de catalog ale webshopului pot fi transmise și către sisteme externe. Platforma poate asigura fluxuri de date, printre altele, pentru Google Shopping și alte cataloage externe, cu informații precum EAN-ul, codul de articol al producătorului, marca, prețul, categoria sau starea stocului. Feedul Google Merchant Center se construiește pe aceeași bază: transmite către Google datele catalogului de produse al webshopului. Scopul nu e deci să întreținem aceeași informație în mai multe sisteme separate, ci tocmai ca fiecare interfață să lucreze din aceeași sursă de date de încredere.
În mod ideal, un produs are un preț corect, o stare de stoc reală, un identificator precis și o fișă de produs ordonată. Din aceleași date se construiesc pagina de produs destinată cumpărătorilor, datele structurate interpretabile de Google și feedul transmis către Merchant Center. Cu cât aceste informații provin mai mult dintr-un singur sistem, cu atât mai puțin trebuie să te temi că discrepanțele și erorile rezultate din ele creează probleme în funcționare.
Din cauza prețului și a stocului, soluția tehnică e deosebit de importantă
Numele produsului se schimbă rar de la o oră la alta, dar prețul și stocul se pot modifica chiar și de mai multe ori pe zi. De aceea nu e deloc indiferent în ce mod ajung datele structurate în pagină, respectiv cât de repede urmează schimbările petrecute în webshop. Conform recomandărilor de merchant listing ale Google, la paginile comerciale datele structurate Product trebuie făcute disponibile deja în HTML-ul inițial. Procesarea markupului creat exclusiv cu JavaScript e mai puțin fiabilă la date care se schimbă rapid.
La câteva zeci de produse, asta poate nu are un efect spectaculos, dar la un catalog de mai multe mii are deja o importanță serioasă. Dacă zilnic se schimbă prețul sau stocul la sute de produse, modul de actualizare a datelor nu mai e o chestiune SEO, ci parte a infrastructurii tehnice a webshopului.
Datele structurate trebuie verificate din când în când
Faptul că un markup funcționează impecabil nu garantează că va fi așa și peste jumătate de an. O actualizare de șablon, un nou tip de produs, o gestionare modificată a prețurilor sau o variație de produs tratată greșit pot provoca ușor o eroare din care cumpărătorul nu observă nimic, în timp ce motorul de căutare primește deja date incomplete sau imprecise.
Google Search Console oferă rapoarte separate pentru verificarea datelor structurate de merchant listing și product snippet, iar URL-urile individuale pot fi examinate și cu Rich Results Test. În Search Console nu apar doar erorile, ci se poate urmări bine și cum se schimbă numărul elementelor valide, de exemplu după o dezvoltare sau o modificare de șablon. La webshopuri, verificarea datelor structurate merită integrată între sarcinile tehnice regulate la fel ca examinarea erorilor de indexare sau a indicatorilor Core Web Vitals.
Nu doar pentru Google merită puse în ordine datele de produs
Importanța datelor structurate am explicat-o multă vreme mai ales prin rich resulturile Google, dar azi imaginea e mai largă. Tot mai multe sisteme care procesează conținutul webului nu caută pur și simplu pagini, ci încearcă să interpreteze și relațiile dintre informații.
În asta ajută mult dacă un webshop poate descrie clar că un anumit număr e preț, altul e GTIN, un text e nume de marcă, iar o stare e informație de stoc. Firește, nu orice produs va apărea automat prin asta în fiecare motor de căutare bazat pe AI, dar o structură de date precisă și consecventă lasă mult mai puține ghicitori sistemelor care vor să proceseze oferta.
De fapt, acesta e unul dintre cele mai importante roluri ale datelor structurate; să descrie cât mai clar ce informație ce înseamnă exact într-un webshop.
În spatele unui webshop bun stă azi și o structură de date bună
Pe cumpărător nu-l interesează cu adevărat cât de ordonată e structura de date a magazinului online. Deschide webshopul, găsește produsul, îi vede prețul, apoi îl comandă. În fundal, același produs trebuie să apară consecvent în baza de date de produse, pe pagină, în datele structurate și în feedul transmis către Google.
Product descrie despre ce e vorba, iar Offer în ce condiții poate fi cumpărat. Merchant listingul se poate sprijini și pe aceste date atunci când Google construiește o afișare de produs cu caracter comercial.
Într-un magazin online modern, datele structurate nu sunt deci un supliment SEO montat ulterior, ci fac parte din infrastructura tehnică la fel ca gestionarea stocurilor sau feedul de produse. Acesta e și unul dintre elementele importante ale abordării Sellvio: SEO-ul tehnic, datele structurate și canalele externe de produse se construiesc pe același catalog de produse.
Sarcina comerciantului nu e astfel să creeze coduri separate pentru Google, ci să lucreze cu date de produs precise și consecvente. Dacă asta e în ordine, treaba fundalului tehnic e deja să transmită aceste informații în forma potrivită acolo unde e nevoie de ele.