Refreshing an old post is one of the cheaper things a content program can do. Then comes a small question that causes more argument than it should: do you change the date? Change it every time and you risk telling readers a page is newer than it is. Never change it and a genuinely rewritten post looks abandoned. The answer is a rule you can apply the same way each time.
What Google says
Google's guidance on creating helpful, people-first content includes a self-check question aimed at search-engine-first content: are you changing the date of pages to make them seem fresh when the content has not substantially changed? Google's separate documentation on byline dates says its systems look at several factors to form a best estimate of when a page was published or significantly updated, and recommends showing a visible date, labelled with text such as "Publish" or "Last updated", and supplying datePublished and dateModified in structured data.
Read together, the message is not "never touch the date". It is that a date should describe the page honestly. When Google's Search Liaison commented on the helpful-content wording, the point he made, as reported by Search Engine Journal and others, was that it concerns changing a date only to make Google think a page is fresh. Fixing a typo is not what it is about. Sources disagree on how much weight the passage carries in ranking, so treat this as a matter of honesty with readers first and search second.
A rule that holds up
Change the visible date and dateModified when a reader who saw the old version would now get different answers. Leave them alone when they would not. In practice:
- New date: a corrected or replaced fact, a changed recommendation, a new section, steps that were rewritten because the product or interface changed, or a statistic swapped for a current one.
- No new date: typo and grammar fixes, a repaired link, reformatting, a new internal link, a tweaked meta description.
If you are unsure, ask what you would write in a changelog. If the honest entry is "fixed a typo", the date stays. If it is "the recommendation changed", the date moves.
Keep both dates, and keep them in agreement
The cleanest pattern is to show the original publish date and a separate "last updated" date once the post has had a substantial revision. That tells a reader how old the idea is and how current the advice is, which are different questions. Then make sure the structured data matches what the page shows. A visible date that says one thing while dateModified says another gives search systems conflicting estimates and gives readers no reason to trust either.
Say what changed
A one-line note near the top, such as "Updated October 2026: the steps now reflect the current settings screen", does more for trust than the date alone. It also keeps you honest: if you cannot write the line, you probably have not made an update that earns the date.
A five-step check before you republish
- List what changed in plain words. If the list is only cosmetic, stop and leave the date.
- Re-check every fact and figure you kept against its original source, not against your old draft.
- Update the visible date and
dateModifiedtogether, to the same day. - Add the short "what changed" note if the edit is more than a light revision.
- Keep the URL the same, so whatever authority the page has built up carries over.
The takeaway
A date is a claim about the page. Move it when the content moved and leave it when it did not. That is the whole policy, and it costs nothing to follow. It also fits the wider habit of checking before you publish: the same discipline that decides which pages should never carry ads keeps a content program's records worth believing.
Sources: Google Search Central, "Creating helpful, reliable, people-first content" and "Influence your byline dates in Google Search"; Search Engine Journal and Wordtracker coverage of the September 2023 helpful content update.