Publication date identifies first release; modification date describes a content revision. Define what warrants that second date and keep visible dates consistent with metadata. Copying a file, rebuilding the site or fixing spacing does not establish that information was reviewed.
The method: when to show published date, modified date, or both
1. Keep the original publication date stable
The publication date should represent the first true publication of the article, not the date of a later migration, import, template change, or redesign. Schema.org defines datePublished as the date of first publication, which is the correct reference for editorial history. validator.schema.org
2. Use the modified date only for meaningful editorial changes
The modification date should change when the substance changes: updated statistics, revised legal references, new screenshots, expanded sections, corrected facts, rewritten introductions, refreshed examples, or a new recommendation set. It should not change just because the CMS re-saved the page, the layout changed, or a tracking script was edited. Schema.org defines dateModified as the most recent modification date, and Google recommends it when applicable to provide more accurate date information. schema.org
3. Make the date visible on the page
Google recommends placing the date and time between the headline and the article body. Visible dates help users directly and also reduce interpretation ambiguity for search systems. If you show both dates, label them clearly, for example: Published on and Updated on. developers.google.com
4. Mark up the article correctly
Use Article or a suitable subtype such as BlogPosting, with datePublished and, when relevant, dateModified in ISO 8601 format and with timezone information. Google explicitly recommends timezone information; otherwise it may default to Googlebot’s timezone. For a multilingual or international site, that detail avoids avoidable date shifts around midnight or cross-market publication workflows. developers.google.com
What can go wrong
Auto-updating every page creates false freshness
A common error is to stamp every page with a recent “updated” date during deployment, migration, or cache rebuild. That may mislead users and send mixed signals to crawlers. If the page looks newly updated but the body still contains old references, confidence drops immediately. This is especially risky on service pages, legal information, pricing explanations, and local landing pages.
Conflicting dates reduce clarity
Problems appear when the visible date says one thing, structured data says another, the XML sitemap lastmod says a third thing, and the article text mentions an old reference point such as “this year” or “recently.” Google’s guidance is clear that multiple signals are used together, so inconsistency creates unnecessary noise. developers.google.com
Removing dates can hurt confidence
Some publishers hide dates on evergreen content to avoid looking old. That can work against both UX and search visibility. On informational pages, users often want to know whether the content predates a major product change, regulation change, redesign, or local market update. If the page has no date and no review signal, it becomes harder to trust.
Redesigns often rewrite history by accident
During a website rebuild, imported content is frequently assigned the migration date as the new publication date. This is one of the most common editorial SEO errors in a website redesign. It breaks historical consistency, distorts analytics by content age, and can create credibility issues for authors, case studies, and archived insights.
Checks an agency should perform
Editorial checks
- Verify that each article has one real first publication date.
- Define what counts as a “meaningful update” before changing the modified date.
- Replace vague time phrases such as “recently” or “last year” when the article is updated.
- Check whether the content needs an additional reviewer signal for sensitive topics.
Technical checks
- Confirm that visible dates match structured data.
- Confirm that structured data uses valid ISO 8601 values with timezone.
- Check that the CMS does not auto-refresh dateModified on trivial saves.
- Audit XML sitemap lastmod logic so it reflects meaningful page changes, not every deployment.
- Test article markup and page output after template or plugin changes.
Search and experience checks
- Review whether date snippets shown in search align with the intended page signals.
- Measure CTR differences between clear-dated and unclear-dated editorial templates.
- Check engagement on time-sensitive pages versus evergreen guides.
- Review whether updated content actually improves usefulness, not just recency labeling.
Structured data: what matters in practice
For article pages, structured data should support the editorial truth, not replace it. Google recommends using article structured data with datePublished and optionally dateModified for more accurate date information. Schema.org also supports these properties broadly across CreativeWork and WebPage. developers.google.com
This matters for classic SEO, but also for machine interpretation in answer engines and LLM-driven discovery. Systems that synthesize pages into summaries or recommendations look for coherent page-level metadata. If the body, byline, structured data, and feed timestamps disagree, the page becomes harder to classify confidently. A dedicated structured data implementation reduces that ambiguity.
What good implementation looks like
A good article template shows a stable original publication date, an updated date only when there has been a substantive revision, and matching structured data in ISO 8601 format with timezone. The content itself also reflects the update: revised examples, corrected claims, refreshed screenshots, improved internal linking, and current terminology. That is the difference between genuine maintenance and cosmetic freshness. developers.google.com
If you want to audit how your current templates, schema, and CMS handle article dates, the practical next step is to request a page-level review of your editorial and service templates via contact, starting with one article, one local page, and one page affected by a redesign or migration.
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| RFC 3339 · Date-time | 2026-10-22T09:00:00+02:00 | The explicit offset relates local time to UTC; this example is not an appointment. |
Sources consulted on 22 October 2026. These points are neither a website audit nor an overall conformance statement.
Verification workshop: evidence before a decision
A proposed exercise on a chosen scope, using fictional data where needed. Record what you observe; this scenario describes no test already performed on your website.
- Action to try
Compare a punctuation correction with a change to a condition or method. Decide whether each change provides new information to the reader.
- Record to retain
Retain the before-and-after passage, reason for the change and editorial approval date. Check agreement between the visible date and metadata.
- What this evidence does not establish
A file copy or build date does not establish a content review. A recent date does not make a claim accurate.