Technical SEOTechninis SEO

Schema ir struktūriniai duomenys paslaugos turtingiems rezultatams

Q: Kas yra struktūrizuoti duomenys SEO srityje ir kodėl jie svarbūs?

Struktūrizuoti duomenys – tai mašininiu būdu skaitomas kodas (dažniausiai JSON-LD), kuris padeda paieškos sistemoms suprasti puslapyje pateikiamus objektus ir jų savybes. Su jų pagalba galima aprašyti produktus, pasiūlymus, organizacijas, straipsnius, vaizdo įrašus, naršymo grandines (breadcrumbs), vietos verslus ir kt. Jie svarbūs todėl, kad „Google“ naudoja šiuos signalus, kad įvertintų tinkamumą gauti išplėstus paieškos rezultatus (rich results) ir tiksliau interpretuotų puslapio kontekstą su mažiau neaiškumų. Didelėse svetainėse tai gali padėti nuosekliau pateikti produktus, kategorijas ir turinį paieškoje. Struktūrizuoti duomenys nepakeičia turinio ar nuorodų , tačiau pagerina, kaip jūsų esami puslapiai yra suprantami. Praktikoje didžiausi pokyčiai dažniausiai matomi per geresnį SERP atvaizdavimą ir didesnį paspaudimų rodiklį (CTR), o ne per staigius pozicijų šuolius.

Q: Ar schemos žymėjimas (schema markup) tiesiogiai pagerina reitingus?

Dažniausiai ne tiesiogiai, vienu žingsniu. „Google“ yra aiškiai nurodžiusi, kad struktūrizuoti duomenys pirmiausia padeda suprasti turinį ir nustatyti, ar jis gali būti tinkamas tam tikroms paieškos funkcijoms, o ne garantuoja reitingų šuolį. Praktinė nauda pasireiškia turtingesniais paieškos rezultatais, aiškesniais ryšiais tarp subjektų ir geresniu suderinimu tarp puslapio bei paieškos užklausos ypatybių, kurioms jis gali atitikti. Jei produktų puslapiai dėl to gauna geresnius merchant tipo patobulinimus ir CTR auga 15–35% , tai yra reikšminga SEO vertė net jei vidutinė pozicija keičiasi tik nežymiai. Kai kuriose svetainėse ir tvarkingesni struktūrizuoti duomenys mažina dviprasmybes dėl puslapio tipo bei turinio tikslo, o tai gali prisidėti prie platesnės techninės kokybės.

Q: Kiek kainuoja schemos ir struktūrizuotų duomenų įgyvendinimas?

Kaina priklauso nuo puslapių skaičiaus, šablonų (template’ų) kiekio, duomenų sudėtingumo ir nuo to, ar jums reikia tik audito, ar visapusiškos įgyvendinimo pagalbos. Mažesnei svetainei su 5–10 tipų puslapių dažnai užtenka kryptingo audito ir diegimo plano, o įmonės lygio e. parduotuvė su milijonais URL, produktų srautais, regioninėmis kainomis ir individualiais šablonais reikalauja gilesnio inžinerinio darbo. Skirtumas nėra tik papildomame kode—svarbiausia taisyklių apibrėžtis, kraštinių atvejų testavimas ir tai, kad klaidingas žymėjimas neišplistų. Daugumai verslų pagrindiniai kainos veiksniai yra įgyvendinimo sudėtingumas ir QA (kokybės užtikrinimo) gylis. Per pradinę konsultaciją apibrėžiu apimtis pagal šablonų skaičių, duomenų šaltinius ir diegimo riziką, kad gautumėte realų įvertinimą, o ne bendrą „paketo“ pasiūlymą.

Q: Per kiek laiko pavyksta pamatyti rezultatus įdiegus struktūrizuotus duomenis?

Paprastai patobulinimus dėl validacijos galima pastebėti jau tada, kai pataisytą žymėjimą perindeksuoja paieškos sistema. Tačiau turtingų rezultatų (rich results) pokyčiai dažnai užtrunka ilgiau ir jų galutinis laikas priklauso ne tik nuo jūsų, bet ir nuo indeksavimo bei atnaujinimų dažnio. Daugeliui svetainių pirmi aiškesni pokyčiai matomi per 2–8 savaites po įdiegimo, ypač Search Console rodikliuose. CTR pokyčiai dažniausiai tampa ryškesni po 1–3 mėnesių, kai sukaupiama pakankamai parodymų paveiktuose puslapių tipuose. Įmonių (enterprise) svetainėms procesas gali užtrukti ilgiau dėl etapinio diegimo ir skirtingų indeksavimo ciklų tarp šablonų. Rekomenduoju vertinti progresą etapais: pirmiausia validacija, tada tinkamumo aprėptis, vėliau parodymų dalis, o galiausiai CTR ir pajamų poveikis.

Q: Ar JSON-LD schema žymėjimas yra geresnis nei microdata?

Dažniausiai – taip. JSON-LD paprasčiau įdiegti, ją lengviau derinti (debuginti) ir ji rečiau „užteršia“ šabloną, kai microdata yra įterpiama tiesiog per visą HTML. Taip pat JSON-LD geriau tinka didelėms organizacijoms, kurioms reikia centralizuoti schemos logiką ir užtikrinti nuoseklų patikrinimą (QA) daugelyje šablonų. Microdata vis dar gali veikti, tačiau ją sunkiau prižiūrėti, kai dažnai keičiama priekinė (frontend) dalis arba kai skirtingos komandos redaguoja tuos pačius komponentus. Įmonėms JSON-LD paprastai yra saugesnis ir labiau pritaikomas augimui. Vienintelis trūkumas: pateikiami duomenys turi atitikti matomą turinį ir būti patikimai sugeneruojami, kitaip pats formatas nepadės, jei įgyvendinimas yra prastas.

Q: Kokie schemos tipai svarbiausi e.komercijos svetainėms?

Daugumai e.komercijos svetainių svarbiausi yra tokie schemos tipai kaip Product , Offer , AggregateRating , BreadcrumbList , Organization , o kartais – FAQ ar Video . Tikslus derinys priklauso nuo to, kokį turinį iš tikrųjų pateikia jūsų puslapiai ir ką „Google“ gali rodyti jūsų rinkoje. Produktų žymėjimas svarbus, nes jis palaiko pardavėjo skelbimų ir produkto ištraukų (snippet) tinkamumą, o breadcrumbs padeda aiškiau parodyti struktūrą ir gali pagerinti URL pateikimą paieškoje. Organization ir prekės ženklo (brand) subjektai stiprina bendrą svetainės supratimą ir nuoseklumą firminių paieškų rezultatuose. Prioritetą teikiu pagal pajamų įtaką ir šablonų apimtį, o ne pagal tai, kiek schemos tipų galima „pridėti“. Švarus „Product“ įgyvendinimas 100 000 URL dažnai duoda kur kas daugiau nei dešimt eksperimentinių tipų, išbarstytų po visą svetainę.

Q: Kaip tvarkote schemos žymėjimą dideliuose (enterprise) tinklalapiuose su milijonais URL?

