Article Schema: Required Properties, Recommended Fields, and QA

Article schema is Schema.org structured data that identifies a page’s article and describes properties such as its headline, author, publication and modification dates, and representative images. For Google’s Article feature, the current documentation accepts Article, NewsArticle, or BlogPosting and lists recommended properties rather than a separate set of mandatory Article properties.

That last point corrects a common implementation mistake. Schema.org defines a broad vocabulary; Google documents the subset and behavior it uses for Google Search features. A field can be valid Schema.org without being a Google Article recommendation, and Google’s recommendations can change independently of the vocabulary.

The current property picture#

Google’s Article documentation recommends the following core fields when they apply:

Google also recommends multiple high-resolution representative images in 16:9, 4:3, and 1:1 aspect ratios for best results. That is a Google recommendation, not permission to generate nonexistent variants or mark a logo as an article image.

A minimal JSON-LD pattern#

The following is illustrative markup, not a claim about a real publisher or page. Replace every example value from the rendered article and its canonical data model.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/insights/article#article",
  "mainEntityOfPage": "https://example.com/insights/article",
  "headline": "A visible article headline",
  "datePublished": "2026-08-01T09:00:00+08:00",
  "dateModified": "2026-08-24T14:00:00+08:00",
  "author": {
    "@type": "Organization",
    "name": "Example Editorial Team",
    "url": "https://example.com/about"
  },
  "image": [
    "https://example.com/images/article-16x9.jpg",
    "https://example.com/images/article-4x3.jpg",
    "https://example.com/images/article-1x1.jpg"
  ]
}

JSON-LD is not the only supported format. Google supports JSON-LD, Microdata, and RDFa, and generally recommends JSON-LD because it is easier to maintain without interleaving the graph throughout visible HTML. Use the format the publishing system can keep synchronized.

The @id and mainEntityOfPage fields appear here as useful identity structure from Schema.org, not as fields Google lists as mandatory in its current Article feature table. Keep that difference visible in documentation so an engineering convention does not become a fabricated platform requirement.

Choose the type from the page, not the desired feature#

Use Article for a general article. Use BlogPosting when the page is a blog post and that distinction is meaningful in the publisher’s model. Use NewsArticle for news reporting, not merely because the team hopes for a news feature.

The subtype should describe the visible object. Markup is not a costume that changes an evergreen explainer into reporting, an opinion into an investigation, or a product page into an editorial article.

Schema.org’s Article type inherits many properties from CreativeWork and Thing. Those include useful relationships such as mainEntityOfPage, about, mentions, sameAs, and publisher. A property belongs only when its meaning and expected value type match the page.

Keep the graph derived from one publishing record#

The most reliable implementation does not ask editors to maintain a second hidden article. It derives structured data from the same canonical fields that render the page:

• the displayed title supplies headline;
• the contributor registry supplies author type, name, and identity URL;
• the publication system supplies real publication and modification events;
• the media record supplies canonical, crawlable image variants;
• the canonical URL supplies page identity;
• the visible content model supplies any about or mentions relationships.

When two templates independently own these facts, drift is predictable. An article can show one author and mark up another; an automatic daily build can change dateModified without a content revision; a social-card path can replace a representative editorial image; or a translated page can inherit the wrong canonical URL.

Publication dates need event semantics#

datePublished is the first publication date. dateModified is the most recent modification date. They are not interchangeable, and neither should be changed merely because a page was rebuilt, crawled, or included in a new sitemap.

Define which content event updates dateModified: a substantive correction, new section, materially refreshed source set, or another approved change. A typographic fix may or may not qualify under the publisher’s policy, but the policy should be consistent and the visible date treatment should not contradict the graph.

Timezone information is recommended for DateTime values. Dates without time can be valid in Schema.org contexts, but a publishing system that knows the precise event should not discard the timezone and then invent a day boundary later.

Author markup is an identity problem#

Google recommends one author entry per visible author and says author.name should contain the name only. Put the publisher in publisher, a job title in jobTitle, and descriptive text on the linked profile page.

Use Person when a named person wrote or reviewed the article under the site’s contributor policy. Use Organization when the visible byline and editorial responsibility genuinely belong to a team or organization. Do not manufacture a person byline to make markup look richer.

A stable internal contributor page is often the cleanest author.url. sameAs can reference an unambiguous identity page, but it should not become a list of loosely related URLs. Its semantic job is identity, not promotion.

Run three different validations#

Schema QA has three layers because one green check cannot cover the whole deployment.

The validators answer different questions. The Schema Markup Validator focuses on Schema.org structure. The Rich Results Test focuses on Google-supported result types. A deployed-page inspection catches robots, canonical, rendering, or environment issues that pasted code cannot reveal.

A production QA checklist#

Before release, inspect one article from every template variant and automatically assert the mechanical parts across all pages.

Passing QA creates a maintainable description of the article. It does not create a ranking entitlement.

What Article schema cannot prove#

Structured data can give Google explicit clues and can make a page eligible for supported search appearances. It cannot prove that the article is accurate, original, useful, or authoritative. A complete graph around weak content is still weak content.

It also cannot guarantee that Google indexes the URL, chooses a rich result, displays a particular image, creates a Knowledge Panel, or cites the page in a generated answer. Treat those outcomes as separately observed events with their own evidence.