Should You Show Publish Dates on Blog Posts in 2026?

Should You Show Publish Dates on Blog Posts in 2026?

In most cases, yes. Dates help Google pick the right one for your page, they help readers trust what they are reading, and the evidence suggests AI answer engines lean toward newer sources. The real decision is not whether to show a date. It is which date, and how honestly you maintain it.

This comes up on almost every content project we take on. Someone on the team has read that dates hurt click-through rates, so the date gets hidden. Six months later nobody can tell which posts are stale, the AI answers are quoting a competitor, and the blog feels like a graveyard nobody will admit is a graveyard.

So let us take the argument seriously on both sides, using what Google publishes and what the citation data actually shows.

What Does Google Actually Ask For?

Google asks for a clearly labelled, user-visible date that matches your structured data. Its documentation on publication dates gives examples such as "Published February 4, 2019" and "Updated Feb 14, 2019 8pm ET", and says the date, time and timezone should match between the user-visible and structured values.

Google also sets three rules that catch people out. Do not use future dates. Do not use the date of the event described on the page instead of the page's own publication or update date. And if the wrong date keeps getting picked, remove the other competing dates that appear on the page, because a sidebar full of timestamps confuses the choice.

The last rule matters more than teams expect. Related-post widgets, comment timestamps and event listings all put dates into the markup. When Google guesses wrong about which one is the article's date, that is usually why.

Do Dates Hurt Your Click-Through Rate?

Sometimes, on one specific kind of query. If someone is searching for something where recency is the whole point, a 2023 stamp next to your result is a reason to scroll past. That effect is real and it is the honest argument for hiding dates.

But hiding the date does not make the post current. It removes the reader's ability to judge, which is a different thing from earning their trust. In our experience the teams that hide dates are usually solving a content maintenance problem with a CSS rule, and the maintenance problem is still there afterwards.

The better fix is to decide which posts deserve to stay current, update those properly, and let the rest carry their real age. A post that is honestly five years old and still correct is not embarrassing. A post that is secretly five years old and wrong is.

Do AI Answer Engines Prefer Fresh Content?

On average, yes, and there is now a large sample behind that claim. Ahrefs analysed roughly 17 million cited URLs, about 16.975 million, pulled from seven AI search platforms through its Brand Radar product, and compared them against organic Google results for the same queries.

The headline number from that analysis is that URLs cited by AI assistants average 1,064 days since publication, against 1,432 days for URLs in organic results. Ahrefs describes that gap as the AI citations being 25.7 percent fresher. In plain terms, the AI answer is quoting something roughly 2.9 years old where classic search is quoting something roughly 3.9 years old.

Interestingly, the gap narrows when you measure by last update instead of first publication: 909 days for AI citations against 1,047 days for organic, a difference Ahrefs puts at 13.1 percent. Updating a post does move it, just not as far as people hope.

Which AI Platforms Care Most About Freshness?

They differ more than the average suggests, which is why a single freshness rule is a bad plan. In the same Ahrefs analysis, ChatGPT showed the strongest preference, citing content 458 days newer than organic results for the same queries.

Google's AI Overviews sat at the other end. Ahrefs found AI Overviews cites content that is on average 16 days older than organic results, making it the surface least moved by freshness in the set. That fits what Google has always said about its ranking systems, which treat recency as relevant for some queries and irrelevant for most.

The practical reading is that if ChatGPT visibility is your priority, recency is a lever. If Google AI Overviews is your priority, it barely is, and your effort belongs in clarity, structure and sourcing instead. We covered that side of the work in our piece on refreshing old posts versus writing new ones.

Is a Published Date or an Updated Date Better?

Show both when both are true. Google explicitly allows a page to carry an original publication date and a later update date, and recommends marking them up with datePublished and dateModified. Two honest dates give a reader more information than one vague one.

Showing only the updated date is where teams get into trouble. It looks tidy, and it quietly erases the fact that a post has been around for four years. Readers who notice feel misled, and the fix costs you more trust than the original age ever did.

Our default on client blogs is a single visible line carrying the publication date, with the update date added once a real update has happened. It is easy to build, easy to maintain, and it never requires anyone to make a judgement call under deadline pressure.

What Counts as a Real Update?

New information, corrected facts, replaced screenshots, revised recommendations. Google's guidance is direct about the opposite case: dates should reflect genuine publication or meaningful updates, not artificial manipulation for ranking purposes. Changing a year in a heading is not an update.

We use a simple test. If a reader who read the old version would learn something new from the new version, it is an update. If the only difference is that a number in the title now says 2026, it is a timestamp change and it should not move the date.

This matters more now than it did under classic search alone. Answer engines are quoting specific claims, so a post whose date says it was updated last month but whose statistics are three years old is a credibility risk on a much shorter fuse.

How Should Dates Be Marked Up?

With a CreativeWork subtype such as Article or BlogPosting, carrying datePublished and dateModified in ISO 8601 format, matching what the reader sees. That is exactly what Google's documentation asks for, and it is one of the cheapest pieces of structured data to get right.

Two implementation details cause most of the errors we find in audits. The first is timezone drift, where the visible date renders in the reader's local timezone and the markup carries UTC, so the two disagree by a day. The second is a CMS that writes dateModified on every deploy, which tells Google the post changes constantly when it has not changed at all.

If you want the wider context on getting this kind of markup right, our guide to schema markup covers how the pieces fit together on a marketing site.

What Do We Do on Client Sites?

We show the date, we mark it up, and we build the blog so that updating a post is easy enough that it actually happens. The last part is the one people underrate. Most stale content is not a strategy failure, it is a workflow failure.

We also separate the blog into posts that need maintaining and posts that do not. A framework piece, a comparison and anything with numbers in it goes on the maintenance list. An opinion piece from two years ago is allowed to simply be from two years ago, because its value was never its recency.

When a blog gets big enough that this becomes a chore, the answer is usually to publish less and maintain more. We wrote about that trade-off in our piece on pruning old blog posts, and the same logic applies to dates.

So Should the Date Stay or Go?

It should stay, and it should be true. The freshness advantage in AI citations is real but modest and uneven across platforms, and it is not large enough to justify misleading readers about how old something is. Honesty is the cheaper long-term position.

What we would change is the surrounding habit rather than the date itself. Decide which posts you will keep current, update them for real, mark them up cleanly, and let the rest age in public. That leaves you with a blog you can defend to a reader, a crawler and an answer engine at the same time.

If you want a second opinion on how your blog is structured, or you are staring at a few hundred posts and cannot tell which ones are worth saving, we are happy to walk through it. You can reach our team at phoenix.studio.