Strukturovaná data mezinárodně: Schema.org napříč jazyky

Úvod do strukturovaných dat pro vícejazyčné webové stránky

Strukturovaná data podle Schema.org pomáhají vyhledávačům porozumět obsahu vašeho webu – a to napříč jazykovými hranicemi. Pokud provozujete více jazykových verzí, správné označování je ještě důležitější. Vyhledávače jako Google používají strukturovaná data k zobrazování rich results, jako jsou úryvky, ceny produktů nebo prvky FAQ. U vícejazyčných stránek musí být tato označení jazykově specifická, jinak mohou být poskytnuty nesprávné informace – například telefonní číslo z německé stránky ve francouzské verzi.

Typická chyba: převezmete schéma jednoho jazyka do jiných verzí, aniž byste upravili jazykové údaje. Nestačí pouze přeložit obsah; i struktura musí odrážet cílový jazyk. Například pole inLanguage objektu schématu by mělo uvádět jazyk dané stránky. Německá stránka produktu obdrží `inLanguage: 'de'`, anglická `inLanguage: 'en'`. Kromě toho můžete pomocí `translationOfWork` odkazovat na původní verzi.

Prakticky začněte s nejdůležitějšími typy stránek: organizace, produkt, FAQ. Ty jsou nejčastěji používány pro rich results. Předem zkontrolujte, které stránky v jakém jazyce jsou obzvláště relevantní. Pro mezinárodní firemní stránku se hodí schéma Organization, pro e-shop schéma Product. Dbejte na to, aby každá jazyková verze měla vlastní JSON-LD skript nebo samostatné položky ve skriptu. Používejte nástroje jako Google Rich Results Test k ověření každé jazykové verze zvlášť. Mějte na paměti, že test poskytuje pouze okamžitý snímek – pravidelná kontrola je doporučena.

Z právního hlediska je třeba dbát na to, že strukturovaná data nesmí obsahovat osobní údaje, které by porušovaly GDPR. Při uvádění kontaktních údajů v různých zemích se ujistěte, že jsou údaje správné a aktuální. V případě pochybností se poraďte s právním poradcem. Díky čisté implementaci vícejazyčných strukturovaných dat zvyšujete šance, že budete v různých jazykových regionech nalezeni s relevantními rich results.

Základy Schema.org a jazykového označování

Schema.org nabízí společnou slovníkovou strukturu podporovanou vyhledávači. Pro vícejazyčné weby je správné označení jazyka klíčové. Každý objekt schématu může mít vlastnost `inLanguage`, která udává jazyk obsahu (např. `'de'`, `'en'`, `'fr'`). Tento údaj by měl odpovídat skutečnému jazyku stránky. V JSON-LD nastavíte `@language` buď na celém dokumentu, nebo na jednotlivých objektech, pokud se vyskytuje více jazyků.

Příklad: Pro produkt v němčině použijete: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Pokud stejný produkt označíte na anglické stránce, bude místo toho `"inLanguage": "en"` a název v angličtině. Vyhněte se míchání vícera jazykových verzí v jednom objektu schématu – vede to k nekonzistencím. Místo toho použijte samostatné značkovací bloky pro každý jazyk, nebo pracujte s poli `@language` uvnitř objektu, pokud je entita vícejazyčná.

U webových údajů, jako jsou `WebSite` nebo `WebPage`, byste měli rovněž uvést jazyk. Při přepínání jazyků na stránce můžete pomocí `potentialAction` nebo `translationOfWork` odkazovat na jiné jazykové verze. V praxi se osvědčilo umístit pro každý jazyk samostatný JSON-LD blok do příslušné hlavičky stránky. Tím zůstává přiřazení jednoznačné a validační nástroje jej správně interpretují.

Dbejte na to, aby jazykové kódy používaly standard ISO 639-1 (např. „de“ pro němčinu, „en“ pro angličtinu). Pro regionální varianty můžete přidat kód země, tedy „de-CH“ pro švýcarskou němčinu. Přitom musíte ověřit, zda vyhledávač toto jemné rozlišení podporuje – obvykle postačí základní jazykový kód. Každou jazykovou verzi validujte samostatně pomocí Google Structured Data Testing Tool nebo Rich Results Test. Zaznamenejte si případná varování ohledně chybějících jazykových údajů a cíleně je opravte.

Schema organizace: Údaje o společnosti v několika jazycích

Schéma organizace je ideální pro společnosti s vícejazyčnými weby, protože poskytuje centrální informace jako název, adresu a kontaktní údaje. Pro každou jazykovou verzi byste měli vytvořit samostatný objekt Organization označený v příslušném jazyce. `name` by měl být uveden v cílovém jazyce – tedy „Muster GmbH“ v němčině a „Sample Inc.“ v angličtině. Pokud má společnost jednotný název, stačí překlad popisu (`description`).

