SEO-16

Datum změny v sitemapě je neplatné nebo v budoucnu

InfoPřístup pro crawlery

Co kontrola měří

Kontrola projde každý <lastmod> v sitemapě a hledá dvě formální vady. Neplatný formát: hodnota neodpovídá W3C Datetime, ve kterém má <lastmod> podle protokolu sitemaps.org být: přípustné jsou jen RRRR, RRRR-MM, RRRR-MM-DD a úplné datum a čas s časovým pásmem (2026-09-15T10:30:00+02:00). Datum v budoucnu: hodnota leží víc než 24 hodin za okamžikem, kdy jsme sitemapu stáhli (future_tolerance_hours: 24 v config/seo.json).

Report uvede počet obou vad, celkový počet adres s <lastmod> a jeden příklad i s přesnou hodnotou. Tolerance 24 hodin pokrývá časová pásma (datum bez času čteme jako půlnoc UTC, pásma sahají do +14 h) i rozjeté hodiny serveru; zítřejší datum bez času proto nález nevyvolá.

Sitemapu čteme stejně jako u SEO-15: index do pěti vnořených souborů, jinak řádky Sitemap: z robots.txt, včetně .xml.gz.

Co kontrola nedělá:

  • Nepozná, jestli si Google neplatný zápis přesto přečte. Tvrdíme jen, že neodpovídá formátu, který protokol uvádí. Čas bez pásma (2026-09-15T10:30:00) přečte leckterý parser; jestli i Google, nevíme.
  • Neověřuje, že platné datum je pravdivé. To dělají SEO-15 a SEO-17.
  • Nekontroluje chybějící <lastmod>: to je SEO-07.

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

Jak silný důkaz za tím stojí

Efekt nedoložený

Doporučujeme to, protože to neuškodí nebo to má jiný užitek, ale vliv na to, jestli vás jazykové modely budou citovat, neslibujeme. Nikdo ho zatím nedoložil.

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

Formát je fakt, ne názor: sitemaps.org u <lastmod> odkazuje na W3C Datetime a výslovně dovoluje vynechat čas. Datum změny v budoucnu pravdivé být nemůže, a Google podle své dokumentace používá <lastmod> jen tehdy, když je konzistentně přesný. Takové hodnoty tedy může ignorovat.

Při měření na 26 webech (15. 9. 2026) neměl žádný neplatný formát ani datum v budoucnu. Je to vada vzácná a obvykle mechanická, o to snáz se opraví.

Jak to opravit

  • Zapisujte RRRR-MM-DD, nebo úplné datum a čas i s pásmem: 2026-09-15T10:30:00+02:00.
  • Mezera místo T a čas bez pásma formátu neodpovídají: typicky vzniknou, když generátor vypíše databázový čas bez převodu.
  • Datum v budoucnu obvykle znamená přehozený měsíc a den, špatné časové pásmo nebo datum plánované publikace; opravte zdroj, ze kterého se hodnota bere.
<url>
  <loc>https://vase-domena/clanek</loc>
  <lastmod>2026-09-15T10:30:00+02:00</lastmod>
</url>

Co o tom říká report

Popis nálezu

Z [total] URL se `<lastmod>` v sitemapě: neplatný formát [invalid]× (protokol sitemaps.org pro `<lastmod>` uvádí W3C Datetime), datum v budoucnu [future]×. Příklad: [example] má `<lastmod>` `[value]`. Datum změny v budoucnu nemůže být pravdivé a Google podle své dokumentace používá `<lastmod>` jen tehdy, když je konzistentně přesný. Takové hodnoty proto může ignorovat. Zda si neplatný zápis přesto přečte, nevíme. Jde o doporučení pro klasické vyhledávání (Google); nemáme doklad, že by to ovlivňovalo viditelnost v odpovědích AI asistentů.

Doporučení

Zapisujte `<lastmod>` jako `RRRR-MM-DD`, nebo jako úplné datum a čas s časovým pásmem (`2026-09-15T10:30:00+02:00`). Čas bez pásma ani mezera místo `T` formátu neodpovídají. Datum v budoucnu obvykle znamená chybu v generátoru (přehozený měsíc a den, špatné časové pásmo, datum plánované publikace). Opravte zdroj, ze kterého se hodnota bere.

Zdroje

Text ověřen 2026-09-15