Jak validovat strukturovaná data bez nástrojů Google

Validace strukturovaných dat se zvláštně navázala na nástroje zaměřené na Google. Je to pochopitelné: mnoho týmů přidává JSON-LD proto, že chce rozšířené výsledky, a testovací nástroje Google jsou dobře známé. Strukturovaná data ale nejsou formát Google. Obvykle jde o JSON-LD používající slovník Schema.org, vložený do HTML, interpretovaný mnoha konzumenty a udržovaný vaším vlastním publikačním workflow.

Pokud validujete jen optikou vyhledávače, můžete přehlédnout základní problémy: neplatný JSON, data, která po renderování zmizí, zastaralé ceny produktů, konfliktní kanonické URL nebo markup, který je technicky platný, ale sémanticky nedává smysl.

Lepší workflow začíná u standardů. Nejprve validujte data jako data, potom slovník a nakonec stránku tak, jak skutečně existuje v produkci.

Co vlastně validujete?

„Strukturovaná data“ nejsou jedna věc. Na většině webů mají čtyři vrstvy:

1. Syntaxe JSON — dá se kód parsovat?
2. Model JSON-LD — expanduje se do smysluplných propojených dat?
3. Slovník Schema.org — jsou typy a vlastnosti věrohodné?
4. Pravdivost na úrovni stránky — odpovídá markup tomu, co vidí uživatelé a crawleři?

Nástroje Google se většinou zaměřují na čtvrtou vrstvu a na způsobilost pro rozšířené výsledky specifické pro Google. Užitečné ano. Úplné ne.

Například toto může být platné JSON-LD, a přesto jde o slabá strukturovaná data:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Tady není nic rozbitého. Pokud má ale viditelná stránka jiný nadpis, žádné uvedení autora a datum poslední úpravy, které je v rozporu s markupem, máte problém s kvalitou, ne se syntaxí.

Krok 1: Parsujte JSON dříve, než začnete přemýšlet o SEO

Začněte nudnou kontrolou: dá se JSON parsovat?

JSON-LD vložené do HTML se často rozbije kvůli drobným chybám v šabloně:

• koncové čárky
• neescapované uvozovky v názvech produktů
• neplatné zalomení řádků uvnitř řetězců
• chybějící složené závorky po podmíněných polích
• duplicitní script bloky kvůli dědičnosti layoutů
• CMS pluginy vypisující neúplné objekty

Pro lokální kontroly nepotřebujete SEO platformu. Použijte nástroje, které už máte ve svém vývojovém stacku.

V JavaScriptu:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

V CI extrahujte obsah scriptů z vyrenderovaného HTML a parsujte ho jako JSON. Tím zachytíte mnoho problémů dříve, než se dostanou do produkce.

Důležitý bod: udělejte to před jakoukoli validací Schema.org. Validátor slovníku nepomůže, pokud data nejsou platný JSON.

Krok 2: Kontrolujte chování JSON-LD, nejen syntaxi JSON

Platný JSON ještě automaticky neznamená platné JSON-LD. JSON-LD používá koncepty jako @context, @type, @id a vztahy v grafu. Pokud jsou chybně vytvořené, parsery mohou vaše data interpretovat jinak, než jste zamýšleli.

Minimálně ověřte:

• každý blok má vhodný @context
• primární entity mají jasné hodnoty @type
• opakované entity tam, kde je to užitečné, používají stabilní hodnoty @id
• vnořené entity jsou logicky propojené
• pole se používají tam, kde je možných více hodnot

U větších webů jsou stabilní identifikátory obzvlášť užitečné. Pokud se vaše organizace objevuje v datech Article, Product, BreadcrumbList a FAQPage, použití stejného @id pomáhá konzumentům pochopit, že jde o odkazy na tutéž entitu, ne o čtyři nesouvisející organizace se stejným názvem.

Typický vzor vypadá takto:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Nesnažíte se tu udělat dojem na validátor. Snažíte se, aby vaše data byla méně nejednoznačná.

Krok 3: Validujte proti slovníku Schema.org

Jakmile jsou JSON a struktura JSON-LD v pořádku, zkontrolujte slovník.

Validátor Schema.org je užitečný, protože testuje proti termínům Schema.org, ne proti pravidlům jednoho vyhledávače pro rozšířené výsledky. Může ukázat, zda jsou vlastnosti rozpoznané, zda se typy interpretují podle očekávání a zda vaše vnořené struktury dávají smysl.

Tady zachytíte chyby jako:

• publishingDate místo datePublished
• imageUrl tam, kde se očekává image
• markup Product na výpisu kategorie, který není produktem
• AggregateRating bez smysluplně hodnocené položky
• Person použitý pro účet značky

S varováními zacházejte opatrně. Schema.org je záměrně flexibilní. Validátor může povolit vlastnost, která pro váš případ použití není užitečná, nebo varovat před něčím, co je volitelné. Berte validaci jako důkaz, ne jako verdikt.

Praktické pravidlo: pokud vlastnost pomáhá stroji přesněji porozumět stránce, ponechte ji. Pokud existuje jen proto, že ji někdo zkopíroval z generátoru snippetů, zpochybněte ji.

Krok 4: Porovnejte markup s viditelným obsahem

Vyhledávače a další konzumenti dat mají tendenci nedůvěřovat markupu, který neodpovídá stránce. A co je důležitější, uživatelé si zaslouží konzistenci.

U každého typu strukturovaných dat porovnejte markup s viditelnou stránkou:

Article a BlogPosting

