Ako validovať štruktúrované dáta bez nástrojov Google
Praktický pracovný postup na kontrolu JSON-LD, slovníka Schema.org, vykresleného HTML a správania v produkcii bez toho, aby bol Google považovaný za jediný zdroj pravdy.
Obsah
- Čo vlastne validujete?
- Krok 1: Parsujte JSON skôr, než začnete myslieť na SEO
- Krok 2: Kontrolujte správanie JSON-LD, nielen syntax JSON
- Krok 3: Validujte voči slovníku Schema.org
- Krok 4: Porovnajte značkovanie s viditeľným obsahom
- Article a BlogPosting
- Product
- LocalBusiness
- BreadcrumbList
- Krok 5: Validujte vykreslenú stránku, nie svoju šablónu
- Krok 6: Skontrolujte produkčné transportné detaily
- Krok 7: Pridajte testy štruktúrovaných dát do procesu vydávania
- Kontrolný zoznam validácie so štandardmi na prvom mieste
Validácia štruktúrovaných dát sa stala zvláštne závislou od nástrojov orientovaných na Google. Je to pochopiteľné: mnohé tímy pridávajú JSON-LD preto, že chcú rozšírené výsledky, a testovacie nástroje Google sú známe. Štruktúrované dáta však nie sú formát Google. Zvyčajne ide o JSON-LD so slovníkom Schema.org, vložený do HTML, interpretovaný mnohými konzumentmi a udržiavaný vaším vlastným publikačným workflow.
Ak validujete iba optikou vyhľadávača, môžete prehliadnuť základné problémy: neplatný JSON, dáta, ktoré po vykreslení zmiznú, neaktuálne ceny produktov, konfliktné kanonické URL alebo značkovanie, ktoré je technicky platné, ale sémanticky nezmyselné.
Lepší postup je začať štandardmi. Najprv validujte dáta ako dáta, potom validujte slovník a napokon validujte stránku tak, ako existuje v produkcii.
Čo vlastne validujete?
„Štruktúrované dáta“ nie sú jedna vec. Na väčšine webov majú štyri vrstvy:
- Syntax JSON — dá sa kód parsovať?
- Model JSON-LD — rozšíri sa na zmysluplné prepojené dáta?
- Slovník Schema.org — sú typy a vlastnosti primerané?
- Pravdivosť na úrovni stránky — zodpovedá značkovanie tomu, čo môžu vidieť používatelia a crawlery?
Nástroje Google sa väčšinou zameriavajú na štvrtú vrstvu plus na pravidlá oprávnenosti pre rozšírené výsledky špecifické pre Google. Užitočné, áno. Úplné, nie.
Napríklad toto môže byť platný JSON-LD a stále ísť o slabé štruktúrované dáta:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Best winter jackets",
"datePublished": "2026-01-12",
"author": {
"@type": "Organization",
"name": "Editorial Team"
}
}
Nie je tu nič pokazené. Ak má však viditeľná stránka iný nadpis, žiadne uvedenie autora a dátum poslednej úpravy, ktorý je v rozpore so značkovaním, máte problém s kvalitou, nie so syntaxou.
Krok 1: Parsujte JSON skôr, než začnete myslieť na SEO
Začnite nudnou kontrolou: dá sa JSON parsovať?
JSON-LD vložený do HTML sa často pokazí pre malé chyby v šablóne:
- koncové čiarky
- neescapované úvodzovky v názvoch produktov
- neplatné zalomenia riadkov v reťazcoch
- chýbajúce zložené zátvorky po podmienených poliach
- duplicitné script bloky z dedenia layoutu
- CMS pluginy vypisujúce neúplné objekty
Na lokálne kontroly nepotrebujete SEO platformu. Použite nástroje, ktoré už máte vo svojom vývojovom stacku.
V JavaScripte:
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 prvkov z vykresleného HTML a parsujte ho ako JSON. Takto zachytíte mnoho problémov skôr, než sa dostanú do produkcie.
Dôležitý bod: urobte to pred akoukoľvek validáciou Schema.org. Validátor slovníka nepomôže, ak dáta nie sú platný JSON.
Krok 2: Kontrolujte správanie JSON-LD, nielen syntax JSON
Platný JSON nie je automaticky platný JSON-LD. JSON-LD používa pojmy ako @context, @type, @id a vzťahy v grafe. Ak sú poškodené, parsery môžu vaše dáta interpretovať inak, než ste zamýšľali.
Minimálne potvrďte, že:
- každý blok má vhodný
@context - primárne entity majú jasné hodnoty
@type - opakované entity používajú stabilné hodnoty
@id, kde je to užitočné - vnorené entity sú logicky prepojené
- polia sa používajú tam, kde je možných viac hodnôt
Pri väčších weboch sú stabilné identifikátory obzvlášť užitočné. Ak sa vaša organizácia objavuje v dátach Article, Product, BreadcrumbList a FAQPage, použitie rovnakého @id pomáha konzumentom pochopiť, že ide o odkazy na tú istú entitu, nie o štyri nesúvisiace organizácie s rovnakým názvom.
Typický vzor vyzerá takto:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Ltd",
"url": "https://example.com/"
}
Nesnažíte sa tu zapôsobiť na validátor. Robíte svoje dáta menej nejednoznačnými.
Krok 3: Validujte voči slovníku Schema.org
Keď sú JSON a štruktúra JSON-LD v poriadku, skontrolujte slovník.
Validátor Schema.org je užitočný, pretože testuje podľa termínov Schema.org, nie podľa pravidiel jedného vyhľadávača pre rozšírené výsledky. Môže ukázať, či sú vlastnosti rozpoznané, či sa typy interpretujú podľa očakávania a či vaše vnorené štruktúry dávajú zmysel.
Tu zachytíte chyby ako:
publishingDatenamiestodatePublishedimageUrltam, kde sa očakávaimage- značkovanie
Productna výpise kategórie, ktorý nie je produktom AggregateRatingbez zmysluplne hodnotenej položkyPersonpoužitý pre značkový účet
S upozorneniami zaobchádzajte opatrne. Schema.org je zámerne flexibilný. Validátor môže povoliť vlastnosť, ktorá nie je užitočná pre váš prípad použitia, alebo upozorniť na niečo, čo je voliteľné. Validáciu berte ako dôkaz, nie ako verdikt.
Praktické pravidlo: ak vlastnosť pomáha stroju presnejšie pochopiť stránku, ponechajte ju. Ak existuje iba preto, že ju niekto skopíroval z generátora úryvkov, spochybnite ju.
Krok 4: Porovnajte značkovanie s viditeľným obsahom
Vyhľadávače a iní konzumenti dát majú tendenciu nedôverovať značkovaniu, ktoré nezodpovedá stránke. Ešte dôležitejšie je, že používatelia si zaslúžia konzistentnosť.
Pri každom type štruktúrovaných dát porovnajte značkovanie s viditeľnou stránkou:
Article a BlogPosting
Skontrolujte, či sú nadpis, autor, dátum publikovania, dátum úpravy, obrázok a vydavateľ viditeľné alebo rozumne odvoditeľné. Ak publikujete obsah s asistenciou AI, vaše štruktúrované dáta by sa nemali používať na zakrývanie nejasného autorstva. Samostatne sme písali o poctivom zverejnení používania AI na malom webe a rovnaký princíp platí aj tu: metadata majú objasňovať, nie zahmlievať.
Product
Skontrolujte názov, cenu, dostupnosť, menu, varianty, hodnotenia a počty recenzií. Štruktúrované dáta produktov sú obzvlášť náchylné na zastaranie, pretože ceny a stav skladu sa menia mimo CMS.
LocalBusiness
Skontrolujte názov, adresu, telefónne číslo, otváracie hodiny a obsluhovanú oblasť. Ak päta hovorí jednu vec a váš JSON-LD inú, JSON-LD nie je „lepší“. Je rozporuplný.
BreadcrumbList
Skontrolujte, či pozície omrvinkovej navigácie zodpovedajú viditeľnej trase a či sú URL kanonické, crawlrateľné a zbytočne nepresmerované.
Nie je to okázalá práca. Zároveň je to miesto, kde sa nachádza veľa problémov so štruktúrovanými dátami.
Krok 5: Validujte vykreslenú stránku, nie svoju šablónu
Mnohé weby generujú JSON-LD cez JavaScript, tag managery, personalizačné vrstvy alebo hydratáciu komponentov. To znamená, že súbor šablóny nemusí predstavovať to, čo crawler alebo prehliadač skutočne vidí.
Validujte vykreslené HTML aspoň v troch stavoch:
- lokálny vývojový build
- stagingová alebo náhľadová URL
- produkčná URL
Použite DevTools v prehliadači na kontrolu finálneho DOM. Vyhľadajte application/ld+json a skopírujte presný obsah script prvku, ktorý existuje po vykreslení. Ak sa serverovo vykreslené značkovanie líši od hydratovaného značkovania, rozhodnite, ktorú verziu očakávate, že budú konzumenti čítať.
Skontrolujte aj to, či sa štruktúrované dáta neduplikujú. Duplicitné bloky Article alebo Product sú bežné, keď schému generuje CMS plugin aj vlastný komponent. Duplikácia nie je vždy fatálna, ale konfliktná duplikácia je problém: dve ceny, dvaja autori, dva dátumy publikovania alebo dve kanonické URL.
Je to podobné ako čítanie výkonnostných a diagnostických reportov: prvou úlohou nie je panikáriť, ale oddeliť signál od šumu. Rovnaký návyk pomáha, keď čítate report Lighthouse bez paniky — hoci samotné štruktúrované dáta by sa nemali redukovať na jedno skóre.
Krok 6: Skontrolujte produkčné transportné detaily
Štruktúrované dáta môžu byť vo vašom zdroji dokonalé a napriek tomu v produkcii zlyhať, pretože stránka nie je dostupná tak, ako predpokladáte.
Skontrolujte:
- finálny stavový kód je
200, nie soft 404 - kanonická URL zodpovedá stránke, ktorú validujete
- presmerovania sú zámerné a stabilné
- direktívy robots neblokujú indexovanie tam, kde sa indexovanie očakáva
- HTML nie je pre niektoré user agenty nahradené chybovou stránkou
- cachované stránky neposkytujú zastaraný JSON-LD
Tu záleží na kontrole HTTP. Ak stránka produktu prechádza cez tri URL pred dosiahnutím kanonického cieľa, validujte finálnu stránku, nie prvú URL skopírovanú z CMS. Pre samotnú mechaniku je užitočným sprievodcom náš návod na ladenie presmerovaní a HTTP hlavičiek v produkcii.
Štruktúrované dáta nežijú vo vákuu. Cestujú spolu s hlavičkami, presmerovaniami, cachovaním, kanonickými značkami a direktívami robots.
Krok 7: Pridajte testy štruktúrovaných dát do procesu vydávania
Manuálna validácia je v poriadku pre jednu stránku. Neškáluje však na stovky alebo tisíce URL.
Jednoduchá automatizovaná testovacia sada dokáže zachytiť najdrahšie chyby:
- načítať reprezentatívne URL pre každý typ šablóny
- extrahovať všetky bloky JSON-LD
- parsovať ich pomocou
JSON.parse - overiť povinné polia pre každý typ stránky
- skontrolovať, že dátumy sú platné reťazce ISO 8601
- skontrolovať, že URL sú absolútne a kanonické
- skontrolovať, že pri produktových stránkach existujú cena a dostupnosť
- skontrolovať, že duplicitné entity nie sú v konflikte
Môžete to spúšťať v CI pre šablóny a podľa harmonogramu pre produkčné URL. Cieľom nie je dokázať, že sa zobrazí každá funkcia rozšírených výsledkov. To nemôže sľúbiť nikto mimo vyhľadávača. Cieľom je udržať vaše vlastné dáta presné, parsovateľné a konzistentné.
<!-- tool-cta:start -->
💡 Vyskúšajte toto: Pred validáciou logiky schémy spustite svoj JSON-LD cez JSON Formatter, aby ste zachytili syntaktické chyby, ktoré by inak narušili každú následnú kontrolu.
<!-- tool-cta:end -->
Kontrolný zoznam validácie so štandardmi na prvom mieste
Použite tento krátky kontrolný zoznam skôr, než sa opýtate, či sa stránka páči vyhľadávaču:
- Je každý blok JSON-LD platný JSON?
- Obsahuje každý blok správny
@contexta@type? - Sú vlastnosti Schema.org napísané správne?
- Zodpovedá značkovanie viditeľnému obsahu?
- Sú dátumy, ceny, hodnotenia a dostupnosť aktuálne?
- Sú URL absolútne, kanonické a dostupné?
- Je vykreslená produkčná stránka tá istá stránka, ktorú ste testovali?
- Sú duplicitné entity zámerné a bez konfliktov?
Ak na tieto otázky viete odpovedať áno, urobili ste trvácnu časť práce so štruktúrovanými dátami. Testovanie špecifické pre vyhľadávače môže byť neskôr stále užitočné, ale malo by byť finálnou kontrolou kompatibility, nie základom vášho validačného procesu.