Article Schema:
Required Fields, JSON-LD Example, and QA Checklist

Article schema gives machines an explicit account of the article already visible on a page: its headline, author, dates, and representative images. It uses the Schema.org vocabulary. Google’s current Article documentation accepts Article, NewsArticle, or BlogPosting and describes recommended properties rather than a separate mandatory set, so the practical goal is accuracy and synchronization—not filling every available field.

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.

“No required properties” in Google’s current Article documentation does not mean “anything is useful.” It means eligibility is not expressed as a mandatory Article-field checklist; applicable properties still need to be truthful, correctly typed, visible or supported by the page, and technically accessible.

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.

Google’s current Article documentation names Article, NewsArticle, and BlogPosting; lists author, dateModified, datePublished, headline, and image as recommended properties; and says there are no required Article properties.

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.

Google recommends including all visibly presented authors in markup, using author-identifying URLs, and keeping structured data representative of page content. Its general guidance favors fewer complete and accurate properties over a larger inaccurate set.

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.

1. Validate vocabulary and syntax — Run the generated graph through Schema.org’s Schema Markup Validator. Fix invalid JSON, wrong types, misspelled properties, and malformed nested values.
2. Validate the Google feature — Run Google’s Rich Results Test. Resolve critical issues and review non-critical issues without inventing values simply to clear a warning.
3. Validate the rendered URL — Deploy a small set, confirm Google can access the canonical page and image URLs, inspect the rendered source, and check that visible article facts match the graph.
4. Monitor the template after release — Use Search Console and template-level tests to detect pages that break after a CMS, author model, image pipeline, canonical rule, or date behavior changes.

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.

Google’s implementation sequence includes validation, limited deployment, URL inspection, and monitoring. Google Search Console’s Rich Results Test shows that Schema.org and Google expose separate validators because vocabulary correctness and Google feature handling are not the same test.

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.

Implement the smallest accurate Article graph your publishing system can keep synchronized, then validate vocabulary, Google feature handling, and the deployed page as three separate gates.

Frequently asked questions#