Google's Article structured data documentation contains this sentence, twice, in two different sections: "There are no required properties; instead, add the properties that apply to your content."
That is the whole correction. Article, BlogPosting and NewsArticle have zero required properties. headline is not required. image is not required. datePublished and author are not required. All seven of the fields you have seen listed as mandatory are on Google's recommended list, and the difference between recommended and required is not pedantry. It decides whether a missing field is a bug you stop the release for or a nice-to-have you schedule.
The short answer
- Google's Article doc says "There are no required properties" in both the setup steps and the type definitions.
- Recommended:
headline,image,datePublished,dateModified,author,author.name,author.url.- Article objects must use one of three types:
Article,NewsArticle,BlogPosting.- Google's own web.dev ships Article markup with two properties and none of the rest. We checked on 15 August 2026.
- Validators report missing recommended fields as non-critical issues. Google says fixing those "isn't necessary to be eligible for rich results".
What the doc actually says
Other Google structured data pages open their setup instructions the same way: "Add the required properties." The Article page does not. It opens with:
Add as many recommended properties that apply to your web page. There are no required properties; instead, add the properties that apply to your content.
Then, further down, under Structured data type definitions, it repeats the point before listing anything:
To help Google better understand your page, include as many recommended properties that apply to your web page. There are no required properties; instead, add the properties that apply to your content.
Compare that with Product, which has a Required properties heading with name under it. Or Breadcrumb, which requires itemListElement and says a BreadcrumbList must contain at least two ListItem entries. Those types have real gates. Article does not, and the doc goes out of its way to say so.
The seven recommended properties, and what each one buys
Recommended is not the same as pointless. Each of these does a specific job, and three of them do more work than the rest.
| Property | Type | What it is for |
|---|---|---|
headline |
Text | The article title Google associates with the page |
image |
ImageObject or URL | Makes the larger-than-thumbnail treatment possible |
datePublished |
DateTime | First publication, in ISO 8601 with a timezone |
dateModified |
DateTime | Last substantive change, used for freshness |
author |
Person or Organization | The entity that wrote it, as a node not a string |
author.name |
Text | The author's name |
author.url |
URL | A page that uniquely identifies that author |
author.url is the one worth arguing about. Google describes it as "A link to a web page that uniquely identifies the author of the article. For example, the author's social media page, an 'about me' page, or a bio page." A name string is ambiguous. There are a lot of people called John Smith. A URL is a key, and it is the mechanism by which a byline becomes an entity that can accumulate a reputation across pages and sites.
dateModified is the second one that pays, and the one most likely to be a lie. It should mean the content changed. If your CMS writes today's date every time a template deploys, you are telling Google that every article on the site was revised this morning. Do not do that.
Where the "required" story comes from
Two mechanisms, both easy to check, neither of them malicious.
The first is validator output. Google's own setup instructions, which appear on every structured data page including Article, say this:
Validate your code using the Rich Results Test and fix any critical errors. Consider also fixing any non-critical issues that may be flagged in the tool, as they can help improve the quality of your structured data (however, this isn't necessary to be eligible for rich results).
Non-critical issues are what a missing image produces. They appear in a warnings list next to a yellow marker, and a warnings list looks like a requirements list if you have not read the sentence above. The parenthetical is doing all the work and almost nobody quotes it. So if a page tells you headline is required for Article, what it is describing is the Rich Results Test's warning output, not Google's documentation.
The second is generalisation. Most rich result types genuinely do have required properties, and Article is the odd one out. If you learned Product first, you carry the mental model over, and nothing in the tooling contradicts you loudly enough to notice.
Google's own site does not follow Google's recommendations
We pointed our schema validator at web.dev/articles/lcp on 15 August 2026. web.dev is a Google property and that page is Google's own reference for Largest Contentful Paint. Here is its complete Article block, verbatim:
{
"@context": "https://schema.org",
"@type": "Article",
"dateModified": "2025-09-04",
"headline": "Largest Contentful Paint (LCP)"
}
Two properties out of seven. No image, no datePublished, no author. By the popular reading of the doc, this markup is broken. By the actual doc, it is completely valid, because Article has no required properties and these are the properties that apply to the content as its owners see it.
The page also carries a BreadcrumbList where the last ListItem does include item, which is allowed. Google's doc says item is not required on the last crumb, not that it is forbidden.
Two lessons sit in that JSON. Valid does not mean complete, and complete does not mean better by default. A missing author on a documentation page maintained by a team is arguably more honest than inventing a Person node. A missing author on your blog is a gap, because your byline is the thing carrying the expertise signal.
A BlogPosting block worth shipping
This is what a post on a normal content site should emit. One @graph, nodes referencing each other by @id so the author and the publisher are entities rather than repeated strings.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "BlogPosting",
"@id": "https://example.com/blog/article-schema#article",
"mainEntityOfPage": "https://example.com/blog/article-schema",
"headline": "Article Schema Has No Required Properties in 2026",
"description": "What Google's Article documentation requires, recommends, and does not ask for.",
"image": "https://example.com/blog/article-schema/og.png",
"datePublished": "2026-08-19T09:00:00Z",
"dateModified": "2026-08-19T09:00:00Z",
"author": { "@id": "https://example.com/#adarsh" },
"publisher": { "@id": "https://example.com/#org" }
},
{
"@type": "Person",
"@id": "https://example.com/#adarsh",
"name": "Adarsh Mishra",
"url": "https://example.com/about"
},
{
"@type": "Organization",
"@id": "https://example.com/#org",
"name": "Example",
"url": "https://example.com",
"logo": "https://example.com/icon.png"
}
]
}
Four choices in there are deliberate. author points at a Person node with a url, because that is what Google recommends and what makes the byline resolvable. datePublished carries a timezone, because a bare date is ambiguous and Google's own examples include offsets. headline matches the visible H1 rather than the meta title, because markup describing content the user cannot see has always been against the general guidelines. And BlogPosting is used rather than Article, because the page is a blog post and Google accepts all three types.
Our article schema generator produces this free with no signup. The schema validator tells you which recommended fields a live page is missing.
The four ways this goes wrong in production
Ranked by how often they survive review.
author as a bare string. "author": "Adarsh Mishra" is valid schema.org and useless as an identity claim. Make it a Person node with a url.
dateModified that moves on deploy. Freshness signals only mean something if they are true. A site where every article was modified this morning is a site that has told Google its dates are noise.
headline that does not match the page. Filling it from the SEO title while the H1 says something else creates a mismatch between markup and visible content. Google's introduction to structured data is direct about it: do not "add structured data about information that is not visible to the user, even if the information is accurate".
Markup on a page with no article. Category pages, tag pages and search result pages sometimes inherit the blog template's JSON-LD. A BlogPosting node on a listing page is a false statement about the page, and it is trivially detectable.
None of these will get you penalised on their own. All of them make your markup a worse description of reality, which is the only thing markup is for. Structured data does not lift rankings, and ranking first does not mean you get cited either, which is a separate and more uncomfortable finding.
What to do next
Open one published post, view source and find the application/ld+json block. Check two things. Is author an object with a url, and does dateModified reflect a real edit? Those two fix most of the value on most sites. Everything else on the recommended list is a smaller improvement to a page Google already understands.
Then stop optimising the markup. Google's generative AI guidance says structured data isn't required for AI search and there is no special schema for it. That puts a firm ceiling on what this work returns. The harder question sits above that ceiling. Do AI answers name you at all? Our product, SEOBuilder, scans live AI answers and returns the citation URLs so you can see who got named instead of you. Seven engines on the same buyer questions, Google AI Overviews and ChatGPT included. We do not cover Grok.
The method is in how to measure AI visibility. The pricing reality of running these checks is in what SEO data actually costs. The rest of the schema picture is in the schema types that still earn something in 2026.