When dateModified should differ from datePublished
Keep the original publication date and update dateModified only after a meaningful content change. Align visible dates, Article JSON-LD, and sitemap lastmod.
Written for an editor maintaining evergreen articles and deciding whether a correction, link update, or rewrite deserves a new modification date.
Key facts
- Google Article guidance recommends accurate ISO 8601 publication and modification dates.
- A modification date should correspond to a meaningful change visible on the page.
- Sitemap lastmod should align with significant page updates rather than routine builds.
A useful rule: make each important claim understandable and verifiable without requiring the reader to reconstruct your meaning from the rest of the page.
What each date tells the reader
`datePublished` identifies when the article first became public. `dateModified` identifies the most recent substantive revision. Keep the first value stable through later edits and update the second only when the page's useful content changes. The visible page should show these dates in language a reader understands, such as “Published” and “Last updated.” A future review due date serves a different editorial purpose and should not appear as completed freshness. Do not backdate newly created pages or set every article to the deployment date. Accurate provenance helps readers judge whether rules, platform behavior, and examples remain current.
- Store publication, modification, and review due as separate fields.
- Keep the original publication value after a rewrite or migration.
- Use complete ISO dates and one site-wide timezone convention.
Sources: 1
Which edits count as substantive?
Update the modification date when you change a material answer, correct a factual error, add evidence that changes confidence, revise a process after platform behaviour changes, or replace a broken recommendation. Adding a new section or changing an internal link can also be substantive when it alters the reader's path or the page's structured data. Fixing punctuation, adjusting spacing, updating a global footer, or rebuilding the application does not normally change the article itself. Write a short change note for major revisions so an editor can defend the date later. Consistent rules matter more than claiming maximum freshness.
- Ask whether the edit changes what a careful reader would know or do.
- Record the reason and source behind every material date change.
- Batch cosmetic edits without touching article modification fields.
Align visible content and Article JSON-LD
The Article node should use the same headline, author, `datePublished`, and `dateModified` values shown on the page. A structured date that is newer than the visible footer creates a mismatch, and a visible “updated today” label generated at request time misleads readers when the content has not changed. Use one article record as the source for rendering and JSON-LD. Include the author's accurate type and URL, and keep the publisher separate. Validate the built page rather than only the data object because layouts and cached routes can output stale or overridden metadata.
- Extract visible and JSON-LD dates in a test and require exact equality.
- Keep author names free from prefixes, job titles, and publisher labels.
- Update the modification date and structured data in the same content change.
Sources: 1
Keep sitemap lastmod consistent
Map the article's significant modification date to the sitemap `lastmod` value. Google states that it uses `lastmod` when the value is consistently and verifiably accurate. Do not call `new Date()` for every record during a build, because unrelated deployments then mark the whole archive as changed. If an article has never been modified after publication, using the publication date as its current content date is reasonable. When the system cannot provide accurate values, omitting `lastmod` is better than publishing noise. Test consecutive builds to ensure unchanged records keep identical dates.
- Use the content record rather than filesystem or deployment timestamps.
- Reject sitemap dates earlier than publication or later than the current day.
- Keep redirects and non-indexable pages out of the canonical sitemap inventory.
Sources: 2
Build a review workflow around evidence
Set review cadence from the subject. Platform rules, crawler names, API features, prices, and legal requirements need tighter checks than stable explanations. On the review date, open every cited source, verify the page behaviour, and read the full article before changing `dateModified`. If nothing material changed, record the completed review internally without presenting a content modification to readers. If sources moved but claims remain correct, update the links and decide whether that source maintenance is significant for the public page. The date should reflect editorial work that improves or confirms the article's usable substance.
- Store source checked dates separately from page modification dates.
- Schedule quarterly reviews for fast-moving SEO and AI platform guidance.
- Publish a correction note immediately when a material claim was wrong.
Put it to work
Find the highest-impact fix on your site.
Check visible dates, Article JSON-LD, sitemap lastmod, canonical metadata, and source freshness on the published page.
Compare article date signalsSources
- 1.Google Search Central: Article structured dataChecked 2026-07-26
- 2.Google Search Central: Build and submit a sitemapChecked 2026-07-26