dateModified and datePublished: A Freshness Guide for AI

A date is the cheapest freshness signal you can send, and one of the easiest to get subtly wrong. It sits in three different places on a page, each one read by a different system, and when those three copies disagree, the whole signal turns to noise. This guide walks through what datePublished and dateModified actually mean, where they live, what Google and AI answer engines do with them, and why bumping a date without changing the content behind it tends to backfire.

The three places a date lives

When you think about "the date on a page," you are usually picturing one thing: the "Published on" or "Last updated" line near the headline. But a well-built page carries that date in three separate spots, and they are not the same thing.

The visible date. The text a human reads, sitting under the title or at the foot of the article: "Published 4 March 2026" or "Updated last week." This is the version every reader sees, and the only one most people ever check.

The structured data. A machine-readable copy of the same fact, written into the page's JSON-LD block as datePublished and dateModified. Nobody sees this directly. It exists so a search engine does not have to guess the date by reading the page like a person would.

The plumbing. Two signals that live outside the visible page entirely. The Last-Modified HTTP header, sent by your server when the page is requested, and the lastmod value in your XML sitemap, the file that lists your URLs for crawlers. Both are dates, both claim to say when the page last changed, and both are invisible unless you go looking with a developer tool.

A reader only ever meets the first one. Google reads all three and weighs them against each other. Most AI answer engines, as we will get to, mostly see the first one and whatever Google or Bing already worked out. The point of keeping all three in sync is that a disagreement between them is itself a signal, and not a good one.

datePublished and dateModified: what each one actually means

Both properties come from schema.org, and both belong to CreativeWork, which is the parent type for Article, BlogPosting, WebPage, NewsArticle, VideoObject, and most other content types you would mark up. You do not need an Article specifically to use them.

datePublished is, in schema.org's words, the "date of first publication or broadcast." It is set once, when the page goes live, and it never changes again. If you genuinely republish a page as a new piece (new URL, rewritten from scratch, treated as fresh content), that is a new datePublished. A normal edit is not.

dateModified is "the date on which the CreativeWork was most recently modified." This one moves. Every time you make a real change to the page, it should be updated to match. The word doing the work in that definition is "modified," and it means the content, not the page's own housekeeping. Regenerating a template, touching a stylesheet, or rolling the copyright year in the footer is not a modification in the sense that matters here.

Both values use ISO 8601 format, which is the YYYY-MM-DD ordering, optionally followed by a time and a timezone: 2026-03-04 on its own is fine, 2026-03-04T09:30:00+00:00 is better. Google's Article structured data documentation lists both as recommended rather than required, and notes that if you leave the timezone off, it assumes Googlebot's own timezone, which may not be yours.

Here is what a minimal, correct pair looks like inside a page's JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to winter-proof a drip irrigation system",
  "datePublished": "2024-10-11T08:00:00-05:00",
  "dateModified": "2026-02-28T14:20:00-05:00"
}

That page was first published in October 2024 and last meaningfully edited at the end of February 2026. Both facts are true, both are stated plainly, and a machine does not have to infer either one.

What Google actually does with the dates

Google is open about the fact that it does not trust any single date. Its guidance on publication dates puts it directly: "Google doesn't depend on a single date factor because all factors can be prone to issues. That's why our systems look at several factors to determine our best estimate of when a page was published or significantly updated."

Structured data is one of those factors, and Google explicitly recommends providing it. But it is checked against everything else: the visible date on the page, the lastmod in your sitemap, the date in the URL if there is one, references to the page elsewhere, and Google's own record of when it last saw the page change. Your job is to make all of those agree so Google's "best estimate" lands on the date you actually mean.

Three things from that same guidance are worth pinning down.

Consistency is a stated requirement, not a nicety. Google asks you to "ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values." If your byline says one date and your JSON-LD says another, you have handed Google a contradiction to resolve, and it may not resolve it your way.

A shown date is never guaranteed. Even a perfectly marked-up date might not appear in the search result. Google's line is that following the guidelines "does help our algorithms find and process the information," but there is no promise it gets displayed. Mark dates up because they help Google understand the page, not because you are certain of a visible payoff.