U adres použijte schéma `PostalAddress` s `addressCountry` a `addressLocality`. Pro mezinárodní pobočky můžete předvídat více položek `location`. Dbejte na to, aby telefonní čísla (`telephone`) obsahovala správnou předvolbu země. Příklad: pro německou stránku `+49 30 1234567`, pro švýcarskou stránku `+41 44 1234567`. Totéž platí pro e-mailové adresy a otevírací dobu. Použijte `areaServed` k pokrytí zemí, ve kterých společnost působí.

Často přehlíženým detailem je vlastnost `sameAs` pro profily na sociálních sítích. Pokud existují, uveďte jazykově specifické profily – například německou Facebook stránku a anglický Twitter účet. Také `url` by měla odkazovat na jazykově specifickou domovskou stránku. U vícejazyčných webů můžete pomocí `translationOfWork` vytvořit propojení mezi jazykovými verzemi, pokud stránky zobrazují stejný obsah v jiném jazyce.

Praktické doporučení: Implementujte schéma organizace na domovské stránce každé jazykové verze. K tomu vložte JSON-LD skript do `<head>`. Vyhněte se duplicitám vytvořením samostatného bloku pro každý jazyk s odpovídajícím `inLanguage`. Validujte označení pomocí Google Rich Results Testu a zkontrolujte, zda jsou kontaktní údaje správně zobrazeny. Právně musíte dbát na to, aby uvedené informace byly úplné a v souladu s ochranou soukromí. Zejména u více poboček: Povinnost poskytnout impressum se může lišit podle země. V případě pochybností vyhledejte právní radu. Díky těmto detailům zajistíte, že vaše společnost bude ve všech jazykových regionech jednotně a správně reprezentována.

Schéma produktu: Jazykově specifické označování popisů produktů

Pro vícejazyčné weby je označení produktů pomocí Schema.org Product v příslušném jazyce zásadní. Každá jazyková verze produktu by měla mít vlastní schema značku, která obsahuje místní název, popis a atributy jako cena, měna nebo dostupnost. Použijte atribut `inLanguage` pro každý jazyk – např. `"inLanguage": "de-DE"` pro němčinu (Německo). Dbejte na to, že název produktu a popis v JSON-LD objektu jsou skutečně v němčině, nejen jazykový tag.

Častou chybou je označení všech jazykových variant stejným `@id` (např. globální ID produktu). Místo toho byste měli pro každý jazyk přiřadit vlastní `@id`, např. `https://example.com/de/produkt/123` a `https://example.com/fr/produit/123`. Google tak může zobrazit správnou verzi. U cen použijte `priceCurrency` s kódem ISO-4217 (např. EUR, USD) a uveďte cenu jazykově specificky – i když zůstává stejná, patří k místní stránce.

Praktické doporučení: Vytvořte pro každý produkt šablonu JSON-LD, která dynamicky nastaví jazykové parametry. Každou jazykovou verzi otestujte jednotlivě pomocí Rich Results Test od Googlu. Ujistěte se, že atribut `url` odkazuje na příslušnou jazykovou URL. Vyhněte se míchání všech jazyků v jednom JSON-LD bloku – to často vede k chybám validace. Obrázky můžete ponechat jazykově nezávislé pomocí atributu `image`, ale ujistěte se, že URL obrázků jsou správné.

Navíc můžete přizpůsobit `offers` s `availability` podle trhu (např. `InStock` pro Německo, `PreOrder` pro Francii). Globálně používejte `gtin` nebo `mpn`, ale u `sku` zachovejte lokální varianty. Nakonec otestujte, zda jsou strukturovaná data v Search Console správně indexována pro každou jazykovou verzi.

Schema FAQ: Optimalizace stránek s otázkami a odpověďmi pro vícejazyčné prostředí

Stránky FAQ ve více jazycích těží z jasného, jazykově specifického označení pomocí schematu FAQPage. Každá jazyková verze stránky FAQ obdrží vlastní JSON-LD objekt. Nastavte `inLanguage` na příslušný jazykový kód (např. `fr-FR` pro francouzštinu). Otázky a odpovědi musí být v objektu formulovány v cílovém jazyce – strojový překlad často nestačí; nechte je zkontrolovat rodilým mluvčím, protože nuance jsou klíčové.

Typická chyba: Stejné `@id` pro všechny jazykové varianty. Místo toho použijte jako `@id` jazykově specifickou URL, např. `https://example.com/de/faq/` a `https://example.com/en/faq/`. V rámci schematu FAQPage uveďte otázky jako `mainEntity` s `@type: Question` a odpovídající odpověď jako `acceptedAnswer`. Každá otázka může mít navíc `inLanguage`, což je však redundantní, pokud je celá stránka označena. Omezte počet otázek na stránku na maximálně 10–15, protože vyhledávače berou v úvahu pouze omezený počet položek.

