Article schema

Use Article when the primary entity represented by the visible page matches the Schema.org definition. Select a more specific subtype when accurate.

• headline

• @id
• mainEntityOfPage
• author
• publisher
• datePublished
• dateModified
• image

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/articles/example/#article",
  "headline": "Example Article",
  "mainEntityOfPage": "https://example.com/articles/example/",
  "datePublished": "2026-07-26",
  "author": {
    "@id": "https://example.com/people/example/#person"
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  }
}

• Choosing the type only because a rich result is desired.
• Adding properties not visible or supported by the site.
• Creating conflicting duplicate entities instead of using stable @id values.
• Failing to update markup when visible data changes.

Use Article only when the page visibly represents the corresponding entity or relationship. Begin with the page purpose and the entity graph, then select the most specific supported type. Do not let the available vocabulary dictate claims the page does not make.

• Syntax validation, type/property validation, consumer testing, and post-deployment inspection.
• Record the page template, generator, source fields, responsible owner, and release reference.
• Avoid publishing properties that are unsupported, hidden, stale, or inconsistent with visible content.
• Parse the deployed json-ld, validate the graph, compare it with visible content, and test any target consumer requirements.
• Schedule review when visible content, offers, ownership, locations, products, or consumer documentation changes.