Article Schema: What to Include (and What Google Actually Uses)

Schema.org's Article type defines dozens of possible properties. Google's own rich-result documentation uses a much smaller required and recommended list. Confusing the two — implementing everything schema.org allows, or implementing only the bare minimum Google requires — both miss the point of what Article schema is actually for. This guide covers the properties that matter, which ones Google's systems actually consume, and which are worth adding anyway for reasons beyond eligibility.

Article is the generic parent type and is always valid. NewsArticle is the correct subtype for genuinely time-sensitive news content and unlocks specific news-related rich results and Google News eligibility that generic Article doesn't. BlogPosting is the correct subtype for blog content specifically — which is what most practitioner and company blog content actually is, this article included. Using the more specific accurate subtype rather than defaulting to generic Article gives search engines more precise signal about content type, similar to the Organization-vs-LocalBusiness subtype decision covered elsewhere in this series.

Worth being precise about terminology, since it trips people up: "Article schema" refers to the schema.org type; "Article structured data" refers to the actual JSON-LD (or Microdata/RDFa) implementation of that type on a real page. The article schema type defines what properties are possible; your specific implementation decides which of those you actually populate, and how well. A page can use the correct schema type and still ship weak article structured data — a technically valid Article block with only the three Google-required fields and nothing that builds real entity connections is a common example of getting the type right and the implementation thin.

For a standard blog post specifically, BlogPosting is almost always the more accurate schema type than generic Article — a blog post is definitionally different from a news article or a static informational page, and using the more specific type costs nothing while giving search engines a clearer signal about what kind of content they're looking at.

Google's Rich Results Test flags a specific, fairly short list as required for Article rich-result eligibility: headline, image, and datePublished. Miss any of these and the page won't validate for Article rich results, regardless of how complete the rest of the schema is.

headline should match the page's actual H1 or title closely — Google has flagged mismatched headline and on-page title as a quality signal issue in the past, and it's a basic consistency check worth running manually rather than trusting automated validation alone to catch.

image needs to meet minimum resolution requirements (Google's current guidance specifies at least 1200px width) and should be an array if the page has multiple candidate images, giving Google's crawler options rather than a single fixed choice.

datePublished should be an accurate ISO 8601 timestamp, not a placeholder or a build-time value that doesn't reflect when the content actually went live.

dateModified matters more than its "recommended, not required" status suggests — it's one of the clearest signals a search engine has for content freshness, and Google has stated it uses this field when evaluating whether a page's content is current. Update it accurately whenever you meaningfully revise the article; don't touch it for trivial typo fixes, and don't fake freshness by bumping it without real changes, which is a pattern Google's guidance explicitly warns against.

author and publisher are technically recommended rather than required for Article rich results specifically, but they're the properties doing the E-E-A-T and entity-disambiguation work covered in depth in the Person and Organization schema guides in this series — reference both by @id rather than inline objects, connecting this Article into the same entity graph as the rest of the site.

description gives a concise summary independent of the meta description, useful as a distinct field a search engine or AI system can pull from directly.

mainEntityOfPage explicitly declares which page is the canonical source for this Article entity — mainly relevant when the same article content might be syndicated or mirrored elsewhere, telling Google which copy is authoritative.

articleBody and wordCount, while not required for rich-result eligibility, feed directly into the retrieval-layer mechanics covered in the AI Overviews article in this series — giving a retrieval system the actual article text and its length as structured, explicitly-labeled data rather than something it has to extract from the surrounding page markup.

Article schema markup rarely sits alone on a well-built page — it's one node in the same connected structured data graph as Organization, Person, and potentially BreadcrumbList or WebPage schema on the same URL. Treating Article schema as an isolated implementation task, disconnected from the rest of the site's structured data, is exactly the mistake covered elsewhere in this series with Person and Organization schema: the same @id and @graph pattern applies here too. An Article node's author and publisher properties are only as useful as the Person and Organization nodes they point at — thin or disconnected Article structured data on a site with otherwise strong entity data is a real, common gap worth auditing for specifically, since it's easy to build every other schema type correctly and still leave Article as an afterthought.

Sites publishing a high volume of blog post content face a specific version of this problem: templating Article schema once and applying it uniformly across every blog post is efficient, but only if the template correctly pulls per-post values (headline, image, dates, word count) from the actual content rather than falling back to defaults when a field is missing. A blog post published without a genuine cover image, for instance, needs the template to either surface a real fallback image or flag the gap — not silently render a broken or missing image property that fails Google's resolution requirement covered above. Auditing Article schema across a large blog post archive for these silent per-post gaps is a worthwhile periodic check, not just a one-time implementation task.

An article schema generator or general schema markup generator will reliably produce the three Google-required properties and often the commonly-recommended ones, since those are well documented and easy to template. What generators consistently miss: the @id-based author and publisher references (they'll produce inline objects instead, disconnected from your site's actual Person and Organization nodes), articleBody and wordCount (less commonly templated, since they require pulling actual content rather than just metadata fields), and mainEntityOfPage. Generator output is a reasonable first pass for the required fields; treat the connective and content-depth fields as a manual addition afterward.

Older Article schema guidance frequently references AMP-specific considerations, since AMP pages had their own Article rich-result eligibility rules for a period. AMP's relevance to Google Search has diminished significantly since Google decoupled Top Stories eligibility from AMP specifically — if you're implementing Article schema on a new or non-AMP site today, AMP-specific guidance in older articles can generally be ignored, but it's worth recognizing why so much existing content still mentions it.

The most common issue found in real audits: image below Google's minimum resolution requirement, which silently fails rich-result eligibility without an obvious validator error pointing at resolution specifically. Second most common: author and publisher as disconnected inline objects rather than @id references into the site's Person and Organization graph, which validates fine but forfeits the entity-disambiguation value covered throughout this series. Third: dateModified left stale or entirely absent, undercutting a freshness signal that costs nothing to maintain accurately. And on multi-author or syndicated sites, missing or incorrect mainEntityOfPage causes real confusion about which URL is the canonical source when the same article legitimately appears in more than one place.

Run the page through Google's Rich Results Test to confirm rich-result eligibility specifically, and the Schema.org validator for broader schema.org compliance. Then do the manual checks automated validation won't catch: does the headline match the on-page title, is dateModified actually accurate, do the author and publisher @id references resolve to real, complete Person and Organization nodes elsewhere on the site. Article schema's real value compounds with the rest of your entity graph — validate it as part of that graph, not as an isolated block.