Short answer: Do not change a page's date unless its content has materially changed. A visible last-updated date, the dateModified in structured data and the lastmod in your sitemap are all signals about change, and they only help while they are true.
Google lists changing dates to make pages seem fresh as a warning sign of content made for search engines first, and says it stops trusting a sitemap whose lastmod values do not match reality.
Which three dates are we talking about?
A page can state when it changed in three places. The first is the date a reader sees, such as "Last updated 18 October 2026" near the title. The second is dateModified, and datePublished, in the page's JSON-LD structured data. The third is the lastmod value for the page's URL in the XML sitemap.
Engines use these to decide what has changed and what is worth fetching again. Each is only useful if it is accurate, and the three should describe the same moment. When they disagree, or when one is generated by the clock instead of by the content, they stop being signals and become noise.
The visible date, the structured-data date and the sitemap lastmod should all be computed from one real value per page, so they cannot drift apart. Google also asks that the visible and structured dates match, and that dates are never in the future. (Google Search Central: Add a byline date)
Should you update the date to make old posts look fresh?
No. If the content has not substantially changed, the date should not change. Google's guidance on people-first content lists changing the date of pages to make them seem fresh, when the content has not substantially changed, as a warning sign of content made primarily for search engines. Adding or removing large amounts of text only to look fresh is another.
There is a second cost. Google's sitemap guidance says that if lastmod does not match reality, eventually it is not going to believe you anymore. A site that stamps every page with today's date on every deploy teaches the crawler to ignore the field, including on the day you really do update something important.
Freshness reports change, it does not create value
Adding or removing content to seem fresh will not help, and updating a stale page's date without checking its facts is worse than leaving it alone. If the numbers on the page are old, a new date is a lie a reader can catch.
When is an old date perfectly fine?
For evergreen reference content: a definition, a history, a recipe, an explanation of a principle that does not change. An old date on a page that is still correct is not a defect. Readers do not distrust a two-year-old explanation of how a fixed thing works.
Dates matter most where accuracy ages: pricing, regulations, tool comparisons, statistics, how-tos for software, and best-of lists. There a reader, and an engine, wants to know the page is current. Match the effort to how fast the content goes stale.
| Situation | What to do with the dates |
|---|---|
| Content changed materially | Update the visible date, dateModified and sitemap lastmod together |
| Only the template, footer, navigation or styling changed | Leave all three alone |
| A typo or small wording fix | Your choice. Not required, and never bump in bulk |
| The page never had a date | Add datePublished with the real first-publish date. Add dateModified only if the page has really been revised |
| The CMS cannot tell a real edit from a template change | Omit lastmod for those URLs. Google says leaving it out is fine |
| The build tool stamps every page at deploy | Stop. Derive the date from the content's real edit date |
If you cannot find a real date, because there is no git history or CMS record, do not invent one. Ask the owner, or leave the field out.
What does a passing freshness check actually prove?
Very little about honesty. The freshness check in our toolkit passes if at least one article-type JSON-LD item has a date that parses. It does not check how recent the date is, whether the structured date matches the visible one, or whether dateModified is earlier than datePublished. A set of invented, distinct-looking dates passes.
The sitemap check is slightly sharper. It fails if any lastmod is more than a day in the future, or if every entry carries the same timestamp and that timestamp is within the last day, which is the signature of a build-time clock. Otherwise it passes. So a green result means the signals exist and are not obviously broken. It does not mean they are true, and you have to check consistency yourself.
This is the same pattern as other audit findings: a check can be satisfied without the underlying thing being right.
Why audit findings need checkingHow do you make the dates honest, in order?
Source each date from the content, not the clock
Use the CMS modified field, a frontmatter updated field, or the last git commit that touched the content file. Beware that a commit date moves when someone reformats or renames a file, so prefer a frontmatter field if you need control.
Feed all three places from one value
Compute the date once per page, then render the visible date, the JSON-LD and the sitemap lastmod from it. That removes drift by design.
Show a visible date in a time element
Put a labelled Published or Last updated date near the title, with a machine-readable datetime attribute, and keep it matching the structured data.
Set datePublished and dateModified in ISO 8601
Add them to the Article, BlogPosting or WebPage JSON-LD. A date alone is valid, and a time with a correct timezone adds precision. Never use a future date, and describe the page's own publication, not the event it covers.
Emit sitemap lastmod only where you trust it
Use a standard date format and never a build timestamp. If you cannot trust the value for a URL, omit it.
Choose real refreshes by traffic, then update the dates
Decide which pages deserve a genuine refresh by looking at where rankings or clicks have fallen. Update the content first, and only then the dates.
What does honest structured data look like?
A post first published in March and materially revised in October carries both dates. The visible text on the page says the same thing.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to ...",
"datePublished": "2026-03-02",
"dateModified": "2026-10-18"
}One more trap: a date-only value near midnight can render as the previous or next day in another timezone. Where precision matters, use a full timestamp with an offset. And do not expect a visible byline date in search results even when everything is correct, because Google does not guarantee one.
Where is the full implementation guide?
This article covers why honesty matters and how to decide. The full procedure, including how to grep a sitemap and wire dates in each framework, is in the documentation.
Read the content freshness implementation guideThe same guide is an agent skill, so a coding agent can make the fix in your repository. The skill source is public.
View the skill source on GitHubThe skills can be installed into Claude Code and other coding agents. Install details are in the skills index.
See how to install the AEO skillsCommon questions
Does updating the date on a post improve my rankings?
No. Google says adding or removing content to seem fresh will not help, and lists changing dates without changing the content as a warning sign of search-engine-first content. Freshness signals report that something changed. They do not create value on their own.
What is the difference between datePublished and dateModified?
datePublished is when the page first went live. dateModified is when it was last significantly changed. Add dateModified only if the page has really been revised, and never set it earlier than datePublished or to a future date.
Why does my sitemap show today's date on every URL?
Almost always because the build tool stamps every page with the build time when no real date is supplied. Google says it stops trusting lastmod that does not match reality, so derive the value from the content's real edit date or omit it for URLs you cannot trust.
Is an old publish date bad for evergreen content?
No. An old date on a page that is still correct is not a defect. Dates matter most where accuracy ages, such as pricing, regulations, comparisons and software how-tos. Spend refresh effort there first.
Sources
Related guides
Want it done for you
Want this done and re-checked every month? Our monthly maintenance re-runs your buying questions in ChatGPT, Perplexity and Google, ships the fixes that keep you out of the answers, and reports what moved. Or run the free check on your site first at advancelabs.dev/tools/audit.
See how it works