Jūs to netvarkote po vieną URL. Schemos žymėjimą valdote pagal šablonų taisykles, „source-of-truth“ (vienintelio tiesos šaltinio) susiejimą, reprezentatyvų atrinkimą, automatizuotą validaciją ir išleidimo (release) valdymą. Dideliuose domenuose schemos logiką apibrėžiu pagal puslapio tipą ir kraštinius atvejus, o tada pasitelkiu robotus ir Python skriptus, kad patikrinčiau tūkstančius pavyzdžių dėl trūkstamų laukų, neteisingų reikšmių, dublikatų (pasikartojančių entitetų) bei neatitikimų matomam turiniui. Tai vienintelis praktiškas būdas užtikrinti, kad žymėjimas išliktų patikimas, kai viename domene gali būti 20 mln. sugeneruotų URL ir šimtai skirtingų šablonų būsenų. Taip pat būtina stebėsena, nes tiek feed‘o pakeitimai, tiek frontend išleidimai, tiek CMS redagavimai gali iš naujo įvesti klaidas be perspėjimo. Enterprise schemos žymėjimas yra sistema, o ne vienas snippet‘as.

Q: Ar mums reikia nuolatinės priežiūros po schemos įdiegimo?

Taip, ypač jei jūsų svetainė dažnai keičiasi. Struktūrizuoti duomenys gali „nulūžti“, kai atnaujinami šablonai, keičiamos kainodaros ar inventoriaus informacijos sklaidos (feed’ai), skirtingai tvarkomos apžvalgos arba turinio komandos publikuoja naujus puslapių formatus, kurie nebeatitinka pradinių taisyklių. Net jei žymėjimas vis dar galioja, paieškos funkcijų tinkamumo reikalavimai ir „Google“ dokumentacija gali kisti, todėl tai, kas veikė prieš dvejus metus, kartais reikia peržiūrėti. Paprastai rekomenduoju nuolatinį stebėjimą bet kuriai svetainei, kurioje yra dažni leidimai, keli regionai ar daugiau nei keli tūkstančiai svarbių URL. Priežiūra nebūtinai reiškia nuolatinį sunkų darbą, tačiau ji turėtų apimti periodinius patikrinimus, pranešimus apie klaidas ir reguliarius auditus. Taip išvengsite tyliai prarandamos išplėstų rezultatų (rich results) aprėpties.

Schema ir struktūrinių duomenų darbai nėra apie atsitiktinių JSON-LD blokų pridėjimą ir viltį, kad „Google“ parodys žvaigždes.

Įdiek Schema dabar Peržiūrėti atvejus

Šioje paslaugoje

Apžvalga Greita SEO įvertinimo užklausa Kodėl struktūrizuotų duomenų SEO svarba 2025-2026 m.Kas įtraukta Kaip tai veikia Schema žymėjimo paslauga: standartinis vs. verslo (enterprise) požiūris Pilnas struktūrizuotų duomenų kontrolinis sąrašas: ką apimame Tikri rezultatai iš schemos žymėjimo projektų Ar schema markup tinka jūsų verslui?Dažniausiai užduodami klausimai Pradėkite savo struktūrizuotų duomenų įdiegimą jau šiandien Auditas arba konsultacija Galbūt jums taip pat prireiks

Schema ir struktūrinių duomenų darbai nėra apie atsitiktinių JSON-LD blokų pridėjimą ir viltį, kad „Google“ parodys žvaigždes. Tai apie tai, kad jūsų puslapiai būtų suprantami mašinoms, atitiktų tinkamus turtingus rezultatus ir būtų nuoseklūs su tuo, kaip iš tikrųjų veikia šablonai, feed’ai, kanoniniai URL ir vidinis susiejimas. Padedu e.komercijai, SaaS, leidėjams, prekyvietėms ir tarptautiniams projektams sukurti struktūrinius duomenis, kurie atlaiko realaus masto iššūkius – nuo 100 000 puslapių iki 10M+ URL. Rezultatas – švaresnis atitikimas, stipresnis SERP pateikimas, geresnis paspaudimų rodiklis ir mažiau brangių žymėjimo klaidų visoje svetainėje.

Patirtis ir projektų rezultatai

+35%

CTR lift on enriched SERPs

↑

15+

Schema types implemented at scale

100K+

Pages deployed with validated markup

↑

<2%

Post-launch critical error rate target

Greita SEO įvertinimo užklausa

Atsakykite į 4 klausimus — gaukite personalizuotą rekomendaciją

Kokio dydžio yra jūsų svetainė?

Kokia jūsų didžiausia SEO problema šiuo metu?

Ar turite atskirą SEO komandą?

Kaip skubiai reikia pagerinti SEO?

Sužinokite daugiau

Kodėl struktūrizuotų duomenų SEO svarba 2025-2026 m.

Struktūrizuoti duomenys dabar yra svarbesni nei bet kada, nes paieškos rezultatai nebėra tik paprastos mėlynos nuorodos su pavadinimu ir išrašu. „Google“ kuria produktų išrašus, pardavėjų sąrašus, receptų korteles, straipsnių patobulinimus, duonos takelius, organizacijų skydelius ir entitetų ryšius iš mašininio skaitomo ženklinimo signalų, o silpna markup struktūra mažina jūsų tinkamumą viskam tam. Dideliuose tinklalapiuose problema dažniausiai nėra ta, kad schema visur neįdiegta; dažniau schema yra nenuosekli, pasenusi, įterpta netinkamoje vietoje arba atjungta nuo kanoninės puslapio logikos. Dažnai matau svetaines, kuriose papildinys prideda Organization schemą, tačiau produktų puslapiai vis tiek pateikia sugadintus Offer laukus, netinkamus kainų formatus arba atsiliepimus, kurie nesutampa su matomu turiniu. Tokios problemos paprastai išryškėja atliekant techninį SEO auditą, nes markup kokybė priklauso nuo šablonų, atvaizdavimo, indeksavimo ir naršymo (crawl) elgsenos. Internetinėms parduotuvėms ryšys dar glaudesnis, nes struktūrizuoti duomenys įtakoja, kaip produktai atsiranda paieškoje, ir kaip kaina, prieinamumas bei atsiliepimų informacija interpretuojama kartu su platesne eCommerce SEO strategija. Jei „Google“ negali pasitikėti jūsų puslapiuose esančiais entitetų duomenimis, jūsų sąrašai atrodo silpnesni net tada, kai reitingai išlieka stabilūs. Tai reiškia prarastus paspaudimus be akivaizdaus reitingų kritimo jūsų „dashboard“ rodikliuose.

