Article schema: the five properties Google actually reads

Article schema is one JSON-LD block naming the things a parser otherwise has to guess at from your HTML: who wrote the page, when it was published, when it last changed, what its title is, and which image belongs to it. Google's documentation lists five supported properties and marks none of them required. Everything else schema.org defines on the type is valid markup that Google's page does not claim to read.

Before you start

Check what your site already emits. WordPress SEO plugins, Shopify blog themes and most headless starters ship an Article or BlogPosting block by default, and a hand-written second one does not replace it — it sits next to it. Open the page source, search for ld+json, and decide whether you are writing a new block or editing a generated one. Fifteen seconds, and it changes the job.

The rest of this assumes a page that really is an article: a post, a news story, something with an author and a date on it. Category listings, tag archives and homepages are other types, and marking them up as articles is how sites end up shipping structured data that contradicts the page.

What article schema is for, and what it is not for

Google's page — Article (Article, NewsArticle, BlogPosting) structured data, retrieved 2026-09-01, last updated 2025-12-10 — states the payoff in its opening sentence, and it is narrower than most write-ups suggest. Adding it "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)". Better title text. Better images. Better dates.

The next sentence removes the reason most people had for adding it: "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." Top stories does not require the markup. Google's structured data feature gallery, retrieved the same day, does list Article — "a news, sports, or blog article displayed in various rich result features, such as the title of the article and larger-than-thumbnail images" — filed under News and Sports, which is a fair description of the audience the feature was built for.

A one-person site publishing blog posts sits outside that audience. The block is still worth shipping, for the reason the documentation actually supports: it states the author, the dates and the canonical title in a form that needs no guessing. What it does not do is add a box to the result page.

There are no required properties. That is not permission to skip them — it means nothing will tell you what you left out.

Why Google's list is shorter than schema.org's

Two vocabularies meet on this page and they are nowhere near the same size. The schema.org Article page, retrieved 2026-09-01, defines the type as "an article, such as a news article or piece of investigative report", places it under Thing › CreativeWork › Article, and lists eight properties of its own: articleBody, articleSection, backstory, pageEnd, pageStart, pagination, speakable and wordCount. Inherited from CreativeWork and Thing are well over a hundred more. The same page puts deployment at "10M+ Domains", from monthly aggregations of Google's web index dated July 2026.

The five Google names

Under the heading "The Google-supported properties are the following", every entry falls under a single subheading — Recommended properties — and there is no second subheading. The entries are author (with author.name and author.url broken out), dateModified, datePublished, headline and image. The sentence governing all of them appears twice on the page: "There are no required properties; instead, add the properties that apply to your content."

The distance between a hundred-odd properties and five is the entire practical content of this topic. Generators and plugins emit articleBody, wordCount, articleSection, mainEntityOfPage and publisher into every post because the vocabulary permits it. publisher is the one worth knowing about: it appears on Google's page only inside the author best-practices section, as the correct home for a publisher name that would otherwise be stuffed into author.name. It is not in the supported list.

Do it: six steps

Half an hour for the first template, about five minutes per template after that.

1. Pick the type. Google's page: "Article objects must be based on one of the following schema.org types: Article, NewsArticle, BlogPosting." A blog post is BlogPosting, a dated news story is NewsArticle, and Article covers what neither fits. Done when the choice is made per template, never per post.
2. Fill headline from the same field that renders the visible title. Google asks for a concise one, "as long titles may be truncated on some devices". Done when the two strings match character for character; templates that build them separately drift within a month.
3. Emit datePublished and dateModified in ISO 8601 with an offset. Google's page: "We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot." Done when both values carry something like +08:00 on the end, and dateModified moves when you actually edit the post.
4. Write author as an array, one object per person, each carrying @type, name and url. Google: "When specifying multiple authors, list each author in their own author field", and "Use the Person type for people, and the Organization type for organizations. Don't use the Thing type". Done when author.name holds a name and nothing else — the page explicitly rules out job titles, honorific prefixes, publisher names and introductory words such as "posted by".
5. Point image at the article's own image rather than the site logo. Google's wording: "Use images that are relevant to the article, rather than logos or captions", plus a recommendation for "multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1". Done when each URL loads for a signed-out request.
6. Validate with the Rich Results Test, then deploy a handful of pages and read them with the URL Inspection tool — Google's own sequence. The same page tells you to confirm the URL is not blocked by robots.txt, the noindex tag, or login requirements. Done when the block parses with no critical errors.

