Strukturovaná data a rich snippety pro e-shop

Dvě různé věci, kterým se říká „strukturovaná data“

Pojem „strukturovaná data“ znamená v e-commerce dvě věci a plete se to i lidem z oboru. Než se pustíme dál, vyplatí se je od sebe oddělit.

Strukturovaná produktová data jsou údaje uložené u produktu jako samostatná pole — parametry a vlastnosti. Barva jako parametr „barva: černá“, ne jako slovo schované ve větě popisku. Velikost, materiál, značka, cena, dostupnost. To jsou data ve vašem e-shopu.

Strukturovaná data podle schema.org jsou naproti tomu značky v kódu stránky, kterými se stejná fakta říkají vyhledávači strojově čitelně. Člověk je nevidí, robot ano. Nejčastěji ve formátu JSON-LD, což je blok kódu v hlavičce nebo patičce stránky.

Vztah mezi nimi je jednoduchý a zásadní: první je předpoklad, druhé je výstup. Když produkt nemá barvu jako samostatný parametr, žádné označkování ji do výsledku nedostane — není odkud ji vzít. Jak parametry v e-shopu vůbec získat a doplnit, rozebírá článek o obohacení a transformaci produktových dat.

Jedno upřesnění, které ušetří zklamání: z parametrů vznikne ve výsledku cena, dostupnost, značka nebo EAN. Hvězdičky ne. Ty pocházejí z hodnocení od zákazníků a žádné doplňování parametrů je nenahradí. Jak z chudých dat udělat použitelné popisky a parametry ve velkém, rozebírají produktové popisky pro SEO i konverzi.

Co se z toho ve výsledku objeví — a co ne

Rozšířený výsledek (anglicky rich result, hovorově rich snippet) je výsledek vyhledávání obohacený o cenu, dostupnost nebo hvězdičky hodnocení. Zabírá víc místa a vizuálně vyčnívá. To je celý jeho smysl.

Hned na začátku ale patří tři upřesnění, bez kterých si o rozšířených výsledcích uděláte falešnou představu.

Rozšířený výsledek mění vzhled, ne pořadí. Strukturovaná data vás ve výsledcích neposunou nahoru. Google celou tuhle dokumentaci vede pod hlavičkou „appearance“, tedy vzhledu výsledku. Efekt je nepřímý: nápadnější výsledek si uživatelé pravděpodobněji vyberou. Sám Google to formuluje opatrně — označkování „může umožnit“ poutavější výsledky, které uživatele „mohou motivovat“ k větší interakci. Žádný slib nárůstu.

Zobrazení není zaručené. Tuhle větu Google opakuje na konci každé stránky dokumentace, například u úryvků recenzí: „Google nezaručuje, že se funkce využívající strukturovaná data ve výsledcích vyhledávání objeví.“ Označkování zakládá nárok, ne povinnost.

A ne všechno, co se o rozšířených výsledcích píše, platí v Česku. Google má pro e-shopy dvě rodiny produktových výsledků. Produktové úryvky (product snippets) jsou ty běžné, s cenou a hvězdičkami přímo ve vyhledávání. Záznamy obchodníka (merchant listings) jsou bohatší nákupní výsledky, například „oblíbené produkty“ nebo nákupní znalostní panel. Ukazují se jen u stránek, kde jde produkt skutečně koupit, a vždycky obsahují cenu (dokumentace k záznamům obchodníka). Google seznam zemí sám nezveřejňuje. Podle přehledu, který průběžně vede analytik Brodie Clark, běží tyhle výsledky v USA, Brazílii, Japonsku, Kanadě, Mexiku, Indii, Austrálii a několika dalších zemích — v Evropě zatím ne.

Pro český e-shop je tedy reálný cíl produktový úryvek a drobečková navigace, ne obrázky z amerických prezentací. Zajímavá výjimka jde opačným směrem: karusely produktů, které Google testuje od roku 2024, jsou dostupné právě jen v Evropském hospodářském prostoru, Turecku a Jihoafrické republice. Věrnostní programy ve strukturovaných datech naopak fungují v osmi zemích, mezi kterými Česko není. U každé novinky se proto vyplatí ověřit, kde vlastně platí.

Jak si to ověřit: vyhledejte si na Googlu název svého nejprodávanějšího produktu a podívejte se, jak vypadá váš výsledek proti konkurenci. Má někdo cenu, dostupnost, hvězdičky nebo cestu v katalogu, a vy ne? Přesně tenhle rozdíl řeší zbytek článku.

Čím začít: rozhodněte se, o co vám vlastně jde, než začnete cokoli nastavovat. Cena a dostupnost jsou snadno dosažitelné a týkají se každého produktu. Hvězdičky vyžadují hodnocení od zákazníků, což je delší práce.

Které typy dnes e-shopu dávají smysl

Nemusíte značkovat všechno. Pro e-shop stačí zvládnout čtyři typy — a rozumět tomu, proč pátý z běžně doporučovaných už neplatí.

Ještě předtím jedno omezení, které platí pro všechny: produktový rozšířený výsledek dostane jen stránka, která se týká jednoho konkrétního produktu (nebo jeho variant). Kategorie ani výpis „boty v našem obchodě“ ho nedostane, ať je kód sebelepší.

Cena a dostupnost ve výsledku (Product a Offer)

Product popisuje samotný produkt, Offer jeho nabídku — cenu, měnu a dostupnost. Bez nich se ve výsledku neukáže ani cena, ani „skladem“.

