Kupcu običajno zadošča nekaj sekund, da na strani izdelka najde zanj pomembne informacije. Hitro se izkaže, za kakšen izdelek gre, koliko stane, ali je na voljo, kdo je proizvajalec in v mnogih primerih tudi, kdaj lahko prispe. Kar je za človeka očitno, pa iskalnik precej težje zanesljivo prepozna.
Na strani izdelka se lahko hkrati pojavijo redna cena, akcijska cena, strošek dostave, kataloška številka, informacija o zalogi, ime blagovne znamke in več drugih podatkov; Googlova naloga je, da med njimi prepozna, katera informacija kaj pomeni in kako se navezuje na izdelek. Pri tem pomagajo strukturirani podatki. Njihova odličnost se kaže v tem, da strani ne dodajajo nove vsebine, temveč v standardizirani obliki naredijo že obstoječe informacije bolj nedvoumne.
Pri spletnih trgovinah ima to še posebej velik pomen. Z oznakama Product in Offer je mogoče natančno navesti med drugim ime izdelka, ceno, valuto, razpoložljivost, kataloško številko ali identifikator GTIN. Te podatke lahko Google uporabi tudi pri različnih prikazih izdelkov, zato se lahko stran izdelka ob ustrezni implementaciji pokaže s podrobnejšimi informacijami kot običajen zadetek.
To je razlog, zakaj strukturiranih podatkov ni smiselno obravnavati kot ločeno tehnično SEO-nalogo. V sodobni spletni trgovini so del istega sistema podatkov o izdelkih kot samo ime izdelka, cena ali stanje zaloge, poleg tega pa lahko neposredno prispevajo k temu, da iskalnik ponudbo natančneje razume in bolje prikaže.
Product in Offer: opisujeta dve različni stvari
Pojma se lahko na prvi pogled zdita enaka ali podobnega namena, a imata pri opisovanju podatkov o izdelkih povsem različni vlogi.
Product identificira sam izdelek; sem lahko sodijo ime izdelka, opis, slika, blagovna znamka, kataloška številka, proizvajalčev identifikator ali GTIN – torej vsi podatki, iz katerih postane nedvoumno, za kateri izdelek točno gre.
Offer pa nasprotno opisuje že konkretno ponudbo trgovca. Tu se pojavijo cena, valuta, stanje zaloge, stanje izdelka in stran, kjer ga je dejansko mogoče kupiti.
Razlika je pomembna zato, ker lahko isti izdelek prodaja veliko spletnih trgovin pod različnimi pogoji. Boschev vrtalnik je pri vsakem trgovcu isti izdelek, pri čemer je na enem mestu za 42.990 forintov na voljo takoj, drugje pa stane 39.990 forintov, a ga je mogoče dostaviti šele čez dva tedna. Product torej pove, kaj je izdelek, Offer pa, pod kakšnimi pogoji ga je mogoče kupiti v dani spletni trgovini.
Morda se zdi tehnična podrobnost, v resnici pa je prav ta ločitev tista, zaradi katere so strukturirani podatki v trgovskem okolju resnično uporabni.
Merchant listing ni še en tip sheme
Poleg Product in Offer se pogosto pojavi tudi izraz merchant listing, zato je lahko misliti, da gre za tretji tip strukturiranih podatkov. To pa je pogost nesporazum, saj ne govorimo o novem tipu sheme, temveč o eni od Googlovih trgovskih možnosti prikaza.
Potrebne informacije za takšne zadetke lahko med drugim zagotavljajo podatki Product in Offer. Google zahteve za običajni product snippet in za merchant listing obravnava ločeno, saj se slednji nanaša izrecno na strani, kjer lahko obiskovalec izdelek tudi dejansko kupi. Zato se lahko poleg cene in zaloge prikažejo tudi informacije o dostavi ali vračilu.
O razliki je vredno nekoliko spregovoriti, saj lahko povzroči nesporazume. Poglejmo primer ... Strokovna revija lahko napiše podroben test telefona in pri tem uporabi strukturirane podatke Product, a zaradi tega še ne postane spletna trgovina. Na strani izdelka spletne trgovine pa je prisotna že konkretna trgovska ponudba, zato imajo pomembno vlogo tudi podatki Offer. Pri merchant listingu torej ni dovolj Googlu zgolj sporočiti, za kakšen izdelek gre. Iskalnik mora razumeti tudi, pod kakšnimi pogoji ga dani trgovec ponuja.
V iskalniku lahko na klik vpliva že cena
Klasični SEO je dolgo govoril o tem, s kakšnim naslovom in meta opisom se stran prikaže na seznamu zadetkov. Pri spletnih trgovinah lahko danes pred kupca pride precej več informacij, še preden obišče stran.
Če Google natančno pozna ceno, zalogo ali druge podatke o izdelku, jih lahko uporabi pri določenih prikazih v iskanju. Funkcije merchant listing se lahko med drugim pojavijo v Googlovem iskalniku, na površini Google Images, v izdelčnih zadetkih in v okolju tipa Shopping.
Če nekdo vidi več podobnih izdelkov drugega ob drugem, lahko cena in status razpoložljivosti že med iskalnimi zadetki vplivata na to, na katero trgovino klikne. Niti najmanj ni gotovo, da obiskovalca pritegne zadetek z najlepšim meta opisom. Povsem mogoče je, da prednost dobi tisti, pri katerem je takoj vidno, da je izdelek na zalogi in ga je mogoče naročiti po sprejemljivi ceni.
Pomembno pa je, da strukturirani podatki za nič ne pomenijo samodejnega jamstva. Ustrezen markup lahko stran usposobi za prikaz določenih informacij, a Google ne obljublja, da jih bo prikazal pri vsakem iskanju. Ne glede na to v dobi AI-iskalnikov vsaki spletni trgovini toplo priporočamo dosledno uporabo strukturiranih podatkov.
Napačna cena je slabša od manjkajočega podatka
Pri strukturiranih podatkih velja osnovno načelo, ki ga ni vredno izgubiti izpred oči: kar navedemo iskalniku, se mora ujemati s tem, kar kupec dejansko vidi na strani.
Če je cena izdelka 49.990 forintov, tudi v markupu ne sme biti drugega zneska. Enako velja za zalogo: pri razprodanem izdelku ne sme ostati stanje InStock le zato, ker strukturiranih podatkov nismo pravočasno osvežili. Googlovo pričakovanje je nedvoumno: podatki v označevanju morajo biti usklajeni z vsebino strani izdelka, zato pri spletni trgovini niti najmanj ni priporočljivo ročno izdelati blok JSON-LD in ga nato za mesece prepustiti samemu sebi. Podatki o izdelkih se nenehno spreminjajo: cena se lahko spremeni, izdelek lahko poide ali spet postane dosegljiv, začne se lahko akcija ali pa se spremenijo pogoji prodaje.
Če strukturirani podatki niso v neposredni povezavi z dejanskimi podatki o izdelkih spletne trgovine, prej ali slej nastane razhajanje – na to bi stavili tudi visoko vsoto, če bi imeli s kom. Takrat ne govorimo več o tehnični optimizaciji, temveč o problemu kakovosti podatkov. Na tej točki postane posebej pomembno, kako te informacije upravlja in osvežuje sam pogon spletne trgovine.
Structured data in Merchant Center feed nista isto
V krogih spletnih trgovcev se pogosto pojavi vprašanje: če obstaja Merchant Center feed, ali so strukturirani podatki sploh potrebni, oziroma obratno – če Google informacije lahko prebere tudi s strani izdelka, zakaj je treba pošiljati ločen feed?
Večkrat povemo, da v praksi med njima ni smiselno izbirati. Strukturirani podatki so neposredno na strani izdelka, zato lahko Google tudi od tam razbere aktualne informacije o ceni, zalogi in drugih podatkih izdelka. Merchant Center pa trgovske podatke prejme kot ločen vir podatkov, ki jih lahko uporabi med drugim za oglase Shopping in brezplačne prikaze izdelkov.
Vira se poleg tega lahko dopolnjujeta. Samodejne posodobitve Merchant Centra lahko v določenih primerih uporabijo tudi strukturirane podatke na spletni strani, da zaznajo spremembo cene, zaloge ali akcijske cene. To ne nadomešča rednega osveževanja feeda, lahko pa zmanjša verjetnost, da v sistemu ostane zastarela informacija.
Če se na primer zvečer spremeni cena izdelka, je lahko v Merchant Centru še prejšnja vrednost, medtem ko stran izdelka in strukturirani podatki že kažejo novo. V takem primeru Google v določenih situacijah zna prepoznati razhajanje in upoštevati novejši podatek.
To dobro kaže, da vloga strukturiranih podatkov danes že precej presega vprašanje, kako se stran prikaže med organskimi zadetki, saj vse bolj postajajo organski del ekosistema podatkov o izdelkih spletne trgovine.
Tudi identifikatorji izdelkov niso administrativna nadloga
V spletni trgovini, ki upravlja več tisoč izdelkov, je lahko na EAN, GTIN, SKU ali proizvajalčevo kataloško številko gledati preprosto kot na obvezno polje za izpolnitev. V resnici ti identifikatorji pomagajo, da spletna trgovina, Google in drugi trgovski sistemi zanesljivo govorijo o istem izdelku.
Možno je, da pri lastnem, unikatnem izdelku artikel pogosto dobro loči že samo poimenovanje, pri Samsungovem televizorju ali Boschevem orodju pa lahko obstaja ogromno medsebojno podobnih modelov, zato je natančen GTIN ali MPN veliko zanesljivejša opora kot samo ime izdelka. Ni naključje, da tudi Google Merchant Center več takšnih identifikatorjev neposredno uporablja za razumevanje podatkov o izdelkih. Urejen katalog izdelkov zato ni zgolj administrativno vprašanje, temveč vrednost tudi s tehničnega in SEO-vidika. Če je osnovni podatek napačen ali pomanjkljiv, ga naknadno noben generator shem ne more nadomestiti z resnično informacijo.
In kaj se zgodi s številnimi velikostmi, barvami, pakiranji?
Pri preprostem izdelku je položaj lahek: obstaja en izdelek, ena cena in eno stanje zaloge. V mnogih spletnih trgovinah pa je izdelek na voljo v več velikostih, barvah, pakiranjih ali tehničnih različicah, zato postane pomembno tudi, kako se te variacije povezujejo med seboj.
Google poleg Product ponuja strukturirano podatkovno rešitev tudi za obravnavo variant izdelkov in ProductGroup. Cilj tudi tu ni, da bi na stran prišlo čim več markupa, temveč da tehnični opis natančno sledi resnični strukturi izdelkov spletne trgovine.
Na tej točki se že dobro vidi razlika med spletno trgovino, zgrajeno na vnaprej urejeni podatkovni strukturi, in sistemom, naknadno zakrpanim z ločenimi rešitvami.
Strukturirani podatki morajo prihajati iz sistema
Zelo pomembno je povedati in razumeti, da upravljanje strukturiranih podatkov v Sellviu ne temelji na posebej nameščenem SEO-dodatku, temveč je organski, vgrajeni del tehničnega sistema SEO/GEO/AEO platforme. Umešča se v isti zaledni sistem kot indeksirljivost, XML sitemap, canonical URL-ji ali upravljanje hreflang.
To je tako pomembno zato, ker upravljavcu spletne trgovine tako ni treba za vsak izdelek posebej pripravljati strukturiranih podatkov – kar bi bila pri večji ponudbi izdelkov, milo rečeno, nesprejemljiva naloga. Tako pa se sistem lahko opre na tiste podatke o izdelkih, ki so tako ali tako temelj delovanja spletne trgovine. Če se na primer spremeni cena ali zaloga, iste informacije ni treba znova vnašati. Pri večjem katalogu izdelkov to ni več preprosta funkcija udobja, temveč pogoj, da je podatke mogoče dosledno upravljati tudi dolgoročno.
Tehnični sistem pa lahko dela le s tem, kar dobi iz kataloga izdelkov. Če manjka proizvajalec, ni naveden EAN, je ime izdelka nenatančno ali je informacija o zalogi napačna, tudi strukturirani podatki ne morejo biti popolni. Kakovost se zato v resnici odloči že pri vnašanju in vzdrževanju podatkov o izdelkih.
Sellviovi kanali izdelkov so del istega podatkovnega sistema
Prek Sellviovih kanalov izdelkov je mogoče kataloške podatke spletne trgovine posredovati tudi zunanjim sistemom. Platforma lahko med drugim zagotavlja podatkovne tokove za Google Shopping in druge zunanje kataloge, z informacijami, kot so EAN, proizvajalčeva kataloška številka, blagovna znamka, cena, kategorija ali stanje zaloge. Google Merchant Center feed je zgrajen na istem temelju: podatke kataloga izdelkov spletne trgovine posreduje Googlu. Cilj torej ni vzdrževati iste informacije v več ločenih sistemih, temveč ravno to, da vse površine delajo iz istega zanesljivega vira podatkov.
V idealnem primeru ima izdelek eno pravilno ceno, resnično stanje zaloge, natančen identifikator in urejeno podatkovno stran. Iz istih podatkov nastanejo stran izdelka, namenjena kupcem, strukturirani podatki, ki jih razume Google, in feed, posredovan Merchant Centru. Čim bolj te informacije izvirajo iz enega sistema, tem manj se je treba bati, da bodo razhajanja in iz njih izhajajoče napake povzročale težave pri delovanju.
Zaradi cene in zaloge je tehnična rešitev še posebej pomembna
Ime izdelka se redko spremeni iz ure v uro, cena in zaloga pa se lahko spremenita tudi večkrat na dan. Zato sploh ni vseeno, na kakšen način pridejo strukturirani podatki na stran oziroma kako hitro sledijo spremembam v spletni trgovini. Po Googlovih priporočilih za merchant listing morajo biti pri trgovskih straneh strukturirani podatki Product dostopni že v začetnem HTML-ju. Obdelava markupa, ustvarjenega izključno z JavaScriptom, je pri hitro spreminjajočih se podatkih manj zanesljiva.
Pri nekaj deset izdelkih to morda nima opaznega učinka, pri katalogu z več tisoč izdelki pa ima že resen pomen. Če se cena ali zaloga dnevno spreminja pri stotinah izdelkov, način osveževanja podatkov ni več SEO-vprašanje, temveč del tehnične infrastrukture spletne trgovine.
Strukturirane podatke je treba občasno preveriti
To, da markup deluje brezhibno, še ne pomeni, da bo tako tudi čez pol leta. Posodobitev predloge, nov tip izdelka, spremenjeno upravljanje cen ali slabo obravnavana varianta izdelka zlahka povzročijo napako, ki je kupec sploh ne opazi, medtem ko iskalnik že prejema pomanjkljive ali nenatančne podatke.
Google Search Console zagotavlja samostojna poročila za preverjanje strukturiranih podatkov merchant listing in product snippet, posamezne URL-je pa je mogoče preveriti tudi z orodjem Rich Results Test. V Search Consoli se ne prikažejo le napake, temveč je dobro mogoče spremljati tudi, kako se spreminja število veljavnih elementov, na primer po razvoju ali spremembi predloge. Pri spletnih trgovinah je preverjanje strukturiranih podatkov smiselno vgraditi med redne tehnične naloge, enako kot pregled indeksirnih napak ali kazalnikov Core Web Vitals.
Podatke o izdelkih ni vredno urediti le zaradi Googla
Pomen strukturiranih podatkov smo dolgo razlagali predvsem z Googlovimi rich results, danes pa je slika širša. Vse več je sistemov, ki obdelujejo vsebino spleta in ne iščejo zgolj strani, temveč poskušajo interpretirati tudi povezave med informacijami.
Pri tem veliko pomaga, če spletna trgovina zna nedvoumno opisati, da je določena številka cena, druga GTIN, da je neko besedilo ime blagovne znamke, neko stanje pa informacija o zalogi. Zaradi tega se seveda vsak izdelek še ne pojavi samodejno v vsakem iskalniku na osnovi AI, a natančna in dosledna podatkovna struktura pušča precej manj ugibanja sistemom, ki želijo ponudbo obdelati.
Pravzaprav je to ena najpomembnejših vlog strukturiranih podatkov; čim bolj nedvoumno opisati, katera informacija v spletni trgovini kaj točno pomeni.
Za dobro spletno trgovino danes stoji tudi dobra podatkovna struktura
Kupca ne zanima prav zares, kako urejena je podatkovna struktura spletne trgovine. Odpre spletno trgovino, najde izdelek, vidi njegovo ceno in ga naroči. V ozadju pa se mora isti izdelek dosledno pojavljati v bazi podatkov o izdelkih, na strani, v strukturiranih podatkih in v feedu, posredovanem Googlu.
Product opisuje, za kaj gre, Offer pa, pod kakšnimi pogoji je izdelek mogoče kupiti. Merchant listing se lahko opre tudi na te podatke, ko Google pripravlja trgovski prikaz izdelkov.
V sodobni spletni trgovini zato strukturirani podatki niso naknadno nameščen SEO-dodatek, temveč prav tako del tehnične infrastrukture kot upravljanje zalog ali feed izdelkov. Tudi to je eden od pomembnih elementov Sellviovega pristopa: tehnični SEO, strukturirani podatki in zunanji kanali izdelkov so zgrajeni na istem katalogu izdelkov.
Naloga trgovca tako ni izdelovati posebnih kod za Google, temveč delati z natančnimi in doslednimi podatki o izdelkih. Če je to urejeno, je naloga tehničnega zaledja že ta, da te informacije v ustrezni obliki posreduje tja, kjer so potrebne.