Schemų žymėjimo nepaisymo kaina dažniausiai slepiasi tiesiog akivaizdžiai. Kategorijos puslapis gali užimti 2–4 vietas, tačiau konkurentas su galiojančiu breadcrumb (trupinių) žymėjimu, merchant listing praplėtimais ir tvarkingesniais entitetų signalais gali pelnyti paspaudimą, nes jo įrašas užima daugiau vietos vizualiai ir atsako į didesnę užklausos dalį dar prieš vartotojui nusileidžiant į svetainę. Daug produktų turinčiose svetainėse neteisingi Offer, AggregateRating ir Product žymėjimai gali tyliai panaikinti tinkamumą dešimtims tūkstančių URL, o komandos tai dažnai pastebi tik po sezoninio srauto kritimo. Taip pat mačiau, kaip įmonės remiasi bendrais pluginų nustatymais, kai konkurentai naudoja konkrečiam puslapio tipui pritaikytą žymėjimą, paremtą konkurentų ir rinkos analize. Tai leidžia jiems užfiksuoti daugiau užklausų variantų ir turėti turtingesnių branded paieškos funkcijų. Leidėjams ir dokumentacijos svetainėms prastas Article, FAQ, Video ir Breadcrumb įgyvendinimas silpnina kontekstą ir gali sumažinti, kaip aiškiai sekcijos yra interpretuojamos. Praleista proga dar labiau išauga, kai šablonai masteliuojami per kalbas ir rinkas, nes viena bloga logikos taisyklė iš karto nukopijuojama į 40 lokalių. Todėl struktūrizuoti duomenys neturėtų būti traktuojami kaip tik kosmetinė SEO užduotis ar vienkartinis programuotojo tiketas. Tai matomumo ir CTR sistema, turinti tiesioginį poveikį pajamoms.

Pranašumas yra realus, kai įgyvendinimas susiejamas su verslo logika, o ne vien schema žodynu. Per 41 eCommerce domeną, 40+ kalbų, dirbau aplinkose, kur viename domene buvo apie 20M sugeneruotų URL ir nuo 500K iki 10M indeksuotų puslapių, todėl sprendimai dėl žymėjimo turėjo atlaikyti mastą, feedų pokyčius ir šablonų atnaujinimus, nepažeidžiant veikimo. Tokiose aplinkose geriau struktūruoti duomenys buvo platesnių rezultatų dalis, pavyzdžiui, +430% matomumo augimas, 500K+ URL per dieną indeksuojami po techninių pataisymų ir 3 kartus geresnis nuskaitymo (crawl) efektyvumas, kai puslapio signalai susiderino. Įmonių parduotuvėms, marketplace’ams ir daugiakalbėms svetainėms švari schema padeda paieškos sistemoms greičiau ir su mažiau neaiškumo suprasti produktus, pasiūlymus, kategorijas, prekės ženklo (brand) esybes ir turinio tarpusavio ryšius. Tai ypač vertinga, kai derinama su tarptautiniu & daugiakalbiu SEO ir įmonių eCommerce SEO, kur nuoseklumas tarp skirtingų lokalizacijų dažnai lemia skirtumą tarp mastelį leidžiančio augimo ir pasikartojančių tvarkymo projektų. Mano požiūris – susieti tinkamumą (eligibility), patikrinti pagal realias puslapio būsenas, kiek įmanoma automatizuoti generavimą ir stebėti nukrypimus (drift) po paleidimo. Būtent taip struktūrizuoti duomenys iš „kontrolinio sąrašo“ elemento tampa našumo sistema.

Kaip taikome schemos žymėjimo (schema markup) įgyvendinimą dideliu mastu

Mano požiūris prasideda nuo paprastos taisyklės: schema markup turi aprašyti realią puslapio būseną ir tikrą už jo esantį verslo objektą. Aš nepradedu nuo plugin’ų, iš blogų įrašų nukopijuotų snippet’ų ar universalių schemų generatorių. Pradedu nuo puslapio tipų, šablonų, šaltinio-of-truth laukų ir paieškos funkcijų, kurias realiai galite įdiegti savo svetainėje. Tai svarbu, nes produkto puslapis su penkiomis variantų būsenomis, marketplace pardavėjais, regioninėmis kainomis ir dalinėmis likučio tiekimo (stock) užkandomis reikalauja kitokio įgyvendinimo nei švari reklaminė (brochure) svetainė. Daug schemų problemų iš tikrųjų yra duomenų modeliavimo problemos, todėl dažnai šį darbą derinu su Python SEO automatizavimu: ištraukti pavyzdžius, patikrinti laukus ir palyginti puslapio išvestį su numatyta verslo logika. Tikslas – ne sukurti daugiau markup; tikslas – sukurti patikimą markup. Kai Andrii Stanetskyi dirba su struktūrizuotais duomenimis, procesas remiasi praktikų apribojimais, išmoktais dirbant su enterprise eCommerce sistemomis, o ne plugin’o nustatymų ekranu.

Technologijų rinkinys priklauso nuo svetainės, tačiau procesas yra nuoseklus. Naudoju „Screaming Frog“ pasirinktinę ištrauktį (custom extraction), naršyklės atvaizdavimo (browser-rendered) nuskaitymus, „Search Console“ našumo ir tobulinimo ataskaitas, žalių HTML versijų palyginimą, šablonų atranką, logų įrodymus, kai tai aktualu, ir šaltinio lauko validavimą iš TVS (CMS) arba tiekimo (feed) eksporto. Dideliems diegimams aš kuriu patikras Python kalba, kad pažymėčiau trūkstamas privalomas savybes, neteisingas reikšmes, dubliuojamus objektus (entities), nesuderintą @id naudojimą arba neatitikimus tarp matomo turinio ir JSON-LD išvesties. Prireikus naudoju „BigQuery“, „Sheets“ pagrindu sudarytas QA matricais ir pasirinktinius validavimo skriptus, kad peržiūrėčiau tūkstančius URL, o ne atlikčiau dvidešimties puslapių patikrinimą „iš akies“ ir spėliočiau. Ataskaitos siejamos su poveikiu per SEO ataskaitos ir analitika, kad komanda matytų aprėptį, klaidų mažėjimą, rich result įspūdžius ir CTR pokyčius pagal puslapio tipą. Čia taip pat svarbi patirtis su 10M+ URL architektūra: negalite rankiniu būdu QA atlikti schemos milžiniškame domene, ir negalite pasitikėti paleidimu be reprezentatyvios atrankos logikos. Geras struktūruotų duomenų darbas yra ir inžinerija, ir SEO, ir valdymas (governance).

Dirbtinis intelektas yra naudingas šiame darbo procese, bet tik tinkamose vietose. Naudoju Claude ir GPT modelius, kad padėtų schema taisyklių dokumentavime, atributų (property) susiejime, didelių validavimo išvadų (validation outputs) modelių aptikime ir greitesniame techninių įgyvendinimo pastabų juodraščių rengime kūrėjams. Aš neperduodu gamybinio (production) žymėjimo dizaino modeliui ir nesitikiu, kad jis supras jūsų CMS išimtis (edge cases), vietinio inventoriaus logiką ar variantų architektūrą. Vietoje to, AI veikia žmogaus peržiūrimo proceso viduje — dažniausiai kartu su AI & LLM SEO workflow’ais, kur užklausos (prompts) yra apribotos pagal realius puslapių pavyzdžius, schema.org specifikacijas ir numatomus išvesties formatus. Tai gali reikšmingai sutrumpinti dokumentavimo laiką ir prisidėti prie dalies iš manęs pasiektos 80% rankinio darbo sumažinimo automatizuotose SEO operacijose. Taip pat tai padeda QA komandoms dideliu mastu klasifikuoti įspėjimus, atskirti nekenksmingus praleidimus nuo tinkamumo (eligibility) blokatorių ir kurti pakartojamus leidimo (release) patikrinimus. Tačiau galutinis patvirtinimas visada gaunamas atliekant validaciją pagal realius URL, realiai atvaizduotą turinį ir realius verslo duomenis. Būtent tai ir skiria AI naudojimą kaip pagalbą nuo jo naudojimo kaip pakaitalo techniniam sprendimui.