Jak se to projevuje: produkt se ve vyhledávání zobrazí jako obyčejný odkaz s názvem a útržkem textu, zatímco konkurence ukazuje cenu a dostupnost. U zboží, kde lidé srovnávají, je to znatelný rozdíl v tom, kam klikne oko.

Co Google vyžaduje u produktového úryvku: povinný je name a alespoň jedno ze tří polí — offers, review nebo aggregateRating. Když máte offers, musí obsahovat price.

Co navíc vyžadují záznamy obchodníka: povinné jsou name, image a offers, a uvnitř nabídky price i priceCurrency. Doporučené jsou pak availability, brand, sku, gtin, itemCondition, hodnocení a údaje o dopravě a vratkách.

Povinné pole je vstupenka, doporučené pole rozhoduje o tom, jak bohatý výsledek dostanete. A i když v Česku záznamy obchodníka zatím neběží, doporučená pole se vyplatí vyplnit i tak. Čtou z nich Nákupy a Merchant Center, tedy účet, přes který e-shop posílá produktová data do Googlu — jak rozebíráme dál.

Jak si to ověřit: vložte adresu produktu do Testu rozšířených výsledků (postup je hned v další kapitole). Zkontrolujte, jestli tam cena a dostupnost skutečně jsou a jestli sedí s tím, co je na stránce vidět.

Čím začít: neřešte zatím doplňková pole. Ověřte, že u produktu vůbec existuje cena a dostupnost a že odpovídají realitě. Zbytek je optimalizace, tohle je základ. A když zjistíte, že šablona nemá odkud brát značku nebo parametry, problém je o patro níž, v datech samotných. Co s tím, rozebírá kapitola o tom, co zvládnete sami bez programátora.

Ještě k variantám. Když produkt existuje ve víc velikostech nebo barvách, ideální je, aby označkování popsalo každou variantu zvlášť — vlastní kód, vlastní cenu, vlastní dostupnost. Platformy to řeší různě: Shoptet posílá samostatnou nabídku ke každé variantě, Upgates jen jednu na celý produkt. Když má vaše šablona jen jednu nabídku, ve výsledku se obvykle ukáže cena nejlevnější varianty. Není to chyba, ale počítejte s tím, že zákazník pak na stránce uvidí jiné číslo, než na které klikl.

Hvězdičky u produktu (AggregateRating)

Hvězdičky jsou z celého označkování to nejviditelnější a lidé je hledají nejčastěji. Zároveň se kolem nich nejvíc plete — proto nejdřív vyjasnění, o kterých hvězdičkách je vůbec řeč, a teprve potom, co pro ně musí platit.

Tři různé hvězdičky, které se pletou

Když se lidé ptají na „hvězdičky u Googlu“, myslí tím tři různé věci — a každá vzniká jinde.

Hvězdičky u placené reklamy (hodnocení prodejce) pocházejí z Merchant Center a ze zpětné vazby, kterou zákazníci nechají po nákupu. Se schématem na vaší stránce nesouvisejí.

Hvězdičky u firemního profilu jsou recenze podniku na Googlu. Také samostatný svět — spravují se ve Firemním profilu.

Hvězdičky u produktu v organickém výsledku vznikají z označkování AggregateRating na produktové stránce. Tohle je ta jediná ze tří možností, o které je tenhle článek — a proto nepomůže sbírat recenze firmy. Potřebujete hodnocení u konkrétních produktů, viditelné na stránce a označkované v kódu.

Dvě podmínky a jedno nedorozumění

Pro hvězdičky u produktu platí dvě podmínky, o kterých se moc nemluví — a koluje kolem nich jedno rozšířené nedorozumění.

Jak se to projevuje: výsledek s hvězdičkami a počtem hodnocení nese sociální důkaz ještě předtím, než na něj někdo klikne. Bez nich vypadá i velmi dobře hodnocený produkt stejně jako neznámé zboží.

Hodnocení musí být vidět na stránce. Google to říká přímo v pravidlech pro úryvky recenzí: obsah recenzí musí být pro návštěvníka snadno dostupný z označkované stránky. Označkovat hvězdičky, které na stránce nikde nejsou, je porušení pravidel.

Nesmíte agregovat hodnocení z cizích webů. To má v Česku konkrétní dopad: natáhnout si hvězdičky z Heureky a vydávat je za hodnocení na vašem webu jde proti pravidlům. Některé platformy import hodnocení z Heureky přímo nabízejí — v tom případě si ohlídejte, jestli se importovaná hodnocení dostávají i do označkování produktu.

A to nedorozumění: pravidlo o „vlastních recenzích na sebe sama“, které Google zavedl v září 2019, se produktů netýká. Dopadá na typy LocalBusiness a Organization, tedy na situaci, kdy si firma hodnotí sama sebe. Hodnocení produktů, která vám nechali zákazníci ve vašem e-shopu, označkovat smíte.

Jak si to ověřit: v Testu rozšířených výsledků hledejte položku aggregateRating a porovnejte ji s tím, co ukazuje stránka. Že hodnocení vidíte na webu, ještě neznamená, že je Google dostane — na jedné testované šabloně Shoptetu produkt viditelně ukazoval „2,7 z 5 ze 3 hodnocení“, ale v označkování žádné hodnocení nebylo.

