Are the last-updated dates in your sitemap believable?

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?

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.

Fix it with your AI

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

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 explains what each scan reads, and the full list of checks shows the rest.