Skalė keičia viską diegiant schemą. 500 puslapių svetainė gali išgyventi tam tikrus markup neatitikimus; tačiau rinkoje su milijonais URL tai neįmanoma. Kai dirbate su filtruota navigacija (faceted navigation), lokalizuotais domenais, JavaScript atvaizdavimu, šablonų paveldėjimu ir skirtingomis indeksavimo būsenomis, jums reikia struktūrizuotų duomenų taisyklių, kurios būtų kuriamos pirmiausia pagal architektūrą. Štai kodėl ši paslauga dažnai sutampa su svetainės architektūra & URL struktūra ir svetainės kūrimas + SEO, ypač kai komandos perprojektuoja šablonus ar migruoja platformas. Jei canonical nurodo vieną kryptį, hreflang – kitą, o schema aprašo trečią puslapio versiją, „Google“ gauna prieštaringus signalus ir jūsų patobulinimai tampa nestabilūs. Daug kalbų turinčiose svetainėse taip pat tikrinu kalbą, valiutą, regioninį pasiekiamumą ir esybių nuoseklumą ta pačia disciplina, kuri naudojama tarptautiniame & daugiakalbiame SEO. Rezultatas – ne tik galiojantis markup paleidimo dieną, bet ir sistema, kuri ir toliau veikia svetainei augant.

„Enterprise“ schemos žymėjimo paslaugos: kaip iš tikrųjų atrodo tikras struktūrizuotų duomenų žymėjimas

Standartiniai taisyklingo struktūrizuoto duomenų pateikimo sprendimai nepavyksta įmonių (enterprise) mastu, nes jie remiasi prielaida, kad puslapis yra fiksuotas objektas. Iš tikrųjų įmonių svetainės puslapiai surenkami iš kelių sistemų: CMS turinio, kainodaros srautų (pricing feeds), inventoriaus paslaugų, atsiliepimų platformų, merchandising (prekių pateikimo) logikos, lokalizavimo sluoksnių ir frontend atvaizdavimo (rendering) sistemų. Kiekviena iš šių sistemų gali sukelti neatitikimų tarp to, ką mato vartotojas, ir to, ką deklaruoja markup. Svetainėje su milijonais URL net 2% klaidų gali reikšti dešimtis tūkstančių negaliojančių puslapių, ir tai dar neatsižvelgiant į regioninius skirtumus, senas (legacy) šablonų versijas ir crawl budget apribojimus. Mačiau situacijas, kai prekybininkai pateikia Product markup filtruotuose kategorijų puslapiuose, Article markup plonuose (thin) žymų (tag) puslapiuose, o Offer reikšmės valandoms lieka „pasenusios“, nes buvo įkeltos iš talpyklos (cached) po to, kai pasikeitė atsargos. Tai ne smulkios QA klaidos; tai pasitikėjimo klausimai, dėl kurių „Google“ tampa mažiau užtikrinta jūsų puslapio signalais apskritai. Įmonių schema darbas reiškia taisyklių sukūrimą netobuloms sistemoms ir dokumentavimą, kas turėtų nutikti, kai šaltinio duomenys yra neišsamūs.

Būtent čia tampa būtini pasirinktiniai įrankiai. Dažnai kuriu Python skriptus, kurie nuskenuoja reprezentatyvių URL rinkinius, išanalizuoja JSON-LD blokus, normalizuoja reikšmes ir palygina jas su puslapio laukais, eksportais ar backend pavyzdžiais, kad pastebėtų pokyčius (drift), kol tai nepadaro „Google“. Itin didelėse svetainėse tai gali paversti rankinę peržiūros užduotį, kuri užtruktų dienas, automatizuota ataskaita, parengta per kelias minutes—tai palaiko tą patį 80% rankinio darbo sumažinimo principą, kurį jau esu pasiekęs platesnėse SEO operacijose. Dėl labai šabloniškų svetainių struktūrų taip pat kuriu puslapio tipo (page-type) informacijos skydus, kurie parodo galiojančią aprėptį, trūkstamas privalomas savybes, dubliuotas entitetų (duplicate entities) versijas ir įdiegimo variacijas pagal aplanką, kalbą (locale) ar šablono versiją. Kai verslas kuria didelius landing page rinkinius arba URL, kuriami pagal feed’us, tai dažnai sutampa su programmatic SEO enterprise, nes žymėjimo (markup) logika turi augti kartu su puslapių generavimo logika. Tas pats galioja ir produktų gausiose el. parduotuvėse, kur schema turi išlikti suderinta su indeksavimo tikslais, susijusiais su website SEO promotion. Pasirinktinis validavimas užtikrina, kad struktūriniai duomenys laikui bėgant tyliai neprastėtų. Be jo komandos dažniausiai problemas pastebi tik tada, kai sumažėja rich result aprėptis.

Struktūrizuotų duomenų projektai taip pat sėkmingi arba nesėkmingi priklausomai nuo to, kaip gerai jie atitinka komandos veiklos modelį. Kūrėjams reikia tikslių priėmimo kriterijų, o ne miglotų SEO pastabų, pvz., „pridėkite schemą“. Turinį rengiančios komandos turi žinoti, kurie laukai yra būtini tinkamumui, kaip matomas tekstas daro įtaką žymėjimui (markup), ir kada negalima skelbti vietos žymų (placeholder). Produktų vadovams svarbu suprasti, kodėl sprendimas dėl šablono, pavyzdžiui, įvertinimų (reviews) įkėlimas asinchroniškai arba keičiamas breadcrumb logika, gali paveikti paieškos pateikimą. Todėl paprastai dirbu kaip „įkomponuotas“ partneris su kūrėjais, analitikais ir redaktoriais, o ne tiesiog pristatau PDF ir dingstu. Dokumentacija, leidimų (release) pastabos ir trumpos apmokymo sesijos dažnai tokios pat svarbios kaip pats kodas, ypač organizacijose, kur struktūrizuoti duomenys liečia kelias komandas (squads). Tai puikiai dera su SEO komandos mokymais ir SEO mentoriaus konsultacijomis, nes ilgalaikė sėkmė priklauso nuo vidinio supratimo. Geriausias įgyvendinimas yra toks, kurį jūsų komanda gali palaikyti po pirmojo paleidimo.

Struktūrizuotų duomenų rezultatai yra kaupiami, tačiau jie nėra magiški ar akimirksniu pasiekiami. Pirmąsias 30 dienų pagrindiniai laimėjimai dažniausiai yra švaresnis validavimas, mažiau plėtinio (enhancement) klaidų ir atkurta tinkamumo (eligibility) būsena svarbiniuose šablonuose. Po 60–90 dienų galite pradėti matyti stipresnius „rich result“ įspūdžius, stabilesnę produktų plėtinio (product enhancement) aprėptį ir CTR pagerėjimus puslapių tipuose, kur žymėjimas dabar atitinka paieškos ketinimą. Po 6 mėnesių nauda tampa aiškesnė, kai struktūrizuoti duomenys integruojami į platesnes SEO sistemas, tokias kaip SEO curation & monthly management, turinio tobulinimus ir techninius pataisymus. Per 12 mėnesių geriausi rezultatai pasiekiami taikant valdymą: išleidimų (release) patikras, stebėseną ir periodinį plėtimą į naujų tipų schemą, kai svetainė yra tam pasirengusi. Atsižvelgdamas į tai, lūkesčius suformuluoju aiškiai: vien schema nepadarys stebuklų silpnam turiniui ar prastai architektūrai, tačiau ji gali reikšmingai pagerinti, kaip jūsų stipriausi puslapiai yra suprantami ir pateikiami. Tinkami metrikai, kuriuos verta stebėti: tinkamumo aprėptis (eligibility coverage), „rich result“ įspūdžiai, CTR pagal puslapio tipą, klaidų (error) kritiškumas (severity) ir pajamų indėlis iš praturtintų (enriched) įrašų.