Čím začít: bez hodnocení nebudou hvězdičky, ať máte kód sebelepší. Zapněte proto sbírání hodnocení u produktů; na většině platforem je to modul nebo doplněk, který se zapíná v administraci. A nastavte automatický e-mail s žádostí o hodnocení pár dní po doručení. Google žádné minimum nestanovuje, ale u jednoho jediného hodnocení se hvězdičky ve výsledku běžně neobjeví. Počítejte spíš v desítkách u vašich hlavních produktů než v jednotkách napříč celým katalogem.

Drobečková navigace (BreadcrumbList)

Drobečková navigace ve výsledku nahradí neúhlednou adresu čitelnou cestou v katalogu. Nemá zvláštní omezení, funguje spolehlivě a většina platforem ji generuje sama. Ze všech čtyř typů je to nejmenší práce s nejjistějším výsledkem.

Jak si to ověřit: vyhledejte si vlastní produkt a podívejte se na řádek nad názvem. Buď tam vidíte cestu typu „Domů › Kategorie › Podkategorie“, nebo holou adresu s lomítky a parametry.

Čím začít: pokud drobečky na webu vůbec nemáte, tahle úprava pomůže i návštěvníkům, ne jen robotům — a v SEO auditu e-shopu je to jedna z prvních věcí, na které narazíme.

Údaje o obchodu (Organization)

Organization popisuje samotný obchod — název, logo, adresu, kontakt. Sám o sobě rozšířený výsledek u produktu neudělá, ale je to místo, kam patří dvě věci, které Google u e-shopů chce: zásady dopravy (hasShippingService) a zásady vrácení zboží (hasMerchantReturnPolicy).

Jak se to projevuje: jestli doprava něco stojí a do kdy se dá zboží vrátit, řeší zákazník ještě před nákupem. Google z těchhle údajů čerpá do Nákupů a Merchant Center — a u záznamů obchodníka i do samotného výsledku, až se dostanou do Evropy. Když je nemá, zákazník si pro ně musí dojít na web a část lidí se cestou ztratí.

Ani jedna z pěti nejrozšířenějších platforem, které jsme prošli, zásady vrácení zboží negeneruje (přehled platforem najdete níž v kapitole o tom, co dostanete od platformy).

Jak si to ověřit: v Search Console, tedy v bezplatném nástroji Googlu s daty o vašem webu, otevřete sekci Nákupy a přehled Doprava a vrácení zboží — uvidíte, co Google z vašeho webu přečetl. Do Testu rozšířených výsledků se dívat nemusíte; ten hlásí způsobilost pro rozšířené výsledky, a tuhle položku mezi nimi nenajdete.

Čím začít: nehledejte programátora. Dopravu a vratky můžete nastavit přímo v Merchant Center nebo v Search Console a takové nastavení má dokonce přednost před označkováním na stránce. Předpokládá to ale založený a propojený účet Merchant Center — jak ho napojit, rozebírá článek o napojení do Merchant Center přes rozhraní.

FAQ ve výsledcích (FAQPage): typ, který Google vypnul

Ještě donedávna patřily časté otázky mezi standardní doporučení pro e-shopy. Dnes už to doporučení neplatí — a stojí za to vědět proč, protože stejný mechanismus se bude opakovat.

Google omezil zobrazování FAQ nejdřív v srpnu 2023 jen na autoritativní vládní a zdravotnické weby. Od 7. května 2026 je vypnul úplně a v červnu 2026 smazal i dokumentaci. Zmizely také z Testu rozšířených výsledků a z přehledů v Search Console.

Poučení z toho není „mazat FAQ ze stránek“. Google výslovně říká, že označkování není potřeba odstraňovat sám od sebe: nepoužívaná strukturovaná data ve vyhledávání problém nedělají, jen nemají viditelný efekt. Poučení je jiné a užitečnější:

Označkování je trvalé, funkce nad ním se mění. Google za posledních pár let zrušil nebo omezil FAQ, návody, vyhledávací pole webu a šest dalších typů. Když si tedy někde přečtete „nasaďte tenhle typ a získáte X“, ověřte si datum článku a aktuální seznam podporovaných typů. Pravidlo, které vydrží: značkujte to, co na stránce opravdu je, a neohýbejte data kvůli jednomu vzhledu ve výsledku.

Máte to vůbec? Ověření za pět minut

Ověřit si, co váš e-shop posílá, můžete hned — a nepotřebujete k tomu umět číst kód.

Krok první: Test rozšířených výsledků. Otevřete Test rozšířených výsledků od Googlu, vložte adresu produktu a spusťte test. Za chvíli uvidíte, jaké typy strukturovaných dat Google na stránce našel a jestli jsou platné.

Důležitý detail: vkládejte adresu, ne zkopírovaný kód. Test s adresou stránku načte i se vším, co dodělá JavaScript. Vložený kód ne — a u řady e-shopů byste tak přišli přesně o tu část, kterou chcete zkontrolovat.

Otestujte tři produkty, ne jeden. Běžný skladový produkt, produkt s variantami a produkt bez ceny nebo vyprodaný. Právě u těch dvou druhých se ukazují díry, které na běžném produktu nevidíte — a pořád je to práce na pět minut.

Krok druhý: přečíst výsledek. Google rozlišuje kritické problémy, které brání zobrazení rozšířeného výsledku, a nekritické problémy, které ho jen ochudí. Platná položka znamená, že nemá žádný kritický problém a může se jako rozšířený výsledek zobrazit. Ne že se zobrazí — proč, o tom je další kapitola.

Test zároveň ukazuje počet nalezených položek. Když u jednoho produktu najde dvě položky typu Product, máte označkování dvakrát — a to je problém, ke kterému se ještě vrátíme.

