Date Consistency Check: lastmod, Last-Modified Headers, Schema and Visible Dates

A page can declare its date in four places, and nothing forces them to agree. The CMS writes one, the server writes another, an SEO plugin writes a third, and an editor types the fourth.

As of October 2026, no AI vendor states that page dates influence which pages it retrieves or cites. Anthropic's web search tool does expose a page_age field in its results, described as "When the site was last updated". That shows the date is surfaced to the model. It does not show the date is weighted.

The wider evidence is unresolved. Seer Interactive's July 2026 study reported that 75% of cited pages had been updated within a year, but it had no group of non-cited pages to compare against. Without that base rate, it cannot show the date made any difference. A 252,000-trial lab study (arXiv 2605.25517) found a recent timestamp helped, but only on pages already placed inside the model's context, with no live search involved. The full picture is in content freshness and AI citations.

So why check at all? These fields are self-declared and easy to edit. Bumping them proves nothing. Contradictions, though, are a real defect: a page that tells readers, crawlers and engines three different stories about when it changed is a page with broken data. Pick one true date and make every field say it.

Each field comes from a different system, which is why they drift apart.

The lastmod field is a hint the publisher writes about itself, which is why it proves little on its own. Whether your XML sitemap helps AI search engines is a separate question from whether its dates are accurate.

Schema dates deserve the same framing. Google's AI optimization guide says you don't need special markup to appear in its generative AI features. Check schema dates for accuracy, not because they earn citations.

Budget about an hour for a first pass on a small site.

1. Pick a sample. Choose 10 to 20 URLs that cover every template: pricing, product, blog post, docs, about. Date bugs live in templates, so one bad page usually means every page on that template is bad.
2. Pull the sitemap lastmod. Open your sitemap and find each URL's entry. It looks like this:

<url><loc>https://example.com/pricing</loc><lastmod>2026-10-01</lastmod></url>

3. Read the response header. Run curl -sI https://example.com/pricing and look for the Last-Modified line. Note "absent" if there isn't one. Run it again a few minutes later. If the value changed and nobody edited the page, the header is reporting request or cache time.
4. Extract the schema dates. View the raw page source (not the browser inspector) and search for dateModified and datePublished.
5. Find the visible date in the raw HTML. Compare the raw source with the rendered page. Vercel found that ChatGPT and Claude crawlers fetch JavaScript files but don't execute them. A date that only appears after JavaScript runs is invisible to those crawlers.
6. Record the ground truth. Open the CMS revision history and note the date of the last real content change. Ignore saves that only touched formatting or metadata.
7. Compare in one row. Put all five values side by side in a spreadsheet, one row per URL. Flag any field more than a day off the ground truth (a day allows for time zones).
8. Fix at the source. Trace each flagged field to the template, plugin or server rule that writes it, and correct that.

You are already reading headers in step 3, so check for stray suppression directives at the same time. The X-Robots-Tag header check covers that.

Run down this list for every sampled URL:

• Sitemap lastmod matches the last real content change, within a day.
• Sitemap lastmod values differ across URLs (they are not all one build timestamp).
• Last-Modified header is either absent or stable between two requests with no edit in between.
• Last-Modified header does not post-date the ground truth because of a deploy or cache purge.
• Schema dateModified matches the ground truth.
• Schema datePublished is earlier than or equal to dateModified.
• No date in any field is in the future.
• The visible "Updated" or "Published" date matches the schema date it claims to represent.
• The visible date appears in the raw HTML, not only after JavaScript runs.
• Every date field moved when the page's facts (a price, a plan, a spec) last changed.
• No plugin or script bumps dates on a schedule without a content change.

Good

Every field agrees, within a day, with the last real edit in the CMS. Pages that haven't changed in a year say so. The visible date sits in the server-rendered HTML. When you changed a price last month, the dates on that page moved and the dates on untouched pages didn't.

Bad

These patterns each point to a specific cause:

• Every sitemap URL shares one lastmod. The sitemap generator stamps build time. Fix the generator to read each page's edit date.
• dateModified is newer than any real edit. A plugin updates it on every save, or a "refresh" tool bumps it on a schedule. Turn that behavior off.
• Last-Modified changes on every request. The server or CDN reports generation time. Either set it from the content's edit date or remove it.
• Visible date is older than the schema date. The template hardcodes the original publish date as "Updated". Map it to the correct field.
• datePublished is after dateModified. A migration rewrote one field and not the other.

Say you run a hypothetical SaaS site whose pricing page shows "Updated March 2026" while its schema says October and its sitemap says yesterday. Nobody, human or crawler, can tell which is true. That is the defect to fix.

Don't fix it by moving every date forward. If the content didn't change, the date shouldn't either. Whether changing the last updated date helps AI cite a page has no supporting evidence, and faking it corrupts your own records.

Date bugs arrive with system changes, not with time. Rerun the full check:

• After any CMS, theme or SEO plugin update.
• After a CDN, caching or hosting change.
• After a site migration or URL restructure.
• After a pricing or product change, to confirm the dates moved with the facts.

With no system changes, a quarterly sample of one URL per template is enough.

Pair it with a facts check. A date that moved while the price on the page is still last year's is two problems on one page. The guide to fixing contradicting brand facts covers that half, and both fit inside a one-afternoon AI visibility check.

Clean dates tell you your own data is accurate. They don't tell you whether any engine read a date, weighted it, or retrieved your page at all. Retrieval is per query and at each engine's discretion.

The levers with documented mechanisms are about access: server-rendering the content that matters, allowing each retrieval bot in robots.txt, and making sure your firewall or CDN doesn't turn crawlers away. If a brand is missing from AI answers, check those first. Date hygiene is worth doing because broken data is broken, not because it moves citations.

Should I update dateModified every time I republish a page? Only when the content changed in a way a reader would notice: a new price, a corrected fact, a rewritten section. Fixing a typo or changing a layout isn't a content change. If a plugin bumps dateModified on every save, turn that off. The field should record when the page's substance changed, because that is the only version of the date that stays useful to readers and to your own audits.

Which date wins when the fields disagree? The CMS revision history wins, specifically the last edit that changed the page's substance. Treat that as ground truth and make every other field match it. Don't pick the newest date because it looks fresher. Don't pick the sitemap value because it's easiest to edit. Trace each wrong field back to the system that writes it and correct the rule there, so the fix holds for every page on that template.

Do AI engines read schema dates or the sitemap lastmod? No vendor documents which date fields it reads or how it uses them. Anthropic's web search tool exposes a page_age field described as when the site was last updated, but it doesn't say where that value comes from or that it affects selection. As of October 2026, the honest answer is that dates are surfaced by at least one engine and weighted by none that has said so.

Is a missing Last-Modified header a problem? Not by itself. An absent header is better than one that reports the time of every request, because a wrong date is worse than no date. If your server can set Last-Modified from the content's real edit date, do that. If it can't, leaving the header off is a reasonable choice. The checklist only fails a header that contradicts the ground truth.

Can bumping dates to look fresh get a page penalized? The evidence here doesn't measure a penalty for date bumping, so no one can promise one either way. The concrete harm is to you: fake dates destroy your record of what changed when, mislead readers, and make any freshness analysis on your own site meaningless. Since no vendor says dates drive selection, there is nothing to gain that would offset those costs.