How to Set Up Article Schema on Editorial Pages

Article schema is the least glamorous markup on a content site and the one most likely to be wrong everywhere at once, because it ships from a template nobody re-reads. This guide covers the setup, the properties worth filling, and a mistake we made across an entire library before catching it — which is the part of schema work that never appears in schema tutorials.

What is Article schema actually for?

Classification, not citation. Google's structured-data introduction describes structured data as "a standardized format for providing information about a page and classifying the page content," feeding Google's understanding of a page and its eligibility for rich results. That is the documented job, and it is a real one.

The job it does not have is earning AI citations. Ahrefs tracked 1,885 pages that added JSON-LD between August 2025 and March 2026 against roughly 4,000 matched controls, and measured −4.6% on Google AI Overviews with statistical zeros on AI Mode (+2.4%) and ChatGPT (+2.2%). Google says the same thing from the other direction: there is "no special schema.org structured data that you need to add" for its AI features. Ship Article markup because the rich-result pipeline reads it — the full accounting of that null result is in what the evidence shows about schema and AI citations.

Which properties does an Article node actually need?

Fewer than most implementations carry, filled properly. Google's guidance is explicit about the trade: prioritize "fewer but complete and accurate recommended properties" over a longer list you cannot populate. This is the set we generate on every editorial page:

Properties per schema.org's Article type; the selection and rationale are ours, from generating this node across 400+ pages [our data].

One rule governs all of them, and it is Google's, not ours: "don't add structured data about information that is not visible to the user, even if the information is accurate." Markup is a description of the page, not a second page.

Should an editorial Q&A page use Article or QAPage?

Article plus FAQPage — and we know because we shipped the other answer first. On our insurance build, pages built around a single question went out with QAPage markup, on the reasonable-sounding logic that a page answering one question is a Q&A page. It was wrong, and the correction was a library-wide revert to Article plus FAQPage with the primary question folded into the visible page [our data].

The reasoning, stated as ours rather than as a citation: the Q&A rich result is built for pages where readers submit and vote on answers — forums and community sites — not for an editor answering a question they wrote themselves. Google's type-specific Q&A documentation is not on our closed source list, so we describe the decision we made and why, and leave the rule to the vendor's own page. The FAQ half of the pairing, including when it stops being worth the bytes, is in is FAQ schema still worth adding.

The generalizable lesson is not about QAPage. It is that structured data types encode a format assumption about who wrote the content and how, and picking a type because its name matches your page's shape is how libraries end up with thousands of pages of confidently invalid markup.

What does the JSON-LD look like?

One block, generated from the same fields that render the page:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Set Up Article Schema on Editorial Pages",
  "description": "Article schema in 5 steps, and the QAPage mistake we reverted.",
  "mainEntityOfPage": "https://example.com/learn/article-schema-setup/",
  "author": { "@type": "Person", "name": "Jared" },
  "publisher": { "@id": "https://example.com/#organization" },
  "datePublished": "2026-08-21",
  "dateModified": "2026-08-21"
}

Two structural choices in there are worth copying. The publisher is a reference to an @id, not a repeated object — the Organization node is published once and pointed at from everywhere, which is the pattern in Organization schema as your entity home. And every value is generated from page data rather than typed, so the markup cannot describe a page that no longer exists.

How should dates behave in Article markup?

datePublished is set once at first publish and never moves; dateModified moves when the content substantively changes. Deriving a publication date from a review date is the fake-freshness pattern that makes date signals worthless, and it is trivially detectable by anyone comparing your markup against an archive.

On our builds the two dates are separate frontmatter fields with separate rules, and the review date that drives our freshness gate is a third field that never touches the markup at all [our data]. Keeping them distinct costs nothing and removes the temptation entirely.

How do you validate it, and does any of this get you cited?

Validate the built HTML, not the template. Google's structured-data introduction names the Rich Results Test as the tool for validating markup and the rich result status reports for monitoring after deployment; that tool's URL is not on our closed source list, so we point you at Google's introduction page and to the check that caught more defects for us: parsing every JSON-LD block out of the rendered page in CI and failing the build on anything unparseable. Source-level review passes while escaping defects ship. How that generation and validation works across hundreds of pages is schema at scale.

As for citations — no. Article markup will not get your page quoted by an answer engine, the controlled evidence says so, and Google says no markup is needed for its AI features. Against our own interest: if implementing Article schema on your stack means plugin sprawl or a per-page agency line item, the honest recommendation is to skip it and spend the same effort on the visible answer, which is what the retrieval evidence actually rewards. We generate it because generation makes it free, and the passage work that does move extraction is the subject of our generative engine optimization guide.