Article Schema: The Seven Properties Google Supports, and the Author Rules Nobody Follows

Open the JSON-LD on almost any WordPress blog post and you will find an Article node carrying twenty or thirty properties: publisher, mainEntityOfPage, articleSection, wordCount, commentCount, inLanguage, isPartOf, speakable. Then open Google’s documentation for Article structured data and count the properties it says it supports.

There are seven.

That gap is not a scandal — extra schema.org properties are valid and harmless, and some are useful to consumers other than Google. But it explains why Article schema is simultaneously the most-deployed structured data type on the web and one of the least deliberately implemented. Almost nobody chose those thirty properties. A plugin did.

Article schema is structured data describing a news article, blog post or sports article, emitted as Article, NewsArticle or BlogPosting. Google uses it to understand the page and to show better title text, images and date information in search results — not to produce a dedicated rich result. Its supported property set is small, and its author properties carry documented rules most implementations break.

Key takeaways

• Google supports seven properties on Article, all recommended, none required: author, author.name, author.url, dateModified, datePublished, headline and image. publisher is not among them.
• It is not a rich result. Google’s stated benefit is that Article markup can help Google understand more about the web page and show better title text, images, and date information — there is no Article-specific SERP feature for an ordinary blog.
• Top stories does not require it. Google states there is no markup requirement to be eligible for Google News features like Top stories.
• author.name must contain only a name. Google’s best practices explicitly bar the publisher name, job titles, honorifics and introductory words such as “posted by” from that field.
• Dates need a timezone or Google picks one. Without offset information Google will default to the timezone used by Googlebot, which is not yours.

The seven properties

Google’s Article documentation lists its supported properties in a single table, headed Recommended properties. In full:

Property	Type	What Google does with it
author	Person or Organization	Identifies who wrote the article
author.name	Text	The author’s name, and nothing else
author.url	URL	A page that uniquely identifies the author
datePublished	DateTime	First publication, ISO 8601
dateModified	DateTime	Most recent modification, ISO 8601
headline	Text	The article title
image	ImageObject or URL, repeated	A representative image

Three of those seven are about the author and two are about dates. That distribution is the most useful thing on the page: Google’s interest in Article markup is overwhelmingly who wrote this and when, not what the article contains.

The type itself must be one of three: Article objects must be based on Article, NewsArticle or BlogPosting. Pick the one that is true. A blog post is a BlogPosting; a news story is a NewsArticle; anything else that is genuinely an article is Article. There is no ranking difference to chase here, and choosing NewsArticle for marketing content is a claim about your publication that is not true.

As with Organization markup, there are no required properties — the instruction is to add the ones that apply. The failure mode differs though. With Organization schema the risk is an under-populated node that identifies nothing. With Article the risk is the opposite: a plugin-generated node so large that nobody notices the two fields Google actually reads are wrong.

What Article schema does and does not earn you

Worth being precise about, because expectations here are routinely inflated.

Google’s own description of the benefit is modest: adding Article structured data “can help Google understand more about the web page and show better title text, images, and date information for the article in search results on Google Search and other properties (for example, Google News and the Google Assistant).”

Read that as three specific things — better title text, better images, better date information — and one broader one, eligibility on Google properties beyond Search. What it does not say is that Article markup produces a distinctive result format. For a normal blog post it does not. If you are expecting a visible change in the SERP after deploying it, you will usually be disappointed, and that disappointment is a documentation-reading problem rather than an implementation one. The broader question of which structured data types actually repay the effort is in do rich snippets help SEO.

The other expectation worth deflating: Google says plainly that “while there’s no markup requirement to be eligible for Google News features like Top stories, you can add Article to more explicitly tell Google what your content is about.” Article schema is not the entry ticket to Top stories that it is frequently sold as. It is a clarification, offered voluntarily.

Which leaves the real reason to implement it carefully in 2026, and it is not about Google’s SERP at all. The author and date properties are the machine-readable form of two things answer engines weight heavily when deciding what to cite: who is accountable for a claim, and how current it is. That case is made in full in E-E-A-T for AI search and structured data for AI search. Article schema is where those signals are declared on a per-page basis.

The author rules, and how implementations break them

Google devotes an entire documented section to author markup best practices. It exists because these mistakes are widespread, and each one is machine-detectable in your own output within a minute.

Rule 1: include every author shown on the page. If the byline says two people, both belong in the markup.

Rule 2: multiple authors go in separate fields. Google shows the correct and incorrect forms side by side. Correct:

"author": [
  { "name": "Willow Lane" },
  { "name": "Regula Felix" }
]