Krok třetí: Search Console, ale na správném místě. Většina typů se v Search Console vykazuje v sekci Vylepšení, ale produktová data ne — ta jsou v samostatné sekci Nákupy, pod názvy Produktové úryvky a Záznamy obchodníka. Když je hledáte ve Vylepšeních, dojdete k závěru, že žádná nemáte. (Pokud Search Console ještě nemáte zřízenou, ověření webu je otázka pár minut a vyplatí se i mimo tohle téma.)

Krok čtvrtý, nepovinný: podívat se do zdroje. Na produktové stránce stiskněte Ctrl+U a pak Ctrl+F a hledejte application/ld+json. Kolik výskytů prohlížeč najde, tolik bloků v tomhle formátu stránka posílá. Bez tohohle kroku o nic nepřijdete — duplicitu i obsah označkování ukáže i Test rozšířených výsledků.

Když nenajdete nic, ještě to neznamená, že nic nemáte. Buď je označkování ve starším formátu mikrodat, kde se hledá itemtype — a tak to dělá většina e-shopů u nás, protože tak pracují Shoptet i Upgates. Nebo ho vkládá JavaScript až po načtení stránky; pak ho uvidíte po stisknutí F12 v záložce Elements.

Mikrodata přitom nejsou horší volba. Je to jen starší způsob, jak zapsat totéž. Google je čte úplně stejně jako JSON-LD a není důvod kvůli nim cokoli přepisovat.

Test svítí zeleně a ve výsledcích nic: pět bran

Zelený test a prázdné výsledky — tuhle frustraci zná každý, kdo strukturovaná data někdy nasazoval. V Search Console je položka platná, a ve vyhledávání se přesto neděje nic. Není to náhoda ani chyba: mezi vaším kódem a hvězdičkou ve výsledku stojí pět bran a nástroje umí zkontrolovat jen první dvě.

První brána: procházení a indexace. Stránka musí být zaindexovaná a Googlebot k ní i k obrázkům musí mít přístup. Blokace v robots.txt, značka noindex nebo přihlášení celou věc zastaví hned na začátku.

Jak to poznáte: zadejte adresu produktu do nástroje Kontrola adresy URL v Search Console. Když hlásí, že stránka není v indexu, nemá smysl řešit označkování — nejdřív musí být vidět stránka. Proč se stránky do indexu nedostávají, rozebírá článek o tom, proč se e-shop neukazuje.

Druhá brána: syntaxe a povinná pole. Kód musí být validní a obsahovat povinné vlastnosti daného typu. Chybějící povinné pole znamená diskvalifikaci, varování jen ochuzený výsledek.

Jak to poznáte: Test rozšířených výsledků vypíše chyby i varování. Chyby opravte, varování zvažte podle toho, o jaké pole jde.

Třetí brána: kvalitativní pravidla. Označkování musí odpovídat tomu, co je na stránce vidět, musí být k věci a nesmí obcházet pravidla. Tady nástroje končí — Google to říká otevřeně v obecných pokynech ke strukturovaným datům: porušení kvalitativního pravidla může zabránit zobrazení i syntakticky správných dat a „Test rozšířených výsledků tyhle problémy nedokáže identifikovat.“

Jak to poznáte: jedině vlastníma očima. Otevřete produktovou stránku vedle výstupu z testu a projděte čtyři otázky:

• Je hodnocení, které je v kódu, skutečně vidět i na stránce?
• Sedí cena v kódu s cenou po slevě?
• Není označkovaná kategorie nebo výpis jako jeden produkt?
• Nejsou v kódu hodnocení stažená odjinud?

Čtvrtá brána: důvěra v celý web. Rozhodnutí, které Google dělá napříč webem, ne pro jednu stránku. John Mueller z Googlu to popsal jako otázku, jestli „můžeme tomuhle webu věřit, že přes strukturovaná data dodá něco rozumného“.

Jak to poznáte: testem přes dotaz site:, který je popsaný hned v další kapitole. A počítejte s tím, že to není úkol na tenhle týden — důvěryhodnost webu se staví obsahem a kvalitou dlouhodobě.

Pátá brána: existence funkce. Typ může být zrušený jako FAQ, dostupný jen na počítačích, jen pro určitý obor — nebo jen v jiných zemích, jak jsme popsali výš u záznamů obchodníka.

Jak to poznáte: podívejte se do aktuální dokumentace Googlu k danému typu. Když tam stránka není nebo nese poznámku o ukončení, kód je v pořádku a jen se nemá kde projevit.

Test dotazem site:: ve které bráně to vázne

Tenhle test zvládne každý. Vyhledejte na Googlu site:vasedomena.cz a podívejte se, jestli se u vašich produktů rozšířené výsledky zobrazují tam.

Když se u dotazu site: rozšířené výsledky ukazují, ale u běžných dotazů ne, prošli jste první tři brány a problém je ve čtvrté — v celkové důvěryhodnosti webu.

Když se neukazují ani u dotazu site:, Google to zatím jednoduše nezpracoval, nebo něco vázne dřív. Tady má smysl vrátit se ke kontrole indexace a syntaxe.

Ať už vázne cokoli, počítejte s časem. Google uvádí, že najít a projít novou stránku mu trvá několik dní. Mueller doporučuje dát tomu pár týdnů, než začnete hledat chybu, a ověření opravy v Search Console může podle nápovědy trvat dva týdny i déle. Den po nasazení se nedá měřit nic.

