How Google Picks the Date Shown Next to Your Result

The date in a search result snippet is not read out of a field you control. It is an inference. Google collects several date-ish signals from your page, decides which one is most likely to describe the content, and then decides separately whether to display anything at all.

Most CMSs emit three to six date signals per page, and they routinely disagree. That disagreement is why you see a two-year-old date on a page you rewrote last month, or no date on a news article that desperately needs one.

Which signals Google actually looks at

Google Search Central publishes guidance on dates for article pages, and the short version is: it does not rely on a single source. The documented advice is to show a clear visible date near the headline, to back it with structured data using ISO 8601 including a timezone offset, to avoid future dates, and to keep the two consistent with each other.

That guidance exists because extraction is heuristic. Here is what a typical page hands over, and what each signal is good for:

The first two rows are documented inputs. The URL-slug row is an inference drawn from how often date-stamped URLs surface with exactly that date even after the page is rewritten — treat it as a pattern, not a confirmed rule.

Two things the table makes clear. First, lastmod and Last-Modified are crawl-layer signals; they tell Google when to come back, not what to print in the snippet. Second, the noisiest signals are the ones nobody audits: a comment thread with visible timestamps, an archive widget, or a footer that renders the current year into something that looks like a date.

Why Google sometimes shows no date at all

Date display is query-dependent. Google decides whether recency matters for the query before it decides what date to show. Google announced a freshness-oriented ranking change back in 2011, and the behavior since then has been consistent with freshness being weighted heavily for queries about events, prices, versions, and recurring topics, and barely at all for stable reference queries.

So three different outcomes are all normal for the same URL:

• No date shown. The query doesn't look time-sensitive, or Google's confidence in any extracted date is low.
• Published date shown. Google found a consistent original date and no credible evidence of a substantive update.
• Modified date shown, sometimes with an "Updated" label. Google found an update signal it believes.

If your date is missing, the first hypothesis should be low extraction confidence caused by contradictory signals, not a penalty.

Why bumping dateModified usually does nothing

The "refresh the date, get a CTR lift" tactic assumes Google reads dateModified and prints it. It doesn't work that way, for a mechanical reason: Google already has the previous version of the page. A recrawl produces a content diff. If the body text is byte-for-byte identical and only a timestamp moved, the structured data claim is contradicted by the strongest available evidence.

Two failure modes follow. Either the displayed date simply doesn't change, or Google reduces its trust in your date signals site-wide and starts preferring the visible or URL-derived date instead. The second is harder to detect and harder to undo.

This is also contested territory in practice. Plenty of practitioners report snippet dates updating after trivial edits. The honest reading: date extraction has a confidence threshold, and on sites where other signals are clean and consistent, structured data carries more of the decision. On sites where signals conflict, it carries less. The decision criterion is whether you can defend the new date with an actual content diff.

How to audit which date Google is showing

Search Console will not tell you this — snippet dates aren't in the performance report or the BigQuery export. You have to compare two datasets you build yourself.

Dataset one: the date your page claims. Crawl your own URLs and extract every date signal from each page. A minimal extraction pass per URL should capture JSON-LD datePublished and dateModified, the OpenGraph published time, the first <time datetime> inside the main content region, any date in the URL path, and the Last-Modified header.

signals = {
  "jsonld_published": jsonld.get("datePublished"),
  "jsonld_modified":  jsonld.get("dateModified"),
  "og_published":     meta("article:published_time"),
  "visible_time":     first_time_element(main_content),
  "url_date":         re.search(r"/(\d{4})/(\d{2})/", url),
  "http_last_mod":    response.headers.get("Last-Modified"),
}
conflicts = len({normalize_day(v) for v in signals.values() if v}) > 1

Dataset two: the date Google displays. Sample the queries each URL ranks for, capture the SERP, and parse the date prefix from the snippet. Then classify each URL:

1. No date shown
2. Shows published date (matches your claim)
3. Shows modified date (matches your claim)
4. Shows a date you don't recognize

Category 4 is the interesting one. It almost always traces back to a stray visible date or a date-stamped URL. Category 1, at scale, usually traces back to the conflicts flag above being true across a whole template.

Making your dates unambiguous

The goal is a single, defensible date per page expressed consistently in every channel.

<p class="byline">Updated <time datetime="2025-03-14T09:30:00-04:00">March 14, 2025</time></p>

{
  "@type": "Article",
  "datePublished": "2023-06-02T11:00:00-04:00",
  "dateModified": "2025-03-14T09:30:00-04:00"
}

Note the timezone offsets. Google's documentation asks for them, and bare 2025-03-14 strings force a guess about which day you mean in a global index.

What to do

1. Crawl your templates and count date signals per page. Any template emitting more than two distinct days is a bug.
2. Remove dates from non-content regions, or move them outside the main content container so extraction doesn't pick them up.
3. Add timezone offsets to every structured-data date. This is cheap and documented.
4. Gate dateModified behind a real content diff in your publishing pipeline — if the body hash didn't change, don't move the timestamp.
5. Stop putting dates in URL slugs for evergreen content. You cannot retract that signal later without a redirect.
6. For news and Top Stories eligibility, treat datePublished accuracy as a hard requirement, not an optimization.
7. Re-audit the SERP display sample quarterly. Date extraction confidence shifts as your signals change, and the only way to see it is to look at the snippets.