Freshness signals and honest dateModified

dateModified is a claim that the page changed in a way a reader would care about, on that date. It should move when the content changes materially, stay put when it doesn’t, and match the date printed on the page. A page whose structured date says one thing, whose byline says another, and whose content hasn’t changed since either is telling every reader — human or machine — that its dates can’t be relied on.

Freshness is a real input to how pages get judged, which is exactly why it gets gamed. This covers what the date fields mean, what Google’s documentation asks for, and how to check that your dates are telling the truth, on one page and across a site.

What are datePublished and dateModified?

They’re two properties schema.org defines on CreativeWork, which covers articles, blog posts, and most editorial pages.

• datePublished is the “Date of first publication or broadcast.”
• dateModified is “The date on which the CreativeWork was most recently modified.”

Both accept a Date or a DateTime. Google’s Article structured data documentation describes them the same way — the date the article was “first published” and “most recently modified,” in ISO 8601 format — and recommends including a time zone, “otherwise, we will default to the timezone used by Googlebot.” It lists no required properties for Article; you add the ones that apply.

The same two facts usually appear in two more places on a page. The Open Graph protocol defines article:published_time (“When the article was first published”) and article:modified_time (“When the article was last changed”) as meta tags. And the visible byline — often wrapped in an HTML <time datetime="…"> element — is the date a person actually reads.

That’s up to three statements of the same two facts. The job is to make them agree.

What does Google say about dates?

Google’s guidance on byline dates starts from the fact that the date shown in results is an estimate: “A byline date is the date that Google estimates that the web page was updated or published,” and “Google doesn’t depend on a single date factor because all factors can be prone to issues.”

Its recommendations come down to five:

1. A visible date. “Add a user-visible date to the page and feature it prominently.”
2. Structured dates. Specify datePublished and/or dateModified in structured data, with a time and time zone recommended for precision.
3. Consistency. “Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values.”
4. No future or event dates. “Don’t specify future dates, or the date of the action described on the page.” The dates “must describe the publication or update date of the page, not the stories or events described therein.”
5. Fewer competing dates. If the wrong date gets picked, “consider removing some or all other dates that appear on the page.”

Read together, the instruction is that a page should state its own dates once, plainly, and the same way everywhere.

Why is faking dateModified a trust failure?

Google names the practice directly. Its guidance on creating helpful content, under “Avoid creating search engine-first content,” asks site owners: “Are you changing the date of pages to make them seem fresh when the content has not substantially changed?” The next question in the same list covers the site-wide version — adding or removing content “primarily because you believe it will help your search rankings overall by somehow making your site seem ‘fresh?’” — and answers it: “(No, it won’t)”.

There’s a mechanical cost too, separate from any policy. A date is checkable against the content it describes. A page dated last week that still recommends a setting deprecated two years ago, or cites “the latest” version of something three versions back, contradicts itself — and anything comparing the claim to the content can see it. Once a site’s dates are known not to mean anything, the honest ones stop meaning anything either.

The common causes are rarely deliberate:

• Build-time stamping. The template sets dateModified to the build or request time, so every deploy “updates” every page. You can spot it when hundreds of unrelated URLs share one modified timestamp.
• Trivial edits. A typo fix, a footer change, or a template refresh bumps the date because the CMS records any save.
• Split sources. The byline reads one CMS field and the JSON-LD reads another, and only one gets edited.
• Event dates in the wrong slot. An event page puts the event date in datePublished, which is the case Google’s guidance rules out.

What counts as a modification?

No standard defines it, so you need a house rule, written down. A workable one: change dateModified when a fact, figure, recommendation, or section changes — anything that would alter what a reader takes away. Don’t change it for typo fixes, formatting, link repairs, or template changes. Never change datePublished after first publication.

Showing both dates on the page is the honest pattern: “Published 12 March 2026 · Updated 10 October 2026.” The reader can see the page has a history, and the structured data says the same thing. If the revision is significant, a one-line note of what changed makes the update date verifiable rather than asserted. This matters most for pages carrying dated facts — the kind what makes a page citable recommends — because a dated claim is only as good as the date on the page around it.

How do you keep the visible and structured dates consistent?

Render them all from one field. The byline, the <time datetime> attribute, the Open Graph meta tags, and the JSON-LD should read the same stored value, so it’s impossible to edit one without the others. In the page source that looks like:

<p>Published <time datetime="2026-03-12">12 March 2026</time>
 · Updated <time datetime="2026-10-10">10 October 2026</time></p>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Freshness signals and honest dateModified",
  "datePublished": "2026-03-12T09:00:00+00:00",
  "dateModified": "2026-10-10T09:00:00+00:00"
}
</script>

The visible text omits the time and zone, which the Google guidance allows. The structured values carry them. Both say the same day. If your site publishes across time zones, check that the zone conversion doesn’t push the structured date onto a different calendar day from the visible one.

Make the modified field one an editor sets on purpose, not one the CMS sets on save. That single change removes most of the trivial-edit drift.

How do you audit dates on one page?

Four checks, all in a browser:

1. Find the visible date. Note what the byline says, and whether the page shows a published date, an updated date, or both.
2. Read the structured dates. Paste the URL into Google’s Rich Results Test or validator.schema.org. Both show the parsed JSON-LD, including datePublished and dateModified.
3. Read the meta tags. View source and search for article:modified_time and article:published_time.
4. Compare against the content. Are the dates the same day across all three? Is any date in the future? And does the content plausibly date from when the page says it was last modified — or does it mention things that changed since?

The fourth check is the one no tool can make for you, and the one that catches a bumped date.

How do you audit dates across a site?

Without a terminal, a crawler’s custom extraction plus a spreadsheet covers it. Add four rules:

• //time/@datetime — the visible date’s machine-readable value
• //meta[@property='article:modified_time']/@content
• //meta[@property='article:published_time']/@content
• A regex extraction against the page source for the JSON-LD value: "dateModified"\s*:\s*"([^"]+)", and the same for datePublished

Crawl, export, and compare the first ten characters of each — the YYYY-MM-DD part — so a time zone suffix doesn’t create false mismatches. With the visible date in C and the JSON-LD modified date in D:

=LEFT(C2, 10) = LEFT(D2, 10)

Filter to FALSE for disagreements. Three more columns find the other faults. Future-dated pages:

=DATEVALUE(LEFT(D2, 10)) > TODAY()

How many URLs share this exact modified timestamp:

=COUNTIF(D:D, D2)

And, with the JSON-LD published date in E, pages whose published date is later than their modified date:

=LEFT(E2, 10) > LEFT(D2, 10)

A high COUNTIF on a full timestamp is the build-time-stamping signature. Blank cells matter as much as mismatches: a page with no date anywhere has nothing for a reader to judge it by.

In a terminal, the dates for one URL:

curl -s "$URL" | grep -oE '"date(Published|Modified)"\s*:\s*"[^"]+"|article:(published|modified)_time" content="[^"]+"|<time[^>]*datetime="[^"]+"'

Run it over a URL list to get the same table, one line per date.

How GEOBee reads freshness

Freshness is a GEO-lens signal in GEOBee, weight 15 of 100, and it checks for a recent published or modified date — the three lenses lists it beside the other six GEO signals. It reads the dates the page states. It can’t tell whether the revision behind a date was real, which is why the consistency and content checks above stay a person’s job, and why the only honest way to move the signal is to revise the page and date the revision. Answer Engine Optimization: a page-level guide covers the extraction signals freshness sits beside.

To find the pages on your site with no date or a stale one, download GEOBee and crawl it — Freshness is scored per URL, alongside the structured data each page declares.