Strukturovaná data a datová konzistence

LLM a generativní AI
Veronika Benková
Štruktúrované dáta a dátová konzistencia

Strukturovaná data a datová konzistence v éře SEO, AEO a AIO

Strukturovaná data jsou strojově čitelné anotace, které explicitně popisují obsah stránky a vztahy mezi entitami. V SEO zlepšují srozumitelnost pro vyhledávače, v AEO (Answer Engine Optimization) zpřístupňují přesné odpovědi asistentům a v AIO (AI Optimization) poskytují modelům LLM spolehlivý „zdroj pravdy“. Klíčem k úspěchu však není jen výběr typu schema.org, ale také datová konzistence napříč webem, profily a feedy (sitemapy, produktové katalogy, adresáře NAP).

Proč je konzistence důležitější než samotné schéma

  • Deduplikace a slučování signálů: totožné entity napříč doménami a kanály se mají slučovat, nikoli tříštit (jedna firma ≠ tři názvy a tři telefonní čísla).
  • Přesná identifikace: konzistentní identifikátory (IČO, SKU, GTIN, URL, @id) umožňují sjednocení znalostí o entitě.
  • Stabilita odpovědí: asistenti si vytvářejí „mentální model“ značky; protichůdná data vedou k nepřesným odpovědím.
  • Měření: smysluplné přiřazení (impressions → clicks → conversions) je možné pouze při konzistentních datech.

Standardy schema.org: přehled typů (FAQ, HowTo, Product, Article…)

  • FAQPage: kurátorované otázky a odpovědi, vhodné pro rychlé pokrytí uživatelských dotazů.
  • HowTo: postupy krok za krokem, média, čas, materiály, bezpečnostní poznámky.
  • Product: stav zásob, cena, měna, identifikátory (SKU, GTIN), recenze.
  • Article/NewsArticle/BlogPosting: publikační metadata, autor, data, rubriky, obrázky.
  • LocalBusiness/Organization: údaje NAP (Name, Address, Phone), otevírací doba, geolokace, identifikátory.
  • Event, JobPosting, Course, SoftwareApplication, Service a další podle oboru.

Model „zdroje pravdy“ a datové toky

Data mají vznikat v jednom source of truth (CMS, PIM, DAM, CRM) a odtud se bezpečně replikovat do frontendu, feedů a integrací.

  1. Model entit: definujte povinná a volitelná pole pro každý typ (produkt, článek, pobočka, FAQ).
  2. Identifikátory: udržujte stabilní @id/URL, interní ID, SKU/GTIN, IČO/DIČ a mapování na externí profily.
  3. Normalizace: jednotné formáty (data ISO 8601, měny ISO 4217, telefonní čísla E.164, země ISO 3166).
  4. Validace: validátory schémat (JSON Schema), unit testy a kroky CI před publikováním.
  5. Publikování: generování JSON-LD při vykreslování + export sitemap a tematických feedů.

Konzistentní údaje NAP: Name–Address–Phone bez kompromisů

  • Název: používejte oficiální nebo obchodní název bez variant (zkratky a doplňky pouze tehdy, jsou-li oficiální).
  • Adresa: formát podle poštovních standardů; ukládejte také geo.latitude a geo.longitude.
  • Telefon: formát E.164 (např. +421233456789), stejné číslo napříč webem a profily.
  • Otevírací doba: používejte openingHoursSpecification a speciální dny (specialOpeningHoursSpecification).
  • Profily a identifikátory: propojte sameAs (firemní profily), IČO a registrační čísla; v sitemapách používejte kanonické URL.

Příklad JSON-LD: LocalBusiness s údaji NAP a otevírací dobou

Příklad JSON-LD: Product s cenou, skladovou dostupností a identifikátory

Příklad JSON-LD: Article a HowTo na jedné stránce

Článek může obsahovat související návod. Každá entita má vlastní @id; důležité je konzistentní propojení.

Příklad JSON-LD: FAQPage (konzistentní s obsahem HTML)

Vícejazyčnost a hreflang: datová konzistence napříč trhy

  • Každá jazyková verze má vlastní URL a vlastní schéma s inLanguage.
  • Kanonické odkazy odkazují samy na sebe; jazykové ekvivalenty propojte pomocí hreflang (v HTML nebo v sitemapách).
  • Názvy entit překládejte konzistentně (název firmy se obvykle nepřekládá, popis ano).

Datové feedy: jak sladit schéma s externími kanály

