Identify what each date represents
Before changing an article, record its original publication date, displayed update label and structured date fields. Check whether the CMS stores editorial updates separately from file writes or deployments. A build timestamp describes an operational event; it does not automatically mean that the advice was reviewed that day.
Create a brief change record naming the editor, the affected passage and the reason for the edit. Distinguish a spelling correction, a repaired link and a revised recommendation. This record provides the evidence for a date decision instead of allowing every save operation to silently become a fresh publication.
Keep publication and revision separate
Preserve the original publication date when correcting an existing article. If a genuine update warrants an updated label under your editorial policy, retain the publication history and explain what changed. Do not use a minor cosmetic edit to suggest that an old guide has received a complete new review.
Google’s date guidance recommends clearly labeled visible dates and consistent corresponding structured values such as datePublished and dateModified. Dates should describe the page’s publication or update, not an event mentioned in the article. The time and timezone can provide precision in markup without forcing a detailed clock display on readers.
Define a small editorial decision rule
Agree on a rule with the content owner before the next routine edit. For example, keep an internal record for typo corrections, and use a reader-facing update note when advice, evidence or instructions materially change. This is a proposed editorial convention, not a Google rule that all minor edits must be handled identically.
Inspect the CMS field mapping before adopting that convention. If a save updates a technical timestamp, do not automatically map that timestamp to a label claiming substantive review. Store editorial review history separately when necessary. Never invent an earlier or later update time to make the page appear more attractive.
Illustrative example: one correction and one revision
Imagine a fictional guide published on 3 September. On 8 September an editor corrects a misspelled heading; the internal log records the correction without replacing the original publication date. On 20 September the instructions are revised after checking a changed feature, and an update note describes that substantive revision.
The public publication date remains 3 September. The corresponding update information reflects the actual revision on 20 September, using consistent timezone handling where times are supplied. These dates are teaching examples, not a recommended schedule or a claim that Google will select a particular date for its snippet.
Check the delivered page after publishing
Compare the visible labels with the generated structured data after deployment, including cached pages and translated editions. Check for contradictory blocks that still contain a previous date or a future value. Review any template that sets every article’s date to the latest build time.
Keep a screenshot or saved output alongside the change record so a later reviewer can explain the decision. Google uses multiple signals and does not guarantee displaying the supplied date. An audit can flag mismatches, while the editorial history determines the correct values; a new timestamp is not evidence that the underlying advice became current.