2026-03-17 · Uredništvo Baduno · 24 blog.readMin · Blog & Znanje
Strukturirani podaci na međunarodnoj razini: Schema.org preko jezičnih granica
Višejezične web stranice zahtijevaju precizno strukturirane podatke kako bi tražilice mogle razumjeti sadržaj na temelju jezika. U ovom vodiču saznajte kako pravilno koristiti Schema.org oznake preko jezičnih granica – od organizacije preko proizvoda do FAQ-a. Uz praktične savjete i metode validacije izbjeći ćete tipične pogreške i poboljšati međunarodnu vidljivost svojih sadržaja.
Uvod u strukturirane podatke za višejezične web stranice
Strukturirani podaci prema Schema.org pomažu tražilicama razumjeti sadržaj vaše web stranice – i to preko jezičnih granica. Ako imate više jezičnih inačica, ispravno označavanje postaje još važnijim. Tražilice poput Googlea koriste strukturirane podatke za prikazivanje bogatih rezultata kao što su snippets, cijene proizvoda ili FAQ elementi. Na višejezičnim stranicama ta označavanja moraju biti specifična za jezik, inače se mogu isporučiti pogrešne informacije – primjerice telefonski broj s njemačke stranice u francuskoj verziji. Tipična greška: preuzimanje sheme jednog jezika u druge inačice bez prilagodbe jezičnih oznaka. Pritom nije dovoljno samo prevesti sadržaj; i struktura mora odražavati ciljni jezik. Na primjer, polje inLanguage u Schema objektu treba navesti jezik dotične stranice. Njemačka stranica proizvoda dobiva `inLanguage: 'de'`, engleska `inLanguage: 'en'`. Dodatno, možete koristiti `translationOfWork` za upućivanje na izvornu verziju. Praktično, počnite s najvažnijim tipovima stranica: Organization, Product, FAQ. Oni se najčešće koriste za bogate rezultate. Unaprijed provjerite koje su stranice na kojem jeziku posebno relevantne. Za međunarodnu korporativnu stranicu prikladna je Organization shema, za online trgovinu Product shema. Pazite da svaka jezična inačica dobije vlastiti JSON-LD skript ili zasebne unose u skripti. Koristite alate poput Google Rich Results Testa za pojedinačnu validaciju svake jezične verzije. Imajte na umu da test daje samo trenutnu snimku – redovita provjera se preporučuje. Pravno je važno napomenuti da strukturirani podaci ne smiju sadržavati osobne podatke koji krše GDPR. Prilikom navođenja kontakt podataka u različitim zemljama, osigurajte da su podaci točni i ažurni. U slučaju sumnje potražite savjet pravnog stručnjaka. Čistom implementacijom višejezičnih strukturiranih podataka poboljšavate šanse da budete pronađeni s relevantnim bogatim rezultatima u različitim jezičnim regijama.
Osnove Schema.org i označavanje jezika
Schema.org pruža zajedničku vokabularnu strukturu koju podržavaju tražilice. Za višejezične web stranice, ispravno označavanje jezika je ključno. Svaki Schema objekt može imati svojstvo `inLanguage` koje označava jezik sadržaja (npr. `'de'`, `'en'`, `'fr'`). Ova oznaka treba odgovarati stvarnom jeziku stranice. U JSON-LD postavljate `@language` ili na cijeli dokument ili na pojedinačne objekte ako se pojavljuje više jezika.
Primjer: Za proizvod na njemačkom jeziku koristite: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Ako isti proizvod označavate na engleskoj stranici, tada stoji `"inLanguage": "en"` i naziv na engleskom. Izbjegavajte miješanje više jezičnih verzija u jednom Schema objektu – to dovodi do nedosljednosti. Umjesto toga, koristite zasebne blokove oznaka po jeziku ili radite s `@language` nizovima unutar objekta ako je entitet višejezičan.
Za specifične podatke web stranice poput `WebSite` ili `WebPage` također trebate navesti jezik. Prilikom prebacivanja jezika na stranici možete koristiti `potentialAction` ili `translationOfWork` za upućivanje na druge jezične verzije. U praksi se pokazalo dobrim postaviti zaseban JSON-LD blok za svaki jezik u odgovarajućem <head> dijelu stranice. Na taj način dodjela ostaje jasna i alati za validaciju je ispravno tumače.
Pazite da jezični kodovi koriste ISO-639-1 standard (npr. „de“ za njemački, „en“ za engleski). Za regionalne varijante možete dodati oznake zemalja, poput „de-CH“ za švicarski njemački. Pritom morate provjeriti podržava li tražilica ovu finu razliku – u pravilu je dovoljan osnovni jezični kod. Validirajte svaku jezičnu verziju zasebno alatom Google Structured Data Testing Tool ili Rich Results Test. Zabilježite moguća upozorenja o nedostajućim jezičnim oznakama i ciljano ih otklonite.
Organization-Shema: podaci o tvrtki na više jezika
Organization shema idealna je za tvrtke s višejezičnim web stranicama jer pruža ključne informacije poput naziva, adrese i kontakt podataka. Za svaku jezičnu verziju trebate izraditi zaseban Organization objekt koji je označen na odgovarajućem jeziku. `name` treba navesti na ciljnom jeziku – dakle „Muster GmbH” na njemačkom i „Sample Inc.” na engleskom. Ako tvrtka ima jedinstveni naziv, dovoljan je prijevod opisa (`description`).
Za adrese koristite `PostalAddress` shemu s `addressCountry` i `addressLocality`. Za međunarodne lokacije možete predvidjeti više `location` unosa. Pazite da telefonski brojevi (`telephone`) imaju ispravan međunarodni pozivni broj. Primjer: za njemačku stranicu `+49 30 1234567`, za švicarsku `+41 44 1234567`. Isto vrijedi za e-mail adrese i radno vrijeme. Koristite `areaServed` za pokrivanje zemalja u kojima tvrtka posluje.
Često zanemaren detalj je svojstvo `sameAs` za profile na društvenim mrežama. Priložite jezično specifične profile ako postoje – primjerice njemačku Facebook stranicu i engleski Twitter račun. Također, `url` treba upućivati na početnu stranicu na odgovarajućem jeziku. Kod višejezičnih web stranica možete koristiti `translationOfWork` za povezivanje jezičnih verzija, pod uvjetom da stranice prikazuju isti sadržaj na drugom jeziku.
Praktična preporuka: implementirajte Organization shemu na početnoj stranici svake jezične verzije. U tu svrhu postavite JSON-LD skriptu u `<head>`. Izbjegavajte duplikate tako da za svaki jezik izradite zaseban blok s odgovarajućim `inLanguage`. Validirajte označavanje alatom Google Rich Results Test i provjerite jesu li kontakt podaci ispravno prikazani. Pravno morate voditi računa da su navedene informacije potpune i u skladu sa zaštitom podataka. Osobito kod više lokacija: obveza impressuma može se razlikovati ovisno o zemlji. U slučaju sumnje potražite pravni savjet. Ovim detaljima osiguravate da je vaša tvrtka dosljedno i ispravno predstavljena u svim jezičnim regijama.
Product-Schema: Jezično specifično označavanje opisa proizvoda
Za višejezične web stranice, označavanje proizvoda s Schema.org Product na odgovarajućem jeziku ključno je. Svaka jezična verzija proizvoda treba dobiti vlastitu Schema oznaku koja sadrži lokalni naziv, opis i atribute poput cijene, valute ili dostupnosti. Pritom koristite atribut `inLanguage` po jeziku – npr. `"inLanguage": "de-DE"` za njemački (Njemačka). Pazite da naziv proizvoda i opis u JSON-LD objektu doista budu na njemačkom, a ne samo jezična oznaka.
Česta pogreška je označavanje svih jezičnih varijanti istom `@id` (npr. globalnim ID-om proizvoda). Umjesto toga, svakom jeziku dodijelite vlastitu `@id`, poput `https://example.com/de/produkt/123` i `https://example.com/fr/produit/123`. Na taj način Google može prikazati ispravnu verziju. Kod cijena koristite `priceCurrency` s ISO-4217 kodom (npr. EUR, USD) i navedite cijenu jezično specifično – čak i ako cijena ostaje ista, pripada lokalnoj stranici.
Praktična preporuka: Kreirajte JSON-LD predložak za svaki proizvod koji dinamički postavlja jezične parametre. Provjerite svaku jezičnu verziju pojedinačno pomoću Google Rich Results Testa. Pazite da `url` atribut upućuje na odgovarajući jezični URL. Izbjegavajte miješanje svih jezika u jednom JSON-LD bloku – to često dovodi do grešaka validacije. Za slike, atribut `image` možete zadržati jezično neovisnim, ali provjerite jesu li URL-ovi slika ispravni.
Dodatno, možete prilagoditi `offers` s `availability` ovisno o tržištu (npr. `InStock` za Njemačku, `PreOrder` za Francusku). Globalno koristite `gtin` ili `mpn`, ali za `sku` zadržite lokalne varijante. Na kraju testirajte jesu li strukturirani podaci u Search Console ispravno indeksirani za svaku jezičnu verziju.
FAQ-Schema: Višejezična optimizacija FAQ stranica
FAQ stranice na više jezika imaju koristi od jasnog, jezično specifičnog označavanja pomoću sheme FAQPage. Svaka jezična verzija FAQ stranice dobiva vlastiti JSON-LD objekt. Postavite `inLanguage` na odgovarajući jezični kod (npr. `fr-FR` za francuski). Pitanja i odgovori moraju biti sastavljeni na ciljnom jeziku – strojni prijevod često nije dovoljan; neka ih provjeri izvorni govornik jer su nijanse ključne.
Tipična pogreška: ista `@id` za sve jezične varijante. Umjesto toga, koristite jezično specifični URL kao `@id`, npr. `https://example.com/de/faq/` i `https://example.com/en/faq/`. Unutar sheme FAQPage navedite pitanja kao `mainEntity` s `@type: Question` i pripadajući odgovor kao `acceptedAnswer`. Svako pitanje može dodatno dobiti `inLanguage`, ali to je redundantno ako je cijela stranica označena. Ograničite broj pitanja po stranici na najviše 10–15 jer tražilice uzimaju u obzir samo ograničen broj unosa.
Preporuka: Koristite sustav za upravljanje sadržajem koji nudi polje za višejezičnost po unosu FAQ-a. U JSON-LD izlazu dinamički dohvatite trenutni jezik. Validirajte svaku jezičnu verziju pojedinačno pomoću Rich Results Testa i obratite pozornost na upozorenja o nedostajućim `name` svojstvima pitanja. Dodajte svakom pitanju `url` koji upućuje na konkretnu sidrišnu točku kako bi korisnici mogli skočiti izravno na odgovarajući odgovor.
Napomena: FAQPage je prikladan samo za stranice s izričitim pitanjima i odgovorima. Nemojte ga koristiti za opće stranice podrške. Nakon implementacije testirajte vidljivost u Google pretraživanju – FAQ bogati isječci često se pojavljuju kod upita s upitnim riječima. Za višejezični SEO isplati se prilagoditi odgovore lokalnim izrazima (npr. „Kako mogu?“ vs. „Comment puis-je?“).
Suptilnosti inLanguage atributa: jezični kod i regionalna oznaka
Atribut `inLanguage` u Schema.org označava jezik sadržaja, pri čemu se vrijednost idealno sastoji od jezičnog koda (ISO 639-1) i opcionalnog regionalnog koda (ISO 3166-1 Alpha-2) – npr. `en-US` za američki engleski. Regija je važna kada se sadržaji razlikuju: „colour“ naspram „color“ ili različite mjerne jedinice. Bez regije, kod se tumači kao opći jezik. Stoga koristite `de-DE`, `de-AT`, `de-CH` za stranice specifične za zemlju, čak i ako je tekst gotovo identičan.
Praktični primjer: Proizvod se nudi na njemačkoj i austrijskoj stranici. Jezik je njemački, ali se cijene i uvjeti dostave razlikuju. Postavite `inLanguage: "de-DE"` za njemačku i `"de-AT"` za austrijsku stranicu. Na taj način Google bolje razumije regionalnu relevantnost. Isto vrijedi za `en-GB` i `en-US`. Ako vam nije potrebna regionalna razlika, dovoljno je `"de"` ili `"en"`. Međutim, pazite da jezični kod uvijek pišete malim slovima, a regiju velikim slovima (npr. `fr-CA`).
Česta pogreška je korištenje `inLanguage` na nadređenom objektu dok podobjekti imaju drugi jezik. Primjer: Web stranica na njemačkom, ali pojedinačni članak na engleskom. Tada postavite `inLanguage: "de"` na WebSite i `inLanguage: "en"` na Article. Validirajte ovo pomoću Schema validatora jer neki alati prijavljuju sukobe. Za višejezične stranice s hreflang oznakama, `inLanguage` bi trebao odgovarati odgovarajućoj hreflang vrijednosti – to pomaže Googleu da isporuči ispravnu verziju.
Praktična provedba: Definirajte jedinstveni `@id` za svaku jezičnu verziju i dosljedno postavite `inLanguage`. Koristite središnju konfiguracijsku datoteku koja sadrži ispravne kodove za svaki jezik. Testirajte pomoću alata schema.org hoće li se `inLanguage` oznaka prihvatiti. Savjet: Ne zaboravite `inLanguage` ni na AMP stranicama ili strukturiranim podacima putem Microdata. Kod JSON-LD postavite ga na najvišoj razini (npr. `WebSite` ili `WebPage`). Za dinamički sadržaj poput blog članaka, `inLanguage` može varirati ovisno o postu – tada ga postavite po stavci.
Pravilno označavanje višejezičnosti na jednoj URL adresi
Ako URL sadrži sadržaj na više jezika – primjerice putem jezičnog prebacivanja, tabova ili akordiona – morate u strukturiranim podacima jasno označiti koji tekst pripada kojem jeziku. Inače, crawler tražilice može pogrešno pretpostaviti da je sav sadržaj na jednom jeziku, što dovodi do pogrešaka u indeksiranju i prikazu.
Osnovna metoda je korištenje atributa `inLanguage` na odgovarajućim elementima. Kod FAQ sheme s pitanjima i odgovorima na njemačkom i engleskom na istoj stranici, označite svako pitanje i odgovor zasebno: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Isto vrijedi za Product sheme: opišite `name` i `description` po jeziku u zasebnom `Product` objektu s posebnim `inLanguage`, ili koristite `@language` i `@value` u svojstvu `multilingualDescription` (ako vaš vokabular to podržava).
Za organizacije s višejezičnim nazivima koristite niz `name` objekata: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Izbjegavajte deklarirati cijelu stranicu kao višejezičnu. Umjesto toga, dodjelu jezika napravite što je moguće granularnije. Uobičajena pogreška je postavljanje `inLanguage` samo na najvišoj razini sheme bez označavanja podređenih elemenata. Stoga u svom validacijskom tijeku provjerite jesu li svi tekstovi ispravno jezično označeni.
Kao konkretna preporuka: za svaku jezičnu varijantu na URL-u izradite zaseban shema objekt koji sadrži samo tekstove tog jezika i postavite `inLanguage` na odgovarajući jezični kod. Ako stranica prema zadanim postavkama prikazuje glavni jezik, a ostale učitava putem JavaScripta, pohranite strukturirane podatke za sve jezike statički u HTML-u. Alati poput Google Rich Results Testa pokazat će označava li se ispravno. Testirajte svaku jezičnu verziju zasebno tako što ćete natjerati crawler na željeni jezik putem URL parametra ili kontrole kolačića.
Razgraničenje hreflang i inLanguage: Kada koju metodu?
`hreflang` i `inLanguage` služe različitim svrhama u međunarodnom SEO-u i ne treba ih miješati. `hreflang` je HTML element ili HTTP zaglavlje koji tražilicama signalizira da postoje alternativne jezične ili regionalne verzije iste stranice. Služi za ispravnu isporuku odgovarajuće stranice korisnicima u različitim zemljama ili s određenim jezičnim postavkama. `inLanguage` je, s druge strane, atribut u strukturiranim podacima (Schema.org) koji označava jezik na kojem je napisan određeni tekst.
Kada koristiti što? Koristite `hreflang` ako imate zasebne URL-ove za različite jezične verzije (npr. `example.com/de/` i `example.com/en/`). Time sprječavate probleme s dupliciranim sadržajem i osiguravate da se ispravna stranica pojavi u isječku. `inLanguage` je potreban kada na jednom URL-u označavate višejezični sadržaj ili kada strukturirani podatak poput opisa proizvoda postoji na više jezika. `inLanguage` dakle nadopunjuje `hreflang` na razini pojedinačnih blokova teksta.
Česta zabluda: `inLanguage` ne zamjenjuje `hreflang`. Čak i ako svaki redak članka označite s `inLanguage`, tražilice bez `hreflang` ne znaju postoje li alternativne verzije cijele stranice. Obrnuto, `hreflang` nije dovoljan za precizan opis višejezičnog sadržaja unutar jednog URL-a. U praksi to znači: Ako imate zasebne stranice za svaki jezik, primarno je potreban `hreflang`, dok `inLanguage` u strukturiranim podacima na tim stranicama samo navodi konkretan jezik sadržaja. Ako se više jezika nalazi na jednom URL-u, nužno je koristiti `inLanguage` za svaki jezično specifičan element.
Konkretna preporuka: Planirajte svoju URL strategiju prije implementacije. Odlučite hoćete li koristiti zaseban URL po jeziku (ccTLD, poddomena, poddirektorij) ili zajednički URL s dinamičkim prebacivanjem jezika. Za potonje je ispravno označavanje `inLanguage` neophodno. U svakom slučaju provjerite da vaši `hreflang` tagovi upućuju na sve relevantne jezične verzije i da nema proturječja s `inLanguage` oznakama u strukturiranim podacima. Usklađivanje ova dva signala može pomoći tražilicama da pravilno mapiraju vaš sadržaj.
Validacijski tijek rada: Alati i automatske provjere
Ručna provjera strukturiranih podataka na svakoj jezičnoj verziji sklona je pogreškama i dugotrajna. Automatizirani validacijski tijek rada osigurava da su vaše Schema.org oznake ispravne i ostaju takve – čak i nakon ažuriranja sadržaja ili dodavanja novih jezika. Najvažniji alati su Google Rich Results Test (za tipove koje Google podržava, poput FAQ, Product) i Schema.org Validator (za provjeru sintakse). Dodatno, alati poput Screaming Frog SEO Spider mogu izvući strukturirane podatke s cijele web stranice i provjeriti ih na pogreške.
Ugradite provjeru u svoj CI/CD proces: nakon svake implementacije ili jezičnog ažuriranja pokrenite automatizirani test. Koristite API Google Rich Results Testa ili skriptu koja parsira vaše stranice i provjerava JSON-LD blokove prema vlastitoj shemi. Obratite posebnu pozornost na sljedeće izvore pogrešaka: - Nedostajući `inLanguage` na mjestima gdje se pojavljuje više jezika. - Proturječni jezični kodovi (npr. „de“ umjesto „de-DE“ za regionalne varijante). - Nepotpuna obavezna polja (npr. `name` kod Product na svakom jeziku). - Zastarjeli `hreflang` tagovi koji više ne odgovaraju vašim trenutnim URL-ovima.
Konkretna preporuka: Za svaku vrstu sheme (Organization, Product, FAQ) izradite popis potrebnih atributa po jeziku. Koristite alat za testiranje poput `json-schema` za automatsku validaciju podataka. Osim toga, redovito (npr. mjesečno) provedite potpuni crawl sa Schema.org Validatorom i generirajte izvješća o stranicama s pogreškama. Dokumentirajte kategorije pogrešaka i zadužite odgovorne osobe za ispravke. Imajte na umu da se strukturirani podaci moraju provjeravati na produkcijskim stranicama – testiranje na stagingu nije dovoljno jer tamo mogu biti drugačiji sadržaji. Samo tako osiguravate da se pogreške relevantne za tražilice pravovremeno isprave.
Višejezične web stranice zahtijevaju precizno strukturirane podatke kako bi tražilice mogle razumjeti sadržaj na temelju jezika. U ovom vodiču saznajte kako pravilno koristiti Schema.org oznake preko jezičnih granica – od organizacije preko proizvoda do FAQ-a. Uz praktične savjete i metode validacije izbjeći ćete tipične pogreške i poboljšati međunarodnu vidljivost svojih sadržaja.
Česte pogreške u međunarodnim strukturiranim podacima
Označavanje višejezičnih web stranica pomoću Schema.org nosi tipične zamke. Česta pogreška je izostanak ili netočno navođenje atributa jezika `inLanguage`. Ako, primjerice, nudite proizvod na njemačkom, ali u oznaci niste postavili `inLanguage: "de-DE"`, tražilice će podatke možda protumačiti kao jezično neutralne. Druga temeljna pogreška je miješanje jezika unutar jednog Schema bloka. Izbjegavajte postavljati svojstvo `name` na engleskom, a `description` na njemačkom u istom `Product` objektu. Umjesto toga, za svaku jezičnu verziju potrebno je izraditi zaseban blok s ispravnim `inLanguage`.
Još jedna raširena pogreška je korištenje neprikladnih Schema tipova. Za višejezično poduzeće mnogi pogrešno posežu za `LocalBusiness`, iako je `Organization` ispravan izbor kada ne postoji fizička adresa na svakom jeziku. Također, kod proizvoda se često zaboravlja jezično specifično označavanje svojstva `offers`. Osim toga, izostaje ažuriranje strukturiranih podataka nakon prijevoda: novoprevedeni tekst proizvoda mora se prilagoditi i u oznaci – inače će rezultati pretraživanja prikazivati zastarjele ili netočne informacije.
Zanemarivanje validacije dodatna je kapitalna pogreška. Nakon svake izmjene provjerite oznake odgovarajućim alatima. Netočne ili nedostajuće `@id` reference za entitete koji su isti na više jezika (npr. organizacija) dovode do duplikata ili nepotpunih podataka. Također se često zanemaruje interakcija s `hreflang`: tamo gdje ne postoje alternativni URL-ovi, morate raditi s `inLanguage` na istoj stranici.
Preporuke za djelovanje: Provjerite svaku oznaku za ispravno dodjeljivanje jezika. Koristite zasebne Schema blokove za svaku jezičnu verziju s jedinstvenim `@id`-ovima. Izbjegavajte miješanje – čak i u `aggregateRating` ili `review` jezik mora biti ispravan. Nakon svakog prijevoda provedite ponovnu validaciju i uskladite podatke s vidljivim sadržajem. Samo tako osiguravate da tražilice ispravno razumiju vašu višejezičnu ponudu.
Testiranje s Google Rich Results, Bing Webmaster Tools i Yandex
Provjera višejezičnih Schema.org oznaka ne bi se trebala ograničiti na samo jedan alat. Svaka tražilica ima vlastite interpretacije i kriterije validacije. Google Rich Results Test prvo je mjesto: unesite URL s vašom oznakom ili izravno zalijepite kod. Obratite pozornost na sve pogreške i upozorenja – osobito jesu li `inLanguage` oznake ispravno prepoznate. Čest problem je što Google prihvaća `de-DE`, ali uz nedostajući regionalni dio (`de`) ipak daje upozorenje. Testirajte svaku jezičnu verziju zasebno.
Bing Webmaster Tools nudi provjeru URL-a s prikazom strukturiranih podataka. Ovdje možete vidjeti interpretira li Bing oznake očekivano. Bing je često stroži u validaciji `inLanguage` i možda očekuje obavezno dvoslovni jezični kod bez regije (npr. `de` umjesto `de-DE`). Provedite test uživo i ispravite odstupanja. Bing također prikazuje moguće duplikate ako se `@id` vrijednosti koriste više puta.
Yandex Webmaster ima vlastiti validator, posebno relevantan za ruskojezične stranice. I ovdje možete testirati strukturirane podatke. Yandex podržava većinu Schema.org tipova, ali obrada pogrešaka se razlikuje. Osobito se kod `Product` oznaka često prigovara svojstvu `availability`. Stoga i ovdje testirajte svaku jezičnu verziju. Imajte na umu da Yandex može drukčije vagati regionalne jezične kodove poput `de-DE`.
Preporuke za djelovanje: Testirajte svaku jezičnu verziju u sva tri alata nakon implementacije i nakon svake promjene. Zabilježite odstupanja i prilagodite oznake tako da ih sve tri tražilice prihvaćaju. Idealno koristite dvoslovni jezični kod (`de`, `en`) u `inLanguage`, jer ga većina sustava podjednako razumije. Automatizirajte testove s CI alatima kako biste kod višejezičnih web stranica s mnogo stranica zadržali pregled.
Checklista za implementaciju višejezičnih Schema.org oznaka
Strukturiran pristup sprječava tipične pogreške u internacionalizaciji. Prije implementacije trebate odrediti jezičnu strategiju: koristite li zasebne URL-ove po jeziku (npr. `/de/produkt` i `/en/product`) ili jedan URL s prebacivanjem jezika? Za zasebne URL-ove koristite `hreflang` i pojedinačnu oznaku po URL-u. Kod jednog URL-a postavite više `inLanguage` blokova s različitim jezičnim kodovima. Također planirajte koji su tipovi sheme potrebni: tvrtka (Organization), proizvodi (Product), FAQ (FAQPage) itd.
Prilikom provedbe obratite pažnju na sljedeće: Svaki objekt sheme dobiva jedinstveni `@id` koji identificira entitet neovisno o jeziku. Za svaku jezičnu verziju kreirajte zaseban objekt koji putem `inLanguage` označava jezik. Koristite dosljedne jezične kodove – po mogućnosti dvoslovni ISO kod (npr. `de`, `en`) dopunjen regijom ako je potrebno. Povezujte ispravno unutar oznaka: kod `Organization` koristite `url` i `logo` s jezično specifičnim putanjama. Provjerite odgovaraju li tekstovi poput `name` i `description` vidljivom sadržaju.
Nakon implementacije slijedi validacija: testirajte svaku jezičnu verziju s Google Rich Results Testom, Bing Webmaster Tools i Yandexom. Ispravite pogreške i upozorenja. Obratite posebnu pažnju na nedostajući `inLanguage` ili pogrešne jezične kodove. Dodatno koristite Schema.org alat za validaciju od Googlea za provjeru sintakse. Dokumentirajte sve promjene i nakon svakog prijevoda provedite ponovna testiranja.
Konačno, praćenje je dio procesa: pratite učinkovitost u Search Console, posebno izvješća o strukturiranim podacima. Reagirajte na nove pogreške ili upozorenja. Ažurirajte oznake pravodobno kada mijenjate ili prevodite sadržaj. Provedite redovite audite kako biste osigurali dosljednost kroz sve jezične verzije. Dobro održavana implementacija Schema.org poboljšava vidljivost u rezultatima pretraživanja – bez jamstava, ali s praktičnom koristi.
Pravne napomene: Vlastita odgovornost kod automatskog prijevoda
Automatski prijevod strukturiranih podataka nosi pravne rizike koje vi kao operater višejezične web stranice morate samostalno provjeriti. Osobito kod Schema.org oznaka koje sadrže pravno relevantne sadržaje poput uputa o sigurnosti proizvoda, općih uvjeta poslovanja ili oznaka robnih marki, netočan prijevod može dovesti do slučajeva odgovornosti. Na primjer, pogrešno preveden naziv proizvoda ili obmanjujući opis proizvoda može prekršiti zakon o tržišnom natjecanju. Stoga preporučujemo da sve automatski izrađene prijevode pregleda izvorni govornik stručnjak za to područje. To se posebno odnosi na polja poput „description“ u Product shemi ili „answer“ u FAQ shemi, gdje su nijanse ključne.
Osim točnosti sadržaja, važnu ulogu imaju i aspekti zaštite podataka: ako vaša shema sadrži osobne podatke (npr. recenzije kupaca u Review shemi), morate osigurati da prijevod bude u skladu s GDPR-om. Automatske usluge prevođenja smiju se koristiti samo ako usluga nudi dovoljna jamstva zaštite podataka. Ne postoji opća zabrana, ali odgovornost za obradu podataka leži na vama kao operateru web stranice. Posavjetujte se s pravnim savjetnikom o specifičnim zahtjevima u vašim ciljnim zemljama.
Još jedna pravna zamka: korištenje „inLanguage“ s nedopuštenim jezičnim kodovima. Uvijek koristite službene BCP-47 kodove (npr. „de-DE“ umjesto „deutsch“). Netočni kodovi mogu dovesti do toga da vaše oznake budu ignorirane od strane tražilica – što iako nije pravni problem, utječe na pronalažljivost. Stoga prije objave provedite validaciju alatima poput Google Rich Results Testa i dodatno provjerite pokrivaju li prijevodi ispravno sva pravno relevantna polja.
Preporuka za djelovanje: Definirajte radni tok u kojem svaku automatski prevedenu Schema oznaku provjerava izvorni govornik urednik ili pravnik. Dokumentirajte taj proces kako biste u slučaju spora mogli dokazati da ste ispunili svoju dužnu pažnju. Izbjegavajte automatski prijevod tekstualnih blokova s pravnim karakterom (npr. uvjeti jamstva, izjave o odricanju od odgovornosti); prevedite ih ručno ili putem stručne službe.
Pregled: Lokalizacija potpomognuta umjetnom inteligencijom i budući razvoj shema
Lokalizacija Schema.org oznaka sve se više olakšava pomoću AI alata. Trenutačni sustavi mogu na temelju neuronskih mreža stvoriti prijevode koji su kontekstualno precizniji od starijih statističkih metoda. Za višejezične web stranice to znači: možete brže prevesti velike količine podataka o proizvodima ili FAQ sadržaja na više jezika. Međutim, osiguranje kvalitete i dalje je ključno jer AI modeli ne uviđaju uvijek ispravno specifične pojmove iz industrije ili regionalne nijanse. Praktičan pristup je korištenje AI za sirovi prijevod, nakon čega slijedi ljudska provjera. Alati poput Baduno kombiniraju AI prijevod s provjerom izvornog govornika i nude skalabilno rješenje.
Paralelno s razvojem AI, Schema.org kontinuirano proširuje svoj vokabular. Budući tipovi mogli bi se više usmjeriti na AI generirani sadržaj, poput sheme "AIContent" za označavanje strojno stvorenih tekstova. Povezivanje s Knowledge grafovima također postaje važnije: višejezične oznake mogle bi se u budućnosti automatski generirati iz središnjih baza znanja. Već sada postoji svojstvo "translationOfWork" koje eksplicitno prikazuje odnos između prevedenih sadržaja. Preporučujemo da takve nove značajke rano uključite u svoju strategiju kako biste bili spremni na ažuriranja tražilica.
Drugi trend su dinamične, jezično specifične oznake koje se prikazuju na temelju konteksta korisnika. Na primjer, shema proizvoda mogla bi sadržavati lokalnu valutu i mjernu jedinicu ovisno o lokaciji korisnika. Izazov je u pravilnoj upotrebi "inLanguage" i izbjegavanju sukoba s hreflang. Buduće verzije sheme mogle bi jasnije definirati kako prikazati regionalne varijante unutar jedne sheme. Da biste se pripremili, gradite svoje oznake modularno: koristite zasebne blokove za svaki jezik unutar istog JSON-LD ili koristite zasebne script oznake po jezičnoj verziji – ovisno o tehničkoj infrastrukturi.
Preporuka za djelovanje: Testirajte AI rješenja za prijevod s reprezentativnim skupom vaših podataka o shemi i izmjerite stopu pogrešaka. Pratite Schema.org izdanja kako biste identificirali nove značajke. Pilotirajte dinamičko prikazivanje oznaka za različite ciljne skupine i validirajte rezultate pomoću Search Consolea glavnih tražilica. Na taj način osiguravate da vaša višejezična stranica profitira od budućeg razvoja bez preuzimanja pravnih ili tehničkih rizika.
Primjer iz prakse: Postupna implementacija višejezične stranice proizvoda
Kako bismo teorijske osnove pretočili u praksu, razmotrimo fiktivnu e-commerce web stranicu koja nudi pametni telefon na njemačkom, engleskom i francuskom jeziku. Pretpostavimo da je stranica proizvoda dostupna putem jedinstvenog URL-a s prekidačem jezika (npr. example.com/smartphone). Cilj je označiti Schema.org Product markup s jezično specifičnim podacima.\n\n1. **Postavljanje jezičnih kodova**: Za svaku jezičnu varijantu koristi se jedinstvena vrijednost inLanguage. Primjer: njemački: "de-DE", engleski: "en-US", francuski: "fr-FR".\n\n2. **Označavanje naziva i opisa jezično specifično**: U JSON-LD markupu koristi se @graph niz. Svakoj jezičnoj varijanti dodjeljuje se vlastiti objekt proizvoda s pripadajućim inLanguage. Primjer:\n```json\n{\n "@context": "https://schema.org",\n "@graph": [\n {\n "@type": "Product",\n "inLanguage": "de-DE",\n "name": "Smartphone Pro Max",\n "description": "Leistungsstarkes Smartphone mit 128 GB Speicher",\n "offers": { ... }\n },\n {\n "@type": "Product",\n "inLanguage": "en-US",\n "name": "Smartphone Pro Max",\n "description": "Powerful smartphone with 128 GB storage",\n "offers": { ... }\n },\n {\n "@type": "Product",\n "inLanguage": "fr-FR",\n "name": "Smartphone Pro Max",\n "description": "Smartphone puissant avec 128 Go de stockage",\n "offers": { ... }\n }\n ]\n}\n```\n\n3. **Validacija markupa**: Pomoću Google Rich Results Testa provjerava se za svaku jezičnu verziju je li markup prihvaćen. Pritom treba paziti da podaci o inLanguage odgovaraju stvarnom jeziku stranice.\n\n4. **Integracija putem server-side ili JavaScript**: U praksi se markup najbolje generira na strani poslužitelja, tako da izvorni kod stranice sadrži cijeli JSON-LD. Kod dinamičkog prebacivanja jezika putem JavaScripta, markup se može učitati naknadno, ali ga tražilice možda neće zabilježiti.\n\n5. **Testiranje vidljivosti**: Nakon implementacije provjerava se prijavljuju li strukturirani podaci u Google Search Console kao valjani i pojavljuju li se bogati rezultati u pretrazi.\n\nOvaj korak-po-korak primjer pokazuje kako konkretno postupiti. Prilagodite strukturu svojoj tehnologiji i testirajte svaku jezičnu varijantu zasebno.
Suradnja s pružateljima usluga prevođenja i lokalizacije
Kada implementirate višejezične strukturirane podatke, često surađujete s prevoditeljima ili agencijama za lokalizaciju. Pritom je važno da i Schema.org oznake postanu dio procesa lokalizacije. Dogovorite s pružateljem usluga da ne samo vidljivi sadržaj, već i vrijednosti u JSON-LD (npr. „name”, „description”) moraju biti prevedene. Česta pogreška: agencija dobije samo tekst stranice, ali ne i strukturirane podatke. Stoga pripremite zaseban dokument sa svim Schema poljima – po mogućnosti u JSON formatu – i odredite koja se polja prevode ovisno o jeziku (npr. „offers” ili „review” mogu ostati globalni, dok „name” varira ovisno o jeziku).
Praktični savjet: Koristite glosare i prijevodne memorije i za svoje strukturirane podatke. Tako osiguravate da nazivi proizvoda i stručni pojmovi budu ujednačeni u svim oznakama. Zatražite od pružatelja usluga da postavi jezične kodove (inLanguage) prema vašim specifikacijama – primjerice „de-DE” umjesto samo „de”. Nakon isporuke provjerite na uzorku jesu li sve prevedene vrijednosti polja ispravno unesene u oznake. Automatizirani test pomoću Google Rich Results Testa može dati prve informacije.
Drugi aspekt: suradnja u osiguranju kvalitete. Dogovorite da prevedene Schema podatke prije objave pregleda izvorni govornik. Jer netočno prevedeni atributi proizvoda ili upute u FAQ pitanjima mogu naštetiti međunarodnom rangiranju. Dokumentirajte cijeli proces – od ekstrakcije izvornih tekstova do implementacije – i ažurirajte svoju kontrolnu listu za svaku jezičnu verziju. Tako izbjegavate da strukturirani podaci zastare pri kasnijim ažuriranjima sadržaja.
Pravna napomena: Odgovornost za točne prijevode leži na vama. Zatražite pisanu potvrdu o poštivanju vaših smjernica i ugovorno riješite pitanja odgovornosti za netočne prijevode. Preporučuje se neovisni pravni savjet.
Planiranje proračuna i procjena troškova za višejezičnu implementaciju Schema oznaka
Uvođenje strukturiranih podataka na više jezika uzrokuje jednokratne i tekuće troškove. Osim samog prevođenja sadržaja oznaka, postoje troškovi tehničke integracije, testiranja i održavanja. Za realno planiranje proračuna morate uzeti u obzir sljedeće stavke:
1. Prijevod Schema polja: Po jezičnoj verziji nastaju troškovi za prijevod svih relevantnih JSON-LD elemenata (naslovi, opisi, pitanja, odgovori itd.). Budući da se radi o kratkim, često tehničkim tekstovima, agencije za prevođenje mogu ponuditi posebne cijene. Predvidite dodatak od 10–20% za upoznavanje s Schema definicijama.
2. Tehnička prilagodba: Označavanje se mora izvršiti po jeziku bilo u zasebnim JSON-LD blokovima ili putem višejezičnih polja. Ovisno o sustavu, vaš razvojni tim trebat će dodatno vrijeme za implementaciju logike za promjenu jezika i zamjenskih opcija. Prema iskustvu, početni napor za web stranicu s pet jezičnih verzija iznosi između 15 i 25 radnih dana u razvoju.
3. Testiranje i osiguranje kvalitete: Svaka jezična verzija mora se pojedinačno validirati – pomoću Google Rich Results Testa, Schema.org validatora i ručnim uzorcima. Planirajte otprilike 1–2 dana po jeziku za prvo postavljanje i pola sata po izmjeni.
4. Tekuće održavanje: Kod ažuriranja asortimana proizvoda ili FAQ sadržaja, oznake se moraju pravovremeno prilagoditi. Odredite prevodi li tim za prevođenje uvijek i Schema podatke kod novog sadržaja. Sustav za upravljanje sadržajem koji automatski generira strukturirane podatke smanjuje dugoročni napor, ali zahtijeva odgovarajuće postavljanje.
5. Alati i licence: Ako koristite posebne alate za praćenje strukturiranih podataka (npr. API-je alata za webmastere ili vlastite nadzorne ploče), mogući su troškovi pretplate.
Kao pravilo, za cijeli proces (uvođenje na tri glavna jezika) trebali biste računati s proračunom od 5.000 do 15.000 eura, ovisno o opsegu stranice i broju proizvoda. Kod malih projekata s nekoliko FAQ stranica iznos može biti i niži.
Pravna napomena: Navedeni brojevi služe samo kao orijentacija. Zatražite individualne ponude od programera i prevoditelja i imajte na umu da stvarni troškovi mogu varirati ovisno o složenosti. Za obvezujuće izjave obratite se svojoj pravnoj i poreznoj savjetnici.
blog.faqT
Kako označiti FAQ shemu ako se pitanja razlikuju ovisno o jeziku?
Za svaku jezičnu verziju kreirajte zasebne unose mainEntity s pitanjem (question) i odgovorom (acceptedAnswer). Koristite inLanguage na najvišoj razini sheme FAQ za ciljni jezik. Kod identičnog sadržaja na različitim URL-ovima upotrijebite hreflang, dok je za prijevode na jednoj stranici dovoljno inLanguage. Pazite da su odgovori na odgovarajućem jeziku potpuni i točno prevedeni – automatske prijevode treba pravno provjeriti.
Mogu li označiti stranicu proizvoda s jednim URL-om za više jezika?
Da, pod uvjetom da je sadržaj na istom URL-u višejezičan (npr. putem kartica ili AJAX-a). Postavite inLanguage na odgovarajući DOM fragment ili upotrijebite zasebnu shemu po jeziku sa vlastitim inLanguage. Dodatno, za svaku jezičnu verziju osigurajte naziv (name) i opis (description) na ciljnom jeziku. Kod jasnih URL-ova za državu ili jezik, kombinacija s hreflang obično je poželjnija.
Koji su alati prikladni za validaciju višejezičnih Schema.org oznaka?
Google Rich Results Test provjerava pojedinačne URL-ove i prikazuje pogreške u jezičnim kodovima. Bing Webmaster Tools nudi slične funkcije. Za automatizirane testove na više stranica prikladni su crawleri poput Screaming Froga koji izdvajaju strukturirane podatke. Uvijek ručno provjerite jesu li prijevodi u name, description i ostalim svojstvima točni – u praksi se ovdje najčešće javljaju pogreške.
