Article schema: headline, dates and the ones people fake

datePublished is when the article first became public. dateModified is when its content last meaningfully changed. Both take ISO 8601, and both should include a time and a timezone offset, because a bare date is a twenty-four hour window in an unstated zone and publication order can matter inside that window.

Then there is the trick. Everyone learns that fresher content does better on freshness-sensitive queries, and somebody proposes setting dateModified to the current date on every build, or on a nightly cron. It is trivial to implement and it is a bad trade for three separate reasons.

• It contradicts the page. Your markup says today and your byline says March 2023. One of your own signals is now wrong, and a consumer has to pick, which is a worse position than having only the honest one.
• It destroys the signal you wanted. If every article was modified today, the property carries no information at all. The day you genuinely rewrite something, there is no way to say so, because you already said it about four hundred pages that did not change.
• The visible date usually wins anyway. A date in your markup is one input. What is printed in the article, what the URL implies, what the page said the last time it was crawled, and how much of the text has actually changed since are all inputs too, and the markup does not get to overrule them by asserting harder.

The version that works is unexciting: emit dateModified from the timestamp of the last real edit to the content, in the CMS or the repository, and never from the build clock. If you cannot separate an edit from a redeploy, that is the bug to fix. And if you want a page to be genuinely fresh, change it, then say so.

Article, NewsArticle and BlogPosting generate more deliberation than they deserve. Google documents its article features across all three and does not distinguish between them for eligibility, so choosing between them buys you nothing there. Pick the one that describes the content and move on: BlogPosting for posts, NewsArticle if you are a news publisher reporting events, Article when neither fits.

The distinction does matter in two places. Consumers other than Google are not obliged to treat the three as equivalent, and a feed reader, an aggregator or a research pipeline filtering for news will look at the type. And a handful of properties only exist on the narrower types: dateline and printEdition belong to NewsArticle and are meaningless elsewhere. Declaring NewsArticle on a marketing blog because it sounded more serious is the actual mistake here, and it is a claim about what your site is.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/cdc-without-tears#article",
  "headline": "Change data capture without the 3am pages",
  "alternativeHeadline": "Change data capture without the 3am pages: what two years of replication lag taught us about triggers",
  "description": "Why we moved off triggers, what broke, what we kept.",
  "datePublished": "2026-03-04T09:30:00+00:00",
  "dateModified": "2026-07-19T14:05:00+01:00",
  "author": { "@id": "https://example.com/authors/jane-doe#person" },
  "publisher": { "@id": "https://example.com/#organization" },
  "image": [
    "https://example.com/img/cdc-16x9.jpg",
    "https://example.com/img/cdc-4x3.jpg",
    "https://example.com/img/cdc-1x1.jpg"
  ],
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/cdc-without-tears"
  },
  "isPartOf": { "@id": "https://example.com/#website" },
  "articleSection": "Engineering",
  "inLanguage": "en",
  "wordCount": 2140
}
</script>

Both people properties are references to entities declared elsewhere rather than names repeated here, which is a check in its own right and the single biggest improvement most Article blocks can make. wordCount and articleSection are optional and cheap, and both are things a parser would otherwise have to estimate.

What not to add: articleBody containing your entire article. It is valid, it doubles the weight of your HTML, and it gives you two copies of the same text that can drift apart the moment anybody edits one of them.

Because the facts are already on the page. A byline, a date and a headline are visible in the rendered article, and search engines have been extracting all three from pages without markup for as long as there have been blogs. They have to: most of the web still has no Article block. Absence therefore costs you less here than on any other type in this pillar.

What the markup buys is the removal of one specific ambiguity. A typical article page shows several dates: a publication date, a comment timestamp, three related posts with their own dates, a copyright year in the footer. An explicit datePublished ends the guessing, and that is a real if narrow benefit.

It clears the bottom of the scale for a reason unusual on this list: the common failure is not omission but assertion. Nobody accidentally lies about a heading. A build step that stamps today's date on four hundred articles is a page telling a confident falsehood about itself, which is a different kind of defect from a missing property and rated accordingly. The scale that produces these labels is described on the audit page.

Parse the block, then measure the headline, because that is the one property with a number attached and the one no validator counts for you.

# headline length, from what the page actually serves
curl -s https://example.com/blog/cdc-without-tears \
  | grep -o '"headline": *"[^"]*"' \
  | sed 's/.*: *"//; s/"$//' \
  | awk '{ print length, $0 }'

# the dates as shipped, offsets included
curl -s https://example.com/blog/cdc-without-tears \
  | grep -o '"date[A-Za-z]*": *"[^"]*"'

Then the check that matters more than either. Run those two commands against the same article today and again after your next deploy, having changed nothing in the content. If dateModified moved, your build clock is writing your editorial history, and every freshness claim your site makes is now noise. Fix that before tuning anything else in the block.

Finally, put the rendered page beside the markup and confirm four things agree: the headline against the h1, the published date against the printed one, the byline against the author reference, and the image URL against the hero that actually loaded. All four are places a template can substitute a fallback without anybody noticing, and all four are claims about content a reader can see.