Article dates and updates: show real changes rather than artificial freshness

Update dateModified only when the page's substance changes: corrected facts, new sections, revised recommendations or re-verified claims. Google's Article structured data expects datePublished and dateModified in ISO 8601, and its helpful-content guidance explicitly flags changing dates to look fresh without real change. A newer date is not a ranking lever by itself; it is a signal that should match a genuine revision.

What do datePublished and dateModified actually mean?

These are two different claims about a page's history. datePublished is the date and time the article was first published. dateModified is the date and time it was most recently modified. Google's Article structured data documentation recommends both properties for Article, NewsArticle and BlogPosting, expressed in ISO 8601 format, and recommends including timezone information; without it, Google defaults to the timezone used by Googlebot (Article structured data).

That timezone detail matters more than it looks. A page published at 23:30 in London and a page published at 23:30 in Los Angeles are different moments. If your CMS writes a local timestamp without an offset, the machine reading it has to guess. Adding an offset such as +01:00 or -07:00 removes the guess.

Two practical definitions help:

• Published = the first public version of this URL's article content.
• Modified = the last time the article's meaning changed for a reader.

A typo fix, a CSS tweak, a related-links block or a template migration are not meaning changes. A corrected statistic, a rewritten recommendation, a new section or a removed claim that no longer holds are.

Does a newer date help rankings?

Not on its own, and treating it as a lever is the exact pattern Google's guidance warns about. The helpful-content page asks whether you are "changing the date of pages to make them seem fresh when the content has not substantially changed" as a warning sign, alongside promising answers that do not exist (Creating helpful, reliable, people-first content).

The same page frames the goal as prioritizing helpful, reliable information created to benefit people rather than content created to manipulate rankings. Dates are part of how a page describes itself. When the description is false, the page is less reliable, not more competitive.

What dates can legitimately do:

• Help a reader judge whether a guide still applies to their situation.
• Help search systems place a page in time for queries where recency is part of the intent.
• Support transparency when a page's advice has changed.

What they cannot do is substitute for the revision itself.

A decision table for when to bump the date

That last row is where teams disagree. A defensible policy: log the re-verification in your internal revision log, leave the visible date alone, and mention the review in the article only if it adds reader value (for example, "checked against the 2026 documentation").

How to keep a revision log that survives staff changes

A date without a record is just a number. Keep a lightweight log per article, stored where the next editor can find it:

1. Date and author of the change.
2. What changed — one or two lines, specific enough to audit later.
3. Why — a corrected source, a policy change, a reader question.
4. What was checked — which official page or document was consulted.
5. What was left unchanged — useful when a reviewer asks why a section still says something old.

This log is also your defence when someone asks why a date moved. If the log shows a real edit, the date is honest. If it shows nothing, the date is decoration.

Worked example (hypothetical)

Suppose a guide explains how a platform reports sessions, and the platform changes its measurement definition. The article's explanation of the old behaviour is now wrong.

• Wrong approach: leave the text, change the date to today, hope the page looks current. Readers arrive, find outdated advice, and leave. The date claim is false.
• Right approach: rewrite the affected section, note the change in the revision log, update dateModified with a timezone offset, and keep datePublished as the original. If the change is large enough to alter the article's conclusion, say so in the text.

This is illustrative only — no real traffic, ranking or conversion figures are implied.

What to check on your own pages

A short diagnostic you can run without special tools:

1. Pick five articles that claim recent updates.
2. Open each one and ask: what specifically changed on that date?
3. If you cannot answer from the page or your log, the date is unsupported.
4. Check the structured data: are datePublished and dateModified both present, in ISO 8601, with a timezone?
5. Compare the visible date on the page with the structured data. If they disagree, decide which is correct and fix the other.
6. Look for pages where the date resets on every deploy. That is a CMS default, not an editorial decision.

Where the evidence is thin

Google documents what the properties mean and warns against fake freshness, but it does not publish a formula showing how much a date influences any given result. Anyone claiming a precise ranking effect from a date change is going beyond the available evidence. Treat dates as an honesty and clarity mechanism, not a growth tactic.

Follow-up questions

Should dateModified change if I only fix a typo?

No. A typo fix does not change what the article tells a reader. Bumping the date for cosmetic edits is the pattern Google's helpful-content guidance flags. Keep the date stable and note the fix in your internal log if you track edits at that level.

What if my CMS updates the date automatically on every save?

That is a configuration problem, not an editorial one. Either disable automatic date updates and set dateModified manually, or ensure the CMS only writes it when content fields change. Then verify the output in the structured data, not just in the admin interface, because templates can override what the editor sees.