SEO-16

Sitemap modification date is invalid or in the future

InfoCrawler access

What the check measures

The check goes through every <lastmod> in the sitemap looking for two formal defects. Invalid format: the value does not match W3C Datetime in which <lastmod> should be according to the sitemaps.org protocol. Only YYYY, YYYY-MM, YYYY-MM-DD and a full date and time with a time zone (2026-09-15T10:30:00+02:00) are allowed. Date in the future: the value lies more than 24 hours after the moment we downloaded the sitemap (future_tolerance_hours: 24 in config/seo.json).

The report gives the count of both defects, the total number of URLs with <lastmod> and one example with the exact value. The 24-hour tolerance covers time zones (a date without a time is read as midnight UTC, time zones reach +14 h) and a server clock that is off, so tomorrow's date without a time does not raise a finding.

The sitemap is read the same way as for SEO-15: an index up to five nested files, otherwise the Sitemap: lines in robots.txt, including .xml.gz.

What the check does not do:

  • It does not know whether Google still reads an invalid value. We only claim it does not match the format the protocol specifies. A time without a time zone (2026-09-15T10:30:00) is read by plenty of parsers; whether by Google, we do not know.
  • It does not verify that a valid date is true. That is what SEO-15 and SEO-17 do.
  • It does not check a missing <lastmod>: that is SEO-07.

The finding is site-level and informational, with no effect on the score (reasoning under SEO-15).

How strong the evidence is

Effect not demonstrated

We recommend it because it does no harm or has some other benefit, but we promise nothing about whether it makes language models cite you. Nobody has demonstrated that yet.

For visibility in AI answers we have no documented effect.

The format is a fact, not an opinion: sitemaps.org points <lastmod> to W3C Datetime and explicitly allows leaving out the time. A modification date in the future cannot be true, and according to its documentation Google uses <lastmod> only when it is consistently accurate. So it may ignore such values.

When measured on 26 sites (15 Sep 2026), none had an invalid format or a date in the future. The defect is rare and usually mechanical, which makes it all the easier to fix.

How to fix it

  • Write YYYY-MM-DD, or a full date and time including the zone: 2026-09-15T10:30:00+02:00.
  • A space instead of T and a time without a zone do not match the format; they typically appear when the generator prints a database timestamp without conversion.
  • A date in the future usually means month and day swapped, a wrong time zone or a scheduled publication date; fix the source the value comes from.
<url>
  <loc>https://your-domain/article</loc>
  <lastmod>2026-09-15T10:30:00+02:00</lastmod>
</url>

What the report says about it

Finding description

Of [total] URLs with `<lastmod>` in the sitemap: invalid format [invalid]× (the sitemaps.org protocol specifies W3C Datetime), date in the future [future]×. Example: [example] has `<lastmod>` `[value]`. A modification date in the future cannot be true, and according to its documentation Google uses `<lastmod>` only if it is consistently accurate, so it may ignore such values. Whether it still reads an invalid value, we do not know. This is a recommendation for classic search (Google); we have no evidence that it affects visibility in AI assistants' answers.

Recommendation

Write `<lastmod>` as `YYYY-MM-DD`, or as a full date and time with a time zone (`2026-09-15T10:30:00+02:00`). A time without a time zone, or a space instead of `T`, does not match the format. A date in the future usually means a bug in the generator (month and day swapped, wrong time zone, a scheduled publication date). Fix the source the value comes from.

Sources

Text verified 2026-09-15