Article schema: the property table and what breaks

What is Article schema?

Article schema is a block of machine-readable data that tells a search engine a page is an article — and who wrote it, when, and under what title.

It sits in the same family as every other type on our guide to schema markup. Article is one of the 25 structured data types Google Search currently supports (Google's search gallery, last updated 16 October 2026).

It has three usable forms. Google's documentation says an Article object "must be based on one of the following schema.org types" — and then names exactly three.

Google treats all three the same way for Article features. Picking between them is about describing your content honestly, not unlocking anything extra.

What Article markup actually gets you — and what it does not

Article markup does not produce a standalone rich result on an ordinary blog post. There is no star, no badge, no extra block in the SERP. It helps Google present your article more accurately, and that is the whole promise.

Google's own wording in its Article structured data documentation: the markup can help Google show better title text, images and date information for the article in Search and in properties such as Google News.

• It is currently supported. Article is live in Google's gallery as of 16 October 2026 — unlike FAQ markup, which stopped producing any rich result on 7 May 2026, and HowTo, which went before it.
• It is not a Top Stories ticket. Google says plainly there is no markup requirement for Google News features like Top stories. Newsworthiness and site-level eligibility decide that.
• It is not an AI tactic. Google's guidance on AI experiences (updated 10 July 2026) states there are no additional technical requirements and no special structured data needed for AI Overviews or AI Mode. Structured data governs rich-result eligibility. Nothing more.
• It does not win snippets. Clear sub-headings and a direct answer high on the page do that — see our guide to featured snippets. Markup is not the lever.

So the honest sentence is: still worth adding, because it makes your title, image and dates unambiguous to a crawler — but it will not draw a visible snippet enhancement on a normal post.

The Article property table: what each one does, and what breaks

Here is the part most posts skip. Google's Article page is explicit: "There are no required properties; instead, add the properties that apply to your content." Everything below is recommended, not mandatory.

Read that last row twice. Plenty of guides still call publisher mandatory for Article. Google's current page, last updated 8 September 2026, does not list it at all.

Three things writers get wrong

1. The headline length limit that no longer exists

Google's Article documentation used to state that the headline value "should not exceed 110 characters". That hard limit is gone.

The current wording is softer and more useful: "Consider using a concise title, as long titles may be truncated on some devices."

So 110 is a habit, not a rule. Keep headlines short because a truncated title reads badly on a phone, not because a validator will fail you. And keep the headline value matching the visible title — a headline in markup that disagrees with the H1 on the page is a mismatch, and mismatches are what structured data guidelines genuinely police.

2. author as a bare string instead of a nested entity

This is the one that actually costs you something. Google's author markup best practices are specific: use the Person type for people and Organization for organisations, put only the name in author.name, list each author in their own author field, and add url or sameAs.

A flat string carries none of that. This shape does:

"author": {
  "@type": "Person",
  "name": "Priya Nair",
  "url": "https://example.com/about/priya-nair/"
}

Two authors get two separate author objects, not one name field with "and" in it.

One site-specific warning. On digitalhangover.in a WPCode snippet strips structured data out of post bodies, so a snippet like the one above goes into AIOSEO > Schema > Custom Schema or your theme's head — never pasted into the post editor. Check your own setup before you place code anywhere.

3. dateModified used as a freshness trick

dateModified means the date the content changed. It does not mean the date you opened the post.

Bumping it on a page you did not actually edit tells Google something untrue about your own content, and it tells readers the page was reviewed when it was not. There is no documented ranking reward for the bump.

The honest pattern: update the page properly, then move the date. Publishing to update in place — same URL, revised content, revised date — is also how you keep the link equity you already earned, which matters more than the timestamp does.

The author-markup mistake we inherit most often

From our own work: when we take over a client blog, the single most common structured-data defect we find is not a missing property. It is an author that was never a person.

What we keep inheriting, in rough order of frequency:

1. author as a plain string. The CMS default user name — "Admin", "Team", "Editor" — emitted as text, not as a nested object.
2. The publication as the author. The brand name sitting in author.name while publisher says the same thing. Two fields, one entity, zero information.
3. A byline with no destination. A real human name, no url, no sameAs, and no author page anywhere on the site to point at.

What we replace it with: a nested Person object with the author's real name and a url pointing to a genuine bio page on the site. Where a piece truly has no named human author — a changelog, a data page — we use Organization deliberately, rather than letting a CMS default pretend to be a person.

The fix usually exposes a bigger gap: there is no author page to link to. Building one is the real work, and it pays off beyond markup, because named authorship is what makes thought leadership content traceable to a human. Markup only describes authority. It cannot manufacture it.

Why we do not hand-add BlogPosting on this site

Because it is already there. AIOSEO emits BlogPosting and BreadcrumbList automatically on every post on digitalhangover.in. Adding our own copy by hand produces two Article objects describing one page.

We learned that the expensive way, cleaning duplicate schema off 53 pages. So the policy is one line: on posts, BlogPosting is the plugin's job, and nobody hand-adds it.

Before you write any Article markup, check what your stack already does:

• Plugin output. Most WordPress SEO plugins emit Article or BlogPosting by default. Look before you add.
• Theme output. Some themes emit their own, which is how sites end up with three.
• What is left to add. Usually nothing on a post. Hubs, service pages and tool pages are where hand-written schema still earns its place — different types, no duplication.

If a page genuinely needs Article markup written from scratch, our schema markup generator will build the block for you, and you paste it where your setup allows.

Where to go from here

A sensible order of work, smallest effort first:

1. Audit, do not add. Confirm what your plugin and theme already emit on a post. Remove duplicates before writing anything new.
2. Fix the author object. Nested Person, real name, real url. This is the highest-value change on most blogs.
3. Make dates honest. ISO 8601 with a timezone, and dateModified only when the content moved.
4. Match the headline to the H1. Concise, and the same promise in both places.
5. Then look at the pages nobody links to. Markup cannot help a page Google has not crawled. Our note on orphan pages covers that, and a planned structure of content pillars is what keeps new posts linked from day one.

Article schema is a small, well-documented job with a low ceiling and a real floor. Done right, your title, image, dates and author are unambiguous. Done wrong, you have shipped a second opinion about your own page.