Article Schema: Every Field That Actually Matters

Run a structured data test on any random blog post. Nine times out of ten, you will find an Article schema block that declares headline, author as a plain text string, and datePublished. That is it. Three fields. The bare minimum to pass the Rich Results Test without a warning.

Now ask yourself: why would an AI system cite that page over the hundreds of others saying the same thing? It would not. Because headline and date tell a crawler nothing about provenance, nothing about the author's verifiable identity, and nothing about whether the content has been maintained since it was published.

The three fields most Article schema implementations omit are dateModified, author as a full Person entity (with external identifiers like ORCID or sameAs links), and citation. These are not obscure properties. They are documented on schema.org and recognized by Google. But most CMS plugins ignore them because they are not required for rich results.

Rich results are not the game anymore. AI citation is. And AI agents do not just check whether your schema exists. They check what it says.

The problem with minimal Article schema

Here is what a typical Article schema block looks like on most websites:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Do X",
  "author": "Some Person",
  "datePublished": "2025-06-15"
}

This passes validation. Google will not complain. But look at what is missing.

The author is a string, not an entity. There is no way for a machine to know which "Some Person" this is. No link to a profile page. No external identifier. No connection to an organization. The author could be anyone.

There is no dateModified. A crawler cannot tell if this content was written last year and never touched again, or if it was updated last week with fresh data. For any topic that evolves, this matters enormously. AI systems use freshness as a proxy for reliability [1].

There are no citations. The article might reference three studies and link to five external sources in the body text, but none of that is machine-readable in the schema. A human can see the hyperlinks. An AI agent parsing JSON-LD cannot.

As I wrote in Schema Markup Is Not Technical, It's Strategic, schema is not a developer checkbox. It is a declaration of who you are, what you published, and why it should be trusted. A minimal Article block declares almost nothing.

Every field that matters, ranked

Schema.org defines dozens of properties for the Article type. Most of them are irrelevant for practical purposes. Here are the ones that actually influence how AI systems evaluate and cite your content, ranked by impact.

The pattern is clear. The fields that matter most are the ones that establish provenance: who wrote it, when was it last maintained, and what sources back it up. The fields that matter least are the ones that describe content Google can already infer from the page itself.

The complete Article schema example

Here is a complete Article schema block with every field that matters. This is not hypothetical. This is the pattern I use on this site.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://yourdomain.com/writing/essays/article-schema/#article",
  "headline": "Article Schema: Every Field That Actually Matters",
  "description": "A practitioner's guide to the Article schema fields that influence AI citation probability.",
  "datePublished": "2026-07-16T00:00:00+07:00",
  "dateModified": "2026-07-16T00:00:00+07:00",
  "wordCount": 3100,
  "inLanguage": "en",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://yourdomain.com/writing/essays/article-schema/"
  },
  "image": {
    "@type": "ImageObject",
    "url": "https://yourdomain.com/images/article-schema-hero.webp",
    "width": 1200,
    "height": 630
  },
  "author": {
    "@type": "Person",
    "@id": "https://yourdomain.com/about/#person",
    "name": "Ibrahim Anwar",
    "url": "https://yourdomain.com/about/",
    "jobTitle": "Practitioner & Director",
    "sameAs": [
      "https://www.linkedin.com/in/hibranwar/",
      "https://github.com/hibranwar",
      "https://orcid.org/0009-0005-0025-8553",
      "https://www.wikidata.org/wiki/Q132846926"
    ],
    "worksFor": {
      "@type": "Organization",
      "name": "PT Arsindo Cipta Karya",
      "url": "https://ptarsindo.com"
    }
  },
  "publisher": {
    "@type": "Organization",
    "name": "Ibrahim Anwar",
    "url": "https://yourdomain.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://yourdomain.com/images/logo.webp"
    }
  },
  "citation": [
    {
      "@type": "WebPage",
      "name": "Article Structured Data",
      "url": "https://developers.google.com/search/docs/appearance/structured-data/article"
    },
    {
      "@type": "ScholarlyArticle",
      "name": "ORCID-linked labeled data for evaluating author name disambiguation",
      "url": "https://doi.org/10.1007/s11192-020-03826-6"
    }
  ],
  "isBasedOn": {
    "@type": "WebPage",
    "name": "Schema.org Article Type Documentation",
    "url": "https://schema.org/Article"
  }
}

