A Working Article Schema Example, Explained Field by Field

Most pages ranking for this query hand you a ten-line snippet with a headline, a name string for the author, and nothing else. It validates, it does approximately nothing, and it teaches the wrong habit: treating schema as a checkbox instead of as a machine-readable claim about your content. This page gives you the full example first, then explains what each field is actually for, how the pieces connect into a graph, and where the subtypes and the FAQ rules fit. It is the article-level companion to our Person schema example and Organization schema example, and all three feed the same structured data cheatsheet.

This page maps to Vector 6, Structure, in the 12 Vectors framework: the markup layer that lets LLMs and search systems read your content with high confidence instead of guessing.

The complete article schema example

Here is a full Article block you can adapt. Every property in it is real, current, and drawn from Google's own Article documentation and the schema.org type definition. Swap the values, keep the shape.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/how-to-winterize-a-cottage/#article",
  "headline": "How to Winterize a Cottage in Ontario",
  "description": "A step-by-step guide to closing an Ontario cottage for winter, from plumbing to pest-proofing.",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/about/#jane-doe",
    "name": "Jane Doe",
    "jobTitle": "Senior Property Writer",
    "url": "https://example.com/about/jane-doe/",
    "knowsAbout": ["cottage maintenance", "rural property care", "Ontario real estate"],
    "sameAs": ["https://www.linkedin.com/in/janedoe"]
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Cottage Journal",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/assets/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "image": [
    "https://example.com/assets/cottage-16x9.jpg",
    "https://example.com/assets/cottage-4x3.jpg",
    "https://example.com/assets/cottage-1x1.jpg"
  ],
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/how-to-winterize-a-cottage/"
  },
  "inLanguage": "en-CA"
}

That block goes inside a single <script type="application/ld+json"> tag in the head of the page it describes. One page, one article, one block. If you want to see the exact pattern live, view the source of this page: it carries the same structure, pointed at itself.

What each field earns you

Google's position, stated plainly in its Article documentation, is that no property is required; you add what applies. In practice each recommended property buys a specific thing, and skipping one forfeits that thing.

• headline: the machine-facing title. Keep it under about 110 characters and matched to the visible H1. A headline that differs wildly from the on-page title reads as manipulation.
• author: the E-E-A-T anchor. More on why this must be a Person object, not a string, below.
• publisher: ties the article to a brand entity. Reference your Organization node rather than restating it; our Organization schema example shows the full node this points at.
• datePublished / dateModified: freshness signals, Vector 8 territory. Use ISO 8601 dates and never fake dateModified; Google compares it against actual content changes and stale-but-bumped dates are a known trust deduction.
• image: eligibility for visual treatments. Google recommends providing 16x9, 4x3, and 1x1 crops, each at least 1200 px wide where possible.
• mainEntityOfPage: declares that this page IS the article, rather than a page that merely mentions it. Small field, does real disambiguation work on category and tag pages.
• inLanguage: cheap and skipped constantly. For a Canadian business, en-CA is a locale claim that supports every other Canadian signal on the domain.

The connected @graph beats isolated blocks

The single most common defect Matt sees in article markup is not a missing property. It is fragmentation: an Article block from the SEO plugin, a separate Organization block from the theme, a third block from a plugin the site stopped using in 2023, each declaring overlapping entities with no connection between them. Google parses structured data as a connected graph, and three orphaned blocks force the parser to guess whether "Acme Inc" in block one is the same entity as "Acme" in block three.

The fix is the @graph pattern: one JSON-LD block containing an array of nodes, with each node carrying an @id and referencing the others by that id instead of restating them.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Article", "@id": "https://example.com/post/#article",
      "author": { "@id": "https://example.com/#jane-doe" },
      "publisher": { "@id": "https://example.com/#organization" },
      "isPartOf": { "@id": "https://example.com/#website" } },
    { "@type": "Person", "@id": "https://example.com/#jane-doe", "name": "Jane Doe" },
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Inc" },
    { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com" }
  ]
}

Notice what the references do: the Article does not restate the publisher, it points at it. Author, publisher, and website are each declared once, and every claim resolves to exactly one node. Across a whole site, the Organization and Person nodes keep the same @id on every page, which is how a crawler learns that four hundred articles share one author entity rather than four hundred coincidentally identical name strings. That accumulation is the mechanical basis of topical authority at the entity level, and it is Vector 2 and Vector 6 working together.

Article vs NewsArticle vs BlogPosting

Google accepts three types for article rich results, and they share almost all properties. The choice signals editorial register, not quality.

Do not use NewsArticle on a business blog hoping for Top Stories placement. Top Stories draws on news-publisher signals well beyond markup, and mislabelled content is one more small inconsistency in a trust calculation you want to keep clean. A service business writing guides should use Article; a company blog can use BlogPosting; the difference between those two is close to zero in outcomes, so pick one convention and hold it across the site.

Author as Person: where article schema meets E-E-A-T

The laziest legal markup is "author": "Jane Doe", a bare string. It validates. It also throws away the highest-value part of the block. Google's quality systems increasingly evaluate named author entities across the web, and a string gives them nothing to resolve. A Person object with an @id, a url pointing to a real bio page, a sameAs link to a professional profile, and a knowsAbout array tied to the article topic gives the machine a resolvable, corroboratable entity.

