Strukturovaná data jsou strojově čitelný popis obsahu stránky. Vyhledávači (a čím dál častěji i AI přehledům) říkají: tohle je firma, tohle článek, tohle produkt s cenou, tohle FAQ. Nejsou to „tajný kód na lepší pozice". Jsou to jasně pojmenovaná fakta o tom, co na URL opravdu je.
Na web se dají dostat víc způsoby. Ten, který na projektech používám skoro vždycky, je JSON-LD: jeden JSON blok ve <script type="application/ld+json">, oddělený od HTML šablony. Dá se generovat z CMS, snadno se testuje a při redesignu vám nerozbije polovinu markupů.
Níže: proč to řešit, co ze slovníku schema.org v praxi použít, jak to kontrolovat v GSC a proč mám JSON-LD radši než microdata.
Proč se to vůbec dělá
Vyhledávač vidí HTML. Z něj si něco odvodí sám. Strukturovaná data mu ale dají explicitní model:
- tohle je organizace s názvem, IČO a kontaktem,
- tohle je článek s autorem a datem,
- tohle je produkt s cenou a dostupností,
- tohle je FAQ, které je opravdu na stránce,
- tohle je cesta v drobečkové navigaci.
K čemu to je v praxi:
- Lepší šance na rozšířené výsledky (FAQ, produkt, článek, drobečky) - když Google uzná, že to dává smysl.
- Méně dohadů u entity firmy, produktu nebo autora. Hodí se i ve chvíli, kdy výsledky vypadají spíš jako shrnutí než jako deset modrých odkazů.
- Kontrola kvality vlastního webu - když JSON-LD říká něco jiného než viditelný obsah, máte bug v datech, ne „SEO trik".
Co to není: záruka vyšších pozic, náhrada za dobrý obsah, ani důvod plnit fiktivní recenze a FAQ, které na stránce nejsou.
Schema.org: užitečný slovník, mizerný návod na život
Schema.org je společný slovník typů a vlastností (Organization, Product, Article, FAQPage…). Bez něj by každý vyráběl vlastní formát.
Problém je, že dokumentace je záměrně obecná. Popíše, že Product může mít offers, ale neřekne vám:
- která pole Google v Česku reálně používá u vašeho typu výsledku,
- co se stane, když cenu v JSON-LD máte jinou než u tlačítka Koupit,
- že nacpat
AggregateRatingbez viditelných recenzí je rychlá cesta k problémům, - jak to skloubit s e-shopovou platformou, consent mode a cache.
V praxi proto nezačínám u celého stromu typů na schema.org. Začínám u otázky: jaký typ stránky to je a co z toho má smysl říct nahlas? Teprve pak hledám odpovídající typ a povinná / doporučená pole podle toho, co chce Google u rich results - ne podle toho, kolik vlastností se vejde do generátoru.
JSON-LD vs. microdata (a proč mám radši JSON-LD)
Historicky šly strukturovaná data do stránky několika způsoby. Dva, které potkáváte pořád:
- Microdata - atributy přímo v HTML (
itemscope,itemtype,itemprop). Markup a význam jsou propletené. - JSON-LD - jeden (nebo víc) JSON bloků v
<script type="application/ld+json">, typicky v<head>nebo na konci stránky. HTML zůstává HTML, data jsou data.
Microdata dávají smysl teoreticky: význam je „u elementu". V reálném webu to ale bolí. Redesign přesune nadpis, někdo omylem smaže itemprop, šablona produktu se rozpadne na varianty a najednou máte poloviční Product bez ceny. Debugovat microdata v gigantické Vue/Twig šabloně je radost pro masochisty.
JSON-LD mám rád, protože:
- Odděluje prezentaci od významu - designer sahá do komponent, data jdou z jedné vrstvy (CMS, feed, computed objekt).
- Snáz se generuje a testuje - jeden JSON, jedna validace, jasný diff v gitu.
- Míň rozbíjí responzivitu a refaktoring - nemusíte obalovat každý
<span>sémantikou pro roboty. - Google JSON-LD doporučuje a v tooling (Rich Results Test) je s ním práce přímočará.
Microdata tím neprohlašuju za zakázaná. Když je zdědíte na starém e-shopu a fungují, nemusíte je hned pálit. U nového webu nebo větší úpravy ale defaultně stavím JSON-LD. Míň překvapení, míň nočních „proč zmizel rich snippet po výměně headeru".
Co smysl má vyplňovat (a co spíš ne)
Pravidlo číslo jedna: JSON-LD musí sedět s tím, co uživatel vidí. Když to na stránce není, nepatří to do dat.
Obvykle dává smysl:
- Organization / LocalBusiness - název, URL, logo, kontakt, adresa (když je veřejná a pravdivá).
- WebSite - často se
SearchAction, pokud máte funkční vyhledávání na webu. - WebPage + BreadcrumbList - levná výhra pro orientaci ve výsledcích.
- Article / BlogPosting - headline, datum, autor, image u editorial obsahu.
- Product + Offer - u e-shopu: název, cena, měna, dostupnost, případně SKU. Cena musí sedět s tím, co je na detailu.
- FAQPage - jen když otázky a odpovědi opravdu renderujete na stránce.
Obvykle smysl nemá (nebo je to rizikové):
- vymýšlet hodnocení a recenze „pro snippet",
- FAQ, které na URL neexistuje,
- cpát desítky volitelných polí, protože generátor měl checkbox,
- míchat konfliktní typy na jedné URL bez důvodu,
- tvrdit v datech skladem, když e-shop ukazuje vyprodáno,
- kopírovat cizí příklady i s americkým
telephoneformátem a fiktivním IČ.
Míň přesných polí > hromada nepřesných. Radši solidní Organization + BreadcrumbList + Article než „všechno ze schema.org, ale napůl špatně".
Jak se na to podívat v praxi (nástroje)
Bez tooling jste slepí. Tohle používám pravidelně:
- Google Rich Results Test - první zastávka. Vložíte URL nebo HTML, uvidíte, jestli Google markup vůbec přečetl a jestli je kandidát na konkrétní rich result.
- Schema Markup Validator - kontrola proti slovníku schema.org. Hodí se, když Rich Results Test mlčí a vy nevíte, jestli je JSON syntakticky / typově rozbitý.
- Google Search Console - reporty u vylepšení / rich results (názvy sekcí se časem posouvají): platné položky, varování, chyby, neparsovatelná strukturovaná data. Koukejte na trendy po nasazení, ne jen na jednu zelenou URL v testu.
- Zdrojový kód stránky - hledejte
application/ld+json. Když blok v HTML není (nebo ho dokreslí až rozbitý JavaScript), robot z toho nic nemá. - Screaming Frog (nebo podobný crawler) - hromadný export strukturovaných dat napříč webem. Ideální po migraci nebo když máte podezření, že produktová šablona generuje bordel jen u variant.
- Generátory markupů (Merkle a spol.) - dobré na první draft JSON-LD. Špatné jako jediný zdroj pravdy. Vždycky výstup upravte podle reálného obsahu stránky.
Doplňkově: v Chrome DevTools ověřte, že se skript opravdu dostane do HTML odpovědi ze serveru, ne až do DOMu po hydrataci v prohlížeči. U SPA/SSR je to častá past.
Co konkrétně sledovat v Google Search Console
GSC vám neřekne „máte dobré SEO". Řekne vám, jestli Google markup čte a jestli u konkrétních typů hlásí chyby.
- Po nasazení nechte pár dní na přeindexování. Jednorázový zelený Rich Results Test ≠ hotovo na celém webu.
- Otevřete reporty strukturovaných dat / rich results pro typy, které opravdu posíláte (Produkt, FAQ, Článek, Drobenky…).
- Chyby řešte první - chybějící povinné pole, špatný typ, neparsovatelný JSON.
- Varování berte jako dluh - často doporučená pole. Někdy je doplníte, někdy vědomě necháte být, pokud na stránce nemáte co doplnit pravdivě.
- Když po deployi vyskočí spike chyb, hledejte šablonu (PDP, blog detail, homepage), ne jednu URL. Typicky se rozbije generování pro celý content type.
A ještě jednou: GSC umí ukázat technický stav markupů. Nerozhodne za vás, jestli máte na blogu dávat FAQ, nebo jestli produktové rich results u vás vůbec dávají obchodní smysl.
Jak to skládám na projektech
Krátký postup, který se opakuje:
- Inventura typů stránek (homepage, kategorie, PDP, článek, kontakt).
- Pro každý typ: minimální sada JSON-LD, která je pravdivá.
- Napojení na zdroj pravdy (CMS pole, cena z e-shopu, autor z profilu) - ne hardcoded blábol v šabloně.
- Validace v Rich Results Testu na pár vzorcích.
- Po indexaci kontrola GSC a oprava šablon podle chyb.
Když ladíte i rychlost, měření a on-page SEO kolem toho, často to sedí dohromady s technickým auditem webu nebo s on-page auditem. Samotný JSON-LD je jedna vrstva. Bez srozumitelného obsahu a čistého HTML je to jen pěkně serializovaný vzduch.
Shrnutí
Schema.org je slovník. Google a GSC jsou rozhodčí, jestli váš markup dává smysl. JSON-LD je formát, se kterým se mi nejlíp pracuje, protože neplete význam do každého HTML atributu jako microdata.
Dělejte strukturovaná data kvůli srozumitelnosti pro stroje a kvůli šanci na relevantní rozšířené výsledky. Nedělejte je jako soutěž „kdo má delší JSON". A když si nejste jistí polem: radši ho vynechte, než abyste do něj napsali přání.
