How does Google really determine the publication date of an article?

Why does Google insist on this consistency between visible date and structured data?

Google primarily seeks to prevent date manipulation to deceive users. Some sites modify structured dates to pass off old content as fresh content, hoping to capture traffic on news queries.

The consistency between user display and metadata allows the algorithm to validate the reliability of the information. If the two do not match, Google considers that there is either a technical error or an attempt at manipulation — in both cases, it may choose not to display a date at all in snippets.

What does Google mean exactly by ‘visible date on the page’?

This refers to the date that the user sees directly in the content of the article, usually at the top of the page near the title or author. This date must be clearly readable, not hidden in the footer or buried in legal mentions.

Google uses computer vision algorithms and DOM analysis to identify this visible date. If your CMS displays “Published on March 15” but your structured data states “2023-03-20”, the inconsistency will be detected.

What is the difference between datePublished and dateModified?

The datePublished property indicates the original publication date of the article, which should match what the user sees as the “publication date.” It never changes, even if you update the content.

The dateModified property indicates the last substantial update to the content. Google may use this date to assess the freshness of an updated article, but it does not replace the original publication date in snippets. Both can coexist in the same Schema.org markup.

• Rigorously synchronize the date displayed to the user with the one declared in Schema.org (datePublished)
• Use dateModified only for actual and significant updates, not for minor corrections
• Test your pages with date filters in Google Search to ensure your articles appear within the correct time ranges
• Avoid ambiguous formats: prefer ISO 8601 (YYYY-MM-DD) in structured data, even if your user display is “March 15, 2023”
• Document your convention: clearly define what constitutes a “modification” justifying a change in dateModified

Does this statement align with observed behaviors in the field?

Yes, and it's actually one of the few areas where Google applies its rule quite strictly. We regularly observe cases where articles with visible date / Schema.org inconsistencies lose their rich snippet with date in the SERPs.

What is less clear is the degree of tolerance. Does Google accept a format difference (“03/15/2023” vs “2023-03-15”) as long as the date remains the same? In most cases, yes. But I've seen configurations where a time zone difference (local time display vs UTC in Schema) created issues. [To be verified] depending on your server setup.

What are the gray areas that Google does not mention?

Mueller does not clarify how Google handles evergreen content that is regularly updated. Should you change datePublished or just dateModified? The common practice is to keep datePublished fixed and update dateModified, but some publishers change the publication date to maximize visibility — a risky practice.

Another vague point: what happens when an article is republished elsewhere after several months? If you syndicate content or republish your own archives, what date should you display? Google does not provide clear guidelines, and tests show variable behaviors depending on niches.

In what cases can this rule cause problems?

Multilingual sites often run into issues: an article published on March 15 at 11 PM in France may appear as “March 16” in Asia. If your displayed date varies based on the user's geolocation while your Schema.org remains fixed, you create an inconsistency.

How can you verify that your dates are correctly recognized by Google?

The most reliable method is to use the date filters in Google Search. Launch a query site:yourdomain.com with a term present in your article, then apply a time filter (e.g., “last week”). If your recent article does not appear when it should, that's a warning signal.

Also, use the Google Rich Results Test to validate your Schema.org markup. The tool will flag formatting errors, but not inconsistencies with the visible date — hence the importance of testing in real conditions in the SERPs.

What technical errors must absolutely be avoided?

The classic mistake: a CMS that automatically generates dateModified on every page load, even without content modification. Some WordPress plugins do this, and Google eventually considers your content as constantly updated, which can dilute freshness signals.

Another common trap: displaying a date in client-side JavaScript (thus invisible to Googlebot if the JS does not execute properly) while having a different date in the HTML source. Google will read the raw HTML, and if the date visible after JS rendering differs, you have a problem.

What strategy should be adopted for content updates?

For substantially updated evergreen content (complete overhaul, addition of major sections), change dateModified but keep datePublished intact. Display both dates clearly to the user: “Published on 03/15/2022, updated on 01/10/2024”.

For news articles, never touch datePublished once the article is published, even if you correct typos. The stability of this date is a trust signal for Google. If you republish an archive after several years, treat it as new content with a new URL — do not recycle the old one by just changing the date.

• Audit all your templates to check the visible date / Schema.org consistency on a representative sample
• Disable any CMS feature that updates dateModified automatically without real modification
• Test your recent articles with Google date filters to confirm their temporal indexing
• Document your editorial policy: when do we change dateModified? When do we display both dates?
• Monitor your snippets in Search Console: a sudden loss of displayed dates may indicate a problem
• If you syndicate content, use the original publication date, not your republication date