Rezultatai

Kas įtraukta

01 Struktūruotų duomenų auditas, kuris identifikuoja trūkstamas schemas, netinkamas savybes, tinkamumo spragas ir šablonų lygmens konfliktus, kad tiksliai žinotumėte, kas blokuoja rich rezultatus.

02 Puslapio tipo galimybių žemėlapis, kuris pagal pajamas ir paieškos paklausą prioritetizuoja Product, Breadcrumb, Article, Organization, FAQ, Video, LocalBusiness ir kitus schemas tipus.

03 Schema architektūros dizainas, kuris suderina žymėjimą su kanoniniais reikalavimais, indeksuojamumu, puslapiavimu, filtruojama navigacija, hreflang ir puslapio intencija, o ne traktuoja tai kaip izoliuotą kodą.

04 JSON-LD generavimo logika šablonams, dinamiškam atvaizdavimui ar serverio išvedimui, kad žymėjimas išliktų stabilus tarp leidimų ir didelių URL rinkinių.

05 Validavimo procesai, kurie tikrina privalomų ir rekomenduojamų savybių atitiktį, matomo turinio lygiavertiškumą, feed lygiavertiškumą ir klaidų grėsmingumą dar prieš tai, kai diegimas pasiekia produkciją.

06 Rich rezultatų tinkamumo analizė, kuri atskiria tai, kas techniškai galioja, nuo to, kas realisti labiausiai tikėtina pasirodyti jūsų nišoje ir konkrečiuose puslapio tipuose.

07 Prekiautojo ir produkto signalų suderinimas, kuris užtikrina, kad kaina, prieinamumas, prekės ženklas, GTIN ir atsiliepimų duomenys būtų sinchronizuoti tarp puslapio žymėjimo, feed'ų ir on-page turinio.

08 Daugiakalbių ir daugiarinkinių schemų planavimas, kuris apdoroja lokalizuotas valiutas, kalbos variacijas, regioninį prieinamumą ir atitinkamo subjekto nuoseklumą 40+ kalbų.

09 Stebėjimo informacijos panelės ir įspėjimai dėl schemų klaidų, įspėjimų, žymėjimo nukrypimų ir rich rezultatų aprėpties pokyčių per crawl duomenis, Search Console ir pasirinktinius patikrinimus.

10 Įgyvendinimo dokumentacija kūrėjams, QA komandoms ir SEO suinteresuotiesiems asmenims, kad žymėjimas išliktų lengvai prižiūrimas po paleidimo, o netaptų dar vienu trapiu SEO pataisu.

Procesas

Kaip tai veikia

Etapas 01

1 etapas: Auditas, tinkamumo susiejimas ir prioritetų nustatymas

1-ąją savaitę peržiūriu esamą schemą pagal puslapio tipą, šabloną ir rinką, kad nustatyčiau, kas trūksta, kas yra neteisinga ir ką apskritai neverta daryti. Lyginu žymėjimą su matomu turiniu, kanoninėmis būsenomis ir paieškos funkcijų potencialu, kad kelio planas atspindėtų realią verslo vertę, o ne schemų pageidavimų sąrašą. Rezultatas – prioritetinė matrica, kurioje pateikiami puslapių tipai, rekomenduojama schema, rizikos lygis, priklausomybės ir numatomas poveikis aprėpčiai bei CTR.

Etapas 02

2 etapas: Duomenų modelis ir įgyvendinimo dizainas

2 savaitę apibrėžiu taisykles pagal lauką, šaltinio laukus, atsarginio apdorojimo logiką ir išvesties sąlygas kiekvienam schemos tipui. Tai apima tokius sprendimus kaip kada Product turėtų būti paslėptas, kaip turėtų būti tvarkomas AggregateRating, kaip variantai atvaizduojami į Offer ir kaip Breadcrumb arba Organization subjektai turėtų būti nurodomi su stabiliais ID. Rezultatas – įgyvendinimo dokumentacija kūrėjams bei QA pavyzdžiai galimiems, kraštiniams atvejams ir puslapiams, kurie neįtraukiami.

Etapas 03

3 etapas: diegimo QA ir validacija

3–4 savaitėmis komanda diegia žymėjimą į testavimo aplinką arba kontroliuojamas gamybos partijas, o aš tai patikrinu per nuskaitymus, atvaizdavimo (rendering) patikras, pavyzdines eksportų operacijas ir tinkamumo (eligibility) peržiūras. Testuoju tiek įprastus URL, tiek kraštinius atvejus: pvz., prekes neturinčius (out-of-stock) produktus, puslapiuojamas kategorijas, noindex puslapius, alternatyvias lokalizacijas ir per JavaScript įterptas būsenas. Rezultatas – paleidimo (launch) patvirtinimo ataskaita su kritiniais pataisymais, įspėjimais ir paleidimo į gamybą sąlygomis.

Etapas 04

4 etapas: stebėsena, iteracijos ir valdymas

Po paleidimo stebiu Search Console patobulinimus, rich result pasirodymus, CTR pagal puslapio tipą ir žymėjimo (markup) pokyčius, kuriuos sukelia šablonų atnaujinimai ar feed'o pakeitimai. Jei svetainė didelė, paprastai pridedu automatizuotus periodinius patikrinimus, kad kritinės nuosavybės būtų testuojamos nuolat, o ne tik po kito srauto sumažėjimo. Rezultatas – nuolatinės stebėsenos nustatymas ir ateities patobulinimų backlog'as, dažnai integruojamas į mėnesinį SEO valdymą.

Palyginimas

Schema žymėjimo paslauga: standartinis vs. verslo (enterprise) požiūris

Matmenys

Standartinis požiūris

Mūsų požiūris

„Discovery“

„Patikrina kelias URL adresų validatoriuje ir rekomenduoja bendro pobūdžio schemos tipus.“

„Žemėlapiškai išgrynina schemos galimybes pagal šabloną, indeksavimo būseną, verslo vertę ir faktinę tinkamumą gauti praplėstus (rich) rezultatus.“

Įgyvendinimo metodas

Prideda įskiepio numatytuosius nustatymus arba įterpia kietai užkoduotas ištraukas, neplanuojant pagal vieną tiesos šaltinį.

Sukuria JSON-LD taisykles, susietas su TVS (CMS) laukais, produktų feed’ais, kanonine logika ir atsarginėmis (fallback) sąlygomis.

QA gylis

Patikrina kelis pavyzdinius puslapius prieš paleidimą.

