Signály aktuálnosti obsahu

Proč „čerstvost“ rozhoduje při AI Overviews a LLM

Modely jako ChatGPT, Gemini či vyhledávací AI Overviews zohledňují signály aktuálnosti, které jim pomáhají rozhodnout, zda je váš obsah hodný citace a shrnutí. Dva nejspolehlivější signály, které můžete mít plně pod kontrolou, jsou changelogy (transparentní historie změn) a daty (publikování, aktualizace, přístupu, verze). Správně navržené a technicky exponované snižují riziko, že model vezme zastaralou verzi, a zvyšují pravděpodobnost, že bude upřednostňovat vaše zdroje při tvorbě odpovědí.

Taxonomie dat: co přesně vyjadřují a kam patří

  • Datum publikování (datePublished): První zpřístupnění obsahu. Zůstává stabilní.
  • Datum aktualizace (dateModified): Poslední podstatná změna obsahu; aktualizovat jen při reálných úpravách.
  • Datum verze (version / releaseDate): Pro obsah se semver (např. „2.3.1“) nebo číslovanými vydáními.
  • Datum přístupu (accessed/lastReviewed): U sekundárních zdrojů a přehledů označuje, kdy byl obsah revidován vůči externím zdrojům.
  • Vydání sekce (part/hasPart): Pokud stránka má více částí (kapitoly, tabulky), každá může mít vlastní datum, aby AI věděla, která část je novější.

