Skoro všechny URL v sitemapě mají stejné datum změny

Kontrola spočítá, kolik adres v sitemapě uvádí v <lastmod> tentýž kalendářní den. Nález vznikne, když ho má aspoň 95 % adres s platným datem (min_same_day_share: 0.95 v config/seo.json) a takových adres je aspoň 20 (min_urls_with_lastmod). Report uvede ten den, počet adres a kolik souborů sitemapy jsme přečetli.

Den se bere tak, jak je zapsaný, bez přepočtu časového pásma. Různé časy téhož dne (sestavení, které trvalo pár minut) se počítají jako jeden den.

Práh je z měření, ne od stolu. Na 26 reálných webech (15. 9. 2026) měly weby s daty z gitu nebo z redakčního systému nejčastější den u 0,4–60 % adres. Nejvýš legitimně vypadající hodnota byla 89 %: e-shop na Shopify, kde se datum produktu posouvá s každou synchronizací skladu. Naopak sitemapa, která dosazuje dnešní datum, vyšla na 100 %. Práh 95 % leží nad tou nejvyšší legitimní hodnotou.

Když je na /sitemap.xml index (WordPress, Shopify, velké weby), přečteme nejvýš pět vnořených souborů; když tam sitemapa není vůbec, vezmeme soubory ze řádků Sitemap: v robots.txt. Soubory .xml.gz rozbalíme.

Co kontrola nedělá:

• Nepozná, jestli se obsah opravdu změnil. Je to heuristika: nový web, kde všechny stránky vznikly týž den, vypadá stejně jako sitemapa s datem sestavení. Text nálezu to říká.
• Nepočítá Google News sitemapu (<news:news>): ta z definice obsahuje jen články z posledních dvou dnů, shodné datum je u ní normální.
• Nečte celou sitemapu velkého webu: jen prvních pět souborů. Report uvádí, kolik z kolika.
• Nekontroluje <priority> ani <changefreq>. Google je podle vlastní dokumentace ignoruje, takže nález by nic neřekl.
• Nespouští se pod 20 adres s datem; malý web se třemi stránkami změněnými týž den to legitimně mít může.

Nález je na úrovni celého webu a je informativní: skóre nesnižuje ani o bod, stejně jako chybějící <lastmod> u SEO-07. Jediný doložený důsledek nepřesného data je totiž ten, že ho Google může přestat brát v úvahu, a to je stejný stav, jako by <lastmod> nebyl.

Na viditelnost v odpovědích AI doložený vliv nemáme, stejně jako u SEO-07 a ACC-06. Žádný provozovatel jazykového modelu nedeklaruje, že by <lastmod> četl.

Pro klasické vyhledávání to Google popisuje vlastními slovy: „Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate.“ Datum má odpovídat poslední významné změně: hlavního obsahu, strukturovaných dat nebo odkazů, ne třeba roku v patičce.

Protokol sitemaps.org to říká ještě přímočařeji: datum má odpovídat poslední změně odkazované stránky, „not when the sitemap is generated“, ne okamžiku, kdy se sitemapa vygenerovala.

Z toho plyne i hranice toho, co smíme tvrdit: nepřesný <lastmod> Google může ignorovat. Že ho ignorovat bude, ani jak rychle, dokumentace neříká, a my to nevíme.

Najděte, odkud generátor sitemapy datum bere. Typické příčiny: new Date() v generátoru (Next.js sitemap.ts, vlastní skript), čas sestavení u statického webu, datum posledního nasazení, nebo pole „upraveno“, které posune každé hromadné uložení.

• <lastmod> = datum poslední významné změny stránky, nejlépe ze stejného zdroje jako obsah (redakční systém, historie v gitu).
• Když skutečné datum neznáte, <lastmod> vynechte. Chybějící údaj je poctivější než vymyšlený a stojí stejně.
• Nový web, kde opravdu všechno vzniklo týž den, nález ignorujte; s dalšími úpravami se data rozejdou sama.
• <priority> a <changefreq> kvůli tomu neupravujte, Google je nepoužívá.