2026-01-14 · Redakce Baduno · 6 blog.readMin · Blog a znalosti
Strukturovaná data: Schema.org srozumitelně vysvětleno
Strojově čitelné doplňující informace promění výsledky vyhledávání na bohaté výsledky s hodnocením, FAQ a firemními údaji. Tak to funguje.
Co jsou strukturovaná data
Neviditelné JSON bloky ve zdrojovém kódu popisují, co je na stránce: Toto je společnost s touto adresou, toto je článek s tímto datem, toto je FAQ s těmito otázkami. Vyhledávače nemusí hádat – čtou.
Co to přináší
Oprávnění pro rozšířená zobrazení (výtažky FAQ, drobečková navigace, panel organizace), lepší porozumění souvislostem a čistší položky znalostního grafu. Žádný turbo ranking – ale více místa a důvěry ve výsledku vyhledávání.
Nejdůležitější typy pro podniky
Organization s registračními údaji, WebSite, Service nebo Product s Offer, Article pro odborné články, FAQPage a BreadcrumbList. Pro vícejazyčnost platí: Každá jazyková verze nese své vlastní, přeložené označení.
Nezapomeňte na validaci
Test bohatých výsledků ukazuje, co Google čte, Schema Validátor kontroluje syntaxi. Chybné označení je horší než žádné – stojí důvěru a v horším případě rozšířené zobrazení.
Strukturovaná data a hreflang: Perfektní souhra pro vícejazyčné stránky
Častým zdrojem chyb na vícejazyčných webech je nekonzistentní používání strukturovaných dat a hreflang tagů. Zatímco hreflang signalizuje vyhledávačům jazykové a regionální alternativy stránky, strukturovaná data odhalují typ obsahu. Oba jsou na sobě nezávislé, ale vzájemně se doplňují: Německá produktová stránka by měla obsahovat hreflang tag odkazující na anglickou variantu a zároveň v bloku strukturovaných dat uvádět stejné ID produktu s různými nabídkami a jazyky. Důležité: Každá jazyková verze má vlastní JSON-LD blok s odpovídajícími hodnotami – jinak vznikají rozpory. Test rozšířených výsledků od Googlu často odhalí chyby, například pokud organizace v německé verzi obsahuje anglickou adresu. Po každém nasazení nové jazykové verze proto vždy kontrolujte obě označení současně.
Údržba a aktualizace: Kdo spravuje data?
Strukturovaná data nejsou jednorázový projekt. Pokud se změní ceny, otevírací doby nebo podrobnosti o produktu, je nutné aktualizovat JSON-LD bloky. Ideálně by dynamické naplňování měl zajišťovat redakční systém. Pokud automatizace chybí, je třeba v týmu jasně určit odpovědnou osobu – například redaktora pro články a FAQ data, vývojáře pro organizační data. Vyhýbejte se datovým silům: Zastaralé telefonní číslo v bloku Organization poškozuje důvěru. Plánujte čtvrtletní revize všech strukturovaných dat, minimálně však před každým větším relaunchem. Užitečný je centrální dashboard zobrazující všechny označené stránky a stav jejich validace.
Vytváření a kontrola strukturovaných dat s podporou UI
Moderní nástroje UI dokážou z nestrukturovaného textu automaticky generovat JSON-LD – například pro FAQ stránky nebo články. To práci urychluje, ale přináší rizika: UI často přehlíží kontextové nuance (např. nesprávnou cenu nebo zastaralé datum). Proto je nezbytná rodilá kontrola redaktorem. Využijte UI pro hrubý návrh a poté nechte člověka hodnoty validovat. I u vícejazyčných stránek UI pomáhá s překlady strukturovaných dat, ale hreflang tagy a jazykově specifická ID musí být nastavena ručně. Osvědčený postup: UI vytvoří anglický standardní blok, místní redaktor opraví a doplní pole specifická pro danou zemi.
Strojově čitelné doplňující informace promění výsledky vyhledávání na bohaté výsledky s hodnocením, FAQ a firemními údaji. Tak to funguje.
Označení dynamického obsahu: FAQ, recenze a produkty
Obzvláště časté chyby se vyskytují u dynamického obsahu. Stránky FAQ by měly mít pro každou otázku samostatný JSON-LD záznam – nikoli celý seznam jako jeden objekt Question. U recenzí musí být správně uvedena hodnotící stupnice (např. bestRating a worstRating). Stránky produktů s variantami vyžadují bloky AggregateOffer se všemi informacemi o ceně a dostupnosti. Používejte šablony v CMS, které automaticky generují správné typy. Otestujte každou dynamickou stránku jednotlivě v testu Rich Results, protože chyby se projeví až u konkrétních hodnot. Častou chybou je použití 'Review' místo 'AggregateRating' pro průměrná hodnocení.
Kombinace více typů Schema.org na jedné stránce
Na jedné stránce můžete paralelně označit více typů Schema.org, pokud popisují různé aspekty obsahu. Stránka produktu může současně obsahovat Product-Block (s cenou, dostupností), Organization-Block (pro výrobce) a Review-Block (pro hodnocení). Důležité je, aby každý typ byl ve vlastním JSON-LD skriptu nebo byl konzistentně propojen pomocí @id. Příklad: Product-Block odkazuje na Organization-Block pomocí "brand": {"@id": "#organisation"}. Vyhněte se protichůdným údajům – například různým adresám v Organization a LocalBusiness bloku. Každý typ musí být obsahově správný a jazykově specifický: Francouzská stránka obdrží francouzské hodnoty ve všech blocích. Použijte CMS k modulární správě typů, abyste nemuseli každý blok upravovat ručně. Zkontrolujte v Rich-Results-Testu, zda jsou všechny bloky akceptovány – některé testy zobrazí pouze první blok. Čistá kombinace více typů zvyšuje šance na bohaté výsledky jako karusel, produktové boxy nebo panel organizace.
Práce s @id a referencemi pro propojená data
Schema.org umožňuje odkazovat na objekty pomocí @id a vyhnout se tak redundantním datům. Místo opakování celé organizace na každé stránce definujte centrální Organization-Block s jedinečným @id (např. "https://beispiel.de/#firma") a v ostatních blocích na něj odkazujte pomocí "@id": "https://beispiel.de/#firma". To je užitečné zejména u vícejazyčných webů: Organizace zůstává stejná, pouze jazykově specifická pole jako „name“ nebo „description“ se liší. Dbejte na to, aby @id byla konzistentní napříč všemi jazykovými verzemi – tedy stejné URI pro němčinu, angličtinu atd. Reference lze použít také pro autory článků, značky produktů nebo položky recenzí. Ověřte pomocí Schema-Validátoru, že všechny @id odkazy jsou řešitelné. Chyba: Pokud odkazované @id není definováno ve stejném zdrojovém kódu stránky nebo na jiné stránce, validace selže. Proto centrální entity uložte buď do globálního souboru (např. organisation.json) a vložte je přes JavaScript, nebo použijte CMS k dynamickému vložení. Čistá struktura @id usnadňuje vyhledávačům propojování informací a zlepšuje konzistenci v Knowledge Graphu.
Správné označení BreadcrumbList: tipy a úskalí
Označení BreadcrumbList se může zdát jednoduché, ale v praxi se často objevují chyby, které ohrožují úspěch rich snippetů. Správná implementace začíná pochopením hierarchie: Každá položka v seznamu vyžaduje objekt ItemListElement, který dále obsahuje objekt ListItem. Klíčová je vlastnost position – čísluje prvky vzestupně, počínaje 1 pro domovskou stránku. Vyhněte se vynechání domovské stránky – i když není ve viditelné drobečkové navigaci, měla by být obsažena ve strukturovaných datech. Častou chybou je použití absolutních URL bez ohledu na jazykovou verzi: Ujistěte se, že URL v drobečkové navigaci odkazuje na správnou jazykovou variantu, např. /de/produkte místo /en/products. Také pojmenování prvků musí být jazykově specifické – 'Startseite' v němčině, 'Home' v angličtině. Použijte pole name pro zobrazený text a vyhněte se zkratkám, které by mohly vyhledávače zmást. Po implementaci otestujte každou cestu pomocí nástroje Rich Results Test, protože zejména u dynamicky generovaných drobečků může snadno dojít k prohození pozic nebo k duplicitním položkám. Mějte na paměti, že Google zobrazuje maximálně deset prvků – kratší a přesná navigace je proto lepší než příliš dlouhá.
Vnořené objekty a reference: @id a @context
Složitá strukturovaná data často využívají propojení více typů prostřednictvím referencí @id. Typickým příkladem je stránka produktu, která obsahuje jak nabídku (Offer), tak recenzi (Review). Namísto vložení všech dat do jednoho monolitického bloku je čistší definovat samostatné bloky s jedinečnými hodnotami @id a na ně odkazovat. Hodnota @id musí být jedinečná v rámci stránky i celé domény – ideálně použijte absolutní URL objektu s fragmentem jako #product-1. Vyhněte se generickým ID jako #produkt, protože by mohla způsobit konflikty na více stránkách. Dalším důležitým aspektem je @context: standardně se používá slovníček Schema.org, ale pro proprietární rozšíření lze zadat vlastní kontext. Dbejte na to, aby se ověřená rozšíření jako health-lifesci nebo bib omylem nedostala na komerční stránky. U vícejazyčných stránek musí být reference @id jazykově specifické: Německá stránka produktu odkazuje na německé Offer ID, nikoli na anglické. Užitečnou technikou je použití @reverse pro inverzní vztahy, například když produkt odkazuje na organizaci, ale organizace nemá přímý seznam všech produktů. Takové řetězení otestujte v Schema Validatoru, protože již chybějící dvojtečka může vést k chybě validace. Naplánujte dostatek času na ladění referencovaných objektů – jsou častým zdrojem chyb v rozsáhlých implementacích.
blog.faqT
Mohu na staré stránky dodatečně přidat strukturovaná data?
Ano, strukturovaná data lze kdykoli doplnit. Ujistěte se, že všechny údaje jsou aktuální. Použijte test bohatých výsledků od Googlu ke kontrole správného provedení. U mnoha stránek se doporučuje postupovat postupně podle typu obsahu.
Jak často by měla být strukturovaná data aktualizována?
Vždy, když se změní základní informace (ceny, otevírací doba, podrobnosti o produktu). Naplánujte alespoň čtvrtletní celkovou kontrolu. Dynamické systémy mohou data automaticky vyplňovat – to snižuje náklady na aktualizaci a zdroje chyb.