Doporučení: Použijte redakční systém, který pro každý záznam FAQ nabízí pole pro vícejazyčnost. Při výstupu JSON-LD dynamicky zjišťujte aktuální jazyk. Každou jazykovou verzi validujte samostatně pomocí Rich Results Test a věnujte pozornost varováním o chybějících vlastnostech `name` u otázek. Ke každé otázce přidejte `url` odkazující na konkrétní kotvu – uživatelé tak mohou přejít přímo na příslušnou odpověď.

Poznámka: FAQPage je vhodné pouze pro stránky s explicitními otázkami a odpověďmi. Nepoužívejte jej pro obecné podpůrné stránky. Po nasazení otestujte viditelnost ve vyhledávání Google – FAQ Rich Snippety se často zobrazují u dotazů s tázacími částicemi. Pro vícejazyčné SEO se vyplatí přizpůsobit odpovědi místním formulacím (např. „Jak mohu?“ vs. „Comment puis-je?“).

Jemnosti inLanguage: Jazykový kód a oblastní nastavení

Atribut `inLanguage` ve Schema.org udává jazyk obsahu, přičemž hodnota by měla ideálně sestávat z jazykového kódu (ISO 639-1) a volitelného regionálního kódu (ISO 3166-1 Alpha-2) – např. `en-US` pro americkou angličtinu. Region je důležitý, pokud se obsah liší: „colour“ vs. „color“ nebo různé měrné jednotky. Bez regionu je kód interpretován jako obecný jazyk. Používejte tedy `de-DE`, `de-AT`, `de-CH` pro stránky specifické pro danou zemi, i když je text téměř identický.

Praktický příklad: Produkt je nabízen na německé a rakouské stránce. Jazyk je němčina, ale ceny a podmínky dodání se liší. Nastavte `inLanguage: "de-DE"` pro německou a `"de-AT"` pro rakouskou stránku. Google tak lépe pochopí regionální relevanci. Totéž platí pro `en-GB` a `en-US`. Pokud regionální rozlišení nepotřebujete, stačí `"de"` nebo `"en"`. Dbejte však na to, že jazykový kód se píše vždy malými písmeny a region velkými (např. `fr-CA`).

Častou chybou je použití `inLanguage` na nadřazeném objektu, zatímco podřízené objekty mají jiný jazyk. Příklad: WebSite v němčině, ale jeden článek v angličtině. Pak nastavte `inLanguage: "de"` na WebSite a `inLanguage: "en"` na Article. Ověřte to pomocí validátoru schémat, protože některé nástroje hlásí konflikty. U vícejazyčných stránek s hreflang tagy by `inLanguage` měl odpovídat příslušné hodnotě hreflang – to pomáhá Googlu doručit správnou verzi.

Praktická implementace: Pro každou jazykovou verzi definujte jedinečný `@id` a konzistentně nastavujte `inLanguage`. Používejte centrální konfigurační soubor, který obsahuje správné kódy pro každý jazyk. Otestujte pomocí nástroje schema.org, zda je tag `inLanguage` akceptován. Tip: Nezapomeňte na `inLanguage` ani u AMP stránek nebo strukturovaných dat pomocí microdata. U JSON-LD jej umístěte na nejvyšší úroveň (např. `WebSite` nebo `WebPage`). U dynamického obsahu, jako jsou blogové články, se může `inLanguage` lišit podle příspěvku – pak jej nastavte pro každou položku.

Správné označení vícejazyčnosti na jedné URL

Pokud URL obsahuje obsah ve více jazycích – například pomocí přepínače jazyků, záložek nebo accordionů – musíte ve strukturovaných datech jasně označit, který text patří ke kterému jazyku. Jinak by mohl crawler vyhledávače nesprávně předpokládat, že veškerý obsah je v jednom jazyce, což vede k chybám při indexaci a zobrazení.

Základní metodou je použití atributu `inLanguage` na odpovídajících prvcích. U schématu FAQ s otázkami a odpověďmi v němčině a angličtině na stejné stránce označte každou otázku a odpověď samostatně: ```json { "@type": "Question", "name": "Jak se přihlásím?", "inLanguage": "cs", "acceptedAnswer": { "@type": "Answer", "text": "Klikněte na ...", "inLanguage": "cs" } } ``` Podobně pro schémata produktů: Popište `name` a `description` pro každý jazyk v samostatném objektu `Product` s vlastním `inLanguage`, nebo použijte `@language` a `@value` ve vlastnosti `multilingualDescription` (pokud to váš slovník podporuje).

