2026-03-17 · Redakcija Baduno · 22 blog.readMin · Blogas ir žinios
Struktūriniai duomenys tarptautiniu mastu: Schema.org per kalbų ribas
Daugiakalbės svetainės reikalauja tikslių struktūrinių duomenų, kad paieškos sistemos suprastų turinį pagal kalbą. Šiame vadove sužinosite, kaip teisingai naudoti Schema.org žymėjimus per kalbų ribas – nuo organizacijos iki produkto ir DUK. Praktiškais patarimais ir tikrinimo metodais išvengsite tipinių klaidų ir pagerinsite savo turinio tarptautinį matomumą.
Įvadas į struktūrinius duomenis daugiakalbėms svetainėms
Struktūriniai duomenys pagal Schema.org padeda paieškos sistemoms suprasti jūsų svetainės turinį – net ir per kalbų barjerus. Kai naudojate kelias kalbų versijas, teisingas žymėjimas tampa dar svarbesnis. Paieškos sistemos, tokios kaip Google, naudoja struktūrinius duomenis, kad rodytų išplėstinius rezultatus, pvz., fragmentus, produktų kainas ar DUK elementus. Daugiakalbėse svetainėse šie žymėjimai turi būti kalbai būdingi, antraip gali būti pateikiama neteisinga informacija – pavyzdžiui, telefono numeris iš vokiško puslapio prancūziškoje versijoje.
Tipiška klaida: perkelti vienos kalbos schemą į kitas versijas nepritaikius kalbos nuorodų. Neužtenka tik išversti turinį; struktūra taip pat turi atspindėti tikslinę kalbą. Pavyzdžiui, Schema objekto laukas `inLanguage` turi nurodyti puslapio kalbą. Vokiškam produktų puslapiui priskiriama `inLanguage: 'de'`, angliškam – `inLanguage: 'en'`. Be to, naudodami `translationOfWork` galite nurodyti originalią versiją.
Praktiškai pradėkite nuo svarbiausių puslapių tipų: Organizacija, Produktas, DUK. Jie dažniausiai naudojami išplėstiniuose rezultatuose. Iš anksto įvertinkite, kurie puslapiai kuriomis kalbomis yra ypač svarbūs. Tarptautinei įmonės svetainei tinka Organization schema, o el. parduotuvei – Product schema. Užtikrinkite, kad kiekviena kalbos versija turėtų savo JSON-LD scenarijų arba atskirus įrašus scenarijuje. Naudokite įrankius, tokius kaip Google Rich Results Test, kad patikrintumėte kiekvieną kalbos versiją atskirai. Atkreipkite dėmesį, kad testas suteikia tik momentinį vaizdą – rekomenduojama reguliariai tikrinti.
Teisiniu požiūriu svarbu, kad struktūriniuose duomenyse nebūtų asmens duomenų, pažeidžiančių BDAR. Nurodydami kontaktinius duomenis skirtingose šalyse, įsitikinkite, kad jie yra teisingi ir aktualūs. Kilus abejonių, pasitarkite su teisės ekspertu. Tinkamai įdiegę daugiakalbius struktūrinius duomenis, padidinate galimybes būti rastiems su aktualiais išplėstiniais rezultatais įvairiuose kalbų regionuose.
Schema.org pagrindai ir kalbos žymėjimas
Schema.org teikia bendrą žodyno struktūrą, kurią palaiko paieškos sistemos. Daugiakalbėse svetainėse teisingas kalbos žymėjimas yra esminis. Kiekvienas schemos objektas gali turėti `inLanguage` savybę, nurodančią turinio kalbą (pvz., `'de'`, `'en'`, `'fr'`). Šis nurodymas turi atitikti tikrąją puslapio kalbą. JSON-LD nustatykite `@language` visame dokumente arba atskiruose objektuose, jei yra kelios kalbos.
Pavyzdys: Vokiečių kalba pateiktam produktui naudokite: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Jei tą patį produktą žymite angliškame puslapyje, vietoj to nurodykite `"inLanguage": "en"` ir pavadinimą anglų kalba. Venkite maišyti kelias kalbas viename schemos objekte – tai sukelia nenuoseklumų. Vietoj to naudokite atskirus žymėjimo blokus kiekvienai kalbai arba, jei subjektas yra daugiakalbis, naudokite `@language` masyvus objekto viduje.
Svetainės specifiniams duomenims, pvz., `WebSite` ar `WebPage`, taip pat nurodykite kalbą. Kalbos perjungimo atveju puslapyje galite naudoti `potentialAction` arba `translationOfWork` nuorodoms į kitas kalbines versijas. Praktikoje pasiteisino kiekvienai kalbai įdėti atskirą JSON-LD bloką atitinkamo puslapio `<head>` dalyje. Taip užtikrinamas vienareikšmiškas priskyrimas ir teisingas interpretavimas validavimo įrankiais.
Atkreipkite dėmesį, kad kalbų kodai turi atitikti ISO-639-1 standartą (pvz., „de“ vokiečių, „en“ anglų kalbai). Regioniniams variantams galite pridėti šalies santrumpą, pvz., „de-CH“ Šveicarijos vokiečių kalbai. Tačiau turite patikrinti, ar paieškos sistema palaiko tokį smulkų skirstymą – paprastai pakanka pagrindinio kalbos kodo. Kiekvieną kalbinę versiją patvirtinkite atskirai naudodami Google Structured Data Testing Tool arba Rich Results Test. Užsirašykite galimus įspėjimus dėl trūkstamų kalbos nuorodų ir tikslingai juos ištaisykite.
Organization-Schema: įmonės duomenys keliomis kalbomis
Organization schema yra idealus įmonėms, turinčioms daugiakalbes svetaines, nes pateikia pagrindinę informaciją, tokią kaip pavadinimas, adresas ir kontaktiniai duomenys. Kiekvienai kalbinei versijai turėtumėte sukurti atskirą Organization objektą, pažymėtą atitinkama kalba. `name` turėtų būti nurodytas tiksline kalba – pvz., „Muster GmbH“ vokiečių kalba ir „Sample Inc.“ anglų kalba. Jei įmonė turi vienodą pavadinimą, pakanka išversti aprašymą (`description`).
Adresams naudokite `PostalAddress` schemą su `addressCountry` ir `addressLocality`. Tarptautiniams padaliniams galite numatyti kelis `location` įrašus. Įsitikinkite, kad telefono numeriai (`telephone`) turi teisingą šalies kodą. Pavyzdžiui: vokiškam puslapiui `+49 30 1234567`, šveicariškam puslapiui `+41 44 1234567`. Tas pats galioja el. pašto adresams ir darbo laikui. Naudokite `areaServed`, kad nurodytumėte, kuriose šalyse įmonė veikia.
Dažnai pamirštama detalė yra `sameAs` savybė socialinių tinklų profiliams. Pridėkite kalbai būdingus profilius, jei jie yra – pvz., vokišką Facebook puslapį ir anglišką Twitter paskyrą. Taip pat `url` turėtų nukreipti į kalbinės versijos pagrindinį puslapį. Daugiakalbėse svetainėse galite naudoti `translationOfWork`, kad susietumėte skirtingas kalbines versijas, jei puslapiai turi tą patį turinį kita kalba.
Praktinė rekomendacija: Įdiekite Organization schema kiekvienos kalbinės versijos pagrindiniame puslapyje. Tam įdėkite JSON-LD scenarijų į `<head>`. Venkite dublikatų, kiekvienai kalbai sukurdami atskirą bloką su tinkamu `inLanguage`. Patvirtinkite žymėjimą naudodami Google Rich Results Test ir patikrinkite, ar kontaktiniai duomenys rodomi teisingai. Teisiškai turite užtikrinti, kad pateikta informacija būtų išsami ir atitiktų duomenų apsaugos reikalavimus. Ypač kai yra keli padaliniai: teisinės nuostatos dėl impressumo gali skirtis priklausomai nuo šalies. Abejotinais atvejais pasikonsultuokite su teisininku. Šios detalės užtikrina, kad jūsų įmonė visuose kalbiniuose regionuose būtų atstovaujama vienodai ir teisingai.
Product-Schema: produktų aprašymų žymėjimas pagal kalbą
Keliakalbėms svetainėms būtina produktus žymėti Schema.org Product atitinkama kalba. Kiekviena produkto kalbos versija turėtų turėti savo schemos žymėjimą, įtraukiant vietinį pavadinimą, aprašymą ir atributus, tokius kaip kaina, valiuta ar prieinamumas. Naudokite atributą `inLanguage` kiekvienai kalbai – pvz., `"inLanguage": "de-DE"` vokiečių kalbai (Vokietija). Įsitikinkite, kad produkto pavadinimas ir aprašymas JSON-LD objekte tikrai yra vokiečių kalba, o ne tik kalbos žyma.
Dažna klaida – visų kalbų variantų žymėjimas tuo pačiu `@id` (pvz., globaliu produkto ID). Vietoj to, kiekvienai kalbai suteikite atskirą `@id`, pvz., `https://example.com/de/produkt/123` ir `https://example.com/fr/produit/123`. Taip „Google“ galės rodyti tinkamą versiją. Kainoms naudokite `priceCurrency` su ISO-4217 kodu (pvz., EUR, USD) ir nurodykite kainą pagal kalbą – net jei kaina ta pati, ji priklauso vietinei svetainei.
Praktinė rekomendacija: kiekvienam produktui sukurkite JSON-LD šabloną, kuris dinamiškai nustato kalbos parametrus. Patikrinkite kiekvieną kalbos versiją atskirai naudodami „Google Rich Results Test“. Įsitikinkite, kad `url` atributas nurodo atitinkamą kalbos URL. Venkite maišyti visas kalbas viename JSON-LD bloke – tai dažnai sukelia patvirtinimo klaidas. Nuotraukoms galite palikti `image` atributą nepriklausomą nuo kalbos, bet įsitikinkite, kad vaizdų URL yra teisingi.
Be to, galite pritaikyti `offers` su `availability` pagal rinką (pvz., `InStock` Vokietijai, `PreOrder` Prancūzijai). Naudokite `gtin` arba `mpn` globaliai, o `sku` palikite vietinius variantus. Galiausiai patikrinkite, ar struktūriniai duomenys „Search Console“ yra tinkamai indeksuoti kiekvienai kalbos versijai.
DUK schema: keliakalbis klausimų ir atsakymų puslapių optimizavimas
DUK puslapiai keliomis kalbomis naudingi, kai aiškiai ir pagal kalbą pažymimi naudojant FAQPage schemą. Kiekviena DUK puslapio kalbos versija gauna atskirą JSON-LD objektą. Nustatykite `inLanguage` atitinkamu kalbos kodu (pvz., `fr-FR` prancūzų kalbai). Klausimai ir atsakymai objekte turi būti suformuluoti tiksline kalba – mašininio vertimo dažnai nepakanka; leiskite juos patikrinti gimtajam kalbėtojui, nes niuansai yra svarbūs.
Tipiška klaida: tas pats `@id` visoms kalbos versijoms. Vietoj to naudokite kalbai skirtą URL kaip `@id`, pvz., `https://example.com/de/faq/` ir `https://example.com/en/faq/`. FAQPage schemoje klausimus išvardinkite kaip `mainEntity` su `@type: Question` ir atitinkamą atsakymą kaip `acceptedAnswer`. Kiekvienas klausimas gali papildomai gauti `inLanguage`, tačiau tai yra perteklinė, jei pažymėtas visas puslapis. Laikykite klausimų skaičių puslapyje ne daugiau kaip 10–15, nes paieškos sistemos atsižvelgia tik į ribotą kiekį.
Rekomendacija: naudokite turinio valdymo sistemą, kuri kiekvienam DUK įrašui pateikia keliakalbius laukus. JSON-LD išvestyje dinamiškai gaukite dabartinę kalbą. Patvirtinkite kiekvieną kalbos versiją atskirai naudodami „Rich Results Test“ ir atkreipkite dėmesį į įspėjimus dėl trūkstamų `name` savybių klausimuose. Prie kiekvieno klausimo pridėkite `url`, nukreipiančią į konkretų inkarą – taip vartotojai galės tiesiogiai pereiti prie atitinkamo atsakymo.
Atkreipkite dėmesį: FAQPage tinka tik puslapiams su aiškiais klausimais ir atsakymais. Nenaudokite jo bendruosiuose pagalbos puslapiuose. Po diegimo patikrinkite matomumą „Google“ paieškoje – DUK rich snippets dažnai rodomi paieškos užklausose su klausimo dalelėmis. Keliakalbiui SEO verta pritaikyti atsakymus pagal šaliai būdingas formuluotes (pvz., „Kaip aš galiu?“ vs. „Comment puis-je?“).
inLanguage subtilybės: kalbos kodas ir lokalė
Schema.org atributas `inLanguage` nurodo turinio kalbą, kai reikšmė idealiai sudaryta iš kalbos kodo (ISO 639-1) ir neprivalomo regiono kodo (ISO 3166-1 Alpha-2) – pvz., `en-US` amerikiečių anglų kalbai. Regionas svarbus, kai turinys skiriasi: „colour“ vs. „color“ arba skirtingi matavimo vienetai. Be regiono kodas interpretuojamas kaip bendra kalba. Todėl naudokite `de-DE`, `de-AT`, `de-CH` šalims specifiniuose puslapiuose, net jei tekstas beveik identiškas.
Praktinis pavyzdys: produktas siūlomas vokiškame ir austriškame puslapyje. Kalba vokiečių, bet kainos ir pristatymo sąlygos skiriasi. Nustatykite `inLanguage: "de-DE"` vokiškam ir `"de-AT"` austriškam puslapiui. Taip „Google“ geriau supras regioninį aktualumą. Tas pats galioja `en-GB` ir `en-US`. Jei nereikia regioninio skyrimo, pakanka `"de"` arba `"en"`. Tačiau atkreipkite dėmesį, kad kalbos kodas visada rašomas mažosiomis, o regionas didžiosiomis raidėmis (pvz., `fr-CA`).
Dažna klaida – naudoti `inLanguage` ant aukštesnio lygio objekto, kai subobjektai turi kitą kalbą. Pavyzdys: svetainė vokiečių, bet vienas straipsnis anglų. Tada nustatykite `inLanguage: "de"` svetainėje ir `inLanguage: "en"` straipsnyje. Patvirtinkite tai schema validatoriumi, nes kai kurie įrankiai praneš apie konfliktus. Daugiakalbiams puslapiams su hreflang žymomis `inLanguage` turėtų atitikti atitinkamą hreflang reikšmę – tai padeda „Google“ pateikti tinkamą versiją.
Praktinis įgyvendinimas: kiekvienai kalbos versijai nustatykite unikalų `@id` ir nuosekliai naudokite `inLanguage`. Naudokite centrinę konfigūracijos bylą, kurioje kiekvienai kalbai yra teisingi kodai. Išbandykite su schema.org įrankiu, ar `inLanguage` žyma priimama. Patarimas: net AMP puslapiuose ar struktūriniuose duomenyse naudojant Microdata nepamirškite `inLanguage`. JSON-LD atveju patalpinkite jį aukščiausiame lygyje (pvz., `WebSite` arba `WebPage`). Dinaminiam turiniui, pvz., tinklaraščio straipsniams, `inLanguage` gali skirtis pagal įrašą – tada nustatykite jį kiekvienam elementui.
Daugiakalbystės viename URL teisingas žymėjimas
Kai URL yra turinio keliomis kalbomis – pavyzdžiui, per kalbos keitiklį, skirtukus ar akordeonus – struktūriniuose duomenyse turite aiškiai nurodyti, kuris tekstas priklauso kuriai kalbai. Priešingu atveju paieškos sistemos robotas gali klaidingai manyti, kad visas turinys yra viena kalba, o tai sukels indeksavimo ir rodymo klaidų.
Pagrindinis metodas yra naudoti `inLanguage` atributą atitinkamuose elementuose. DUK schemoje su klausimais ir atsakymais vokiečių ir anglų kalbomis tame pačiame puslapyje kiekvieną klausimą ir atsakymą žymėkite atskirai: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Panašiai galioja Product schemoms: aprašykite `name` ir `description` kiekvienai kalbai atskirame `Product` objekte su atskiru `inLanguage` arba naudokite `@language` ir `@value` `multilingualDescription` savybėje (jei jūsų žodynas tai palaiko).
Organizacijoms su daugiakalbiais pavadinimais naudokite `name` objektų masyvą: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Venkite deklaruoti visą puslapį kaip daugiakalbį. Vietoje to kalbos priskyrimą atlikite kuo detaliau. Dažna klaida – nustatyti `inLanguage` tik aukščiausiame schemos lygyje, nepažymint žemesnių elementų. Todėl patvirtinimo darbo eigoje patikrinkite, ar visi tekstai teisingai pažymėti kalba.
Konkreti rekomendacija: kiekvienai kalbos variante viename URL sukurkite atskirą schemos objektą, kuriame būtų tik tos kalbos tekstai, ir nustatykite `inLanguage` atitinkamam kalbos kodui. Jei puslapis pagal numatytuosius nustatymus rodo pagrindinę kalbą, o kitos įkeliamos per JavaScript, struktūrinius duomenis visoms kalboms pateikite statiškai HTML. Tokie įrankiai kaip „Google Rich Results Test“ parodys, ar žymėjimas teisingai interpretuojamas. Išbandykite kiekvieną kalbos versiją atskirai, priversdami robotą per URL parametrą ar slapuką naudoti norimą kalbą.
hreflang ir inLanguage atskyrimas: kada kurį metodą naudoti?
`hreflang` ir `inLanguage` atlieka skirtingus tikslus tarptautinėje SEO ir neturėtų būti painiojami. `hreflang` yra HTML elementas arba HTTP antraštė, kuri signalizuoja paieškos sistemoms, kad yra alternatyvių kalbinių ar regioninių to paties puslapio versijų. Ji skirta teisingai pristatyti atitinkamą puslapį vartotojams iš skirtingų šalių arba su tam tikrais kalbos nustatymais. `inLanguage` savo ruožtu yra atributas struktūrizuotuose duomenyse (Schema.org), nurodantis kalbą, kuria parašytas konkretus teksto elementas.
Kada naudoti ką? Naudokite `hreflang`, kai turite atskirus URL skirtingoms kalbinėms versijoms (pvz., `example.com/de/` ir `example.com/en/`). Tai padeda išvengti dublikatų turinio problemų ir užtikrinti, kad snippet'e būtų rodomas teisingas puslapis. `inLanguage` būtinas, kai vienu URL pažymite daugiakalbį turinį arba kai struktūrizuotas duomenų elementas, pvz., produkto aprašymas, pateikiamas keliomis kalbomis. `inLanguage` papildo `hreflang` atskirų teksto blokų lygmeniu.
Dažnas nesusipratimas: `inLanguage` nepakeičia `hreflang`. Net jei kiekvieną straipsnio eilutę pažymėsite `inLanguage`, paieškos sistemos be `hreflang` nežinos, ar yra alternatyvių viso puslapio versijų. Ir atvirkščiai, `hreflang` nepakanka, kad būtų smulkiai aprašytas daugiakalbis turinys viename URL. Praktiškai tai reiškia: jei turite atskirus puslapius kiekvienai kalbai, pirmiausia reikalingas `hreflang`, o `inLanguage` struktūrizuotuose duomenyse tuose puslapiuose nurodo konkrečią turinio kalbą. Jei viename URL yra kelios kalbos, būtina naudoti `inLanguage` kiekvienam kalbai specifiniam elementui.
Konkreti rekomendacija: suplanuokite URL strategiją prieš diegimą. Nuspręskite, ar naudosite atskirą URL kiekvienai kalbai (ccTLD, subdomenas, subkatalogas), ar bendrą URL su dinaminiu kalbos perjungimu. Pastarajam atveju teisingas `inLanguage` žymėjimas yra būtinas. Bet kuriuo atveju patikrinkite, ar jūsų `hreflang` žymos nurodo visas atitinkamas kalbines versijas ir neprieštarauja `inLanguage` nuostatoms struktūrizuotuose duomenyse. Šių dviejų signalų suderinimas gali padėti paieškos sistemoms teisingai susieti jūsų turinį.
Tikrinimo darbo eiga: įrankiai ir automatiniai patikrinimai
Rankinis struktūrizuotų duomenų tikrinimas kiekvienoje kalbinėje versijoje yra linkęs į klaidas ir atima daug laiko. Automatizuota tikrinimo darbo eiga užtikrina, kad jūsų Schema.org žymėjimai būtų teisingi ir išliktų – net po turinio atnaujinimų ar pridedant naujų kalbų. Svarbiausi įrankiai yra Google Rich Results Test („Google“ palaikomiems tipams, pvz., DUK, Produktas) ir Schema.org Validator (grynai sintaksės tikrinimui). Papildomai padeda tikrintuvai, pvz., Screaming Frog SEO Spider, išgaunantys struktūrizuotus duomenis iš visos jūsų svetainės ir tikrinantys klaidas.
Įtraukite tikrinimą į savo CI/CD procesą: po kiekvieno diegimo ar kalbos atnaujinimo paleiskite automatinį testavimą. Tam naudokite Google Rich Results Test API arba scenarijų, kuris analizuoja jūsų puslapius ir tikrina JSON-LD blokus pagal jūsų pačių apibrėžtą schemą. Ypatingą dėmesį atkreipkite į šias klaidų priežastis: - Trūkstamas `inLanguage` ten, kur yra kelios kalbos. - Prieštaringi kalbos kodai (pvz., „de“ vietoj „de-DE“ regioniniams variantams). - Neužpildyti privalomi laukai (pvz., `name` produktui kiekvienoje kalboje). - Pasenusios `hreflang` žymos, kurios nebeatitinka jūsų dabartinių URL.
Konkreti veiksmų rekomendacija: kiekvienai schemos rūšiai (Organizacija, Produktas, DUK) sukurkite kontrolinį sąrašą su reikalingais atributais pagal kalbą. Naudokite testavimo įrankį, pvz., `json-schema`, automatiniam duomenų tikrinimui. Be to, reguliariai (pvz., kas mėnesį) atlikite pilną tikrinimą naudodami Schema.org Validatorių ir gaukite ataskaitas apie klaidingus puslapius. Dokumentuokite klaidų kategorijas ir paskirkite atsakingus asmenis už taisymą. Atkreipkite dėmesį, kad struktūrizuotus duomenis reikia tikrinti tiesioginiuose puslapiuose – testavimo aplinkoje to padaryti nepakanka, nes ten gali būti kitoks turinys. Tik taip užtikrinsite, kad paieškos sistemoms aktualios klaidos būtų laiku ištaisytos.
Daugiakalbės svetainės reikalauja tikslių struktūrinių duomenų, kad paieškos sistemos suprastų turinį pagal kalbą. Šiame vadove sužinosite, kaip teisingai naudoti Schema.org žymėjimus per kalbų ribas – nuo organizacijos iki produkto ir DUK. Praktiškais patarimais ir tikrinimo metodais išvengsite tipinių klaidų ir pagerinsite savo turinio tarptautinį matomumą.
Dažnos klaidos tarptautiniuose struktūrizuotuose duomenyse
Kelių kalbų svetainių žymėjimas Schema.org turi tipinių spąstų. Dažna klaida – kalbos atributo `inLanguage` nebuvimas arba neteisingas nurodymas. Pavyzdžiui, jei siūlote produktą vokiečių kalba, bet nežymite `inLanguage: "de-DE"`, paieškos sistemos gali interpretuoti duomenis kaip neutralius kalbos atžvilgiu. Kita esminė klaida – kalbų maišymas viename schema bloke. Venkite, kad `Product` objekte `name` būtų anglų, o `description` – vokiečių kalba. Vietoje to kiekvienai kalbinei versijai turi būti sukurtas atskiras blokas su teisingu `inLanguage`. Taip pat paplitusi klaida – netinkamų schema tipų naudojimas. Daugelis klaidingai renkasi `LocalBusiness`, nors teisingai būtų `Organization`, jei nėra fizinio adreso kiekviena kalba. Produktuose dažnai pamirštama kalbiniu požiūriu atskirai pažymėti `offers` savybę. Be to, po vertimų neatnaujinami struktūriniai duomenys: naujai išverstas produkto tekstas turi būti atitinkamai pataisytas ir žymėjime – kitaip paieškos rezultatuose rodoma pasenusi ar klaidinga informacija. Validacijos nepaisymas yra dar viena kardinali klaida. Po kiekvieno pakeitimo turėtumėte patikrinti žymėjimus tinkamais įrankiais. Klaidingos arba trūkstamos `@id` nuorodos subjektuose, kurie yra vienodi visomis kalbomis (pvz., organizacija), sukelia dublikatus arba neišsamius duomenis. Be to, dažnai ignoruojama sąveika su `hreflang`: jei nėra alternatyvių URL, dirbkite su `inLanguage` tame pačiame puslapyje. Rekomendacijos: Patikrinkite kiekvieną žymėjimą dėl teisingo kalbos priskyrimo. Kiekvienai kalbinei versijai naudokite atskirus schema blokus su unikaliais `@id`. Venkite maišymo – net `aggregateRating` ar `review` kalbos turi sutapti. Po kiekvieno vertimo atlikite pakartotinę validaciją ir suderinkite duomenis su matomu turiniu. Tik taip užtikrinsite, kad paieškos sistemos teisingai supras jūsų kelių kalbų pasiūlymus.
Testas su Google Rich Results, Bing Webmaster Tools ir Yandex
Kelių kalbų Schema.org žymėjimų tikrinimas neturėtų apsiriboti vienu įrankiu. Kiekviena paieškos sistema turi savo interpretacijas ir validacijos kriterijus. Google Rich Results testas yra pirmasis žingsnis: įveskite URL su savo žymėjimu arba įklijuokite kodą tiesiogiai. Atkreipkite dėmesį į visas klaidas ir įspėjimus – ypač ar `inLanguage` nurodymai atpažįstami teisingai. Dažna problema – Google priima `de-DE`, bet, jei trūksta regiono dalies (`de`), vis tiek išduoda įspėjimą. Išbandykite kiekvieną kalbinę versiją atskirai. Bing Webmaster Tools siūlo URL patikrinimą su struktūrinių duomenų peržiūra. Čia galite pamatyti, ar Bing interpretuoja žymėjimus kaip tikėtasi. Bing dažnai griežtesnis validuodamas `inLanguage` ir gali reikalauti tik dviejų raidžių kalbos kodo be regiono (pvz., `de` vietoj `de-DE`). Atlikite tiesioginį testą ir pataisykite neatitikimus. Bing taip pat rodo galimus dublikatus, jei `@id` reikšmės naudojamos kelis kartus. Yandex Webmaster turi savo validatorių, kuris ypač aktualus rusiškoms svetainėms. Čia taip pat galite testuoti struktūrinius duomenis. Yandex palaiko daugumą Schema.org tipų, tačiau klaidų apdorojimas skiriasi. Ypač `Product` žymėjimuose dažnai kritikuojama `availability` savybė. Todėl ir čia išbandykite kiekvieną kalbinę versiją. Atkreipkite dėmesį, kad Yandex regioninius kalbos kodus, pvz., `de-DE`, gali vertinti kitaip. Rekomendacijos: Išbandykite kiekvieną kalbinę versiją visuose trijuose įrankiuose po diegimo ir po kiekvieno pakeitimo. Užsirašykite neatitikimus ir pritaikykite žymėjimus taip, kad juos priimtų visos trys paieškos sistemos. Idealiu atveju naudokite dviejų raidžių kalbos kodą (`de`, `en`) lauke `inLanguage`, nes jį vienodai supranta dauguma sistemų. Automatizuokite testus naudodami CI įrankius, kad daugiakalbėse svetainėse su daugybe puslapių neprarastumėte kontrolės.
Kelių kalbų Schema.org žymėjimų diegimo kontrolinis sąrašas
Struktūruotas metodas padeda išvengti tipinių klaidų internacionalizuojant. Prieš diegimą nustatykite kalbos strategiją: naudokite atskirus URL kiekvienai kalbai (pvz., `/de/produkt` ir `/en/product`) arba vieną URL su kalbų perjungimu? Atskiriems URL naudokite `hreflang` ir kiekvienam URL atskirą žymėjimą. Vieno URL atveju naudokite kelis `inLanguage` blokus su skirtingais kalbų kodais. Be to, planuokite, kokių schema tipų reikės: įmonės (Organization), produktai (Product), DUK (FAQPage) ir kt.
Diegiant atkreipkite dėmesį į šiuos punktus: kiekvienas schema objektas turi unikalų `@id`, kuris identifikuoja subjektą nepriklausomai nuo kalbos. Kiekvienai kalbos versijai sukurkite atskirą objektą, kuriame `inLanguage` nurodo kalbą. Naudokite nuoseklius kalbų kodus – pageidautina dviženklį ISO kodą (pvz., `de`, `en`) papildytą regionu, jei reikia. Teisingai susiekite žymėjimuose: `Organization` atveju naudokite `url` ir `logo` su kalbai specifiniais keliais. Patikrinkite, ar tekstai, tokie kaip `name` ir `description`, atitinka matomą turinį.
Po diegimo atlikite validaciją: išbandykite kiekvieną kalbos versiją su Google Rich Results Test, Bing Webmaster Tools ir Yandex. Ištaisykite klaidas ir įspėjimus. Ypač atkreipkite dėmesį į trūkstamus `inLanguage` arba neteisingus kalbų kodus. Be to, naudokite Google Schema.org validavimo įrankį sintaksei patikrinti. Dokumentuokite visus pakeitimus ir po kiekvieno vertimo atlikite pakartotinius testus.
Galiausiai stebėjimas yra proceso dalis: stebėkite našumą Search Console, ypač struktūrinių duomenų ataskaitose. Reaguokite į naujas klaidas ar įspėjimus. Atnaujinkite žymėjimus laiku, kai keičiate ar verčiate turinį. Reguliariai atlikite auditus, kad užtikrintumėte nuoseklumą visose kalbų versijose. Gerai prižiūrėtas Schema.org diegimas pagerina matomumą paieškos rezultatuose – be garantijų, bet su praktine nauda.
Teisinės pastabos: Asmeninė atsakomybė už automatinį vertimą
Automatinis struktūrinių duomenų vertimas kelia teisinę riziką, kurią, kaip daugiakalbės svetainės valdytojas, turite asmeniškai patikrinti. Ypač kai Schema.org žymėjimuose yra teisiškai reikšmingo turinio, pvz., produktų saugos informacijos, bendrųjų sąlygų ar prekių ženklų pavadinimų, netikslus vertimas gali sukelti atsakomybę. Pavyzdžiui, neteisingai išverstas produkto pavadinimas ar klaidinančios produkto savybės gali pažeisti konkurencijos teisę. Todėl rekomenduojame visas automatiškai sukurtas versijas peržiūrėti gimtosios kalbos specialistui. Tai ypač svarbu tokiems laukams kaip „description“ Product schemoje ar „answer“ FAQ schemoje, kur niuansai yra esminiai.
Be turinio teisingumo, svarbūs ir duomenų apsaugos aspektai: jei jūsų schemoje yra asmens duomenų (pvz., klientų atsiliepimai Review schemoje), turite užtikrinti, kad vertimas atitiktų BDAR reikalavimus. Automatinio vertimo paslaugos turėtų būti naudojamos tik tuo atveju, jei jos suteikia pakankamas duomenų apsaugos garantijas. Visiškas draudimas nėra, tačiau atsakomybė už duomenų tvarkymą tenka jums, kaip svetainės valdytojui. Pasitarkite su teisės konsultantu dėl konkrečių reikalavimų jūsų tikslinėse šalyse.
Kitas teisinis spąstas: „inLanguage“ naudojimas su neteisingais kalbų kodais. Visada naudokite oficialius BCP-47 kodus (pvz., „de-DE“, o ne „deutsch“). Klaidingi kodai gali lemti, kad paieškos sistemos ignoruos jūsų žymėjimus – tai nors ir nėra teisinė problema, tačiau pablogina randamumą. Todėl prieš paleidimą atlikite validaciją naudodami tokius įrankius kaip Google Rich Results Test ir papildomai patikrinkite, ar vertimai teisingai apima visus teisiškai reikšmingus laukus.
Rekomendacija: nustatykite darbo eigą, pagal kurią kiekvienas automatiškai išverstas schema žymėjimas yra peržiūrimas gimtosios kalbos redaktoriaus ar teisininko. Dokumentuokite šį procesą, kad ginčo atveju galėtumėte įrodyti, jog laikėtės rūpestingumo pareigos. Venkite automatinio teisinio pobūdžio tekstų blokų vertimo (pvz., garantijų sąlygos, atsakomybės apribojimai); išverskite juos rankiniu būdu arba per specializuotą paslaugą.
Perspektyva: Dirbtinio intelekto pagrįsta lokalizacija ir būsimi schemų pokyčiai
Schema.org žymėjimo lokalizavimą vis labiau palengvina dirbtiniu intelektu pagrįsti įrankiai. Dabartinės sistemos, remdamosi neuroniniais tinklais, gali kurti vertimus, kurie kontekstiškai tikslesni nei senesni statistiniai metodai. Daugiakalbėms svetainėms tai reiškia: didelius kiekius produktų duomenų ar DUK turinio galima greičiau išversti į kelias kalbas. Tačiau kokybės užtikrinimas išlieka itin svarbus, nes DI modeliai ne visada teisingai atpažįsta specifinius pramonės terminus ar regioninius niuansus. Praktinis sprendimas – naudoti DI pirminiam vertimui, o vėliau atlikti žmogaus patikrą. Tokie įrankiai kaip Baduno sujungia DI vertimą su gimtosios kalbos patikra, taip pasiūlydami mastelio keičiamą sprendimą.
Lygiagrečiai su DI plėtra Schema.org nuolat plečia savo žodyną. Ateities tipai gali labiau atliepti DI generuotą turinį, pavyzdžiui, „AIContent“ schema, skirta mašininiams tekstams žymėti. Taip pat svarbesnis tampa susiejimas su žinių grafais: daugiakalbiai žymėjimai ateityje galėtų būti automatiškai generuojami iš centrinių žinių bazių. Jau dabar yra ypatybė „translationOfWork“, kuri aiškiai nurodo ryšį tarp išverstų turinių. Rekomenduojame šias naujas ypatybes kuo anksčiau įtraukti į savo strategiją, kad būtumėte pasiruošę paieškos sistemų atnaujinimams.
Kita tendencija – dinaminiai, kalbai specifiniai žymėjimai, pateikiami pagal naudotojo kontekstą. Pavyzdžiui, produktų schema pagal naudotojo vietą gali nurodyti vietinę valiutą ir matavimo vienetus. Iššūkis yra teisingai naudoti „inLanguage“ ir išvengti konfliktų su hreflang. Ateities schemų versijos gali aiškiau apibrėžti, kaip pateikti regioninius variantus vienoje schemoje. Norėdami pasiruošti, savo žymėjimus kurkite modulinius: kiekvienai kalbai naudokite atskirus blokus tame pačiame JSON-LD arba atskiras script žymas kiekvienai kalbos versijai – priklausomai nuo techninės infrastruktūros.
Rekomendacija: išbandykite DI pagrįstus vertimo sprendimus naudodami reprezentatyvų savo schemos duomenų rinkinį ir išmatuokite klaidų dažnį. Sekite Schema.org leidimo pastabas, kad identifikuotumėte naujas ypatybes. Išbandykite dinaminį žymėjimų pateikimą skirtingoms tikslinėms grupėms ir patvirtinkite rezultatus naudodami svarbiausių paieškos sistemų „Search Console“. Taip užtikrinsite, kad jūsų daugiakalbė svetainė pasinaudotų ateities pokyčiais be teisinių ar techninių rizikų.
Praktinis pavyzdys: Žingsnis po žingsnio kelių kalbų produkto puslapio diegimas
Norėdami teorines žinias pritaikyti praktiškai, panagrinėsime fiktyvią elektroninės prekybos svetainę, siūlančią išmanųjį telefoną vokiečių, anglų ir prancūzų kalbomis. Tarkime, produkto puslapis prieinamas vienu URL su kalbos perjungikliu (pvz., example.com/smartphone). Tikslas – pažymėti Schema.org Product žymėjimą su kalbai būdingais duomenimis.
1. **Nustatyti kalbos kodus**: Kiekvienai kalbos versijai naudojamas unikalus inLanguage reikšmė. Pavyzdžiui: vokiečių: "de-DE", anglų: "en-US", prancūzų: "fr-FR".
2. **Pavadinimą ir aprašymą pažymėti pagal kalbą**: JSON-LD žymėjime naudojamas @graph masyvas. Kiekvienai kalbos versijai priskiriamas atskiras Product objektas su atitinkamu inLanguage. Pavyzdys: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Product", "inLanguage": "de-DE", "name": "Smartphone Pro Max", "description": „Galingas išmanusis telefonas su 128 GB atmintimi“, "offers": { ... } }, { "@type": "Product", "inLanguage": "en-US", "name": "Smartphone Pro Max", "description": „Powerful smartphone with 128 GB storage“, "offers": { ... } }, { "@type": "Product", "inLanguage": "fr-FR", "name": „Smartphone Pro Max“, "description": „Smartphone puissant avec 128 Go de stockage“, "offers": { ... } } ] } ```
3. **Patvirtinti žymėjimą**: Naudojant Google Rich Results testą, kiekvienai kalbos versijai tikrinama, ar žymėjimas priimamas. Svarbu, kad inLanguage reikšmės atitiktų tikrąją puslapio kalbą.
4. **Integruoti serverio pusėje arba naudojant JavaScript**: Praktikoje geriausia žymėjimą generuoti serverio pusėje, kad puslapio šaltinio kodas turėtų visą JSON-LD. Dinaminiais kalbos pakeitimais naudojantis JavaScript, žymėjimas gali būti įkeliamas vėliau, tačiau paieškos sistemos gali jo neaptikti.
5. **Patikrinti matomumą**: Po diegimo patikrinama, ar struktūriniai duomenys Google Search Console rodomi kaip galiojantys ir ar turtingi rezultatai rodomi paieškoje.
Šis žingsnis po žingsnio pavyzdys parodo, kaip konkrečiai elgtis. Pritaikykite struktūrą prie savo technologijų ir išbandykite kiekvieną kalbos versiją atskirai.
Bendradarbiavimas su vertimo ir lokalizavimo paslaugų teikėjais
Kai diegiate daugiakalbius struktūrinius duomenis, dažnai bendradarbiaujate su vertėjais ar lokalizacijos agentūromis. Svarbu, kad Schema.org žymėjimai taptų lokalizacijos proceso dalimi. Aptarkite su paslaugų teikėju, kad reikia išversti ne tik matomą turinį, bet ir JSON-LD reikšmes (pvz., „name“, „description“). Dažna klaida: agentūra gauna tik puslapio tekstą, bet ne struktūrinius duomenis. Todėl pateikite atskirą dokumentą su visais Schema laukais – geriausia JSON formatu – ir nustatykite, kurie laukai turi būti verčiami pagal kalbą (pvz., „offers“ ar „review“ gali likti globalūs, o „name“ kinta priklausomai nuo kalbos).
Praktinis patarimas: Naudokite glosarijus ir vertimo atmintis taip pat savo struktūriniams duomenims. Taip užtikrinsite, kad produktų pavadinimai ir specialieji terminai būtų vienodi visuose žymėjimuose. Be to, paprašykite paslaugų teikėjo nustatyti kalbos kodus (inLanguage) pagal jūsų nurodymus – pvz., „de-DE“ vietoj „de“. Po pristatymo atsitiktine tvarka patikrinkite, ar visos išverstos laukų reikšmės teisingai įterptos į žymėjimus. Automatizuotas testas su „Rich Results Test“ iš Google gali suteikti pirmųjų užuominų.
Kitas aspektas: bendradarbiavimas kokybės užtikrinime. Susitarkite, kad išverstus Schema duomenis prieš paskelbimą peržiūrėtų gimtosios kalbos redaktorius. Nes neteisingai išversti produktų atributai ar instrukcijos DUK klausimuose gali pakenkti tarptautiniam reitingavimui. Dokumentuokite visą procesą – nuo šaltinio tekstų išgavimo iki įdiegimo – ir atnaujinkite savo kontrolinį sąrašą kiekvienai kalbos versijai. Taip išvengsite, kad vėlesnių turinio atnaujinimų metu struktūriniai duomenys pasentų.
Teisinė pastaba: Atsakomybė už teisingus vertimus tenka jums. Reikalaukite raštiško patvirtinimo, kad jūsų nurodymai vykdomi, ir sutartimi išspręskite atsakomybės klausimus dėl klaidingų vertimų. Rekomenduojama nepriklausoma teisinė konsultacija.
Biudžeto planavimas ir sąnaudų įvertinimas daugiakalbiam Schema diegimui
Struktūrinių duomenų diegimas keliomis kalbomis sukelia vienkartines ir nuolatines išlaidas. Be paties žymėjimo turinio vertimo, atsiranda techninės integracijos, testavimo ir priežiūros sąnaudos. Norėdami realiai planuoti biudžetą, turite atsižvelgti į šiuos punktus:
1. Schema laukų vertimas: Kiekvienai kalbos versijai atsiranda išlaidos už visų svarbių JSON-LD elementų (antraščių, aprašymų, klausimų, atsakymų ir kt.) vertimą. Kadangi tai trumpi, dažnai techniniai tekstai, vertimo agentūros gali pasiūlyti specialias kainas. Apskaičiuokite 10–20 % priedą už įsigilinimą į Schema apibrėžtis.
2. Techninis pritaikymas: Žymėjimas kiekvienai kalbai turi būti atliekamas atskiruose JSON-LD blokuose arba per daugiakalbius laukus. Priklausomai nuo sistemos, jūsų kūrėjų komandai reikės papildomo laiko kalbos keitimo ir atsarginių variantų logikai įgyvendinti. Paprastai pradinis darbas svetainei su penkiomis kalbomis užima nuo 15 iki 25 žmogaus dienų plėtros srityje.
3. Testavimas ir kokybės užtikrinimas: Kiekviena kalbos versija turi būti atskirai patvirtinta – naudojant „Google Rich Results Test“, Schema.org tikrintuvus ir rankines atrankas. Kiekvienai kalbai numatykite apie 1–2 dienas pirmajai sąrankai ir pusvalandį kiekvienam pakeitimui.
4. Nuolatinė priežiūra: Atnaujinus produktų asortimentą ar DUK turinį, žymėjimai taip pat turi būti laiku pakoreguoti. Nustatykite, ar vertimo komanda kartu su nauju turiniu visada pateikia ir Schema duomenis. Turinio valdymo sistema, automatiškai generuojanti struktūrinius duomenis, sumažina ilgalaikes sąnaudas, tačiau reikalauja atitinkamo nustatymo.
5. Įrankiai ir licencijos: Jei naudojate specialius struktūrinių duomenų stebėjimo įrankius (pvz., „Webmaster Tools“ API arba savo valdymo skydelius), gali tekti mokėti abonentinius mokesčius.
Kaip nykščio taisyklė, visam procesui (diegimas trimis pagrindinėmis kalbomis) turėtumėte numatyti nuo 5 000 iki 15 000 eurų biudžetą, priklausomai nuo svetainės apimties ir produktų skaičiaus. Mažiems projektams su keliais DUK puslapiais suma gali būti mažesnė.
Teisinė pastaba: Pateikti skaičiai yra tik orientaciniai. Reikalaukite individualių pasiūlymų iš kūrėjų ir vertėjų ir atkreipkite dėmesį, kad faktinės išlaidos gali skirtis priklausomai nuo sudėtingumo. Dėl įpareigojančių teiginių kreipkitės į savo teisės ir mokesčių konsultantus.
blog.faqT
Kaip pažymėti DUK schemą, jei klausimai skiriasi priklausomai nuo kalbos?
Kiekvienai kalbos versijai sukurkite atskirus mainEntity įrašus su question ir acceptedAnswer. Naudokite inLanguage aukščiausiame DUK schemos lygmenyje tikslinei kalbai. Jei turinys identiškas skirtinguose URL, naudokite hreflang; jei vertimai viename puslapyje, pakanka inLanguage. Įsitikinkite, kad atsakymai atitinkama kalba yra išsamiai ir teisingai išversti – automatinius vertimus reikėtų patikrinti teisiškai.
Ar galiu pažymėti produkto puslapį su vienu URL kelioms kalboms?
Taip, jei turinys tame pačiame URL yra kelių kalbų (pvz., per skirtukus ar AJAX). Nustatykite inLanguage atitinkamam DOM fragmentui arba naudokite atskirą schemą kiekvienai kalbai, su atskiru inLanguage. Be to, kiekvienai kalbos versijai turėtumėte pateikti name ir description tiksline kalba. Aiškių šalių ar kalbų URL atveju paprastai geriau derinti su hreflang.
Kokie įrankiai tinka daugiakalbių Schema.org žymėjimų patikrai?
Google Rich Results Test tikrina atskirus URL ir rodo klaidas kalbų koduose. Bing Webmaster Tools siūlo panašias funkcijas. Automatizuotiems testams per kelis puslapius tinka tokie naršymo įrankiai kaip Screaming Frog, kurie ištraukia struktūrinius duomenis. Visada rankiniu būdu patikrinkite, ar vertimai name, description ir kitose savybėse yra teisingi – praktikoje čia dažniausiai pasitaiko klaidų.
