When to change an article’s publication date, update date, or source-check record

Keep publication, update, and source-check dates separate

Keep the original publication date when you improve an existing article. Add an update date for a substantive change, and record source checks separately when you only confirmed that existing information remains correct.

Google’s publication-date guidance asks for dates that describe the page’s publication or update, rather than an event discussed in the story. A report published in August can describe a quarter that ended in June. Neither date automatically becomes the publication date of your own article. (Google publication dates guidance ↗)

One guide, four different events

Consider a guide first published March 3. An editor checks its source June 5 and finds no change. On September 8, the provider changes a setting and the guide is rewritten. A dictionary link is added September 9.

Swipe or scroll to see all columns.

Use the same dates on the page, in structured data, and in feeds

Judge an update by its effect on the reader, not its word count. Correcting a price from $19 to $190 changes the decision even though only one number changed. Adding a link to an unchanged definition usually does not. If a new source changes the conclusion, record that substantive change even if the edit is short.

Before changing the visible update date, write one sentence explaining what the reader now learns differently. Keep the original publication date and use the same dates in the page, structured data and feeds. Record a no-change source check separately; reopening documentation does not make an old article newly reported.

Set the date from the reader-visible event

Imagine an editor checks a source on Tuesday and finds no change, then corrects a material figure on Wednesday. Save both events in the editorial record. A reader who sees the article on Wednesday should be able to distinguish the original publication from the correction. Tuesday’s source check is evidence of maintenance, but it did not change the reader’s article.

Audit a sample of updates by comparing the visible dates, feed and structured data. If any of those move after a routine rebuild, trace the date to its source. A file timestamp may change when nothing editorial happened. Use an explicit publication field and an explicit update field, and record what triggered each update. On the next rebuild, confirm that an untouched article still reports its previous dates and that a corrected one reports the intended change.

Check one syndicated copy if you distribute updates to partners. A correct date on your own site does not tell you whether a partner received the corrected version.

Which date should a partner feed carry after a correction?

Suppose your site published a story June 1, rechecked it June 5 and corrected it June 8. The table shows where each event belongs. If a partner imports the correction as a new article, ask which field its feed treats as the original date and which field it uses to pick up revisions.

Compare the feed item and partner page against the original. If the updated copy has the right text but a second URL, record both addresses and ask the partner whether it can update the existing item by its stable identifier. Keep a separate record if the partner also changes the date it displays. The delivery of corrected text and the identity of the syndicated article are two different things to verify.

Include one untouched article in the handoff. Its date and identity give you a control for catching a feed-wide change during the repair.