Technical pillar / check date-signal-consistency
Date signals that agree
A measured fact about your markup: the published and updated dates in your structured data, meta tags and visible byline should agree with each other and never point to the future.
By Shimon Carroll, Founder, SEO for AI Agents · Last updated
What this check measures
Every date your page declares: datePublished and dateModified in structured data, the article:published_time, article:modified_time and og:updated_time meta tags, and visible lines such as "Published February 4, 2019" or "Last updated: Feb 14, 2019". We flag a modified date earlier than a published date, a date clearly after the day of the audit, and a visible date that sits well apart from the matching structured data date.
Why it matters
Google says its systems look at several factors to estimate when a page was published or significantly updated, and asks site owners to make dates and times consistent between the user-visible and structured values, and not to specify future dates. When the signals disagree, an engine has to guess which one is true, and the date shown next to your result may be wrong. The Last-Modified header is left out on purpose: CDNs and content systems often set it when a cache refreshes, not when the content changed.
How we score it
Any conflict is low severity, with high confidence for an impossible order or a future date and medium confidence for a visible date that disagrees with structured data (visible dates come in many formats). We allow a small tolerance for time zones and a short grace period for future dates. A page without dates is not penalized here; whether an article should carry dates is a separate freshness check.
Confidence-flag rules
HIGH confidence when two declared machine-readable dates conflict or a date is in the future; MEDIUM when the conflict involves a visible date we parsed from text. Every date we read is listed in the evidence with its source and its value as written.
Common mistakes
- A theme that writes today’s date into dateModified on every request.
- Updating the visible "Updated" line without updating dateModified, or the reverse.
- Scheduling a post with a future datePublished and publishing it early.
- Copying dates from an event the page describes into datePublished.
How to fix it
Pick one source of truth for each date, usually your CMS. Set datePublished once, set dateModified to the last real content change and keep it on or after datePublished, and render the same dates in the visible byline and the meta tags.
Primary sources
Changelog
- · First published. Runs on article pages and on any page that declares two or more dates; other pages are not assessed. The Last-Modified HTTP header is recorded but never compared.