datePublished and dateModified across content pages

What content dates do

A published date tells a reader when something was published, which is not always when it was written; a modified date tells them whether it has been kept up. Both can come from Article structured data or from visible markup in the entry header.

They matter where age changes the answer. On a tutorial for a tool that ships every month, a 2019 date is the most useful thing on the page. On a page about something that has not changed in a century, it is noise, which is why this rule is gated to content-publishing sites.

What squirrel checks

The rule is site-wide. It counts content pages and how many carry each date. A page counts as content when its schema declares Article, BlogPosting or NewsArticle, or when the parser found a visible published date or a visible author. On a crawl of five pages or fewer, every page counts.

Dates are read from any flattened JSON-LD node carrying datePublished or dateModified, falling back to visible entry-meta <time> markup. It emits up to two checks:

• Skipped when no pages were crawled. Message: No pages available for analysis.
• Info when no article content was detected. Message: No article content detected for date analysis.
• date-published passes when the coverage percentage, rounded to a whole number, is 80 or above. Message: 95% of content has datePublished. It warns below that, with Only 40% of content has datePublished or No content pages have datePublished, and Add dates to Article schema as the value. Severity warning, weight 4.
• date-modified passes when its rounded percentage is 50 or above. Message: 70% of content has dateModified. It reports info below that, with 20% of content has dateModified and Add dateModified to show freshness as the value.

Flattening the JSON-LD matters here: a top-level-only read misses every date on a site whose SEO plugin emits an @graph.

The rule only runs when the audit classified the site as a blog, a news site, a healthcare provider or an education site. A classification below medium confidence, or an audit with no site metadata at all, runs the rule anyway.

How to fix it

<time datetime="2026-03-12" class="entry-date published">12 March 2026</time>

Render the date in the article header and put the same value in the Article schema. One content timestamp should drive both.

Move dateModified when the content actually changes. A date that updates on every deploy tells a reader nothing and tells a crawler something false.

Enable / disable

Disable this rule

[rules]
disable = ["eeat/content-dates"]

Disable all E-E-A-T rules

[rules]
disable = ["eeat/*"]

Enable only this rule

[rules]
enable = ["eeat/content-dates"]

enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.

Related rules

• content/date-agreement: whether the dates on a page agree with each other.
• content/freshness: the same signals inventoried per page.
• crawl/sitemap-lastmod-drift: the sitemap date compared against them.
• eeat/author-byline: the other half of a complete byline.

E-E-A-T findings ship in every audit next to the SEO, performance and agent experience rules. See Fix SEO issues with AI for how an agent works through a report.

References

• Article structured data, Google Search Central
• The time element, MDN

Check your site

Run squirrel audit https://example.com and open the E-E-A-T section of the report. The site is reported with the share of content carrying each date. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.