Kromě JSON-LD jsou klíčové feedy, které využívají roboti a platformy. Princip: stejné entity, stejné ID/URL/parametry.

  • XML sitemapy: pouze kanonické URL, správné lastmod, segmentace podle typu obsahu.
  • Merchant/produktové feedy: SKU/GTIN, ceny, skladové zásoby, kategorie → musí odrážet stejné údaje jako Product v JSON-LD.
  • Firemní profily: údaje NAP (Google Business Profile, adresáře) synchronizujte s LocalBusiness.
  • Event/Job feedy: termíny, lokality, stavy (aktivní/ukončený) musí odpovídat webu.
  • Interní feedy NDJSON/CSV: jednoduché toky pro integrace LLM a interní služby se stejnými @id a URL.

Mapování polí: od „source of truth“ po JSON-LD a feed

  1. Definujte mapování: zdrojové pole → pole schema.org → pole ve feedu (např. price_gross → offers.price → g:price).
  2. Pravidla transformace: měna, desetinné čárky, jednotky, lokalizační formáty.
  3. Výjimky: jak reprezentovat nedostupnost (OutOfStock), předobjednávky, dočasné uzavření pobočky.

Validace a QA: co automaticky kontrolovat

  • Sémantika schématu: typy, povinná pole, dostupnost URL (200 OK), obrázky s minimálním rozlišením.
  • Shoda dat: cena v JSON-LD = cena na stránce = cena ve feedu.
  • Shoda údajů NAP: název, adresa a telefon jsou stejné v HTML, JSON-LD, profilech a adresářích.
  • Kanonické odkazy: HTML rel="canonical" odpovídá URL v sitemapách.
  • Konzistence hreflang: vzájemné odkazy, existující cílové URL, správné jazykové kódy.

Monitorování a metriky pro SEO/AEO/AIO

  • Coverage: poměr indexovaných a odeslaných URL.
  • Rozšířené výsledky: počet zobrazení s rozšířeními (FAQ/HowTo/Product/Article).
  • Odpovědi asistentů: citace a kliknutí na vaše kanonické URL.
  • Konzistence NAP: audit změn a odchylek napříč profily.
  • Shoda cen/zkratek: upozornění na nekonzistentní hodnoty mezi webem, JSON-LD a feedy.

Bezpečnost, důvěryhodnost a E-E-A-T

  • Transparentní informace o autorech a datech: u Article/HowTo uvádějte autora, recenzenta a datum aktualizace.
  • Právní náležitosti: licence k médiím, firemní identifikátory, kontaktní údaje.
  • Opatrnost u YMYL: medicína/finance/právo → citujte autority a uvádějte upozornění.

Časté chyby a antipatterny

  1. Nesoulad HTML a JSON-LD: ve schématu je jiný obsah než na stránce.
  2. Duplicitní entity: tentýž produkt se dvěma URL a různými SKU/GTIN.
  3. Nekonzistentní údaje NAP: různé telefonní čísla a názvy v profilech, adresářích a na webu.
  4. Parametrické URL v sitemapách: filtrování, řazení a UTM parametry místo kanonických URL.
  5. Neplatné obrázky: chyba 404 nebo příliš nízké rozlišení pro rozšířené výsledky.

Governance a procesy: jak udržet v datech pořádek

  • Vlastník schématu: odpovědná role za model entit a publikování.
  • Pravidla pojmenování: názvy, slugs, konvence URL a @id.
  • Řízení vydávání: kontrolní seznamy pro schéma, sitemapy a feedy při každém nasazení.
  • Audit: čtvrtletní revize, porovnání s externími profily a adresáři.

Kontrolní seznam před publikováním

  • Má každá entita jednoznačné @id a kanonickou URL?
  • Jsou údaje NAP stejné v HTML, JSON-LD a profilech?
  • Obsahuje index sitemap pouze kanonické URL a správné lastmod?
  • Je FAQ/HowTo/Product/Article validní podle schema.org a skutečně viditelný?
  • Odpovídají si ceny a skladové zásoby na webu, v JSON-LD a feedech?
  • Jsou nastavená upozornění na porušení shody a média s chybou 404?

Shrnutí

Optimalizace pro SEO, AEO a AIO stojí na dvou pilířích: kvalitních strukturovaných datech a neochvějné datové konzistenci. Vyberte správné typy schema.org (FAQ, HowTo, Product, Article…), vytvořte „zdroj pravdy“, slaďte údaje NAP a feedy a zaveďte automatizovanou validaci. Výsledkem jsou přesnější odpovědi asistentů, stabilnější rozšířené výsledky a spolehlivá viditelnost vašich entit v ekosystému vyhledávání a AI.