Deliverable: two blocks and a property table

The minimum useful block. Nothing in it is required by Google; this is simply the smallest version that still says something the HTML alone does not say plainly.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How we cut first-byte time on a Shopify theme",
  "image": ["https://example.com/photos/16x9/photo.jpg"],
  "datePublished": "2026-09-01T09:00:00+08:00"
}
</script>

The full version adds the two properties sites get wrong most often: author as an array of typed objects with a profile URL each, and a dateModified that is wired to the edit rather than typed by hand.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How we cut first-byte time on a Shopify theme",
  "image": [
    "https://example.com/photos/1x1/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/16x9/photo.jpg"
  ],
  "datePublished": "2026-09-01T09:00:00+08:00",
  "dateModified": "2026-09-01T14:30:00+08:00",
  "author": [{
    "@type": "Person",
    "name": "Mei Chen",
    "url": "https://example.com/about/mei-chen"
  }]
}
</script>

Read the table as triage, not as a checklist to finish. The right-hand column is what the documentation says happens when a property is absent, and for most rows it says nothing at all — which is itself the answer.

Two rows need a note. The Rich Results Test line for the date properties is Google's own wording: the test "doesn't show a warning for this property, as it's only recommended if you decide that it's applicable to your site". And author.url has a documented substitute — "You can use the sameAs property as an alternative."

Three ways this goes wrong

None of these throws an error in the Rich Results Test, which is exactly why they survive on a site for years.

1. A dateModified that either never moves or moves on every deploy. Both failures have the same shape: the field claims to describe an edit and is describing a build instead. Wire it to the content's own updated timestamp, or leave it out — Google frames it as applicable only "if you decide that it's applicable to your site".
2. Several authors merged into one string. Google shows the anti-pattern verbatim, a single author object whose name reads "Willow Lane, Regula Felix", and the fix is an array with one object per person. The same section rules out padding the name with a job title or an honorific, both of which have their own properties.
3. The plugin emits Article on pages that are not articles. schema.org defines the type as "an article, such as a news article or piece of investigative report"; a paginated list of post titles is not one. This is what the "before you start" check catches.

Where this stops

Three limits, stated plainly. This markup does not make a page rank — Google's documentation describes it as help with understanding and appearance, never as a ranking input. It does not guarantee display either; the troubleshooting section on the same page says "Google does not guarantee that features that consume structured data will show up in search results". And for a site that is not publishing news or sports, we cannot point at one visible element in a search result that exists only because this block shipped. The documentation names none, and we have not run a test that would isolate one.

There is a fourth thing we do not know: whether AI answer engines parse this type at all. Google's page is about Google Search, schema.org is a vocabulary specification, and neither says anything about how an AI crawler treats BlogPosting. What can be verified today is whether those crawlers reach the page in the first place, which is what an AI crawler check answers, and it is the cheaper thing to fix.

One technical guideline sits away from the property list and is easy to miss. For multi-part pieces, Google asks 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)". If your series template paginates, that line matters more than any property on it.

For the wider question of which structured data types are still worth shipping at all, see schema markup for AI search. For the sibling type that describes where a page sits rather than what it contains, see breadcrumb schema.

Common questions

What is article schema?

A JSON-LD block that labels a page as an article and names its title, image, dates and authors in a fixed vocabulary. Google accepts three schema.org types for it — Article, NewsArticle and BlogPosting — and reads five properties from them.

Is article schema required for SEO?

No, and Google says so twice on its own page: there are no required properties, and Top stories eligibility carries no markup requirement. Treat it as a way to state facts about the page precisely, not as a box to tick before a page can rank.

Should I use an article schema generator?

A generator is fine for the first block and a liability afterwards, because it produces a static snippet while dateModified and author need to come from your data. Generate one, read it against the table above, then move the values into your template.

Article, NewsArticle or BlogPosting — which one?

BlogPosting for posts on a blog, NewsArticle for dated news reporting, Article when neither fits. Google supports all three equally and gives no reason to prefer one for ranking.

How do I check my article schema?

Run the Rich Results Test on the URL first, then the URL Inspection tool on a deployed page — Google's documented order. The first tells you the block parses; the second tells you Google can actually reach the page, which the first does not.

Does adding it change how the result looks?

The documentation promises "better title text, images, and date information", with no guarantee of display. On a non-news site, plan for no visible change.