Vykdo šliaužiklio (crawl) pagrįstą atranką, kraštinių atvejų testavimą ir automatinius nuosavybių patikrinimus didelėse URL aibėse.

Mastelio palaikymas

Sugenda, kai šablonai skiriasi pagal lokalę, variantų būseną arba atvaizdavimo metodą.

Aptarnauja daugiakalbį turinį, srautais (feed) paremtą struktūrą, JavaScript reikalaujančias sistemas ir 10 mln.+ URL architektūras su pakartojamomis taisyklėmis.

Matavimas

Ataskaitos, kad schema buvo pridėta, turint mažai įrodymų apie verslo poveikį.

Stebi tobulinimų aprėptį, išsamių rezultatų (rich results) įspūdžius, paspaudimų rodiklį (CTR), klaidų tendencijas ir šablono nukrypimus laikui bėgant.

Valdymas

Traktuojama schema kaip vienkartinė užduotis po paleidimo.

Sukuriama dokumentacija, leidimo patikros ir stebėsena, kad žymėjimas išliktų galiojantis, kai svetainė tobulėja.

Kontrolinis sąrašas

Pilnas struktūrizuotų duomenų kontrolinis sąrašas: ką apimame

✓ „Product“, „Offer“ ir „AggregateRating“ tinkamumas pajamoms skatinančiuose šablonuose, nes netinkamas commerce žymėjimas gali pašalinti galimybę gauti turtingus rezultatus tūkstančiuose sąrašų. KRITINIS
✓ Atitikmuo su matomu puslapio turiniu: kadangi JSON-LD teiginiai, kurių naudotojai nemato, kelia nepasitikėjimą ir gali panaikinti patobulinimus. KRITINIS
✓ Kanoninių, hreflang ir schemos suderinimas, nes skirtingi signalai tarp puslapio versijų mažina aiškumą indeksavimui ir subjektų (entity) interpretavimui. KRITINIS
✓ Breadcrumb (trupinių) struktūra ir vidinės hierarchijos nuorodos, kurios padeda „Google“ suprasti puslapio vietą ir pagerina ištraukų aiškumą kategorijoms bei straipsniams.
✓ Stabilūs subjektų ID ir pakartotinai naudojamos nuorodos Organization, Brand, Product ir Article entitetams, siekiant išvengti dubliuojamo ar fragmentuoto grafo interpretavimo.
✓ Kalbos nustatymams būdingos reikšmės, tokios kaip valiuta, prieinamumas, kalba ir regioninio pristatymo kontekstas tarptautiniuose šablonuose.
✓ Šablonų išimtys, skirtos noindex, dubliuojamoms, plonoms arba pagal fasetus filtruojamoms (faceted) puslapio versijoms, kad schema nebūtų generuojama ten, kur ji kelia daugiau painiavos nei prideda vertės.
✓ Peržiūrėkite pateikimo (rendering) metodą, kad patvirtintumėte, jog „Google“ nuosekliai mato žymėjimą SSR, CSR ir hibridinėse aplinkose.
✓ „Search Console“ tobulinimo aprėptis, įspėjimų klasifikacija ir tendencijų analizė, kad triukšmą atskirtumėte nuo realių kliūčių.
✓ Po paleidimo vykdykite stebėseną ir įspėjimus dėl žymėjimo (markup) pokyčių, kuriuos sukelia CMS atnaujinimai, tiekimo (feed) pakeitimai arba priekinės dalies (frontend) leidimai.

Rezultatai

Tikri rezultatai iš schemos žymėjimo projektų

Įmonių elektronikos mažmeninė prekyba

+31% organinis CTR į produkto URL per 4 mėnesius

Svetainėje buvo 2,4 mln. produktų ir variantų URL, tačiau produkto žymėjimas (Product markup) buvo nevienodas tarp šablonų ir dažnai nesutapo su matomais kainos ir atsargų duomenimis. Įgyvendinimą perdariau pagal šablonui būdingas JSON-LD taisykles, užtikrinau tiekimo (feed) lygiavertiškumo patikras ir sustiprinau QA kaip platesnio eCommerce SEO sutvarkymo dalį. Kritinių klaidų skaičius, kuris anksčiau siekė dviženklį procentą, sumažėjo iki mažiau nei 2% svarbiausiuose šablonuose, stabilizavosi prekybininko (merchant) sąrašų tinkamumas, o produkto puslapių CTR padidėjo 31% — nepasikliaujant vien pozicijų (rank) augimu.

Daugiakalbė prekyvietė

Po išleidimo apdorota 500 tūkst.+ tinkamų URL per dieną

Ši prekyvietė veikė 18 kalbų aplinkose ir turėjo didelių nenuoseklumų tarp lokalizuotų kainų, prieinamumo pranešimų ir schemos išvesties. Aš sujungiau schemos perprojektavimą su svetainės architektūra ir URL struktūra bei tarptautiniu ir daugiakalbiu SEO, kad kiekviena rinka pateiktų teisingus subjekto ir pasiūlymo duomenis. Kai išleidimas ir validacija buvo baigti, „Google“ pradėjo nuosekliau apdoroti gerokai daugiau tinkamų puslapių, išplėstų rezultatų aprėptis tapo stabilesnė, o komanda pagaliau turėjo pakartojamą būdą patikrinti (QA) naujas rinkas prieš paleidimą.

B2B SaaS dokumentacijos platforma

+57% turtingų rezultatų įspūdžiai per 3 mėnesius

Dokumentacijos hubas naudojo bendrinę pluginų žymėjimo sintaksę, kuri beveik kiekvieną puslapį žymėjo vienodai — tai susilpnino aiškumą apie subjektus ir lėmė silpnus signalus straipsnio lygiu. Tiksliau susiejau puslapių intenciją, įdiegiau tvarkingą Breadcrumb, Article, Organization ir SoftwareApplication žymėjimą bei suderinau diegimą su platesne SaaS SEO strategija ir turinio strategijos bei optimizavimo darbais. Rezultatas — 57% didesni turtingų rezultatų įspūdžiai, nuoseklesni su prekės ženklu susiję žinių signalai ir didesnis CTR didelės intencijos dokumentacijos puslapiuose.

Susiję atvejų tyrimai

4× Growth

SaaS

Cybersecurity SaaS International

From 80 to 400 visits/day in 4 months. International cybersecurity SaaS platform with multi-market S...

0 → 2100/day

Marketplace

Used Car Marketplace Poland

From zero to 2100 daily organic visitors in 14 months. Full SEO launch for Polish auto marketplace....

10× Growth

eCommerce

Luxury Furniture eCommerce Germany

From 30 to 370 visits/day in 14 months. Premium furniture eCommerce in the German market....

Andrii Stanetskyi

Head of SEO / Technical SEO Lead

11 metų sprendžiant SEO problemas kiekvienoje srityje — eCommerce, SaaS, medicinoje, marketplace‘uose, paslaugų versle. Nuo individualių auditų startuoliams iki kelių domenų įmoninių sprendimų valdymo. Rašau Python, kuriu dashboard’us ir atsakau už rezultatą. Jokių tarpininkų, jokių paskyrimų vadybininkų — tiesioginė prieiga tam, kas atlieka darbą.

200+

Įgyvendinti projektai

