Should You Show a Last Updated Date on Blog Posts? Set the Publish Rule

Most teams eventually argue about the date stamp on a blog post.

Someone wants to show “Last updated” on every article.

Someone else worries it makes an old post look stale.

Both concerns are reasonable, and the answer is not a universal yes or no.

It is a rule you set once, apply consistently, and back with the technical details search engines actually read.

This article gives you that rule, the tradeoffs behind it, and the practical details that keep your dates accurate in search results.

Why the date question matters more than it looks

A visible date does two jobs at once.

For readers, it signals whether the advice is current enough to trust.

For search engines, it helps determine what Google calls a byline date: the date Google estimates a page was published or significantly updated.

When Google can determine that date, it may show it in search results if it is useful to the searcher.

Google’s documentation is explicit that its systems do not rely on a single date factor, because every factor can be prone to issues.

Instead, systems look at several signals to estimate when a page was published or significantly updated.

That means your visible date is one input among several, and the details around it matter.

The rule: show dates when they reflect real change

Here is a workable rule for most content teams:

• Show a publish date on every post. Readers expect it, and it gives search engines a clear baseline signal.
• Show a last updated date only when the content changed in a way a reader would care about: new sections, corrected facts, revised recommendations, or updated screenshots.
• Do not bump the date for trivial edits. Changing a comma is not an update, and treating it as one erodes reader trust over time.
• Label dates clearly. Use text like “Published” and “Last updated” so both readers and crawlers know what each date means.

The labeling point comes directly from Google's guidance: add a user-visible date and feature it prominently.

Label it appropriately with text like "Publish" or "Last updated."

Their examples include formats such as “Posted Feb 4, 2019” and “Updated Feb 14, 2019 8pm ET.”

When a last updated date helps

Some content ages fast.

Tool screenshots change, pricing models shift, regulations move, and step-by-step instructions rot.

For that content, a visible update date is a genuine service to the reader.

Someone landing on a guide about a software feature wants to know whether the screenshots match the current interface.

Refreshed content also benefits operationally.

When your team maintains a topic cluster, knowing which posts were recently reviewed helps you decide where to spend the next editing cycle.

A visible date makes that state legible to everyone, not just the person who ran the audit.

There is a related internal question worth settling at the same time: what counts as a refresh at all?

Teams that schedule posts in advance or publish on a fixed cadence often pair that calendar with a review cycle, and the two decisions reinforce each other.

If you have not set a publishing cadence rule yet, it is worth doing before you automate date updates, because the cadence defines when a review should happen.

When hiding the date is the better call

Evergreen content is different.

A conceptual explainer that was accurate on publication and remains accurate today does not need an update badge.

Showing “Last updated” on a page you have not meaningfully changed would be misleading, and readers who notice the pattern stop trusting the stamp.

There is also a subtle risk on the search side.

Google advises minimizing the presence of other dates on the page.

If your page has incidental dates, like event dates or comment timestamps, Google may select an incorrect date.

Their suggested fix is to remove some or all of those other dates.

A page cluttered with dates gives the estimation systems more chances to pick the wrong one.

So the tradeoff is straightforward: a visible update date builds trust when it is honest, and creates noise when it is not.

Decide per content type, not per post.

Make the visible date and the markup agree

This is where many teams quietly go wrong.

Google recommends specifying dates with structured data, using a CreativeWork subtype such as Article, BlogPosting, or VideoObject.

Fill in the datePublished and dateModified fields.

The critical requirement is consistency: the user-visible date and the structured data values must match.

If your page says “Last updated: March 3” but the structured data says dateModified from a different edit, you have created conflicting signals.

Google’s systems weigh multiple factors, and inconsistency gives them nothing reliable to converge on.

The practical checklist:

• The date is required in markup; the time is not, though Google recommends providing a time and timezone for added precision.
• If you include a timezone, use the correct one, accounting for daylight saving time where relevant.
• Time and timezone are optional in the user-visible text even when present in structured data.
• Never specify future dates, and never use the date of the event the page describes. The dates must describe the publication or update of the page itself. If the post covers a dated event, Google notes you can add Event markup to describe those activities separately.

What automation should update on a refreshed page

If you automate content refreshes from performance data, the date question becomes a workflow question.

When a post is materially revised, your automation should update, at minimum:

• The visible “Last updated” label on the page.
• The dateModified field in the structured data, with a matching value.
• Nothing else that looks like a date. Leave the original publish date intact so the page shows both its origin and its most recent review.

The failure mode to avoid is automation that bumps dates on every save.

A draft edit, a typo fix, or a plugin touching the post should not reset the update stamp.

Build the trigger around a meaningful change, such as a flagged revision or a completed review task, rather than around any write to the record.

If your automation touches related records, decide explicitly what a workflow should and should not update before publishing.

Our article on whether a workflow should update associated company records covers this in depth.

One more operational note: automation is only as trustworthy as the review behind it.

A curated list of URLs to refresh, or a title-derived suggestion, does not by itself prove that a page needs updating or that a date bump is honest.

Someone should confirm the change is material before the stamp moves.

A simple decision table

Common mistakes to avoid

• Showing an update date that does not match the structured data, or omitting the label entirely so the date’s meaning is ambiguous.
• Leaving incidental dates scattered across the page, which gives date-estimation systems conflicting candidates.
• Automating date bumps on every edit, which turns an honesty signal into noise.
• Using the date of an event described in the post as the page’s date, which Google explicitly warns against.

Putting the rule into practice

Set one rule your whole team can repeat: every post shows a publish date.

Posts show a last updated date only after a material revision, labeled and mirrored in structured data.

Then audit your templates once.

Check that visible labels use clear wording and that structured data fields exist and match.

Also confirm automation touching dates is triggered by real revisions rather than routine saves.

From there, the date stamp becomes what it should be: a small, honest signal that helps readers decide to trust the page and helps search engines describe it accurately.

• Related: decide your publishing rhythm first with our guide on whether to schedule blog posts in advance or publish now.
• Related: understand how page-level rendering choices affect what crawlers see in our article on lazy loading content and the viewport rule.
• Related: keep your content footprint intentional with our piece on why more blog posts can hurt SEO without a keyword map.

Set the rule once: label every date honestly, mirror it in structured data, and only move the update stamp when the reader would notice the difference.

Source references: developers.google.com.

How Meshline can help. Connect automation, Organic Marketing (demand generation), and customer lifecycle management (Revenue Intelligence).

Bring topic planning, content publishing and performance feedback into the conversation about your workflow. Book a Meshline demo.