Let me walk through the parts that most implementations get wrong.

Author as a Person entity, not a string

This is the single highest-impact change you can make to your Article schema. Replace the author string with a full Person object.

The difference:

// Weak: author as string
"author": "Ibrahim Anwar"

// Strong: author as Person entity
"author": {
  "@type": "Person",
  "@id": "https://yourdomain.com/about/#person",
  "name": "Ibrahim Anwar",
  "url": "https://yourdomain.com/about/",
  "sameAs": [
    "https://www.linkedin.com/in/hibranwar/",
    "https://orcid.org/0009-0005-0025-8553"
  ]
}

When the author is a string, it is just a label. Any page on the internet could claim that author name. There is no way to verify it.

When the author is a Person entity with an @id, a URL, and sameAs links to external profiles, you have created something fundamentally different. You have created a verifiable identity chain. The AI crawler can follow the @id to your about page. It can check if that page declares the same Person entity. It can follow the sameAs links to LinkedIn, ORCID, Wikidata, and confirm that these all describe the same individual.

Google's documentation on author markup best practices explicitly recommends using sameAs to link to author profile pages on other sites [2]. This is not speculation. It is in the docs.

For academic or research content, ORCID is especially powerful. ORCID (Open Researcher and Contributor ID) is a persistent digital identifier that disambiguates researchers with similar names [3]. When you include an ORCID URL in your author's sameAs array, you connect your Article schema to the global academic identity system. AI systems trained on academic literature recognize this signal.

I covered the full Person schema setup in How to Set Up JSON-LD Person Schema, including the sameAs property that connects your identity across platforms. If you have not implemented Person schema on your about page yet, do that first. Your Article schema author should reference the same @id.

dateModified: the freshness signal most people skip

Google's documentation says dateModified is "recommended if you decide that it's applicable to your site." That phrasing makes it sound optional. It is not. Not anymore.

AI retrieval systems use content freshness as a ranking signal. When Perplexity, ChatGPT with browsing, or Gemini encounter two articles on the same topic, one from 2023 with no dateModified and one from 2024 with a dateModified of last month, the second article gets preferred. Not because the date alone determines quality. But because a maintained article is more likely to contain current information.

The rules for honest dateModified usage:

• Only update dateModified when you make substantive changes. Fixing a typo or changing formatting does not count.
• The date must reflect a real content update. Adding a new section, updating statistics, correcting factual errors, adding new references. These count.
• Use ISO 8601 format with timezone: 2026-07-16T00:00:00+07:00
• Make dateModified visible on the page. Display a "Last updated" line. Google explicitly recommends that structured data match visible content [2].
• Never set dateModified to today's date via automation. Some CMS plugins regenerate this timestamp on every build. That is dishonest and Google knows it.

A content audit cycle helps. Set a quarterly reminder to review evergreen articles. When you update them, update dateModified. This creates a visible, verifiable pattern of content maintenance that both human readers and AI systems can observe.

Citation and isBasedOn: declaring your sources in machine-readable format

This is the field almost nobody uses. And it is the one that separates "content" from "citable content" in the eyes of an AI agent.

The citation property in Article schema lets you declare, in machine-readable JSON-LD, the specific sources your article references. Not just hyperlinks in the body text. Structured declarations that say: this article cites these specific works.

"citation": [
  {
    "@type": "WebPage",
    "name": "Article Structured Data - Google Search Central",
    "url": "https://developers.google.com/search/docs/appearance/structured-data/article"
  },
  {
    "@type": "ScholarlyArticle",
    "name": "ORCID-linked labeled data for evaluating author name disambiguation",
    "url": "https://doi.org/10.1007/s11192-020-03826-6",
    "identifier": {
      "@type": "PropertyValue",
      "propertyID": "DOI",
      "value": "10.1007/s11192-020-03826-6"
    }
  }
]

