# Are the last-updated dates in your sitemap believable?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

This search visibility check flags sitemap dates that are invalid, in the future or all identical, which search engines learn to ignore.

This search visibility check flags last-updated dates in your sitemap that are invalid, in the future or all the same. Search engines learn to ignore dates that do not reflect real changes.

## What does this check look at?

It looks at whether the last-updated dates in your sitemap are valid, in the past and different from each other. Google says it uses the date only when it is consistently and verifiably accurate. A Pulse also reads your sitemap, the list of pages you give search engines.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Info finding | The dates look generated rather than real. | Use each page’s real last change, or leave the date out. |

It is about search visibility only and never affects your grade. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

This is information only. It claims no weakness, so it carries no verdict, and you decide whether anything should change. Confidence starts high, because a response from your site shows the thing itself. The report lists what to fix by how directly someone could use it, not by the severity label. Sitemap cards are not security issues and never change your grade.

## Which standards does it relate to?

None. It is about search visibility, so no security standard applies, and it never moves your grade.

## Fix it with your AI

The usual cause is a generator that stamps every page with the build time.

:::fix-prompt any
My sitemap's lastmod dates are unreliable: [paste the problem from the report]. Change my sitemap generator so each page's lastmod comes from the real date its content last changed (for example a CMS updated date or the file's last commit date), in W3C date format, and leave lastmod out for pages where that date is unknown. Do not use the build time.
:::

## How to check

Say Atlas, our example app at `atlas.example`, stamps every sitemap entry with the time of the last deploy. All dates match, and the check adds one card.

Run a Pulse scan from your Lockpick account to see it for your site. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### Is it better to leave dates out?

Leaving them out is better than wrong dates. Accurate dates help search engines revisit pages that really changed.

### Does this change my security grade?

No. It is about search visibility only.

## Sources

- [Build and submit a sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap), Google Search Central, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07
- [Read your report](https://www.lockpick.app/docs/get-started/read-your-report), Lockpick docs, read on 2026-10-07