Industrijos

40+

Padengtos kalbos

11+

Metai SEO

Tinkamumo patikra

Ar schema markup tinka jūsų verslui?

Dideli e.komercijos parduotuvių katalogai su produktų, kategorijų ir prekės ženklų šablonais, kurie jau užima pozicijas, tačiau nepasiekia pakankamai aukšto paspaudimų rodiklio. Jei jūsų skelbimuose trūksta kainodaros, aiškumo dėl prieinamumo arba nuoseklių „breadcrumb“ (trupinių) patobulinimų, struktūrizuoti duomenys gali esamas pozicijas paversti didesniu srautu. Dažniausiai tai geriausiai veikia, kai derinama su enterprise eCommerce SEO arba puslapio greičio & Core Web Vitals optimizavimu.

Turgavietės ir portalus primenančios svetainės, kuriose kuriami milijonai URL’ų iš kanalų, pardavėjų pateiktos informacijos ar inventoriaus sistemų. Šioms įmonėms reikia schemos taisyklių, kurios atsižvelgtų į dublikatus, pardavėjų variacijas, neprieinamus (ne-busidimus) produktų būsenas ir lokalizaciją, o ne į bendrinį papildinį. Dažnai jos taip pat puikiai tinka portal & marketplace SEO ir žurnalo failų analizės.

SaaS įmonės, leidėjai ir žinių bazių valdytojai, kurie nori aiškesnių entitetų signalų, geresnio turinio interpretavimo ir stipresnio prekės ženklo paieškos pateikimo. Jei dokumentacija, straipsniai, vaizdo įrašai ar „kaip tai padaryti“ tipo turinys yra pagrindinis įsigijimo šaltinis, struktūrizuoti duomenys padeda paieškos sistemoms suprasti, kas tiksliai yra kiekvienas puslapis. Poveikis yra didžiausias, kai jį papildo raktinių žodžių tyrimai ir strategija bei turinio strategija ir optimizavimas.

Tarptautiniai prekių ženklai, valdantys daug skirtingų kalbų, valiutų ir regioninių svetainių versijų. Šios komandos turi naudoti žymėjimą, kuris atsižvelgia į kalbos variantus, vietos verslo duomenis, regioninius pasiūlymus ir šablonų paveldėjimą tarp rinkų. Jiems ypač tinka sprendimai, kai struktūrizuotų duomenų (schema) darbai integruojami su tarptautiniu & daugiakalbiu SEO ir nuolatiniu SEO ataskaitų teikimu & analitika.

Netinka jums?

Labai mažas brošiūros tipo svetainės puslapis su keliais statiniais puslapiais ir nėra jokio reikšmingo paieškos poreikio turtingesnių rezultatų (rich results) praplėtimui. Tokiu atveju pirmiausia rinkitės svetainės kūrimą + SEO arba išsamų SEO auditą, o tik tada investuokite į gilesnius struktūrizuotų duomenų sprendimus.

Komandos, ieškančios dirbtinių atsiliepimų žvaigždučių, žymėjimo, kuris nesutampa su matomu turiniu, arba trumpesnių kelių, kurie nepaiso „Google“ gairių. Tai nėra tvarus SEO; jei pagrindinė problema yra silpni pamatai, pradėkite nuo techninio SEO audito arba SEO konsultavimo ir mentoriaus paslaugų.

DUK

Dažniausiai užduodami klausimai

Struktūrizuoti duomenys – tai mašininiu būdu skaitomas kodas (dažniausiai JSON-LD), kuris padeda paieškos sistemoms suprasti puslapyje pateikiamus objektus ir jų savybes. Su jų pagalba galima aprašyti produktus, pasiūlymus, organizacijas, straipsnius, vaizdo įrašus, naršymo grandines (breadcrumbs), vietos verslus ir kt. Jie svarbūs todėl, kad „Google“ naudoja šiuos signalus, kad įvertintų tinkamumą gauti išplėstus paieškos rezultatus (rich results) ir tiksliau interpretuotų puslapio kontekstą su mažiau neaiškumų. Didelėse svetainėse tai gali padėti nuosekliau pateikti produktus, kategorijas ir turinį paieškoje. Struktūrizuoti duomenys nepakeičia turinio ar nuorodų, tačiau pagerina, kaip jūsų esami puslapiai yra suprantami. Praktikoje didžiausi pokyčiai dažniausiai matomi per geresnį SERP atvaizdavimą ir didesnį paspaudimų rodiklį (CTR), o ne per staigius pozicijų šuolius.

Dažniausiai ne tiesiogiai, vienu žingsniu. „Google“ yra aiškiai nurodžiusi, kad struktūrizuoti duomenys pirmiausia padeda suprasti turinį ir nustatyti, ar jis gali būti tinkamas tam tikroms paieškos funkcijoms, o ne garantuoja reitingų šuolį. Praktinė nauda pasireiškia turtingesniais paieškos rezultatais, aiškesniais ryšiais tarp subjektų ir geresniu suderinimu tarp puslapio bei paieškos užklausos ypatybių, kurioms jis gali atitikti. Jei produktų puslapiai dėl to gauna geresnius merchant tipo patobulinimus ir CTR auga 15–35%, tai yra reikšminga SEO vertė net jei vidutinė pozicija keičiasi tik nežymiai. Kai kuriose svetainėse ir tvarkingesni struktūrizuoti duomenys mažina dviprasmybes dėl puslapio tipo bei turinio tikslo, o tai gali prisidėti prie platesnės techninės kokybės.

Kaina priklauso nuo puslapių skaičiaus, šablonų (template’ų) kiekio, duomenų sudėtingumo ir nuo to, ar jums reikia tik audito, ar visapusiškos įgyvendinimo pagalbos. Mažesnei svetainei su 5–10 tipų puslapių dažnai užtenka kryptingo audito ir diegimo plano, o įmonės lygio e. parduotuvė su milijonais URL, produktų srautais, regioninėmis kainomis ir individualiais šablonais reikalauja gilesnio inžinerinio darbo. Skirtumas nėra tik papildomame kode—svarbiausia taisyklių apibrėžtis, kraštinių atvejų testavimas ir tai, kad klaidingas žymėjimas neišplistų. Daugumai verslų pagrindiniai kainos veiksniai yra įgyvendinimo sudėtingumas ir QA (kokybės užtikrinimo) gylis. Per pradinę konsultaciją apibrėžiu apimtis pagal šablonų skaičių, duomenų šaltinius ir diegimo riziką, kad gautumėte realų įvertinimą, o ne bendrą „paketo“ pasiūlymą.

Paprastai patobulinimus dėl validacijos galima pastebėti jau tada, kai pataisytą žymėjimą perindeksuoja paieškos sistema. Tačiau turtingų rezultatų (rich results) pokyčiai dažnai užtrunka ilgiau ir jų galutinis laikas priklauso ne tik nuo jūsų, bet ir nuo indeksavimo bei atnaujinimų dažnio. Daugeliui svetainių pirmi aiškesni pokyčiai matomi per 2–8 savaites po įdiegimo, ypač Search Console rodikliuose. CTR pokyčiai dažniausiai tampa ryškesni po 1–3 mėnesių, kai sukaupiama pakankamai parodymų paveiktuose puslapių tipuose. Įmonių (enterprise) svetainėms procesas gali užtrukti ilgiau dėl etapinio diegimo ir skirtingų indeksavimo ciklų tarp šablonų. Rekomenduoju vertinti progresą etapais: pirmiausia validacija, tada tinkamumo aprėptis, vėliau parodymų dalis, o galiausiai CTR ir pajamų poveikis.