knowsAbout deserves specific attention because almost nobody uses it. It is a plain schema.org Person property that declares topical expertise, and when the article topic falls inside the author's declared knowsAbout range, the byline and the content corroborate each other. On this page, the Person node for Matt declares structured data and generative engine optimization; the page is about structured data. That alignment is exactly the kind of consistency an entity-resolution system can verify cheaply. The full pattern, including how to build the author bio page the url should point at, is in the Person schema example.

One qualitative note from the audit bench. In Matt's audits of Ontario business sites this year, the pattern that repeats is plugin-generated Article markup with a string author and a publisher pointing at a logo file that returns 404. The site owners believed schema was handled because a green checkmark appeared in a plugin dashboard three years ago. Validation is not the bar; coherence is.

Adding FAQPage: the verbatim rule

Many articles append an FAQ section and mark it up with FAQPage schema in the same graph. Fine, with one hard constraint that got much harder in 2026: the questions and answers in the schema must match the visible on-page text word for word. Google validates FAQPage markup against rendered content, and the old habit of putting a short summary answer in the schema while the page carries a longer version now costs you the rich result and degrades the page's standing in Search Console.

The operating rule is mechanical. Write the visible FAQ first. Copy each question and answer into the mainEntity array unchanged. If an answer feels too long for the schema, shorten the visible answer and copy again. There is never a legitimate reason for the two to differ, and a diff between them is a five-line script in any build pipeline. The FAQ block at the bottom of this page and the FAQPage node in its head are character-identical, which you can confirm from source.

The same discipline applies in the other direction: do not add FAQPage markup to a page with no visible FAQ. Schema that describes content the reader cannot see is the textbook definition of markup spam in Google's structured data policies.

Six defects that survive validation

The Rich Results Test checks syntax and required fields. It does not check truth or coherence, which is where article markup actually fails. The recurring defects, in rough order of frequency:

• Author as a string instead of a Person object. Legal, and worth almost nothing.
• Duplicate entity declarations: plugin and theme both emitting Organization nodes with different names or ids.
• Dead references: publisher logos that 404, sameAs profiles that were deleted, mainEntityOfPage ids that do not match the canonical URL.
• Date dishonesty: dateModified bumped on every deploy while the content never changes.
• Schema-content mismatch: headline in the markup differing from the H1, FAQ answers differing from visible text, images in the markup that never render.
• JavaScript-only injection: markup added client-side by a tag manager. Google usually renders it; several AI crawlers, which do not execute JavaScript, never see it. Server-rendered JSON-LD has no such failure mode, which is one reason this site ships as static HTML.

Every one of these passes a validator. Every one of them weakens the graph. The distinction matters because the point of the exercise is not a green checkmark; it is giving retrieval systems a set of claims they can verify against the visible page and the wider web.

Why AI engines raise the stakes on article markup

Traditional Google could afford to be forgiving with sloppy markup because it had a decade of link and behaviour data to fall back on. Retrieval-driven AI answers work with less context per decision: an engine assembling an answer needs to attribute a claim to a source quickly, and an article that declares its author, publisher, dates, and language in machine-readable form is simply cheaper to attribute than one that makes the model infer all of it from prose. Cheaper to attribute means likelier to be cited, all else equal.

This is a probability argument, not a switch you flip. Structured data does not force any engine to cite you, and anyone selling markup as a citation button is overclaiming. What the markup does is remove ambiguity from every downstream system that reads the page, and ambiguity is the tax that unstructured content pays at retrieval time. Our schema markup service exists because doing this properly across a whole site, with stable ids, coherent graphs, and verbatim FAQ discipline, is fiddly detail work that most teams understandably never get around to.

Properties you can safely skip, and two worth knowing

The schema.org Article type carries dozens of properties beyond the core set, and generator tools love padding output with them. Most add nothing. You do not need wordCount, articleBody (duplicating your entire article text into the markup bloats the page and helps nobody), genre, commentCount, or copyrightHolder on a normal business article. Markup weight is not markup value; a lean block of properties a machine can verify beats a long block of properties nobody consumes.

Two of the lesser-known properties do earn their place in specific situations. articleSection is worth setting on large publications where the category itself carries meaning, since it tells the parser which editorial bucket the piece belongs to. And speakable, which flags passages suited to text-to-speech, remains a limited-availability Google feature; it costs little to include on news-style content but should not be mistaken for a general answer-engine signal. The honest framing for both: nice when they apply, never a substitute for getting author, publisher, dates, and the graph connections right.

A deployment checklist for article schema

Before an article ships, the markup passes this list. It takes about four minutes per page manually and near zero when built into a pipeline.

Run your existing articles against that list before writing any new markup. In our experience the fastest wins on established sites come from repairing what a plugin generated years ago, not from adding new properties.

Where this fits in the larger structure

Article schema is one node type in a site-wide graph. The author node it references is covered in the Person schema example, the publisher node in the Organization schema example, and the full type-by-type reference lives in the structured data cheatsheet. If you would rather have the whole graph designed, built, and verified for you, that is the schema markup service, and the work carries the same commitment as everything else we do. Results Guarantee: if your existing domain shows no measurable organic search results after 12 months of work with Formative Digital, we work for free until you see them.

Questions about your own markup, or about whether any of this is worth the effort for your situation? Talk to us. We will tell you honestly, including when the answer is that your current markup is fine.