Trestá Google chyby ve strukturovaných datech?

Krátká odpověď: netrestá. Strach z trestu za chybné schéma je jeden z nejrozšířenějších mýtů kolem tématu a zbytečně brzdí lidi, kteří by jinak něco zkusili.

Nejsilnější důkaz je paradoxně u toho nejtvrdšího případu — u ručního zásahu. Google k němu ve svých obecných pokynech píše: „Ruční zásah kvůli strukturovaným datům znamená, že stránka ztrácí nárok na zobrazení jako rozšířený výsledek; neovlivňuje to, jak si stránka stojí ve vyhledávání.“

Když ani trest za manipulaci s označkováním nesníží pozice, obyčejná chyba v kódu už vůbec ne. Aktuální pravidla proti spamu navíc žádnou sekci o strukturovaných datech neobsahují.

Přesněji tedy: chybný kód nezpůsobí penalizaci, způsobí, že prvek prostě nedostanete. Riskujete zmeškanou příležitost, ne postih.

Ruční zásah přesto existuje — a jmenuje se jinak, než se píše

Pro úplnost: ruční zásah za strukturovaná data existuje, najdete ho v Search Console v sekci Ruční zásahy a od roku 2019 se jmenuje „Structured data issue“ (dříve „Spammy structured markup“). Spouští ho manipulace. Nepořádek v kódu k ručnímu zásahu nestačí.

Google jmenovitě vypisuje, co ho vyvolá. Pro e-shopy jsou nejpodstatnější tyto:

• Strukturovaná data neodpovídají obsahu — v kódu je jiná cena než na stránce.
• Označkování skrytého obsahu — data o něčem, co návštěvník nevidí.
• Označkování výpisu jako jedné položky — kategorie nebo výpis produktů označkovaný jako jeden produkt. Google to výslovně řadí mezi spamové praktiky.
• Chybí způsob, jak recenzi napsat — stránka ukazuje hodnocení, ale není z ní poznat, odkud pochází ani jak přidat vlastní.
• Recenze napsaná provozovatelem o sobě samém.
• Firma označená jako produkt — pokus získat hvězdičky tím, že se celý obchod vydá za produkt.

Poslední bod není teoretický. Při přípravě tohoto článku jsme na jednom českém e-shopu narazili přesně na takový případ. Vedle skutečného produktu s hodnocením 4,9 od 74 zákazníků tam stál druhý blok — a ten jako „produkt“ popisoval celý obchod, s hodnocením 5,0 od 4 431 zákazníků. Vzniklo to snahou dostat do výsledků lepší hvězdičky a je to učebnicový příklad dvou zakázaných věcí najednou: firmy označkované jako produkt a hodnocení, které nepatří k tomu, co stránka prodává.

Co dostanete od platformy a co si musíte dodělat

Většina e-shopů nějaké označkování má, aniž byste o tom museli vědět — generuje ho šablona. Otázka tedy nezní „mám to“, ale „co přesně mi to generuje a kde jsou díry“.

Prošli jsme produktové stránky e-shopů na nejrozšířenějších platformách přímo na webu a porovnali, co skutečně posílají. U každé jsme se dívali na dva až tři různé e-shopy, protože rozsah se liší podle šablony. Vedle pěti platforem v tabulce jsme ověřili i menší české systémy — Webareal, Eshop-rychle, FastCentrik a ByznysWeb — ze kterých pocházejí některé nálezy níž. Výsledek se dá shrnout do jedné věty: rozdíl nedělá platforma, ale to, jestli si toho někdo všiml a dodělal to.

Tabulka níž mluví o tom, co platforma posílá do označkování. Co která platforma umí s parametry a jejich importem, je jiná otázka a rozebírá ji článek o on-page SEO.

Ověřeno na živých produktových stránkách v červenci 2026. Rozsah se u všech platforem liší podle konkrétní šablony, takže na vlastním e-shopu si to ověřte znovu.

Většinu těch děr zavřete bez programátora — jak, píšeme níž.

Duplicitní označkování: dvakrát Product na jedné stránce

Šablona vygeneruje svůj blok, nainstalovaný SEO nebo recenzní doplněk přidá druhý — a na stránce jsou dva popisy jednoho produktu. Podobně vzniká označkování na nečekaných místech: sekce „vybraný produkt“ na úvodní stránce propašuje do kódu produktové schéma, které tam nemá co dělat.

Google nikde neříká, že je to zakázané, a pozice kvůli tomu neztratíte. Riziko je jiné: Google si musí vybrat, který blok použije, a vy nevíte který. Když se bloky liší v ceně nebo dostupnosti, může se do výsledků — a přes Merchant Center i do reklamy — dostat ta špatná hodnota.

Řešení je jednoduché: mít označkování z jednoho zdroje. Buď šablona, nebo doplněk. Většina slušných SEO doplňků umí blok ze šablony potlačit; když to neumí, je to důvod ho nepoužít.

Tiché chyby, o kterých se nedozvíte

Zajímavější než chybějící pole jsou ta, která vypadají vyplněná, ale nesou nesmysl. Několik reálných nálezů z živých šablon:

Prázdná hodnota se stejně odešle. Webareal vypisuje "gtin13": "" i u produktů, kde prodejce EAN nevyplnil. V Search Console to pak figuruje jako neplatná hodnota — a přitom by stačilo pole vynechat.