Zkontrolujte, že nadpis, autor, datum publikování, datum úpravy, obrázek a vydavatel jsou viditelné nebo rozumně odvoditelné. Pokud publikujete obsah vytvořený s pomocí AI, strukturovaná data by neměla sloužit k zastření nejasného autorství. Samostatně jsme psali o poctivém zveřejnění použití AI na malém webu a stejný princip platí i zde: metadata mají objasňovat, ne zakrývat.

Product

Zkontrolujte název, cenu, dostupnost, měnu, varianty, hodnocení a počty recenzí. Strukturovaná data produktů jsou obzvlášť náchylná k zastarávání, protože ceny a stav skladu se mění mimo CMS.

LocalBusiness

Zkontrolujte název, adresu, telefonní číslo, otevírací dobu a oblast poskytování služeb. Pokud patička říká něco jiného než vaše JSON-LD, JSON-LD není „lepší“. Je v rozporu.

BreadcrumbList

Zkontrolujte, že pozice v drobečkové navigaci odpovídají viditelné drobečkové navigaci a že URL jsou kanonické, crawlitelné a nejsou zbytečně přesměrované.

Není to okázalá práce. Zároveň se právě tady najde mnoho problémů se strukturovanými daty.

Krok 5: Validujte vyrenderovanou stránku, ne šablonu

Mnoho webů generuje JSON-LD pomocí JavaScriptu, tag managerů, personalizačních vrstev nebo hydratace komponent. To znamená, že soubor šablony nemusí představovat to, co crawler nebo prohlížeč skutečně vidí.

Validujte vyrenderované HTML alespoň ve třech stavech:

• lokální vývojový build
• staging nebo preview URL
• produkční URL

Pomocí browser DevTools zkontrolujte finální DOM. Vyhledejte application/ld+json a zkopírujte přesný obsah scriptu, který existuje po renderování. Pokud se serverově renderovaný markup liší od hydratovaného markupu, rozhodněte, kterou verzi očekáváte, že budou konzumenti číst.

Zkontrolujte také, zda se strukturovaná data neduplikují. Duplicitní bloky Article nebo Product jsou běžné, když schema vypisuje zároveň CMS plugin i vlastní komponenta. Duplicita není vždy fatální, ale konfliktní duplicita problém je: dvě ceny, dva autoři, dvě data publikování nebo dvě kanonické URL.

Je to podobné jako čtení reportů o výkonu a diagnostice: prvním úkolem není panikařit, ale oddělit signál od šumu. Stejný návyk pomáhá, když čtete Lighthouse report bez paniky — i když samotná strukturovaná data by se neměla redukovat na jedno skóre.

Krok 6: Zkontrolujte produkční transportní detaily

Strukturovaná data mohou být ve zdroji dokonalá, a přesto v produkci selhat, protože stránka není dostupná tak, jak předpokládáte.

Zkontrolujte:

• finální stavový kód je 200, ne soft 404
• kanonická URL odpovídá stránce, kterou validujete
• přesměrování jsou záměrná a stabilní
• direktivy robots neblokují indexaci tam, kde se indexace očekává
• HTML není pro některé user agenty nahrazené chybovou stránkou
• cachované stránky neposkytují zastaralé JSON-LD

Tady záleží na inspekci HTTP. Pokud produktová stránka před dosažením kanonického cíle prochází přes tři URL, validujte finální stránku, ne první URL zkopírovanou z CMS. Pro samotnou mechaniku je užitečným doprovodem náš průvodce debugováním přesměrování a HTTP hlaviček v produkci.

Strukturovaná data nežijí ve vakuu. Cestují společně s hlavičkami, přesměrováními, cachováním, kanonickými značkami a direktivami robots.

Krok 7: Přidejte testy strukturovaných dat do procesu vydávání

Ruční validace je v pořádku pro jednu stránku. Neškáluje ale na stovky nebo tisíce URL.

Jednoduchá sada automatizovaných testů dokáže zachytit nejdražší chyby:

• stáhnout reprezentativní URL z každého typu šablony
• extrahovat všechny bloky JSON-LD
• parsovat je pomocí JSON.parse
• ověřit povinná pole pro každý typ stránky
• zkontrolovat, že data jsou platné řetězce ISO 8601
• zkontrolovat, že URL jsou absolutní a kanonické
• zkontrolovat, že u produktových stránek existují ceny a dostupnost
• zkontrolovat, že duplicitní entity nejsou v konfliktu

Můžete to spouštět v CI pro šablony a podle plánu pro produkční URL. Cílem není dokázat, že se zobrazí každá funkce rozšířených výsledků. To nemůže slíbit nikdo mimo vyhledávač. Cílem je udržet vlastní data přesná, parsovatelná a konzistentní.

<!-- tool-cta:start -->

💡 Vyzkoušejte toto: Před ověřením logiky schématu spusťte svůj JSON-LD přes JSON Formatter, abyste zachytili syntaktické chyby, které by jinak narušily každou následnou kontrolu.

<!-- tool-cta:end -->

Checklist validace začínající u standardů

Použijte tento krátký checklist dříve, než se zeptáte, zda se stránka líbí vyhledávači:

• Je každý blok JSON-LD platný JSON?
• Obsahuje každý blok správný @context a @type?
• Jsou vlastnosti Schema.org napsané správně?
• Odpovídá markup viditelnému obsahu?
• Jsou data, ceny, hodnocení a dostupnost aktuální?
• Jsou URL absolutní, kanonické a dostupné?
• Je vyrenderovaná produkční stránka tou samou stránkou, kterou jste testovali?
• Jsou duplicitní entity záměrné a bez konfliktů?

Pokud na tyto otázky dokážete odpovědět ano, udělali jste trvalou část práce se strukturovanými daty. Testování specifické pro vyhledávače může být později stále užitečné, ale mělo by být závěrečnou kontrolou kompatibility, ne základem validačního procesu.