Sitemapa uvádí starší změnu, než hlásí stránka

U každé nacrawlované stránky, která je v sitemapě s platným <lastmod>, porovnáme dvě tvrzení téhož webu o téže stránce: <lastmod> ze sitemapy a dateModified ze strukturovaných dat (JSON-LD) na stránce. Nález vznikne, když stránka uvádí pozdější změnu o víc než 2 dny (tolerance_days: 2 v config/seo.json). Report uvede počet takových stránek z porovnaných a jeden příklad s oběma hodnotami.

Které dateModified bereme: jen z uzlů, které popisují tuhle stránku: typy …Page (WebPage, FAQPage, CollectionPage…), …Article (Article, NewsArticle, TechArticle…), BlogPosting, Recipe, HowTo, Report a CreativeWork, a jen pokud jejich url nebo @id nemíří na jinou adresu. BreadcrumbList, WebSite, Organization, komentáře ani recenze se nepočítají. Když stránka nese víc hodnot, které se liší o víc než toleranci (typicky výpis článků), přeskočíme ji jako nejednoznačnou.

Tolerance 2 dny pokrývá časová pásma, zaokrouhlení na den (2026-09-12 proti 2026-09-11T22:00:00Z je tentýž okamžik) a cache sitemapy u redakčních systémů.

Hromadná změna se nehlásí. Když aspoň 3 rozpory mají dateModified do 7 dnů od sebe (bulk_change_min_pages, bulk_change_window_days), bereme to jako technické přeuložení (migraci, změnu šablony) a tyhle stránky do nálezu nezapočítáme. Při měření 15. 9. 2026 to na techcrunch.com vyřadilo 13 z 19 rozporů: videa z let 2020–2023 měla dateModified z 7.–10. 5. 2024.

Co kontrola nedělá:

• Nepozná, které z obou dat odpovídá skutečnosti. dateModified se posune i nevýznamnou změnou; pak je <lastmod> v pořádku. Text nálezu to říká a doporučení je podmíněné.
• Nehlásí opačný směr: sitemapa novější než stránka. Google za významnou změnu počítá i změnu odkazů, kterou dateModified článku zachytit nemusí.
• Neporovnává hlavičku Last-Modified. Crawler ji neukládá a u statického hostingu nese čas nasazení souboru, ne změny obsahu; u poctivé sitemapy by dávala falešné nálezy.
• Neporovnává viditelné <time datetime> ani meta article:modified_time: bývá to datum publikace nebo komentáře.
• Neporovnává obsah stránky mezi dvěma audity. Zvažovali jsme to jako nejsilnější důkaz, ale nejde to udělat bez velkého rizika falešných nálezů; zdůvodnění je v docs/moduly-auditu.md.

Nález je na úrovni celého webu a je informativní, bez vlivu na skóre (zdůvodnění u SEO-15).

Na viditelnost v odpovědích AI doložený vliv nemáme.

Google v dokumentaci sitemap píše, že <lastmod> používá, když je „consistently and verifiably (for example by comparing to the last modification of the page) accurate“. Jak přesně „poslední změnu stránky“ zjišťuje, neuvádí, a nevíme, jestli k tomu čte dateModified. Proto nález netvrdí, že Google rozpor vidí; tvrdí jen, že pokud se obsah po datu v <lastmod> opravdu změnil, Google ho může ignorovat.

Samotný rozpor je naopak fakt: dvě hodnoty, které web sám publikuje o téže stránce, si odporují. U strukturovaných dat navíc platí, co u nich platí vždycky: obsah stránky nenahrazují, jen ho popisují.

Nejdřív zjistěte, proč se data rozcházejí, a teprve pak měňte; sjednotit je naslepo může <lastmod> pokazit.

• Obsah se po datu v <lastmod> věcně změnil → opravte generátor sitemapy, aby bral datum poslední významné změny (hlavní obsah, strukturovaná data, odkazy). Typicky bere datum publikace místo data úpravy.
• Sitemapa je z cache → zajistěte, aby se po úpravě stránky obnovila.
• dateModified posunulo jen technické uložení (migrace, hromadná úprava) → sitemapu neměňte. Zvažte, jestli má dateModified takové změny vůbec zachycovat.