Značka, kterou nikdo nezadal. PrestaShop u produktů bez vyplněného výrobce dosadí jako značku název vašeho e-shopu. Google tak u celého neznačkového sortimentu vidí značku „Váš obchod“. WooCommerce zase bere značku výhradně z taxonomie Brands — když ji máte jako běžný parametr produktu, do označkování se nedostane.

Vymyšlené výrobní číslo. PrestaShop při chybějícím mpn (výrobní číslo od výrobce) dosadí referenci, a když chybí i ta, tak interní číslo produktu z databáze. Vzniká identifikátor, který u výrobce neexistuje.

Platnost ceny do roku 2036. Pole priceValidUntil má říkat, dokdy cena platí. Webareal tam dosazuje dnešek plus deset let, PrestaShop dnešek plus patnáct dní — v obou případech bez vazby na jakoukoli skutečnou akci. Opačný extrém je horší: datum v minulosti může zobrazení produktového úryvku zablokovat.

Chybějící typ u ceny. FastCentrik zapisuje cenovou specifikaci bez určení typu, což znamená reálné riziko, že Google cenu vůbec nepřečte.

Chybějící produkt. WooCommerce nevygeneruje blok Product vůbec, když produkt nemá ani cenu, ani hodnocení, ani recenzi. U zboží „na dotaz“ tak označkování tiše zmizí.

A dá se to i dobře. ByznysWeb vyplní pole jen tehdy, když v nich e-shop skutečně data má. Když chybí EAN nebo hodnocení, pole prostě vynechá — a to je přesně chování, které Google od označkování čeká.

Popis, který není popis. PrestaShop bere do pole description meta description stránky, ne popis produktu. Když ji nevyplníte, jde do označkování automaticky ořezaný a často useknutý text.

Zastaralá dostupnost. Nejčastější tichá chyba vůbec: v kódu svítí „skladem“, ve skladu už produkt není. Vedle rozšířeného výsledku to ohrožuje i produkty v Nákupech, jak rozebíráme v další kapitole.

Co zvládnete sami, bez programátora

Podstatná část „chybějících“ polí nechybí kvůli šabloně — ta pole jsou prázdná v katalogu. Když je vyplníte v administraci, objeví se ve výsledku sama.

Doplňte EAN u produktů. Propíše se do pole gtin, které je pro produktové výsledky i pro srovnávače jedno z nejužitečnějších. V ukázkových katalozích Shopify má vyplněný čárový kód zhruba jedna varianta ze šesti, takže tady bývá velká rezerva. U vlastní výroby, rukodělných produktů nebo sad ale EAN prostě neexistuje — nevymýšlejte ho. Místo něj vyplňte značku a vlastní kód a v Merchant Center produkt označte jako zboží bez identifikátoru.

Vyplňte značku a referenci (vaše interní označení produktu, v některých systémech katalogové číslo nebo kód produktu). Značka se propíše do brand, reference do sku. U WooCommerce si ohlídejte, že značky vedete jako Brands, ne jako obyčejný parametr.

Zapněte hodnocení produktů a začněte je sbírat. Bez hodnocení nebudou hvězdičky.

Dopravu a vratky nastavte v Merchant Center nebo Search Console, ne v šabloně.

Teprve když tohle máte a pole pořád chybí, má smysl řešit doplněk nebo zásah do šablony. A pokud jsou data v katalogu chudá napříč celým sortimentem, řeší se to jinde než ve schématu — hromadným doplněním parametrů, o kterém píšeme v článku o obohacení a transformaci feedu.

Feed, schéma a web: tři místa, jedna pravda

Tady se strukturovaná data přestávají týkat jen vzhledu ve vyhledávání a začínají se týkat peněz.

Stejná fakta o produktu žijí na třech místech: ve viditelném obsahu stránky, ve strukturovaných datech v kódu a ve feedu, který odchází do srovnávačů, reklamy a Nákupů. Nemusí být znak po znaku stejná, ale nesmí být v rozporu. Celou datovou stranu rozebírá téma produktové feedy a napojení e-shopu.

A není to naše doporučení — je to mechanika, kterou Google provozuje a měří.

Google skutečně porovnává feed se stránkou

Porovnávání není domněnka. V nápovědě Merchant Center stojí doslova: „Googlebot pravidelně prochází vaše vstupní stránky a porovnává atribut cena ve vašem zdroji dat s cenami na vstupní stránce nebo v označení strukturovaných dat (pokud je implementováno).“ A dodává, že ceny v HTML musí přesně odpovídat cenám nahraným do Merchant Center.

U dostupnosti jde Google ještě dál a vyžaduje shodu na čtyřech místech: vstupní stránka, stránka košíku, strukturovaná data a zdroj dat. Rozpor v kterémkoli z nich znamená zamítnutí produktu. U ceny navíc platí, že příliš mnoho produktů s neodpovídající cenou může vést až k pozastavení účtu. Co všechno se ve feedu běžně rozejde, shrnují typické chyby ve feedu e-shopu.

Jak si shodu ověřit: v Merchant Center otevřete Produkty a kartu s problémy — zamítnutí kvůli ceně a dostupnosti tam figurují pod vlastními názvy, u ceny jako „Neodpovídající cena produktu“. Ručně pak zkontrolujte pět produktů napříč typy: běžný, akční, vyprodaný, s variantami a jeden z okraje sortimentu. Porovnejte cenu ve feedu, na stránce a v Testu rozšířených výsledků. Když se všech pět shoduje, máte slušnou jistotu, že je systém v pořádku.

