Stop Touching Your Publish Dates

We added publish dates to everything. Guides, product pages, foundational resources, news posts - all of them got a visible date stamped between the headline and the first paragraph. It seemed like the responsible thing to do. Within one week, organic traffic dropped 13.37%.

That number comes from a 2024 analysis by Aubrey Yung, and it tracks closely with what we saw internally. The fix seemed obvious in hindsight. The mistake, less so.

We were treating all content the same, and it cost us

The naive approach goes like this: dates build trust, schema markup encourages datePublished and dateModified, and CMS defaults make it easy to surface both. So you turn it on everywhere. There is even a credible consumer behaviour argument - roughly 60% of consumers report that trust and transparency influence their decisions, and a visible date feels like transparency.

Google's own structured data documentation encourages date markup. Most editorial teams interpret that as "add dates to articles." That interpretation is correct for some content types and actively harmful for others.

The problem we didn't catch early enough: we were not separating "last saved" from "last meaningfully updated." Every minor edit - a corrected typo, a formatting tweak, a broken link swap - triggered a new timestamp. That timestamp then surfaced on the page, in the schema, and in the sitemap. A 2019 guide started showing a 2024 date because someone fixed a comma. And we had no mechanism to distinguish that from a genuine content refresh.

Three date signals have to align, or you get ranking noise

The architecture underneath a published date is more layered than most editorial teams realise. There are three distinct signals that Google reads, and when they conflict, you create noise that works against you.

The first is the visible on-page date - what the reader sees, positioned between the headline and the article body, clearly labelled. The second is schema markup: datePublished and dateModified in your structured data. The third is lastmod in your sitemap. All three need to reflect the same underlying reality. If your on-page date says 2024, your schema says 2022, and your sitemap says last week, Google has three conflicting signals and no clean way to interpret the page's freshness.

The CMS architecture matters here. Automatic "last saved" timestamps are useful for editorial tracking. They are not the same as editorial "last meaningfully updated" flags - and the two should live in separate fields. A content team that treats them as interchangeable will surface false freshness signals constantly, without realising it.

The decision logic, once you have that separation in place, is relatively clean. If the content is time-sensitive - news, trend analysis, quarterly reports, anything tied to a specific moment - show the date, keep it updated, and align all three signals. If the content is evergreen - how-to guides, foundational resources, product pages - skip the visible date entirely. The absence of a date is not a trust failure. It is an accurate signal that the content is not anchored to a specific moment in time.

Old dates on evergreen content are a ranking penalty, not a trust signal

Here is what the 13.37% traffic drop taught us. Evergreen content with old visible publish dates ranks lower in Google's freshness algorithm, even when the content itself is current and accurate. The date became a liability, not an asset.

Google's freshness systems - what Amit Singhal described as the mechanism where "if news sites or blog posts are actively writing about a topic, the model figures that it is one for which users are more likely to want current information" - are designed to surface recent content for time-sensitive queries. When you add a 2019 date to an evergreen guide, you are signalling to that system that your content is old. The fact that your guide is comprehensive and accurate does not override the timestamp.

We missed this because we did not validate the change against search intent. We did not check Google Trends for volume spikes that would indicate freshness mattered for these queries. We did not look at whether competing evergreen pages were showing dates. They were not. Competitors with undated foundational resources were outranking us on the same queries we had dominated for years.

John Mueller has been direct about the underlying principle: "Only update the date when you actually make significant changes," and "changing the date without doing anything else is just noise and useless." We were generating noise at scale, systematically, across our entire content archive.

Dates are a freshness signal for some content and a penalty for others

The reusable principle here is not complicated, but it requires you to actually categorise your content before you apply any date logic.

For time-sensitive content, dates serve a genuine function. Readers want to know whether a trend analysis is current. Search engines want to surface recent coverage of fast-moving topics. The date is doing real work. Refresh that content every 6-12 months, add "last updated" labels or brief revision histories when you do, and make sure the update reflects a substantive change - not a reformatted subhead.

For evergreen content, the date is working against you. Evergreen content ranks on relevance and authority, not recency. Adding a date invites the freshness algorithm into an evaluation that should be purely about depth and accuracy. Remove it.

The third category - fake freshness - is worth naming explicitly because it is tempting. Bumping a date without substantive change feels like a low-effort ranking boost. Google tracks crawl history independently. It sees the gap between your claimed modification date and the actual content delta. Mueller's position is unambiguous: that gap is noise, and noise has a cost.

Operationally, the fix requires three things. Separate your CMS fields so automatic timestamps never surface as editorial dates without a human decision point. Audit your date signals across on-page content, schema markup, and sitemap to confirm they agree. And filter every date decision by content type and intent before you publish - not after you see the traffic drop.

We learned this the hard way. The 13.37% recovery required removing dates from dozens of evergreen pages, realigning schema, and updating sitemap entries - about three weeks of cleanup work for a mistake that took about three minutes to make. The asymmetry is worth keeping in mind the next time a CMS default feels like a safe choice.