Two fields. One purpose each. Most sites get both wrong.

In Article, BlogPosting, and TechArticle JSON-LD, datePublished records when the page first went live, and dateModified records when it was last meaningfully changed. Schema.org defines datePublished as the "Date of first publication or broadcast" and dateModified as the date the work "was most recently modified." Both accept Schema.org Date or DateTime values, which in practice means ISO 8601 with a timezone offset (e.g. 2026-04-25T09:30:00-04:00). Google's Article structured data documentation asks for both in ISO 8601 and recommends including dateModified whenever it applies, because it provides more accurate date information than datePublished alone.

The mistake is treating them as interchangeable. They are not. AI Overviews read them one way, Perplexity another, Google News a third. The gap between "set both correctly" and "set one or copy one into the other" is the gap between getting cited and getting skipped.

What each field actually means

datePublished is immutable in spirit. The article went live on a date; that date does not change because you fixed a typo three months later. Re-running your CMS publish action against the same URL should not move it. If the underlying story is genuinely new (a fresh URL, a new canonical), then a new datePublished is correct. Otherwise it stays put.

dateModified is the opposite. It tracks the most recent substantive revision to the body content, the structured data, or the load-bearing links on the page. Google's own sitemap guidance says the same about <lastmod>: "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." That's the bar for dateModified too.

Where AI systems actually look

Different surfaces weight the two fields very differently.

Google News uses date signals as part of its freshness ranking and rewards articles whose dateModified reflects real updates. Perplexity is the most freshness-hungry of the major AI engines: Seer Interactive's 2025 citation analysis found roughly half of Perplexity citations come from current-year content, and Ahrefs's July 2025 study of 17 million AI citations found AI-cited content runs 25.7% fresher than traditional organic results. ChatGPT is even more aggressive, with 76.4% of its most-cited pages updated within the last 30 days. Google AI Overviews show the weakest freshness bias, but they still surface the "Updated [date]" string from your dateModified when they cite you.

The throughline: dateModified is the single most-watched freshness field across classical SEO plus the answer and generative layers stacked on top of it. One field, multiple surfaces, all watching the same number. Stale dateModified on a page that was actually revised last week leaves citations on the table. Inflated dateModified on a page nobody touched gets you classified as freshness spam.

The right pattern, in JSON-LD

Set both fields. Use ISO 8601 with a timezone. Update dateModified only when the content meaningfully changed.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "dateModified vs datePublished",
  "datePublished": "2025-11-05T08:00:00-05:00",
  "dateModified": "2026-04-25T09:30:00-04:00",
  "author": {
    "@type": "Person",
    "name": "Kordu Editorial",
    "url": "https://isitready.dev/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "isitready.dev",
    "logo": {
      "@type": "ImageObject",
      "url": "https://isitready.dev/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://isitready.dev/articles/datemodified-vs-datepublished"
  }
}

If the page has never been revised, omit dateModified rather than copying datePublished into it. The duplicate gives no extra signal and confuses parsers that infer "this article has been maintained" from the presence of a distinct value.

Failure modes that quietly kill visibility

The CMS that bumps dateModified on every save. Many CMS templates emit new Date() into the JSON-LD on every render or every metadata save, including SEO-only edits like swapping a meta description or re-uploading the same hero image. Google detects this. John Mueller's guidance on the topic is direct: "We see a lot of spam and low-quality content that updates dates arbitrarily ('The best fax machine for 2023'), it's pretty obvious and embarrassing." Sites that tag every save as a content update lose trust in all their date signals.

The site that ships dateModified === datePublished forever. A blog from 2022 with both fields frozen at the publish date tells AI systems the article has never been maintained. Citation probability collapses fast: pages untouched for over a year see citation rates drop 75-90% versus recently updated competitors.

Mismatched signals. Sitemap <lastmod> should agree with the page's JSON-LD dateModified. Google's sitemaps documentation says it uses <lastmod> only when the value is "consistently and verifiably" accurate against the actual page. If your sitemap says one date, your JSON-LD says another, and the HTTP Last-Modified header on the URL says a third, Google discards the weakest signal and downgrades trust in the rest. The same applies to any visible "Last updated" byline rendered in HTML: it should match the JSON-LD to the day.

Cosmetic-edit bumps. Fixing a typo, replacing a stock photo, or rotating a year reference does not warrant a new dateModified. Mueller again: "If you're doing this manually, kind of like tweaking the date every time you make a small change like shuffling images, then I would recommend just skipping that and only update the date when you actually make significant changes on a page."

A working update discipline

Treat dateModified as a load-bearing field with a written rule, not a metadata afterthought.

  1. On first publish, set datePublished. Leave dateModified unset.

  2. On any substantive revision (new sections, replaced data, rewritten conclusions, updated structured data), set dateModified to the revision time in ISO 8601 with timezone.

  3. On the same revision, regenerate the sitemap so the URL's <lastmod> matches dateModified to the second.

  4. If your origin sets the HTTP Last-Modified response header for HTML pages, align it too.

  5. Block your CMS from emitting a fresh dateModified on metadata-only saves. Gate it behind a content diff or an explicit author flag.

Verify before shipping

isitready.dev audits Article schema across every crawled page. It checks that datePublished and dateModified are present, in valid ISO 8601, and consistent with sitemap <lastmod> plus the page's HTTP headers. It flags pages where the two fields are identical, where dateModified is older than the rendered "Last updated" byline, and where sitemap and JSON-LD disagree. Run it against your canonical origin before your next refresh cycle.