Označkování je záchranná síť, ne jen ozdoba

Merchant Center má funkci automatických aktualizací položek, která je ve výchozím stavu zapnutá. Google z vaší produktové stránky přečte aktuální údaje a sám si opraví kopii vašich produktových dat.

Čte přitom právě strukturovaná data — konkrétně price, priceCurrency, availability a itemCondition. Produkt s feedem spáruje přes sku nebo gtin.

Praktický scénář vypadá takhle. Ve feedu máte cenu 1 299 Kč. Na webu naskočí sleva na 999 Kč, ale feed se aktualizuje až za pár hodin. Googlebot mezitím navštíví produktovou stránku, přečte z označkování cenu 999 Kč a Merchant Center si ji opraví samo. Produkt zůstane schválený a inzeruje se za správnou cenu.

Bez označkování se Google pokusí cenu odhadnout z obsahu stránky. Když se to nepodaří, produkty vypadnou: „pokud extraktory nedokážou určit cenu, dostupnost nebo stav, budou vaše produkty zamítnuty na úrovni položky.“

A o tuhle síť můžete přijít. Když se údaje ve feedu a v označkování rozcházejí příliš často, Google automatické aktualizace vypne pro celý účet a obnoví je až poté, co při dalším procházení webu naměří dostatečnou shodu. Do té doby padají zamítnutí bez záchranné sítě.

Nasazení v praxi: obrázky, cesta bez feedu a Tag Manager

Zbývají praktické otázky, které se u nasazování vracejí pořád dokola: dvojí pravidla pro obrázky, málo známá cesta do Nákupů úplně bez feedu — a lákavá zkratka přes Tag Manager, která se nevyplácí.

Dvojí požadavky na obrázky, které se pletou

Podobný zmatek jako u pojmu „strukturovaná data“ panuje u obrázků, protože i tady existují dvě různé sady pravidel.

Pro označkování na stránce platí, že obrázek má mít alespoň 50 000 obrazových bodů plochy — tedy šířka krát výška, což odpovídá zhruba rozměru 224 × 224. Doporučené poměry stran jsou 16:9, 4:3 a 1:1.

Pro feed do Merchant Center platí jiná čísla: dnes minimálně 100 × 100 u běžného zboží a 250 × 250 u oblečení. Od 31. ledna 2027 se ale minimum zvedá na 500 × 500 pro všechny kategorie a varování na to Google v účtech ukazuje už od dubna 2026.

Takže když někde narazíte na „obrázky musí mít 500 × 500“, je to požadavek feedu s odloženou platností, ne požadavek označkování. Připravit obrázky do správných rozměrů hromadně pomůže obrázkový editor.

Bonus: produkty se dají do Googlu dostat i bez feedu

Málo známá možnost: Merchant Center umí produkty vytáhnout přímo ze strukturovaných dat na stránce, bez jakéhokoli feedu. Funguje to přes automatizované zdroje dat — Google váš web prochází a produkty z označkování sám vloží do účtu. Podmínkou je označkování na produktových stránkách, ověřený web propojený s účtem a robots.txt, který Googlebota pustí. Kontrola probíhá podle dokumentace nejméně jednou za 24 hodin.

Pro malý e-shop bez technického zázemí to může být nejrychlejší cesta do Nákupů. Pro větší katalog zůstává feed lepší volbou — dá se řídit, obohacovat a pro každý srovnávač i reklamní systém upravit zvlášť. Když použijete feed i automatizované zdroje zároveň, Google podle vlastní dokumentace uzná víc produktů a snáz si data ověří. Co to vlastně feed je a jak vzniká, vysvětluje článek o produktovém feedu pro e-shop.

Schéma z Tag Manageru: proč ho Merchant Center nepřijme

Nasadit strukturovaná data přes Google Tag Manager je lákavé — nepotřebujete programátora ani zásah do šablony. Google to dokonce sám dokumentuje jako možnost a pro běžné vyhledávání to funguje, protože Googlebot stránky vykresluje včetně JavaScriptu.

Pro Merchant Center to ale nefunguje vůbec. V nápovědě k nastavení strukturovaných dat to stojí bez okolků: „Značky strukturovaných dat musí být součástí zdrojového kódu HTML z webového serveru. Značky strukturovaných dat nelze generovat pomocí JavaScriptu po načtení stránky.“

Vzniká tak situace, kdy Test rozšířených výsledků ukáže zelenou, v Search Console je vše platné — a Merchant Center přesto hlásí nedostatečnou shodu a zamítá produkty. Chybu pak hledáte v kódu, a ten je přitom v pořádku. Problém je v tom, odkud se do stránky dostává.

Google navíc na třech místech dokumentace opakuje stejné varování: „Dynamicky generované označkování může způsobit, že procházení pro Nákupy bude méně časté a méně spolehlivé, což je problém u rychle se měnícího obsahu, jako je dostupnost a cena produktu.“ Přesně u ceny a dostupnosti, tedy u toho, na čem e-shopu záleží nejvíc.

Doporučení je jednoznačné: mít strukturovaná data přímo v HTML, které vrací server. John Mueller to říká dlouhodobě a v roce 2022 to shrnul větou, že chce mít označkování přímo na stránce, „aby bylo přesně jasné, co se děje“.

Kde v tom všem stojí Conviu

Běžná SEO agentura vidí web. Feedový nástroj vidí feed. Rozpor ale nevzniká ani na jedné straně — vzniká mezi nimi, a proto ho nikdo nehlídá.