Extra dates on the page work against you. The guidance tells publishers to "minimize the presence of other dates on the page." A comment thread dated last week, a "related posts" widget full of old dates, an unrelated event date in the body text: each one is a candidate Google might latch onto instead of the real one. Keep the real date prominent and clearly labelled ("Published," "Updated"), and keep stray dates away from it.

The sitemap lastmod trust model

The lastmod date in your XML sitemap has its own history with Google. For years Google largely ignored it, because too many sites set every URL's lastmod to the current date on every crawl, which made it worthless. Google's current sitemap documentation now says it "uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate."

The practical shape of this, as described by Google's Gary Illyes, is close to binary. Google samples your lastmod dates against what it finds when it actually fetches the pages. If they hold up, it uses them. If your site has a track record of lastmod values that do not match reality, Google stops trusting the field for your whole domain. The same documentation is explicit that "an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not." A sitemap that claims every page changed today, every day, is the fastest way to get the field ignored.

What AI answer engines do with the dates (the honest version)

This is where expectations and reality tend to part ways.

Google AI Overviews and AI Mode inherit Google's date understanding. They are built on the same index and the same systems that already worked out your page's date from the signals above. So everything in the previous section applies: get your dates consistent and accurate, and the version of your page that feeds an AI Overview carries an accurate date with it. Google has said its AI features lean on the same core ranking systems, and those systems have always had a bias toward content that is genuinely current for questions where recency matters.

Retrieval-based assistants mostly do not read your JSON-LD dates. When ChatGPT, Perplexity, or Gemini answer a question by searching the live web, they fetch pages, pull out the readable text, and cite what looks most relevant and current. There is no published documentation from OpenAI or Perplexity saying their crawlers parse dateModified out of your structured data the way Googlebot does. What they can see plainly is the visible date on the page and, indirectly, how recently the page actually changed. Independent analyses of AI citations have repeatedly found that assistants with live web access cite recently published or updated pages more often, especially for anything with a time element, but that is an observed pattern, not a spec you can code against.

The takeaway splits cleanly. For Google rich results and for the date Google attributes to your page, the structured data matters and needs to be right. For the broader set of AI assistants, the visible date and a real history of updates carry more weight than the markup, because the markup is not what they are reading. A page that says "Updated February 2026" in plain text, and genuinely was, is doing more for its standing with ChatGPT than a flawless dateModified value buried in JSON-LD that the assistant never looks at.

Either way, the honest work is the same: keep the page current, and let all three copies of the date reflect that. There is no version of this where you win by getting the markup right and letting the content rot.

Fake freshness: why bumping the date backfires

The tempting shortcut is obvious. If fresher pages do better, change dateModified to today, change the byline to match, and let the sitemap lastmod follow. The page looks maintained without anyone maintaining it.

It does not hold up, for a few connected reasons.

Google checks the claim against the page. As covered above, lastmod is verified against what Google finds on the actual fetch. Structured-data dates are cross-checked against the visible date and Google's own crawl history. A date that jumped forward with no matching content change is exactly the mismatch those checks exist to catch. Do it across a lot of URLs and you risk Google discounting your date signals site-wide.

It reads as misrepresentation. Google's spam policies prohibit structured data that does not reflect the page's actual content. A dateModified asserting a change that did not happen is a small version of that, and since 2026 the policy framing has been broad enough to treat markup that misleads a generative system the same way it treats markup that misleads a ranking system. We covered the full scope of that shift in our breakdown of the 2026 AI spam policy; the short version is that "the page says X, the markup says Y" is riskier ground than it used to be.

It trains your readers to distrust the date. A visitor who opens a page dated "yesterday" and finds a reference to a product that shut down two years ago learns to ignore your dates. So does anyone evaluating the page for quality, human or otherwise.

A real update is not a high bar. "Significant" in Google's sense means the main content, the structured data, or the links changed. Rewriting a section, adding a new example, correcting figures that went stale, pulling a paragraph that is no longer true: any of those is a genuine dateModified bump. The rule is not "never touch the date," it is "move the date when you move the content, and not before."

When the three dates drift apart