Pro organizace s vícejazyčnými názvy použijte pole objektů `name`: ```json { "name": [ {"@language": "cs", "@value": "Baduno s.r.o."}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Vyhněte se deklaraci celé stránky jako vícejazyčné. Místo toho proveďte přiřazení jazyka co nejvíce granulárně. Častou chybou je nastavení `inLanguage` pouze na nejvyšší úrovni schématu, aniž by byly označeny podřízené prvky. Proto ve svém validačním workflow zkontrolujte, zda jsou všechny texty správně jazykově označeny.

Jako konkrétní doporučení: Vytvořte pro každou jazykovou variantu na jedné URL samostatný objekt schématu, který obsahuje pouze texty v tomto jazyce, a nastavte `inLanguage` na příslušný jazykový kód. Pokud stránka standardně zobrazuje hlavní jazyk, ale ostatní se načítají přes JavaScript, vložte strukturovaná data pro všechny jazyky staticky do HTML. Nástroje jako Google Rich Results Test vám ukáží, zda je označení správně interpretováno. Testujte každou jazykovou verzi samostatně tím, že donutíte crawlera použít požadovaný jazyk pomocí parametru URL nebo cookie.

Rozlišení hreflang a inLanguage: Kdy použít kterou metodu?

`hreflang` a `inLanguage` plní v mezinárodním SEO odlišné účely a neměly by být zaměňovány. `hreflang` je HTML element nebo HTTP hlavička, která vyhledávačům signalizuje, že existují alternativní jazykové nebo regionální verze stejné stránky. Slouží k doručení správné stránky uživatelům v různých zemích nebo s určitým jazykovým nastavením. `inLanguage` je naopak atribut ve strukturovaných datech (Schema.org), který udává jazyk, ve kterém je napsán konkrétní textový prvek.

Kdy které použít? Použijte `hreflang`, pokud máte samostatné URL pro různé jazykové verze (např. `example.com/de/` a `example.com/en/`). Tím zabráníte problémům s duplicitním obsahem a zajistíte, že se ve snippet zobrazí správná stránka. `inLanguage` je nutné, pokud na jedné URL označujete vícejazyčný obsah nebo pokud strukturovaný datový prvek (např. popis produktu) existuje ve více jazycích. `inLanguage` tedy doplňuje `hreflang` na úrovni jednotlivých textových bloků.

Časté nedorozumění: `inLanguage` nenahrazuje `hreflang`. I když označíte každý řádek článku pomocí `inLanguage`, vyhledávače bez `hreflang` nevědí, zda existují alternativní verze celé stránky. Naopak `hreflang` nestačí k podrobnému popisu vícejazyčného obsahu v rámci jedné URL. V praxi to znamená: Máte-li samostatné stránky pro každý jazyk, je primárně vyžadováno `hreflang`, zatímco `inLanguage` pouze ve strukturovaných datech na těchto stránkách uvádí konkrétní jazyk obsahu. Pokud je na jedné URL více jazyků, musíte pro každý jazykově specifický prvek použít `inLanguage`.

Konkrétní doporučení: Naplánujte si URL strategii před implementací. Rozhodněte se, zda použijete pro každý jazyk samostatnou URL (ccTLD, subdoména, podadresář) nebo společnou URL s dynamickým přepínáním jazyků. V druhém případě je správné označení `inLanguage` nezbytné. V každém případě zkontrolujte, zda vaše `hreflang` tagy odkazují na všechny relevantní jazykové verze a nejsou v rozporu s údaji `inLanguage` ve strukturovaných datech. Slaďování těchto dvou signálů může vyhledávačům pomoci správně přiřadit váš obsah.

Validační workflow: nástroje a automatické kontroly

Ruční kontrola strukturovaných dat na každé jazykové verzi je náchylná k chybám a časově náročná. Automatizovaný validační workflow zajistí, že vaše Schema.org označení budou správná a zůstanou tak i po aktualizacích obsahu nebo přidání nových jazyků. Nejdůležitějšími nástroji jsou Google Rich Results Test (pro typy podporované Googlem, jako FAQ, Product) a Schema.org Validator (pro čistě syntaktickou kontrolu). Doplňkově pomohou crawlery jako Screaming Frog SEO Spider extrahovat strukturovaná data z celého webu a zkontrolovat chyby.

Zabudujte kontrolu do svého CI/CD procesu: po každém nasazení nebo jazykové aktualizaci spusťte automatický test. Použijte k tomu API Google Rich Results Test nebo skript, který parsuje vaše stránky a kontroluje JSON-LD bloky proti vlastnímu schématu. Zvláštní pozornost věnujte následujícím zdrojům chyb: - Chybějící `inLanguage` na místech, kde se vyskytuje více jazyků. - Rozporné jazykové kódy (např. „de“ místo „de-DE“ u regionálně specifických variant). - Neúplná povinná pole (např. `name` u Product v každém jazyce). - Zastaralé `hreflang` tagy, které již neodpovídají aktuálním URL.

Konkrétní doporučení: Vytvořte pro každý typ schématu (Organization, Product, FAQ) kontrolní seznam požadovaných atributů pro každý jazyk. Použijte testovací nástroj jako `json-schema` k automatické validaci dat. Pravidelně (např. měsíčně) provádějte kompletní crawl pomocí Schema.org Validatoru a nechte si vygenerovat reporty o chybných stránkách. Zdokumentujte kategorie chyb a přidělte odpovědné osoby pro opravy. Pamatujte, že strukturovaná data musí být kontrolována na živých stránkách – test na stagingu nestačí, protože tam mohou být jiné obsahy. Jen tak zajistíte, že chyby relevantní pro vyhledávače budou včas opraveny.

Časté chyby v mezinárodních strukturovaných datech

Označování vícejazyčných webů pomocí Schema.org s sebou nese typické nástrahy. Častou chybou je chybějící nebo nesprávně uvedený jazykový atribut `inLanguage`. Pokud například nabízíte produkt v němčině, ale v markupu neuvedete `inLanguage: "de-DE"`, vyhledávače mohou data interpretovat jako jazykově neutrální. Další zásadní chybou je míchání jazyků v rámci jednoho Schema bloku. Vyhněte se tomu, že v objektu `Product` nastavíte vlastnost `name` v angličtině a `description` v němčině. Místo toho je třeba pro každou jazykovou verzi vytvořit samostatný blok se správným `inLanguage`.

Další běžnou chybou je použití nevhodných typů Schema. U vícejazyčné firmy mnozí chybně sahají po `LocalBusiness`, přestože `Organization` je správná volba, pokud není k dispozici fyzická adresa v každém jazyce. U produktů se často zapomíná na jazykově specifické označení vlastnosti `offers`. K tomu přistupuje i neaktualizace strukturovaných dat po překladech: nově přeložený text produktu musí být upraven i v markupu – jinak výsledky vyhledávání zobrazí zastaralé nebo nesprávné informace.

Zanedbání validace je další kardinální chybou. Po každé změně byste měli markupy zkontrolovat vhodnými nástroji. Chybné nebo chybějící reference `@id` u entit, které jsou jazykově shodné (např. organizace), vedou k duplicitám nebo neúplným datům. Často se také ignoruje součinnost s `hreflang`: tam, kde neexistují alternativní URL, je nutné pracovat s `inLanguage` na stejné stránce.

Doporučení: Zkontrolujte každý markup na správné jazykové přiřazení. Pro každou jazykovou verzi použijte samostatné Schema bloky s jedinečnými `@id`. Vyvarujte se míchání – i v `aggregateRating` nebo `review` musí jazyk souhlasit. Po každém překladu proveďte novou validaci a porovnejte data s viditelným obsahem. Jen tak zajistíte, že vyhledávače správně porozumí vašim vícejazyčným nabídkám.

Test s Google Rich Results, Bing Webmaster Tools a Yandex

Ověřování vícejazyčných Schema.org markupů by nemělo být omezeno na jediný nástroj. Každý vyhledávač má vlastní interpretace a validační kritéria. Google Rich Results Test je prvním místem: zadejte URL s vaším markupem nebo vložte kód přímo. Sledujte všechny chyby a varování – zejména zda jsou `inLanguage` údaje správně rozpoznány. Častým problémem je, že Google akceptuje `de-DE`, ale při chybějící regionální části (`de`) přesto vydá varování. Testujte každou jazykovou verzi zvlášť.

Bing Webmaster Tools nabízí kontrolu URL s pohledem na strukturovaná data. Zde můžete vidět, zda Bing interpretuje markupy podle očekávání. Bing je často přísnější při validaci `inLanguage` a může vyžadovat dvoupísmenný jazykový kód bez regionu (např. `de` místo `de-DE`). Proveďte live test a opravte odchylky. Bing také zobrazí možné duplicity, pokud jsou hodnoty `@id` použity vícekrát.

Yandex Webmaster má vlastní validátor, který je relevantní zejména pro ruskojazyčné stránky. I zde můžete testovat strukturovaná data. Yandex podporuje většinu typů Schema.org, ale zpracování chyb se liší. Zejména u `Product` markupů je často kritizována vlastnost `availability`. Proto testujte i zde každou jazykovou verzi. Všimněte si, že Yandex může regionální jazykové kódy jako `de-DE` vážit odlišně.

Doporučení: Testujte každou jazykovou verzi ve všech třech nástrojích po implementaci a po každé změně. Zaznamenejte odchylky a upravte markupy tak, aby byly akceptovány všemi třemi vyhledávači. Ideálně použijte v `inLanguage` dvoupísmenný jazykový kód (`de`, `en`), který je srozumitelný pro většinu systémů. Automatizujte testy pomocí CI nástrojů, abyste udrželi přehled u vícejazyčných webů s mnoha stránkami.

Kontrolní seznam pro implementaci vícejazyčných Schema.org markupů

Systematický postup zabraňuje typickým chybám při internacionalizaci. Před implementací byste měli stanovit jazykovou strategii: Používejte samostatné URL pro každý jazyk (např. `/de/produkt` a `/en/product`) nebo jednu URL s přepínáním jazyků? Pro samostatné URL použijte `hreflang` a pro každou URL vlastní značkování. Při jedné URL vložte více bloků `inLanguage` s různými jazykovými kódy. Naplánujte také, které typy schémat jsou potřeba: Organizace (Organization), Produkty (Product), FAQ (FAQPage) atd.

Při realizaci dbejte na následující body: Každý objekt schématu obdrží jedinečné `@id`, které identifikuje entitu nezávisle na jazyce. Pro každou jazykovou verzi vytvořte samostatný objekt, který pomocí `inLanguage` udává jazyk. Používejte konzistentní jazykové kódy – nejlépe dvoupísmenný ISO kód (např. `de`, `en`) doplněný o region, pokud je to nutné. Správně odkazujte v rámci značkování: U `Organization` používejte `url` a `logo` s jazykově specifickými cestami. Zkontrolujte, zda texty jako `name` a `description` odpovídají viditelnému obsahu.

Po implementaci následuje validace: Otestujte každou jazykovou verzi pomocí Google Rich Results Test, Bing Webmaster Tools a Yandex. Opravte chyby a varování. Dbejte zejména na chybějící `inLanguage` nebo nesprávné jazykové kódy. Dále použijte nástroj pro validaci schema.org od Googlu ke kontrole syntaxe. Zdokumentujte všechny změny a po každém překladu proveďte opětovné testy.

Nakonec patří do procesu monitorování: Sledujte výkon v Search Console, zejména zprávy o strukturovaných datech. Reagujte na nové chyby nebo varování. Aktualizujte značkování včas, když měníte nebo překládáte obsah. Provádějte pravidelné audity, abyste zajistili konzistenci napříč všemi jazykovými verzemi. Dobře udržovaná implementace schema.org zlepšuje viditelnost ve výsledcích vyhledávání – bez záruk, ale s praktickým přínosem.

Právní upozornění: Vlastní odpovědnost při automatickém překladu

Automatický překlad strukturovaných dat s sebou nese právní rizika, která musíte jako provozovatel vícejazyčného webu na vlastní odpovědnost zkontrolovat. Zejména u značek Schema.org, které obsahují právně relevantní obsah, jako jsou bezpečnostní upozornění k produktům, obchodní podmínky nebo označení ochranných známek, může nepřesný překlad vést k případům odpovědnosti. Například chybně přeložený název produktu nebo zavádějící popis produktu může porušovat právo hospodářské soutěže. Proto doporučujeme nechat všechny automaticky vytvořené překlady zkontrolovat rodilým mluvčím s odbornými znalostmi. Týká se to zejména polí jako „description“ u schématu Product nebo „answer“ u schématu FAQ, kde jsou rozhodující nuance.

Kromě věcné správnosti hrají roli také aspekty ochrany údajů: Pokud vaše schéma obsahuje osobní údaje (např. hodnocení zákazníků u schématu Review), musíte zajistit, aby překlad proběhl v souladu s GDPR. Automatické překladové služby byste měli používat pouze tehdy, pokud služba poskytuje dostatečné záruky ochrany údajů. Neexistuje žádný obecný zákaz, ale odpovědnost za zpracování údajů nese provozovatel webu. Nechte si poradit od právního poradce ohledně konkrétních požadavků ve vašich cílových zemích.

Další právní nástraha: Použití „inLanguage“ s nepřípustnými jazykovými kódy. Vždy používejte oficiální kódy BCP-47 (např. „de-DE“ místo „deutsch“). Chybné kódy mohou vést k tomu, že vaše značky budou vyhledávači ignorovány – což sice nepředstavuje právní problém, ale zhoršuje to dohledatelnost. Proto před spuštěním proveďte validaci pomocí nástrojů, jako je Google Rich Results Test, a doplňkově zkontrolujte, zda překlady správně pokrývají všechna právně relevantní pole.

Doporučení k postupu: Definujte pracovní postup, ve kterém každé automaticky přeložené značení schématu zkontroluje rodilý mluvčí redaktor nebo právník. Tento proces dokumentujte, abyste v případě sporu mohli prokázat, že jste splnili svou povinnost péče. Vyhněte se automatickému překladu textových bloků s právním charakterem (např. záruční podmínky, vyloučení odpovědnosti); překládejte je ručně nebo prostřednictvím odborné služby.

Výhled: Lokalizace podporovaná umělou inteligencí a budoucí vývoj schémat

Lokalizace schema.org značek je stále více usnadňována pomocí nástrojů s umělou inteligencí. Současné systémy dokáží na základě neuronových sítí vytvářet překlady, které jsou kontextově přesnější než starší statistické metody. Pro vícejazyčné weby to znamená: můžete rychleji převádět velké množství produktových dat nebo obsahu FAQ do několika jazyků. Nicméně zásadní zůstává zajištění kvality, protože modely AI ne vždy správně zachytí oborově specifické termíny nebo regionální nuance. Praktickým přístupem je použití AI pro hrubý překlad následovaný lidskou kontrolou. Nástroje jako Baduno kombinují AI překlad s rodilou kontrolou a nabízejí tak škálovatelné řešení.

Současně s vývojem AI neustále rozšiřuje Schema.org svou slovní zásobu. Budoucí typy by mohly více reagovat na obsah generovaný AI, například schéma „AIContent“ pro označení strojově vytvořených textů. Důležitější se stává také propojení s znalostními grafy: vícejazyčné značky by mohly být v budoucnu automaticky generovány z centrálních znalostních bází. Již nyní existuje vlastnost „translationOfWork“, která explicitně vyjadřuje vztah mezi přeloženými obsahy. Doporučujeme tyto nové vlastnosti zahrnout do vaší strategie co nejdříve, abyste byli připraveni na aktualizace vyhledávačů.

Dalším trendem jsou dynamické, jazykově specifické značky, které se zobrazují na základě kontextu uživatele. Například schéma produktu by mohlo v závislosti na poloze uživatele obsahovat místní měnu a jednotku. Výzvou je správné použití „inLanguage“ a vyhnutí se konfliktům s hreflang. Budoucí verze schema by mohly jasněji definovat, jak zobrazovat regionální varianty v rámci jednoho schématu. Abyste se na to připravili, vytvářejte své značky modulárně: pro každý jazyk použijte samostatné bloky v rámci stejného JSON-LD nebo samostatné script tagy pro jazykovou verzi – v závislosti na technické infrastruktuře.

Doporučení: Otestujte řešení pro překlad založená na AI s reprezentativní sadou vašich schema dat a změřte chybovost. Sledujte poznámky k vydání Schema.org, abyste identifikovali nové vlastnosti. Pilotně nasaďte dynamické zobrazování značek pro různé cílové skupiny a validujte výsledky pomocí Search Console hlavních vyhledávačů. Tím zajistíte, že váš vícejazyčný web bude profitovat z budoucího vývoje bez právních nebo technických rizik.

Příklad z praxe: Postupná implementace vícejazyčné stránky produktu

Abychom převedli teoretické základy do praxe, uvažujme fiktivní e-commerce web, který nabízí smartphone v jazycích čeština, angličtina a francouzština. Předpokládejme, že stránka produktu je dostupná pod jedinou URL s přepínačem jazyků (např. example.com/smartphone). Cílem je opatřit Product-Markup schema.org jazykově specifickými údaji.

1. **Nastavení jazykových kódů**: Pro každou jazykovou variantu se použije jedinečná hodnota inLanguage. Příklad: Čeština: "cs-CZ", Angličtina: "en-US", Francouzština: "fr-FR".

2. **Jazykově specifické označení názvu a popisu**: V JSON-LD značce se použije pole @graph. Každé jazykové variantě je přiřazen vlastní produktový objekt s odpovídajícím inLanguage. Příklad: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Product", "inLanguage": "cs-CZ", "name": "Smartphone Pro Max", "description": „Výkonný smartphone s 128 GB úložištěm“, "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. **Validace značek**: Pomocí Google Rich Results Test se ověří, zda je značka pro každou jazykovou verzi přijata. Je třeba dbát na to, aby hodnoty inLanguage odpovídaly skutečnému jazyku stránky.

4. **Integrace na straně serveru nebo pomocí JavaScriptu**: V praxi je nejlepší generovat značku na straně serveru, aby zdrojový kód stránky obsahoval kompletní JSON-LD. Při dynamickém přepínání jazyků pomocí JavaScriptu lze značku načíst dodatečně, to však vyhledávače nemusí zachytit.

5. **Test viditelnosti**: Po implementaci se ověří, zda jsou strukturovaná data v Google Search Console hlášena jako platná a zda se ve vyhledávání zobrazují Rich Results.

Tento příklad krok za krokem ukazuje, jak konkrétně postupovat. Přizpůsobte strukturu své technologii a každou jazykovou variantu otestujte samostatně.

Spolupráce s překladatelskými a lokalizačními službami

Při implementaci vícejazyčných strukturovaných dat často spolupracujete s překladateli nebo lokalizačními agenturami. Je důležité, aby se schema.org markupy staly součástí lokalizačního procesu. Domluvte se s poskytovatelem služeb, že kromě viditelného obsahu musí být přeloženy také hodnoty v JSON-LD (např. „name“, „description“). Častou chybou je, že agentura obdrží pouze text stránky, nikoli však strukturovaná data. Proto poskytněte samostatný dokument se všemi poli schema – ideálně ve formátu JSON – a určete, která pole se mají překládat jazykově specificky (např. „offers“ nebo „review“ mohou zůstat globální, zatímco „name“ se liší podle jazyka).

Praktický tip: Používejte glosáře a překladové paměti i pro strukturovaná data. Tím zajistíte, že názvy produktů a odborné termíny budou jednotné ve všech markupách. Požádejte poskytovatele, aby nastavil jazykové kódy (inLanguage) podle vašich pokynů – například „cs-CZ“ místo jen „cs“. Po dodání namátkově zkontrolujte, zda jsou všechny přeložené hodnoty polí v markupách správně uloženy. Automatizovaný test pomocí nástroje Rich Results Test od Google může poskytnout první vodítka.

Další aspekt: Spolupráce při zajišťování kvality. Domluvte se, že přeložená schema data před zveřejněním zkontroluje rodilý redaktor. Nesprávně přeložené atributy produktů nebo instrukce v FAQ otázkách mohou poškodit mezinárodní hodnocení. Zdokumentujte celý proces – od extrakce zdrojových textů až po nasazení – a aktualizujte svůj kontrolní seznam pro každou jazykovou verzi. Tím se vyhnete zastarávání strukturovaných dat při pozdějších aktualizacích obsahu.

Právní upozornění: Odpovědnost za správné překlady nese vaše společnost. Nechte si písemně potvrdit dodržování vašich pokynů a smluvně vyřešte otázky odpovědnosti za chybné překlady. Doporučuje se nezávislé právní poradenství.

Plánování rozpočtu a odhad nákladů na vícejazyčnou implementaci schema

Zavedení strukturovaných dat ve více jazycích přináší jednorázové i průběžné náklady. Kromě samotného překladu markupů vznikají náklady na technickou integraci, testování a údržbu. Pro realistické plánování rozpočtu musíte zohlednit následující položky:

1. Překlad polí schema: Za jazykovou verzi vznikají náklady na překlad všech relevantních JSON-LD prvků (názvy, popisy, otázky, odpovědi atd.). Protože se jedná o krátké, často technické texty, mohou překladatelské agentury nabídnout speciální ceny. Počítejte s přirážkou 10–20 % za zapracování do definic schema.

2. Technické úpravy: Značkování musí být provedeno buď v samostatných JSON-LD blocích, nebo pomocí vícejazyčných polí. V závislosti na systému bude váš vývojářský tým potřebovat další čas na implementaci logiky pro přepínání jazyků a záložních řešení. Zkušenosti ukazují, že počáteční úsilí pro web s pěti jazykovými verzemi se pohybuje mezi 15 a 25 člověkodny ve vývoji.

3. Testování a zajištění kvality: Každou jazykovou verzi je nutné samostatně validovat – pomocí Google Rich Results Test, validátorů schema.org a manuálních kontrol. Počítejte s 1–2 dny na první nastavení a půl hodiny na každou změnu.

4. Průběžná údržba: Při aktualizaci produktového sortimentu nebo obsahu FAQ je nutné upravit i markupy. Stanovte, zda překladatelský tým vždy dodá i schema data. Systém pro správu obsahu, který strukturovaná data generuje automaticky, snižuje dlouhodobé náklady, ale vyžaduje odpovídající nastavení.

5. Nástroje a licence: Pokud používáte speciální nástroje pro monitorování strukturovaných dat (např. API nástrojů pro webmastery nebo vlastní dashboardy), mohou vzniknout poplatky za předplatné.

Jako pravidlo byste měli pro celý proces (zavedení ve třech hlavních jazycích) počítat s rozpočtem 5 000 až 15 000 eur, v závislosti na rozsahu stránek a počtu produktů. U malých projektů s několika FAQ stránkami může být částka nižší.

Právní upozornění: Uvedené údaje slouží pouze pro orientaci. Nechte si vypracovat individuální nabídky od vývojářů a překladatelů a mějte na paměti, že skutečné náklady se mohou lišit v závislosti na složitosti. Pro závazné informace se obraťte na své právní a daňové poradce.