Does Google really respect your publication dates… or does it just make them up as it goes?

What exactly does Google mean by 'estimating' the date?

Gary Illyes clarifies that the byline date visible in snippets is not necessarily the one you explicitly declared via schema.org, your meta tags, or your CMS. Google builds its own estimation by combining multiple signals: visible page content, metadata, crawl dates, and probably other undocumented factors.

In plain terms: even if you've properly marked up your publication or update date, Google can decide to display something else. This algorithmic discretion creates a gap between what you declare and what the user sees in search results.

Why doesn't Google just trust the structured markup?

The stated reason — unsurprisingly — is fighting manipulation. Too many sites artificially modify their dates to appear fresh by changing a word or comma and then updating the timestamp. Google wants to display the date most relevant to the user, not the one that benefits SEO.

But this noble intention poses a problem: it introduces an extra layer of opacity. You lose control over an element that directly influences CTR, especially in verticals sensitive to freshness like news, tech, or finance.

What signals does Google use to estimate this date?

Google doesn't reveal its recipe, but we can deduce several probable sources: the HTML5 tag, the datePublished and dateModified properties in JSON-LD, textual date mentions in the content, RSS feeds, crawl history, or even update patterns observed across the domain.

The catch? No guarantee that Google weights these signals the way you hoped. An article published in 2020 but substantially updated may display the old date if Google deems the modification wasn't significant enough.

• Google displays an estimated byline date, not necessarily the one you declare
• This estimation is based on a mix of undocumented signals
• The stated objective is to limit artificial date manipulations
• The concrete result: loss of control over freshness perception in the SERPs
• Time-sensitive verticals (news, tech, finance) are most at risk

Is this estimation logic consistent with what we observe in the field?

Yes and no. We do observe frequent inconsistencies between declared dates in schema.org and those displayed in snippets. Pages updated yesterday can display a date from several months ago, or conversely, old content can show a recent date for no apparent reason.

This behavior is not new, but Gary Illyes's statement officially confirms it: Google allows itself to override your metadata. The problem is, there's no clear guidance on what triggers this rewriting. You're in the dark.

What nuances should be added to this announcement?

First, Gary says "sometimes" — in other words, it's not systematic. Some pages display the date you declare, others don't. The logic applied seems to vary by vertical, perceived site freshness, or E-E-A-T criteria.

Second, [To be verified]: Does Google really distinguish between substantial updates and cosmetic changes? No official data proves it. We can assume the algorithm tries to measure the extent of the change, but nothing guarantees this measurement is reliable or granular.

In what cases doesn't this rule apply — or is it counterproductive?

If your content is evergreen (guides, timeless tutorials), an old date can even harm your credibility. Paradoxically, Google might display an old date even if you've substantially updated the content, simply because the URL or structure hasn't changed.

Another edge case: product or service pages that change little over time. Displaying a recently updated date artificially makes no sense, but Google can still generate one if crawl detects minor modification (addition of a customer review, for instance).

What should you do concretely to maximize control over this date?

First step: properly mark up your dates in JSON-LD with datePublished and dateModified. Even if Google doesn't always respect them, it's a baseline signal you'd be foolish to neglect. Also use the HTML5 <time datetime="..."> tag in visible content.

Next, ensure your updates are substantive and visible. Changing a sentence or fixing a typo isn't enough. Add sections, rephrase paragraphs, integrate recent data. Google must perceive a content change, not cosmetic tweaking.

Finally, monitor your snippets in Search Console and via third-party tools. If an aberrant date appears, check your metadata, your XML sitemap (which may contain contradictory <lastmod> tags), and crawl history.

What mistakes should you absolutely avoid?

Never artificially modify your dateModified without touching actual content. Google detects these manipulations and may ignore your dates entirely, or even demote the page. The game isn't worth the candle.

Also avoid inconsistencies between your different date sources: JSON-LD, <time> tag, sitemap, RSS feed. If Google sees contradictory signals, it'll make its own choice — and it probably won't be the one you wanted.

Last pitfall: leaving generic dates (January 1st, midnight sharp) in your metadata. That screams automated generation. Google will then favor other signals, potentially less advantageous for you.

How do you verify your implementation is sound?

Use Google's rich results test to validate your structured markup. Check that datePublished and dateModified are properly detected, with no errors or warnings.

Then compare the dates displayed in actual snippets with those you declared. If you notice systematic discrepancies, it's a signal that Google is estimating differently — you'll need to dig deeper to understand why.

• Implement datePublished and dateModified in JSON-LD across all content pages
• Use the <time datetime="..."> tag in visible content
• Make substantive updates before changing the date
• Verify consistency between JSON-LD, XML sitemap, and RSS feed
• Monitor snippets via Search Console and third-party tools
• Avoid generic or automated dates
• Test with Google's rich results validator