Changelog jako informační architektura: formát, granularita, čitelnost

  • Granularita: Seskupit změny do kategorií: Added, Changed, Fixed, Deprecated, Removed, Security.
  • Jasná data a verze: Každý záznam má releaseDate a případně version ve formátu semver nebo roku/měsíce.
  • Odkazy: Každý bod by měl odkazovat na sekci nebo ID prvku, kterého se týká (ukotvení „#id“).
  • Strojová i lidská vrstva: Viditelný seznam pro lidi a paralelní mikrostruktura pro stroje (meta, microdata, JSON-LD).

Viditelné UI signály aktuálnosti, které vnímá člověk i model

  • Banner aktualizace: Nepřehlédnutelný prvek s datem a krátkou větu „Naposledy aktualizováno: 2025-10-22“.
  • U sekcí mini-changelog: U důležitých kapitol zobrazte „Změny v této sekci“ se 3 posledními položkami.
  • Nadpis s verzí: V podnadpisu uveďte verzi obsahu (např. „Metodika benchmarku v2.1“).
  • Ikony a značky: „New“, „Updated“ s datem; po 30 dnech „New“ automaticky expiruje.

Technické exponování dat: co dokážou číst roboti a LLM

  • Schema.org / JSON-LD: Používejte Article (nebo TechArticle/HowTo) s datePublished, dateModified, version, hasPart/isPartOf.
  • HTML meta: <meta property="article:published_time"> a article:modified_time jako sekundární signál.
  • HTTP hlavičky: Last-Modified a ETag pro podmíněné requesty; sladit s dateModified.
  • Sitemapy: V <lastmod> uvádějte UTC v ISO 8601 a aktualizujte jen při podstatné změně.
  • Feedy: Atom/RSS s updated/pubDate pro signalizaci nových vydání.

Struktura changelogu: doporučený obsah a pravidla

Položka Popis Povinné? Příklad
Version Semver nebo datumové vydání Ano 2.4.0
Release date Datum vydání v ISO 8601 Ano 2025-10-22
Type Added/Changed/Fixed/Deprecated/Removed/Security Ano Added
Scope/ID Co se změnilo (sekce, komponenta, dataset) Ano #metodika-vyberu-vzorky
Summary Jednověté vysvětlení Ano Přidáno nové kritérium reprezentativnosti.
Rationale Proč změna Doporučené Sladění s novým standardem.
Impact Dopad na čtenáře/model Doporučené Porovnání před/po není přímo kompatibilní.
Links Interní kotvy, diff, issue Doporučené #sekce, /diff?v=2.3.1..2.4.0

Nejčastější chyby s daty, které mate modely

  • Recyklace data publikování při každé drobné aktualizaci (vypadá to jako nový článek, což snižuje důvěryhodnost).
  • Přehnaně častá aktualizace lastmod v sitemapách bez změny obsahu (spamový signál pro crawlery).
  • Neshoda mezi vrstvami: banner píše „Aktualizováno dnes“, ale dateModified je staré.
  • Skryté changelogy jen v git historii bez publikační reprezentace (LLM nevidí privátní repozitáře).

Vzorná hierarchie dat pro rozsáhlé téma

  • Canonical stránka tématu: má „Last reviewed: 2025-10-01“, verzi metodiky a odkaz na plný changelog.
  • Detailní články (leafy articles): každý má své dateModified a mini-changelog se 3 položkami.
  • Datasety a tabulky: samostatný releaseDate a „Data freshness“ (např. zdroj k datu X).

Měření dopadu na AI Overviews a LLM

  • Recall v AI odpovědích: kolik vašich stránek se objeví v citovaných zdrojích.
  • Time-to-pickup: čas od publikace/aktualizace po první zahrnutí v AI odpovědi.
  • Freshness coverage: podíl top URL s konzistentními daty a changelogem.
  • Diff-impact analýza: porovnání návštěvnosti a změn v SERP/AI po konkrétním vydání.

Governance: workflow a odpovědnosti

  1. Autor připraví změny a návrh záznamu do changelogu (včetně kategorie a dopadu).
  2. Editor validuje významnost změny a nastaví dateModified.
  3. SEO/Tech synchronizuje JSON-LD, sitemap lastmod, HTTP hlavičky a cache-invalidation.
  4. Vydavatel nasadí a kontroluje UI bannery a mini-changelogy.
  5. Analytik sleduje metriky a provádí retrospektivu ke vydáním.

Standardy a normy, na které se vyplatí odkazovat

  • ISO 8601 pro formáty dat (UTC, s časovou zónou podle potřeby).
  • Semver pro verzování metodik, API, datových definic.
  • Schema.org typy: Article, Dataset, TechArticle, SoftwareApplication.

Praktické vzory pro různé typy obsahu

  • Metodické články: verzování + „Last reviewed“ + sekční mini-changelog + odkazy na důkazy.
  • Zprávy: pevný datePublished, případně „Update (YYYY-MM-DD): …“ bez změny starého obsahu.
  • Produktové stránky: „Changes since last release“ s technickými detaily a dopadem na uživatele.
  • Datasety: „Data last updated“, periodicita obnovy, výpis rozdílů (přírůstky/odstraněné položky).

Mini-checklist před publikováním

  • Souhlasí datePublished a dateModified s reálnými úpravami?
  • Je changelog srozumitelný, kategorizovaný a vázaný na konkrétní sekce?
  • Synchronizované vrstvy: banner, JSON-LD, meta, hlavičky, sitemap?
  • Je <lastmod> v sitemapě aktualizováno pouze při významných změnách?
  • Má každá klíčová podstránka vlastní data a (mini) changelog?

Jak informovat modely o změnách bez „spamování“

  • Batch release okna: drobné úpravy agregovat do plánovaných vydání.
  • Stabilní URL + kotvy: neměňte adresu, pouze ukotvení v rámci stránky.
  • Konzistentní diffy: pokud máte veřejný repozitář nebo „/changelog“, aby měl předvídatelný formát.

Příklady formulací pro bannery a záznamy changelogu

  • Banner: „Naposledy aktualizováno: 2025-10-22 – Doplnili jsme kapitolu o schématech JSON-LD.“
  • Changelog (Added): „Přidána sekce ‚Měření dopadu‘ se čtyřmi metrikami.“
  • Changelog (Changed): „Přešli jsme na ISO 8601 v celé dokumentaci.“
  • Changelog (Fixed): „Opraveno nesprávné mapování dateModified v JSON-LD.“

Antipatterny: co se nevyplatí

  • „Updated today“ bez detailu: žádná informace o rozsahu změny je slabý signál.
  • Skrytá data v obrázcích: text v PNG/JPG není spolehlivý signál pro stroje.
  • Masové předatelování dat: zpětná změna datumů pro „čerstvost“ snižuje důvěru.

Changelog a data jako trvalá infrastruktura důvěry

Changelogy a přesná data vytvářejí přehlednou trajektorii obsahu, kterou dokážou číst lidé i LLM. Pokud jsou konzistentní napříč UI, metadaty, protokolovými vrstvami a sitemapami, stávají se silným signálem aktuálnosti. Investice do této „infrastruktury důvěry“ se vrací vyšší viditelností v AI Overviews, nižším rizikem zastaralých citací a stabilnější reputací zdroje.