Wrong — and this is what most templates produce, because they concatenate a byline string:

"author": { "name": "Willow Lane, Regula Felix" }

Rule 3: use type and url (or sameAs). Google’s wording is that it “strongly” recommends these, and the reason is entity resolution: a name alone is a string, while a name with a URL is a claim that can be checked against something. If the URL points at an internal profile page, Google recommends marking that page up with profile page structured data as well.

Rule 4: author.name holds only the name. Google lists four things to keep out of it, and every one appears in real implementations:

• The publisher’s name — that belongs in publisher.
• The author’s job title — use jobTitle.
• Honorific prefixes and suffixes — use honorificPrefix or honorificSuffix.
• Introductory words. Google’s example is “posted by”.

A field containing "posted by Dr Jane Doe, Editor in Chief, Acme Media" is four violations in one string, and it is exactly what a template produces when it renders the byline as displayed rather than as data.

Rule 5: use the right type. Person for people, Organization for organisations. Google adds: “Don’t use the Thing type, and don’t use the wrong type (for example, using the Organization type for a person).”

Here is the shape Google’s own example lands on, applying all five:

"author": [
  {
    "@type": "Person",
    "name": "Willow Lane",
    "jobTitle": "Journalist",
    "url": "https://www.example.com/staff/willow-lane"
  }
],
"publisher": {
  "@type": "Organization",
  "name": "The Daily Bug",
  "url": "https://www.example.com"
}

Note where publisher sits: outside the supported-properties table, but present in Google’s own worked example, and it is where the publication name goes so it stops contaminating author.name. That is the honest status of publisher on an Article node — not on the list Google says it supports, and still the correct home for the value.

Check your own output in one command:

curl -s https://example.com/some-article \
  | grep -o '"author":.\{0,200\}'

If what comes back contains a comma-separated list of names, a job title inside name, or the string “by”, you have found the work.

Dates: the field that quietly lies

datePublished and dateModified are the two properties most likely to be wrong in a way nobody notices, because nothing validates them against reality.

Google asks for ISO 8601 format and adds a recommendation with a specific consequence attached: “We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot.” A bare 2026-09-03 is not wrong, but it is incomplete, and Google resolves the ambiguity with its own timezone rather than yours. For a daily-publishing site that is a whole day of drift on some posts.

The failure that matters more is a dateModified that is not true. Two versions, both common:

The template stamps the build date. Every page rebuilt on Tuesday claims it was modified on Tuesday. Nothing changed; a static site generator ran. You are now telling Google and every answer engine that your entire archive was updated simultaneously, which is a freshness claim that no individual page can support.

A future date ships. Content scheduled for next week, with datePublished set accordingly, deployed today. Google receives a page claiming to be published in the future.

I gate both on this site, because both have shipped here. The build fails if any JSON-LD datetime is later than the build date, and datePublished is clamped to the build date so a scheduled post cannot announce a publication that has not happened yet. Neither check is clever; both catch a class of error that is invisible in a source diff and obvious in the output — which is the general argument for validating structured data against the built site rather than the template.

The rule underneath: dateModified should change when the content changed, and not otherwise. If your system cannot distinguish a content edit from a redeploy, emit only datePublished until it can. A missing property is neutral. A false one is a claim.

The technical guideline about canonicals

Buried in Article’s technical guidelines is a rule with consequences well beyond schema:

“For multi-part articles, make sure that the rel=canonical points at either each individual page or a ‘view-all’ page (and not to page 1 of a multi-part series).”

Canonicalising every part of a series to part one is a common instinct and it is wrong. It tells Google that parts two through six are duplicates of part one, which removes them from consideration entirely. Either each part is its own canonical, or there is a single view-all page that all of them point at. The general decision framework is in canonical vs noindex, and the equivalent problem for paginated content is in pagination SEO.

Google also points anyone with subscription or registration walls at paywalled content structured data — the mechanism that lets you show Googlebot content you hide from anonymous visitors without it counting as cloaking. If any of your articles sit behind a wall, that is a prerequisite rather than an enhancement.

Images

Article’s image property is repeated, and Google’s guidance asks for more than one. Its recommendation: multiple high-resolution images, “minimum of 50K pixels when multiplying width and height”, in three aspect ratios — 16x9, 4x3 and 1x1.

Three constraints sit alongside it, and the first is the one that fails silently:

