2026-01-14 · Redakcija Baduno · 6 blog.readMin · Blogas ir žinios
Struktūriniai duomenys: Schema.org suprantamai paaiškinta
Mašininio skaitymo papildoma informacija paverčia paieškos rezultatus turtingais rezultatais su įvertinimais, DUK ir įmonės duomenimis. Štai kaip tai veikia.
Kas yra struktūriniai duomenys
Nematomi JSON blokai šaltinio kode aprašo, kas yra puslapyje: tai įmonė su šiuo adresu, tai straipsnis su šia data, tai DUK su šiais klausimais. Paieškos sistemos neturi spėlioti – jos skaito.
Kuo tai naudinga
Teisė į išplėstinius rodinius (DUK ištraukas, navigacijos kelią, organizacijos skydelį), geresnis ryšių supratimas ir švaresni žinių grafiko įrašai. Ne reitingo turbo – bet daugiau ploto ir pasitikėjimo paieškos rezultate.
Svarbiausi tipai įmonėms
Organization su registracijos duomenimis, WebSite, Service arba Product su Offer, Article specialistų straipsniams, FAQPage ir BreadcrumbList. Daugiakalbiškumo taisyklė: kiekviena kalbos versija turi savo, išverstą žymėjimą.
Nepamirškite patvirtinti
„Rich Results“ testas parodo, ką „Google“ skaito, „Schema“ tikrintuvas patikrina sintaksę. Klaidingas žymėjimas yra blogiau nei jokio – jis kainuoja pasitikėjimą ir, blogiausiu atveju, išplėstinį rodinį.
Struktūriniai duomenys ir hreflang: tobula sąveika daugiakalbiams puslapiams
Dažna klaidų priežastis daugiakalbėse svetainėse – nenuoseklus struktūrinių duomenų ir hreflang žymų naudojimas. Nors hreflang signalizuoja paieškos sistemoms kalbos ir regiono alternatyvas, struktūriniai duomenys atskleidžia turinio tipą. Abu yra nepriklausomi, tačiau papildo vienas kitą: vokiškas produkto puslapis turėtų turėti hreflang žymą, rodančią į anglišką variantą, o struktūrinių duomenų bloke nurodyti tą patį produkto ID su skirtingais pasiūlymais ir kalbomis. Svarbu: kiekviena kalbos versija gauna savo JSON-LD bloką su atitinkamomis reikšmėmis – kitaip kyla prieštaravimų. „Google“ Rich Results testas dažnai rodo klaidas, jei, pavyzdžiui, organizacija vokiškoje versijoje nurodo anglišką adresą. Todėl po kiekvieno kalbos diegimo visada tikrinkite abu žymėjimus lygiagrečiai.
Priežiūra ir atnaujinimas: Kas tvarko duomenis?
Struktūriniai duomenys nėra vienkartinis projektas. Keičiantis kainoms, darbo laikui ar produktų detalėms, JSON-LD blokai turi būti atnaujinami. Idealiu atveju turinio valdymo sistema užtikrina dinaminį užpildymą. Jei šios automatizacijos trūksta, komandoje reikalingas aiškus atsakingas asmuo – pavyzdžiui, redaktorius straipsnių ir DUK duomenims, kūrėjas organizaciniams duomenims. Venkite duomenų sankaupų: pasenęs telefono numeris Organization bloke kenkia pasitikėjimui. Planuokite ketvirtinius visų struktūrinių duomenų patikrinimus, bent jau prieš kiekvieną didelį perkrovimą. Naudinga turėti centrinę valdymo skydą, rodantį visas pažymėtas svetainės dalis ir jų patvirtinimo būseną.
DI pagrįstas struktūrinių duomenų kūrimas ir tikrinimas
Šiuolaikiniai DI įrankiai gali iš nestruktūrizuoto teksto automatiškai generuoti JSON-LD – pavyzdžiui, DUK puslapiams ar straipsniams. Tai pagreitina darbą, tačiau kelia riziką: DI dažnai nepastebi kontekstinių niuansų (pvz., neteisinga kaina ar pasenusi data). Todėl būtinas redaktoriaus atliekamas gimtosios kalbos patikrinimas. Naudokite DI žaliavai versijai, o tada leiskite žmogui patvirtinti reikšmes. Daugiakalbiuose puslapiuose DI taip pat padeda versti struktūrinius duomenis, tačiau hreflang žymas ir kalbai būdingus ID reikia nustatyti rankiniu būdu. Patikrintas metodas: DI sukuria anglišką standartinį bloką, o vietinis redaktorius pataiso ir papildo šaliai būdingus laukus.
Mašininio skaitymo papildoma informacija paverčia paieškos rezultatus turtingais rezultatais su įvertinimais, DUK ir įmonės duomenimis. Štai kaip tai veikia.
Dinaminio turinio žymėjimas: DUK, atsiliepimai ir produktai
Ypač dažnai klaidų pasitaiko dinaminio turinio atveju. DUK puslapiuose kiekvienas klausimas turėtų būti atskiras JSON-LD įrašas – ne visas sąrašas kaip vienas Question objektas. Atsiliepimuose turi būti teisingai nurodyta vertinimo skalė (pvz., bestRating ir worstRating). Produktų puslapiai su variantais reikalauja AggregateOffer blokų su visa kainų ir prieinamumo informacija. Naudokite šablonus CMS sistemoje, kurie automatiškai generuoja teisingus tipus. Išbandykite kiekvieną dinaminį puslapį atskirai naudodami Rich-Results testą, nes klaidos paaiškėja tik esant konkrečioms reikšmėms. Dažna klaida: 'Review' naudojimas vietoj 'AggregateRating' vidutiniams įvertinimams.
Kelių Schema.org tipų derinimas viename puslapyje
Viename puslapyje galite lygiagrečiai žymėti kelis Schema.org tipus, jei jie apibūdina skirtingus turinio aspektus. Produkto puslapyje vienu metu gali būti Product blokas (su kaina, prieinamumu), Organization blokas (gamintojui) ir Review blokas (atsiliepimams). Svarbu, kad kiekvienas tipas būtų atskirame JSON-LD scenarijuje arba nuosekliai susietas per @id. Pavyzdys: Product blokas nurodo "brand": {"@id": "#organisation"} į Organization bloką. Venkite prieštaringos informacijos – pvz., skirtingų adresų Organization ir LocalBusiness blokuose. Kiekvienas tipas turi būti turinio požiūriu teisingai ir kalbai pritaikytai pažymėtas: prancūziškas puslapis gauna prancūziškas reikšmes visuose blokuose. Naudokite CMS, kad moduliariai valdytumėte tipus, nereikėtų kiekvieno bloko rankiniu būdu koreguoti. Patikrinkite Rich-Results teste, ar visi blokai priimami – kai kurie testai rodo tik pirmąjį bloką. Švarus kelių tipų derinimas padidina galimybes gauti turtingus rezultatus, pvz., karuselę, produktų langelius ar organizacijos skydelį.
Darbas su @id ir nuorodomis susietiems duomenims
Schema.org leidžia nurodyti objektus per @id ir taip išvengti perteklinės informacijos. Vietoje to, kad kiekviename puslapyje kartotumėte visą organizaciją, apibrėžkite centrinį Organization bloką su unikalia @id (pvz., "https://beispiel.de/#firma") ir kituose blokuose remkitės jį per "@id": "https://beispiel.de/#firma". Tai ypač naudinga daugiakalbėse svetainėse: organizacija išlieka ta pati, skiriasi tik kalbai būdingi laukai, pvz., „name“ ar „description“. Atkreipkite dėmesį, kad @id būtų nuosekli visose kalbų versijose – t. y. tas pats URI vokiečių, anglų ir kt. Nuorodos gali būti naudojamos ir straipsnių autoriams, produktų prekiniams ženklams ar atsiliepimų elementams. Patikrinkite Schema validatoriu, ar visos @id nuorodos yra išsprendžiamos. Klaida: jei nurodyta @id nėra apibrėžta tame pačiame puslapio šaltinio kode ar kitame puslapyje, tikrinimas nutrūksta. Todėl centrines esybes laikykite arba globaliame faile (pvz., organisation.json) ir įtraukite per JavaScript, arba naudokite CMS dinaminiam įtraukimui. Švari @id struktūra padeda paieškos sistemoms susieti informaciją ir pagerina nuoseklumą Žinių grafike.
Teisingas BreadcrumbList žymėjimas: patarimai ir spąstai
BreadcrumbList išskyrimas gali atrodyti paprastas, tačiau praktikoje dažnai pasitaiko klaidų, kurios kelia pavojų turtingų fragmentų sėkmei. Teisingas diegimas prasideda nuo hierarchijos supratimo: kiekvienas sąrašo įrašas reikalauja ItemListElement objekto, kuris savo ruožtu turi ListItem objektą. Lemiama yra position savybė: ji numeruoja elementus didėjančia tvarka, pradedant nuo 1 pagrindiniam puslapiui. Venkite praleisti pagrindinį puslapį – net jei jis nėra rodomas matomoje duonos trupinių juostoje, jis turėtų būti įtrauktas į struktūrinius duomenis. Dažna klaida – absoliučių URL naudojimas neatsižvelgiant į kalbos versiją: įsitikinkite, kad URL duonos trupiniuose nurodo teisingą kalbos variantą, pvz., /de/produkte, o ne /en/products. Taip pat elementų pavadinimai turi būti kalbos specifiniai – 'Startseite' vokiškai, 'Home' angliškai. Naudokite name lauką rodomam tekstui ir venkite santrumpų ar trumpinių, kurie galėtų suklaidinti paieškos sistemas. Po diegimo patikrinkite kiekvieną kelią naudodami Rich-Results-Test, ypač jei duonos trupiniai generuojami dinamiškai, nes lengvai gali būti sukeistos pozicijos arba sukurti dublikatai. Be to, atkreipkite dėmesį, kad Google rodo ne daugiau kaip dešimt elementų – todėl trumpesnė, tiksli navigacija yra geresnė nei per ilga.
Įdėtieji objektai ir nuorodos: @id ir @context
Sudėtingi struktūriniai duomenys dažnai naudoja kelių tipų susiejimą per @id nuorodas. Tipiškas pavyzdys – produkto puslapis, kuriame yra ir Offer, ir Review. Užuot sudėjus visus duomenis į vieną monolitinį bloką, švariau yra apibrėžti atskirus blokus su unikaliais @id reikšmėmis ir tada juos susieti. @id reikšmė turi būti unikali puslapyje ir visame domene – idealu naudoti absoliutų objekto URL su fragmentu, pvz., #product-1. Venkite bendrinių ID, tokių kaip #produkt, nes jie gali sukelti konfliktus keliems puslapiams. Kitas svarbus aspektas yra @context: pagal numatytuosius nustatymus naudojamas Schema.org žodynas, tačiau nuosavybiniams plėtiniams galima nurodyti savo kontekstą. Atkreipkite dėmesį, kad patikrinti plėtiniai, tokie kaip health-lifesci ar bib, netyčia nepatektų į komercinius puslapius. Daugiakalbiuose puslapiuose @id nuorodos turi būti kalbos specifinės: vokiškas produkto puslapis susieja su vokiška Offer ID, o ne angliška. Naudinga technika yra @reverse naudojimas atvirkštiniams ryšiams, pvz., kai produktas nurodo organizaciją, bet organizacija neturi tiesioginio visų produktų sąrašo. Išbandykite tokius grandininius ryšius Schema-Validator, nes jau vienas trūkstamas dvitaškis sukels tikrinimo klaidą. Skirkite pakankamai laiko klaidų paieškai susietuose objektuose – jie yra dažna klaidų priežastis didelės apimties diegimuose.
blog.faqT
Ar galiu struktūrinius duomenis pridėti ir po to, senuose puslapiuose?
Taip, struktūriniai duomenys gali būti pridėti bet kada. Įsitikinkite, kad visa informacija yra naujausia. Naudokite „Google“ Rich-Results testą, kad patikrintumėte teisingą įgyvendinimą. Esant daug puslapių, rekomenduojama veikti palaipsniui pagal turinio tipą.
Kaip dažnai turėtų būti atnaujinami struktūriniai duomenys?
Kaskart, kai keičiasi pagrindinė informacija (kainos, darbo laikas, produktų detalės). Suplanuokite bent vieną ketvirtinį bendrą patikrinimą. Dinaminės sistemos gali automatiškai užpildyti duomenis – tai sumažina atnaujinimo išlaidas ir klaidų šaltinius.