Why does this matter for AI citation? Because AI systems are increasingly trying to trace provenance. When ChatGPT or Perplexity generates an answer and needs to decide which sources to cite, a page that declares its own sources in structured data gives the AI system a confidence signal. The page is not just making claims. It is showing its work. In a machine-readable format.

The related property isBasedOn serves a slightly different purpose. While citation says "this article references these works," isBasedOn says "this article was derived from this source material." Use it when your article is an analysis of a specific report, a response to a specific study, or a practical guide based on official documentation.

Both properties accept either a URL string or a full CreativeWork object. The full object is better because it gives the AI system more context about what you are citing.

The entity chain: Article to Author to Organization

The real power of a well-structured Article schema is not in any single field. It is in the chain of entities it creates. Here is how the relationships flow.

Every arrow in this diagram is a relationship that an AI system can traverse. The Article points to a Person. The Person points to an Organization and to external identifiers. The AI system follows these links and builds a picture: this article was written by this specific person, who works at this organization, and whose identity is confirmed across multiple platforms.

This is what I call entity infrastructure. It is not about any single tag or property. It is the connected graph of verifiable claims. As I discussed in the sameAs schema essay, the sameAs property is what ties identity nodes together across the web. In the Article schema context, sameAs on your Person author object is what transforms a name string into a disambiguated entity.

Without the chain, your Article schema is a standalone claim with no backing. With it, your content is anchored to a verified identity inside a verified organization. That is the difference between a page that gets crawled and a page that gets cited.

Common mistakes and how to fix them

1. Author as a string instead of a Person object

Already covered above. Replace the string with a full Person entity. If you use WordPress, most SEO plugins default to a string. You will need to override the schema output or use a custom plugin.

2. dateModified missing or auto-generated

Add it manually. Set it to the same value as datePublished initially. Update it only when you make real content changes. If your CMS auto-generates it on every deploy, turn that off.

3. @id missing from Author and Article

The @id property is how JSON-LD creates references between schema blocks. Without it, your Article schema and your Person schema on your about page are disconnected. With matching @id values, they form a single connected graph. Use a URL fragment pattern: https://yourdomain.com/about/#person for the Person, https://yourdomain.com/article-url/#article for the Article.

4. Publisher missing or pointing to the Person

Google recommends that publisher be an Organization, not a Person [2]. Even for personal blogs, create an Organization object with your site name. This is a structural convention, not a philosophical statement about whether you are a business.

5. Headline mismatch with visible h1

Your schema headline must match the visible <h1> on the page. AI systems check for consistency between structured data and visible content. A mismatch is an inconsistency signal. It reduces trust.

6. No citations despite referencing external sources

If your article links to external sources in the body text, declare them in the citation property. This is the lowest-effort, highest-impact improvement for most existing articles.

Implementation checklist

Use this as a practical audit. Check each field against your existing Article schema.

• headline: Matches visible h1 exactly. Under 110 characters.
• author: Full Person object with @id, name, url, sameAs. Not a string.
• author.sameAs: At least LinkedIn and one identity platform (ORCID, Wikidata, Google Scholar).
• datePublished: ISO 8601 with timezone.
• dateModified: Present. Reflects last substantive update. Visible on page.
• publisher: Organization with name, url, logo.
• citation: Array of CreativeWork objects for every source referenced.
• mainEntityOfPage: WebPage with @id matching canonical URL.
• description: Matches meta description. Under 155 characters.
• image: ImageObject with url, width, height. At least 1200px wide.
• inLanguage: Two-letter ISO code (en, id, etc.).
• @id: Present on Article, Person, and WebPage objects.

What about FAQPage schema alongside Article?

Yes. You can and should nest FAQPage schema alongside Article schema on pages that contain FAQ sections. Google supports this. The FAQ section in the body content should be visible (not hidden), and the schema should match the visible questions and answers exactly.

The combination of Article schema (establishing provenance and authorship) and FAQPage schema (targeting specific queries) gives AI systems two complementary signals. The Article schema says "this is a credible piece from a verified author." The FAQPage schema says "this page directly answers these specific questions." Together, they increase the probability that an AI system cites your page for a relevant query.