• Image URLs must be crawlable and indexable. An image blocked in robots.txt is invisible to the feature it was supposed to enable — one more instance of the robots.txt trap.
• Images must represent the marked-up content. Google’s phrasing elsewhere on the same page is to use images relevant to the article “rather than logos or captions”.
• The format must be one Google Images supports.

If you are also thinking about Google Discover, note that its image requirements are stricter and differently shaped — at least 1200 px wide and 16:9 — so a single image satisfying both surfaces needs to be built for the stricter one.

A minimal, correct implementation

Everything Google says it supports, plus publisher from its own example, with nothing invented:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "The article's title, kept concise",
  "image": [
    "https://example.com/photos/16x9/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/1x1/photo.jpg"
  ],
  "datePublished": "2026-09-03T09:00:00+01:00",
  "dateModified": "2026-09-03T09:00:00+01:00",
  "author": [
    {
      "@type": "Person",
      "name": "Jane Doe",
      "jobTitle": "Technical SEO Consultant",
      "url": "https://example.com/about/"
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "url": "https://example.com"
  }
}

Google recommends a concise headline, noting long titles may be truncated on some devices. It does not need to match your H1 exactly, and on a site where the H1 is deliberately longer than the SERP title, headline should follow the title.

Then validate. Google’s sequence is the Rich Results Test for syntax, followed by the URL Inspection tool on a deployed page to confirm Google can actually reach it — checking it is “not blocked by a robots.txt file, the noindex tag, or login requirements”. The two tests answer different questions and neither substitutes for the other.

One troubleshooting note worth knowing before you need it: if a page receives a structured data manual action, Google says the structured data on the page will be ignored even though the page can still appear in results. Markup that is being ignored looks identical to markup that is working, from the outside.

Where this fits

Article schema is one type in a stack. Which types are worth deploying at all is answered in do rich snippets help SEO; the construction mechanics generalise from how to create rich snippets with JSON-LD. The entity that publishes the articles is Organization schema; the navigation context is breadcrumb schema; and the type whose rich result Google retired, along with what it is still good for, is FAQ schema. For why the author and date properties matter more to answer engines than to Google’s SERP, see structured data for AI search.

If you would rather have the schema layer designed once and gated in CI than regenerated by a plugin on every deploy, that is part of GEO and technical SEO consulting.

FAQ

What properties does Article schema require?

None. Google states there are no required properties for Article and that you should add the ones that apply to your content. Its supported set is seven entries, all recommended: author, author.name, author.url, dateModified, datePublished, headline and image. Additional schema.org properties are valid and may be useful to other consumers, but they are outside what Google documents itself as using.

Should I use Article, NewsArticle or BlogPosting?

Whichever is true. Google says Article objects must be based on one of Article, NewsArticle or BlogPosting, and the choice is descriptive rather than strategic — there is no ranking advantage to claiming a type that does not fit. A blog post is a BlogPosting, a news story is a NewsArticle, and Article covers everything else that genuinely is one.

Does Article schema give me a rich result?

Not a distinct one, for an ordinary blog. Google’s stated benefit is narrower: the markup “can help Google understand more about the web page and show better title text, images, and date information” in Search and on other Google properties. Expect improved accuracy in what is already displayed rather than a new result format. Google also notes there is no markup requirement to be eligible for Top stories, so Article schema is not the gate to Google News features it is often described as.

Do I need publisher in Article schema?

It is not in Google’s supported-properties table, but it appears in Google’s own author-markup example and it is where the publication’s name belongs. The practical reason to include it is subtractive: Google’s best practices bar the publisher name from author.name, so having a publisher field is what stops it being appended to the author string.

How should I mark up multiple authors?

One author entry each. Google shows the correct form as an array of separate objects and explicitly warns against merging names into a single field — "name": "Willow Lane, Regula Felix" is the anti-pattern it names. It also asks you to include every author presented on the page, and to add @type plus url or sameAs for each so the name resolves to something verifiable.

What should dateModified be set to?

The date and time the content was genuinely last modified, in ISO 8601, with timezone information — Google notes that without it, it will default to the timezone used by Googlebot. Do not stamp it with the build or deploy date. A dateModified that updates on every rebuild tells Google and every answer engine that your whole archive was revised at once, which is a freshness claim none of those pages can support. If your system cannot tell a content edit from a redeploy, omit the property until it can.

Can I put Article schema on a category or homepage?

No. Article markup describes a single article, so it belongs on the page that is that article. A category listing is not an article, and marking one up as one is a claim about the page that the page does not meet — the kind of mismatch Google’s general structured data guidelines treat as spammy markup usage rather than a syntax error, which means the Rich Results Test will not flag it.