My pracujeme s oběma stranami řetězce. Data načteme do Conviu, zkontrolujeme a upravíme — ven jde do každého kanálu feed, který říká totéž co web. Když je problém v datech samotných, vrátíme je opravená zpátky do e-shopu jako jednorázový soubor.

A tady je ta souvislost, která se snadno přehlédne. Opravená data se uloží do katalogu e-shopu — a protože šablona bere hodnoty právě odtamtud, srovná se s nimi i to, co e-shop posílá do označkování. Jedna oprava tedy spraví web, kód i feed najednou. Když si s tím nevíte rady, rádi to s vámi projdeme; průběžnou stranu pak řeší editor datových feedů.

A co AI vyhledávání?

Kolem strukturovaných dat a umělé inteligence koluje hodně tvrzení, která se nedají doložit. Držme se toho, co je ověřitelné.

Google říká výslovně, že pro AI přehledy žádné zvláštní označkování potřeba není. V dokumentaci k funkcím s umělou inteligencí stojí: „Nepotřebujete vytvářet nové strojově čitelné soubory, textové soubory pro AI ani označkování, abyste se v těchto funkcích objevili. Neexistují ani žádná zvláštní strukturovaná data podle schema.org, která byste museli přidat.“ Podmínkou je indexace a způsobilost pro běžný výsledek, nic víc.

Ve stejné dokumentaci ale Google mezi doporučeními uvádí, aby strukturovaná data odpovídala viditelnému textu stránky a aby údaje v Merchant Center byly aktuální. To sedí s tím, co k tomu řekl John Mueller: u nákupních funkcí — cena, doprava, dostupnost — na strukturovaných datech skutečně záleží, jinde jde spíš o obohacení výsledku. Jak si e-shop stojí v AI vyhledávání a co s tím, rozebíráme samostatně.

OpenAI schema.org nezmiňuje vůbec. Ani ve specifikaci produktového feedu, ani v doporučeních pro obchodníky. Když se v nápovědě OpenAI mluví o „strukturovaných metadatech“, myslí se tím feed a data od poskytovatelů, ne označkování stránky. Kdo tvrdí, že ChatGPT čte schéma z produktových stránek, nemá se o co opřít.

Závěr tedy zní: AI odpovědi se strukturovanými daty vynutit nedají. Pro AI vyhledávání rozhoduje něco jiného — přesná produktová data, která všude říkají totéž. Právě ta plní Nákupy, feedy i asistenty. Přípravu dat pro nákupní agenty rozebíráme zvlášť.

Kolik to reálně přinese

Na otázku, kolik strukturovaná data reálně přinesou, jednoduchá odpověď neexistuje.

Google na svých stránkách publikuje případové studie: Rotten Tomatoes uvádí o 25 % vyšší míru prokliku u stránek s označkováním, Nestlé o 82 % vyšší míru prokliku u stránek zobrazených jako rozšířený výsledek. Tahle čísla kolují po SEO webech jako důkaz.

Jsou to ale případy vykázané samotnými firmami, bez zveřejněné metodiky. Zvlášť číslo od Nestlé se cituje často špatně: neporovnává stránky s označkováním a bez něj, ale stránky, které rozšířený výsledek dostaly, se stránkami, které ho nedostaly. To jsou skupiny, které se lišily už předtím — silné stránky proti slabým — takže číslo měří spíš kvalitu stránek než účinek kódu.

Rozumnější je uvažovat o mechanismu než o procentech. Rozšířený výsledek zabírá víc místa a nese informaci, kterou zákazník hledá — cenu, dostupnost, hodnocení. Že si lidé vyberou spíš takový výsledek než holý odkaz, je pravděpodobné. O kolik, to za vás nikdo neodhadne. Změříte to jen na vlastních datech v Search Console, kde jde výkonnost filtrovat podle vzhledu ve vyhledávání.

Prokliky jsou ale jen jedna strana. Druhý přínos je mnohem hmatatelnější: označkování drží vaše produkty schválené v Merchant Center. To není odhad, to je mechanika popsaná výš — a její selhání se pozná okamžitě, protože produkty zmizí z Nákupů.

Co si z toho odnést

Strukturovaná data jsou levná pojistka a zároveň jeden z mála kroků v SEO, kde se dá výsledek doložit — v Search Console uvidíte, kolik zobrazení má který vzhled výsledku. Nezvednou vám pozice, zato rozhodují o tom, jak výsledek vypadá, a v případě Merchant Center i o tom, jestli se vaše produkty vůbec ukážou.

Pořadí kroků, které dává smysl:

1. Zjistěte, co máte. Tři produkty, Test rozšířených výsledků, pět minut. A zkontrolujte, jestli tam označkování není dvakrát.
2. Vyplňte, co je prázdné. EAN, značka, reference, zapnutá hodnocení. Většina děr není v šabloně, ale v katalogu — a chudé parametry se nikdy neopraví značkováním, jen doplněním dat.
3. Ověřte shodu. Cena a dostupnost v kódu, na stránce a ve feedu musí říkat totéž. Tady je nejvíc peněz i nejvíc rizika — postup najdete v kapitole o feedu.
4. Až potom hodnoťte výsledek. Dejte tomu pár týdnů a použijte test s dotazem site:, než začnete hledat chybu.

Jestli chcete vědět, jak si stojí zbytek webu, prověří to SEO audit e-shopu. Celé téma najdete v tématu SEO a UX pro e-shop.