Page markup declares a future publication date

In the reportPage markup declares a publish or modified date more than 24 hours after capture

article_date_in_future · Issue

Short answer

The report shows the original date, the page fetch time and the full possible time range. Correct the CMS field using the actual publication or modification history.

Severity: Medium. Issue when the earliest possible publication or modification time is more than 24 hours after the fetch.

Why it matters

Google asks for the publication or update date of the page rather than a future date or the date of an event described on it.

What to do

  1. Compare datePublished and dateModified with the page fetch time and the earliest and latest possible times shown in the report.
  2. Correct the CMS value; include the actual timezone if you know it. Do not change publication history merely to make content seem newer.
  3. Run a new full audit of the same page after the correction.

When to leave it as it is: A date whose whole possible range is within the 24-hour tolerance does not trigger this check. If the range crosses that boundary, the audit marks it as unverified. Future release dates belonging to books, films, products or other known item types are outside this page-publication check.

What we read

We read datePublished and dateModified in JSON-LD, microdata and RDFa on an HTML page with a complete current 200 response. Article, WebPage and all their subtypes in the official schema.org 30.1 hierarchy are included.

A datetime with a timezone denotes one instant. Without a timezone, the audit considers every offset allowed by the date grammar, up to 23:59 in either direction. A day, month or year covers the full period; the report keeps both exact boundaries without guessing a timezone.

The check reports a date only when its earliest possible time is later than the original page fetch plus 24 hours. A complete page with no qualifying markup dates is not applicable.

Example & evidence

Illustrative page fetched on 3 October 2026: replace an accidental future CMS date with the actual publication date.

{"@context":"https://schema.org","@type":"Article","datePublished":"2026-10-10T08:00:00+03:00"}
{"@context":"https://schema.org","@type":"Article","datePublished":"2026-10-02T12:00:00Z"}

Confirm & check again

Check for yourself: Check both publication and modification fields against the actual page history. Dates belonging to an item described on the page are different from the page publication date.

Check again: Full audit — A subsequent full audit can close the same-page finding when its markup dates are corrected or when complete current markup no longer has qualifying dates. Removing date markup can count as correction even if future visible text remains: this rule currently checks markup only. Missing coverage or a date-bearing node whose type cannot be confirmed leaves the correction unverified.

Limits & sources

Visible text dates and locale parsing are deferred. This check does not determine the actual publication history or how Google chooses a displayed date.

Date-bearing untyped, foreign or unknown-schema nodes, unsupported values and conflicting intervals of one date field leave coverage uncertain. Other known schema classes do not block the page; nested Article or WebPage records are still checked.

Unread JSON-LD roots and unresolved inline, array or scoped contexts prevent confirmation of a correction. Partial or uncertain rendering can retain a proved future-date finding while leaving the correction unverified. A page that is partial only because its images load lazily through scripts is read as static, with a note, so a correction can be confirmed there.

An original RDFa or microdata publication-date declaration that cannot be projected leaves coverage incomplete, even beside readable markup. Removing only itemscope while itemprop and the date remain does not prove correction. A known future date can still be reported.

Missing or failed responses, shell pages and absent fetch clocks for existing dates are unverified. The report shows up to 10 offending values with exact totals and original source excerpts.

Confidence: High High when the whole possible time range is beyond the exact 24-hour boundary; uncertain source or sibling dates prevent confirmation of a correction.

Sources

  • Google Search Central, Influence your byline dates in Google Search — Dates should describe publication or modification of the page rather than future dates or events described on it; time and timezone are optional and improve precision. Checked 4 October 2026.
  • schema.org, schema.org vocabulary, version 30.1 — The retained official vocabulary defines the fixed Article and WebPage descendant lists and known unrelated types; it does not define the future-date threshold. Checked 4 October 2026.

Editorial review: 2 November 2026