Fill in the properties below and this markup can earn the Article rich result in Google Search.
Without these, the markup is not valid.
Match the visible headline on the page, not the meta title. Google asks only for a concise title, warning that long ones may be truncated on some devices; it publishes no character limit.
The date the article first went live, matching the date shown on the page. Google asks that you include timezone information; without it, it assumes Googlebot's timezone.
Valid without them, but you lose eligibility or detail.
BlogPosting for a blog post, NewsArticle for reported news, Article when neither fits. Google treats all three the same way; the subtype is for other consumers of your markup.
Google's floor is 50,000 pixels when you multiply width by height, and it recommends 16x9, 4x3 and 1x1 crops. Use a URL Google is allowed to crawl, so not one blocked in robots.txt.
The date of the last substantive edit. Leave it equal to datePublished if the article has never been updated.
One or two sentences summarising the article. Google does not list description among its Article properties, so treat this as useful to other consumers of the markup rather than as something Google asks for.
3 errors must be fixed before this markup will validate.
{
"@context": "https://schema.org",
"@type": "Article"
}Article markup describes a news story, blog post or long-form piece: its headline, the image that represents it, when it was published, who wrote it and who published it. Google supports it, and its documentation names Google Search and other properties, giving Google News and the Google Assistant as examples, so this is one of the schema types that still does something visible. Two things are worth knowing before you start. First, Google lists no required properties for Article at all - its documentation says to add the properties that apply to your content, and everything, headline included, is merely recommended. This tool still marks headline and date published as required, because an Article node without them tells a search engine almost nothing, but that is our judgment and not Google's rule. Second, Article markup does not get you into Top Stories: Google states there is no markup requirement for that eligibility, so the subtype you pick neither grants nor blocks it. What the markup reliably does is remove ambiguity, telling Google which line is the headline, which of several images is the lead, and which date is the publication date rather than a comment timestamp.
Tier reflects what Google actually documents for Article, not a guess at what looks thorough.
| Property | Tier | What it does |
|---|---|---|
| @type | Recommended | Article, BlogPosting or NewsArticle. Google treats all three identically; the subtype is for other consumers. |
| headline | Required | Google lists this as recommended, not required, and publishes no character limit - only that long titles may be truncated on some devices. Marked required here because the markup does little without it. |
| description | Optional | A one or two sentence summary. Not in Google's Article property table; useful to other consumers of the markup. |
| image | Recommended | The lead image, at a URL Google is allowed to crawl. Google's floor is 50,000 pixels multiplying width by height, with 16x9, 4x3 and 1x1 crops recommended. |
| datePublished | Required | ISO 8601 date, matching the date shown on the page. Recommended by Google rather than required; marked required here for the same reason as headline. |
| dateModified | Recommended | ISO 8601 date of the last substantive edit. Equal to datePublished if never updated. |
| author | Required | A Person node, not a string. Recommended by Google, and the property it reads as accountability for the piece. |
| author.name | Required | The writer's name. A named person beats the site name. |
| author.url | Recommended | A bio or profile page. Listed by Google among its recommended Article properties. |
| publisher | Optional | An Organization node for the site or masthead behind the article. Not in Google's Article property table, despite being required by the retired AMP guidance that many generators still follow. |
| publisher.name | Required | Required once a publisher node exists at all. An unnamed publisher is an empty claim. |
| publisher.logo.url | Optional | A rectangular logo reproduces better than a square avatar. Not in Google's Article property table. |
A blog post published in August 2026 and substantively updated in September, with a named author and an organisation publisher.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Bubble vs custom code: real SaaS cost over three years",
"description": "A three-year cost comparison of no-code and custom builds, using figures from four real migrations rather than list prices.",
"image": "https://example.com/images/bubble-vs-custom-cover.jpg",
"datePublished": "2026-08-12",
"dateModified": "2026-09-01",
"author": {
"@type": "Person",
"name": "Pratik Talati",
"url": "https://example.com/authors/pratik-talati"
},
"publisher": {
"@type": "Organization",
"name": "BrainFeed Solutions",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
}
}Two structural points. author is a Person node rather than the bare string hand-written markup often uses, which is what Google asks for: Person for people, Organization for organisations. And publisher.logo is an object with a url inside it rather than a bare URL string, because schema.org types logo as an ImageObject.
headline must match the headline a reader sees on the page. SEO plugins often fill it from the meta title instead, which is written for the SERP and frequently differs. Google asks for a concise title and warns that long ones may be truncated on some devices, but it publishes no character limit, so ignore any tool quoting you a hard number.
author should be a Person node with a name, and ideally a url pointing at a bio page. A bare string parses, but it gives Google nothing to connect to. Naming the company as author on every post throws away the one property in this markup that is explicitly about who is accountable for the content.
Refreshing the date on unchanged content is a well-worn trick, and it makes your markup a claim you cannot back up. Google publishes no promise that it takes the date at face value, so treat dateModified as a description of what you actually did: update it when you edit substantively, not on a schedule. Google does ask that you include timezone information, since it otherwise assumes Googlebot's timezone.
If you include a publisher logo at all, it has to be an object with a url inside it rather than a bare URL string, because schema.org types logo as an ImageObject. A flat string parses as JSON and means something different from what you intended. Google does not list publisher.logo for Article, so this costs you nothing with Google either way; it matters to everything else reading the markup.
If Yoast, Rank Math or your theme already emits Article markup, adding a second block gives Google two competing descriptions of the same page. Check the page source before you paste. One correct node beats one correct node plus one stale one.
Google states there is no markup requirement to be eligible for Google News features like Top Stories. Changing the subtype on a marketing blog therefore buys you nothing: markup is not the lever that decides whether you appear there.
Paste the script tag into the article page, inside <head> or anywhere in <body>. It has to be on the article's own URL: markup for a post placed on the blog index describes the index, not the post.
Yoast and Rank Math already output Article markup on posts, so check your page source for an existing Article node first and edit that plugin's settings rather than adding a second one. If nothing is emitting it, a Custom HTML block at the end of the post works, or hook it into wp_head behind an is_single() check.
Blog posts render through templates/article.liquid or the main-article section. Add the tag there so every post gets its own node, populating the values from article.title, article.published_at and article.author rather than hard-coding one post's details.
Want this markup built into your site and kept correct as it changes, rather than pasted in by hand? See how we handle that.
Want more of this? Read more engineering decisions like this one.
Get a free audit of your site's technical SEO, structured data and performance.