Even with good intentions, the three copies of a date fall out of sync constantly, because they are usually maintained by different systems that do not talk to each other.

Hardcoded markup versus a live CMS. A developer writes a JSON-LD template with the dates wired to the CMS fields, then months later someone hardcodes a date into one page during a rush and it never updates again. Or the reverse: the visible date is a live field, the structured data is a static block a plugin generated once.

A redesign that moved the content but not the markup. A theme change rebuilds every visible page, including the byline, but leaves the old structured-data template running underneath, still emitting dates from the previous system's logic.

Plugin defaults. More than one SEO or schema plugin will happily set dateModified to the page's last-saved timestamp in the database, which changes when you edit a tag, adjust a category, or bulk-run an unrelated tool, none of which touched the content.

Caching. A CDN or page cache serves a stale Last-Modified header from whenever the cached copy was generated, while the real page moved on.

The WordPress version of this is common enough to name directly: the visible date comes from the post's modified field, the structured data comes from whichever of Yoast, Rank Math, AIOSEO, or a dedicated schema tool is running, and the sitemap lastmod comes from a fourth source. Four systems, four opinions about when the page last changed. Sorting out which one is authoritative, and making the others follow it, is most of the fix. Markup that is generated from the live page each time it changes, rather than written once and left, sidesteps the drift entirely, because there is only ever one source for the date.

Common mistakes

Setting datePublished to the last edit date. datePublished is the original publication date and it should never move. Only dateModified tracks edits. Swapping them, or setting both to the same moving value, throws away the "how old is this, and how well maintained" distinction that the two dates exist to carry.

Leaving dateModified off entirely on pages you do update. If you maintain a page but never state a modified date anywhere, the freshest signal available is the original publication date, which makes a carefully updated three-year-old guide look abandoned.

A dateModified that is older than datePublished. Usually a timezone bug or a template pulling from the wrong field. It is logically impossible and validators will flag it.

Future dates. Google's guidance says plainly not to use them. A scheduled post whose markup goes live before its stated date, or a timezone offset that pushes the timestamp into tomorrow, both cause this.

Rolling dateModified forward on a schedule with no content change. Covered above. It is the single fastest way to get your date signals discounted, and it is often automated by a plugin setting rather than a deliberate choice.

Marking the date up perfectly and hiding it from readers. If the JSON-LD has a clean dateModified but the page shows no visible date at all, you have satisfied one reader (Googlebot) and left every other one, including most AI assistants, with nothing.

How to check and fix your dates

• Pull up one of your updated pages and compare all three dates. The visible byline, the datePublished and dateModified in the page source (search the source for dateModified), and the Last-Modified header (visible in a browser's network tools, or via any HTTP header checker). They should tell one consistent story.
• Check your XML sitemap's lastmod values against reality. Open the sitemap, pick a few URLs you know you have not touched in months, and confirm their lastmod is not set to this week. If your sitemap stamps everything with the current date, turn that off; an honest older date, or no lastmod at all, beats a fake fresh one.
• Confirm datePublished is frozen. Edit a test page, save it, and re-check the source. If datePublished moved, your markup is wired to the wrong field.
• Look for stray dates near your real one. Comment timestamps, related-post widgets, sidebar archives. Move them away from the headline and byline so Google is not choosing between them.
• Decide which system owns the date. On a WordPress site with several SEO and schema plugins active, pick one to emit the structured-data dates and make sure the others are not also outputting their own. Conflicting date markup from two plugins is its own common error, which we cover alongside the rest in common schema markup errors.
• Only move dateModified when you move the content. Tie the update to a real editorial change: a rewritten section, corrected figures, a new example. If nothing on the page changed, the date should not either.
• After a genuine refresh, watch whether it lands. Google's generative AI performance report and your normal traffic reports will show, over a few weeks, whether an updated page picked up any additional visibility. Freshness is a real lever for appearing in AI Overviews, but only when the update is real.

Getting dates right is one small corner of whether AI systems can make sense of your page at all, alongside heading structure, canonical tags, and metadata. If you want to see where your own pages stand across the whole set, run a free AI readiness check and it will flag freshness, structure, and identity issues in one pass.