Strukturovaná data: Která firemní web opravdu potřebuje
Strukturovaná data nejsou faktor pořadí. Jsou překladem: říkají strojům, co odstavec textu znamená, místo aby to musely hádat. Právě to stále víc rozhoduje o tom, jestli se stránka v odpovědích vůbec objeví.
To nejdůležitější
- Čtyři typy stačí téměř každému firemnímu webu: Organization, WebPage případně Article, BreadcrumbList a FAQPage.
- Doručuje se JSON-LD v
<head>– ne jako značkování ve fluidním textu. - Nejčastější chyba je mlčenlivá a drahá: údaje ve strukturovaných datech, které na stránce samotné nestojí.
- Tři hodně probírané typy si firma poskytující služby může ušetřit – uplatní se jen s odpovídající nabídkou nebo se skutečnými hodnoceními.
Stroj, který čte stránku, vidí nejdřív jen text. Že „Emma Woelk“ je člověk, „TEISENDA GmbH“ firma a „22. srpna 2026“ datum zveřejnění, musí uhodnout – nebo to tam výslovně stojí.
Strukturovaná data jsou právě tou výslovností. Nezlepšují umístění. Rozhodují o tom, jestli stránka vůbec přichází v úvahu pro rozšířená zobrazení a pro generované odpovědi.
Ty čtyři, které stačí
1. Organization – jednou, na úvodní stránce
Kdo jste: název, adresa, logo, rok založení, profily na dalších sítích. To je záznam, díky kterému se vedle výsledku vyhledávání může objevit logo – nejčastějším důvodem, proč chybí, je prostě chybějící tento záznam.
Důležité: Logo musí být k dispozici jako rastrový obrázek. SVG se na tomto místě nevyhodnocuje.
2. WebPage nebo Article – na každé stránce
Co tato stránka je: titulek, popis, jazyk, datum zveřejnění a poslední úpravy. U příspěvků navíc Article případně BlogPosting s autorem jako samostatným záznamem Person – s rolí, ne jen se jménem.
Důležité: Datum změny musí sedět. Datum, které se při každém sestavení stránky nastaví znovu, je signál, který sám sebe znehodnocuje.
3. BreadcrumbList – na všech podstránkách
Kde tato stránka stojí ve struktuře. Viditelně jako cesta nahoře na stránce, strojově čitelně v hlavičce. Obojí patří k sobě – cesta v datech, která na stránce neexistuje, je nesprávný údaj.
4. FAQPage – tam, kde jsou skutečné otázky
Sekce otázek na konci příspěvku. Pro odpovědní stroje vůbec nejcennější typ, protože dodává otázku a odpověď už jako dvojici – přesně v té podobě, v jaké se cituje.
Důležité: Jen pro otázky skutečně viditelné na stránce. Vymyšlené otázky, které stojí jen v datech, jsou porušením pravidel.
Tři, které si můžete ušetřit
Product a Offer. Pro služby s nabídkou na vyžádání nepřinášejí nic – bez ceny a dostupnosti se stejně nezobrazí. Smysl mají teprve u skutečného obchodu.
AggregateRating. Hvězdičky ve výsledku vyhledávání jsou lákavé a vázané na přísné podmínky: hodnocení musí být skutečná, ověřitelná a viditelná na stránce. Sám sobě udělená hodnocení jsou porušením pravidel se skutečným rizikem.
HowTo. V zobrazení bylo výrazně omezeno a většině firemních webů se už péče o něj nevyplácí.
Věděli jste, že…?
Strukturovaná data nejsou faktor pořadí – to Google opakovaně vyjasnil. Rozhodují o zobrazení, ne o pozici.
U odpovědních strojů je to trochu jinak. Model, který má ze stránky postavit odpověď, používá přednostně to, co je jednoznačně označené: dvojice otázka–odpověď, autora s rolí, datum poslední kontroly. Nemusí pak hádat, co patří k sobě. Užitek tedy neleží ani tak v hodnocení jako v citovatelnosti.
Jak se vkládají
Tři pravidla, která zamezí většině problémů.
- JSON-LD, v
<head>. Ne jako atributy ve fluidním textu. JSON-LD se dá udržovat odděleně od vzhledu a při změnách grafiky se neztratí. - Jeden blok na stránku, ne pět. Více záznamů patří do
@grapha propojují se navzájem přes@id. Příspěvek tak odkazuje na tutéž organizaci, která stojí na úvodní stránce, místo aby ji opakoval. - Vytvářet ze stejného zdroje jako viditelný obsah. Když titulek, datum a autor pocházejí ze stejných polí jako stránka sama, nemohou se vůbec rozejít. To je vůbec nejúčinnější prevence.
Nejdražší chyba je ta nejtišší: strukturovaná data říkají něco, co na stránce nestojí. Datum změny ze včerejška u textu z roku 2023. Autor, který se ve viditelné části neobjeví. Otázky v datech, které na stránce neexistují.
Žádnému kontrolnímu nástroji to nepřijde divné – data jsou formálně platná. Přijde to při ruční kontrole a důsledek se pak netýká jen dotčeného označení. Proto je pravidlo vytvářet ze stejného zdroje důležitější než jakákoli úplnost.
Prověřování – v tomto pořadí
| Krok | Čím | Co uvidíte |
|---|---|---|
| 1. Syntaxe | Schema Markup Validator | Jestli je JSON platný a typ správný |
| 2. Zobrazitelnost | Test pro rozšířené výsledky | Jestli by bylo rozšířené zobrazení možné |
| 3. Skutečnost | Search Console, oblast Vylepšení | Co bylo skutečně rozpoznáno, napříč všemi stránkami |
| 4. Shoda | Přečíst si to sami | Jestli každý údaj stojí viditelně i na stránce |
Krok čtyři je jediný, který za vás žádný nástroj neudělá – a jediný, u kterého vyjdou najevo vážné chyby.
Prověř strukturovaná data této stránky na úplnost a na shodu s viditelným obsahem. Viditelný obsah stránky: [vlož text stránky] JSON-LD stránky: [vlož blok] Úkoly: 1. Uveď každý údaj v JSON-LD, který se ve viditelném obsahu nevyskytuje. To je nejdůležitější bod – buď tu důkladný. 2. Uveď každý viditelný údaj, který by měl být označený, ale chybí (autor s rolí, datum změny, otázky, cesta). 3. Prověř, jestli jsou čtyři základní typy smysluplně obsazené: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Uveď typy v bloku, které pro firmu poskytující služby bez obchodu a bez ověřitelných hodnocení nemají žádný užitek. 5. Upozorni na každé porušení pravidel, zejména na sám sobě udělená hodnocení a otázky, které na stránce neexistují. Opravené JSON-LD vypiš na konci celé. Nevymýšlej si hodnoty – chybějící označ jako [doplnit].
Závěr
Strukturovaná data se rychle přeceňují a stejně rychle dělají špatně. Čtyři typy pokryjí potřebu firemního webu a jejich užitek leží méně v pozici než v tom, být citovatelný.
Jediné pravidlo, které to všechno unese: neoznačovat nic, co na stránce nestojí. Kdo data vytváří ze stejného zdroje jako viditelný obsah, vyřešil tento problém strukturálně – a dodatečné kontroly si může do velké míry ušetřit.
Časté otázky
Která strukturovaná data potřebuje firemní web?
Čtyři typy stačí: Organization jednou na úvodní stránce, WebPage případně Article na každé stránce, BreadcrumbList na všech podstránkách a FAQPage všude tam, kde jsou skutečné, viditelné otázky. Product, AggregateRating a HowTo se firmám poskytujícím služby zpravidla nevyplatí.
Zlepšují strukturovaná data pozici ve vyhledávání?
Ne. Nejsou faktorem pořadí, ale rozhodují o zobrazení – třeba o tom, jestli se ve výsledku vyhledávání může objevit logo, cesta nebo rozbalovací otázky. U odpovědních strojů zvyšují citovatelnost, protože dvojice otázka–odpověď, autor a datum jsou jednoznačně označené místo aby se musely hádat.
Proč Google nezobrazuje naše logo?
Nejčastějším důvodem je chybějící nebo neúplný záznam Organization na úvodní stránce. Druhý nejčastější důvod: uložené logo existuje jen jako SVG – na tomto místě je potřeba rastrový obrázek. Ani při správném označení nevzniká nárok na zobrazení.
Jaká je nejčastější chyba u strukturovaných dat?
Údaje, které stojí v datech, ale ne ve viditelném obsahu: nesprávné datum změny, neuvedený autor, vymyšlené otázky. Kontrolní nástroje to nehlásí, protože data jsou formálně platná. Zamezit se tomu dá tím, že se označení vytváří ze stejného zdroje jako viditelný text.
JSON-LD, nebo mikrodata?
JSON-LD v <head>. Je to forma doporučená Googlem, dá se udržovat odděleně od vzhledu a při změnách grafiky se neztratí. Mikrodata rozprostírají označení po fluidním textu a lámou se při každé přestavbě stránky.
Marketing, který se nastaví sám
Beta verze Studio Engine je otevřená. Zarezervujte si místo a podílejte se od začátku.
Zapojit se do bety →