Dažniausiai – taip. JSON-LD paprasčiau įdiegti, ją lengviau derinti (debuginti) ir ji rečiau „užteršia“ šabloną, kai microdata yra įterpiama tiesiog per visą HTML. Taip pat JSON-LD geriau tinka didelėms organizacijoms, kurioms reikia centralizuoti schemos logiką ir užtikrinti nuoseklų patikrinimą (QA) daugelyje šablonų. Microdata vis dar gali veikti, tačiau ją sunkiau prižiūrėti, kai dažnai keičiama priekinė (frontend) dalis arba kai skirtingos komandos redaguoja tuos pačius komponentus. Įmonėms JSON-LD paprastai yra saugesnis ir labiau pritaikomas augimui. Vienintelis trūkumas: pateikiami duomenys turi atitikti matomą turinį ir būti patikimai sugeneruojami, kitaip pats formatas nepadės, jei įgyvendinimas yra prastas.

Daugumai e.komercijos svetainių svarbiausi yra tokie schemos tipai kaip Product, Offer, AggregateRating, BreadcrumbList, Organization, o kartais – FAQ ar Video. Tikslus derinys priklauso nuo to, kokį turinį iš tikrųjų pateikia jūsų puslapiai ir ką „Google“ gali rodyti jūsų rinkoje. Produktų žymėjimas svarbus, nes jis palaiko pardavėjo skelbimų ir produkto ištraukų (snippet) tinkamumą, o breadcrumbs padeda aiškiau parodyti struktūrą ir gali pagerinti URL pateikimą paieškoje. Organization ir prekės ženklo (brand) subjektai stiprina bendrą svetainės supratimą ir nuoseklumą firminių paieškų rezultatuose. Prioritetą teikiu pagal pajamų įtaką ir šablonų apimtį, o ne pagal tai, kiek schemos tipų galima „pridėti“. Švarus „Product“ įgyvendinimas 100 000 URL dažnai duoda kur kas daugiau nei dešimt eksperimentinių tipų, išbarstytų po visą svetainę.

Jūs to netvarkote po vieną URL. Schemos žymėjimą valdote pagal šablonų taisykles, „source-of-truth“ (vienintelio tiesos šaltinio) susiejimą, reprezentatyvų atrinkimą, automatizuotą validaciją ir išleidimo (release) valdymą. Dideliuose domenuose schemos logiką apibrėžiu pagal puslapio tipą ir kraštinius atvejus, o tada pasitelkiu robotus ir Python skriptus, kad patikrinčiau tūkstančius pavyzdžių dėl trūkstamų laukų, neteisingų reikšmių, dublikatų (pasikartojančių entitetų) bei neatitikimų matomam turiniui. Tai vienintelis praktiškas būdas užtikrinti, kad žymėjimas išliktų patikimas, kai viename domene gali būti 20 mln. sugeneruotų URL ir šimtai skirtingų šablonų būsenų. Taip pat būtina stebėsena, nes tiek feed‘o pakeitimai, tiek frontend išleidimai, tiek CMS redagavimai gali iš naujo įvesti klaidas be perspėjimo. Enterprise schemos žymėjimas yra sistema, o ne vienas snippet‘as.

Taip, ypač jei jūsų svetainė dažnai keičiasi. Struktūrizuoti duomenys gali „nulūžti“, kai atnaujinami šablonai, keičiamos kainodaros ar inventoriaus informacijos sklaidos (feed’ai), skirtingai tvarkomos apžvalgos arba turinio komandos publikuoja naujus puslapių formatus, kurie nebeatitinka pradinių taisyklių. Net jei žymėjimas vis dar galioja, paieškos funkcijų tinkamumo reikalavimai ir „Google“ dokumentacija gali kisti, todėl tai, kas veikė prieš dvejus metus, kartais reikia peržiūrėti. Paprastai rekomenduoju nuolatinį stebėjimą bet kuriai svetainei, kurioje yra dažni leidimai, keli regionai ar daugiau nei keli tūkstančiai svarbių URL. Priežiūra nebūtinai reiškia nuolatinį sunkų darbą, tačiau ji turėtų apimti periodinius patikrinimus, pranešimus apie klaidas ir reguliarius auditus. Taip išvengsite tyliai prarandamos išplėstų rezultatų (rich results) aprėpties.

Kiti žingsniai

Pradėkite savo struktūrizuotų duomenų įdiegimą jau šiandien

Jei jūsų svetainė jau turi pozicijas, tačiau SERP pateikimas yra silpnesnis, nei turėtų būti, struktūrizuoti duomenys dažnai yra vienas aiškiausių techninių pataisymų, turintis pamatuojamą naudą. Tinkamai įdiegus, jūsų puslapius Google lengviau supras, jie bus labiau tinkami naudingiems paieškos patobulinimams ir atsparesni keičiantis šablonams bei vykdant tarptautinius diegimus. Jūs neieškote copywriter’io, kuris šemą išmoko iš dokumentacijos santraukų — dirbate su Andrii Stanetskyi, vyresniuoju SEO strategu, turinčiu 11+ metų patirtį įmonių eCommerce SEO srityje, praktiškai atsakingu už 41 domeną 40+ kalbų, ir giliai išmanančiu 10M+ URL architektūrą. Šis pagrindas svarbus, nes iššūkis dažniausiai nėra „pridėti“ žymėjimą vieną kartą. Iššūkis — sukurti žymėjimą, kuris išlieka tikslus masteliuojant, automatizuojant ir nuolat vykstant paleidimų ciklams. Būtent čia techninis SEO, Python automatizavimas ir AI pagalba atliekant QA tampa praktiškais pranašumais, o ne skambiais žodžiais.

Pirmas žingsnis – darbinė sesija, kurios metu peržiūriu jūsų puslapių tipus, esamą žymėjimo (markup) išvestį, „Search Console“ praturtinimo duomenis ir verslo puslapius, kuriuose labiausiai reikėtų geresnio SERP pateikimo. Jei susisieksite, paprastai paprašysiu nedidelio URL pavyzdžio pagal šabloną, prieigos prie „Search Console“, jei ji yra, ir bet kokios turimos dokumentacijos apie feed’us ar CMS laukus. Tada galėsiu pasakyti, ar jums reikia koncentruoto audito, pilnos įgyvendinimo pagalbos, ar platesnio techninio įsitraukimo, apimančio susijusias sritis, pvz. techninis SEO auditas, svetainės kūrimas + SEO, arba SEO kuravimas ir mėnesinis valdymas. Dauguma projektų nuo susipažinimo etapo iki pirmo praktiškai įgyvendinamo rezultato gali pereiti per kelias dienas, o ne savaites. Tikslas – greitai pašalinti neapibrėžtumą ir suteikti jūsų komandai aiškų kelią į patikimus, keičiamo mastelio (scalable) sprendimus su struktūrizuotais duomenimis, orientuotais į pajamas.