Article Schema vs BlogPosting Schema: Does It Matter for SEO?
Pick the wrong schema type and your structured data will still validate, still pass Google's Rich Results Test, and probably still earn the same rich results as before. So why does the question keep coming up? Because it sounds like it should matter. Article schema and BlogPosting schema share almost every property, yet developers and content teams treat the choice as though it shifts rankings. This guide cuts through that assumption and explains what the distinction actually does, where it genuinely changes things, and how to choose without overthinking it.
On this page
- BlogPosting is a subtype of Article and inherits all the same properties.
- The schema type label is not a ranking lever for search results.
- Fields like headline, author, and dateModified matter more than the type chosen.
- Use BlogPosting for dated posts and Article for evergreen reference content.
Last updated
The relationship between Article and BlogPosting
Schema.org is built as a hierarchy of types. Article sits near the top of the content branch, broad enough to cover news pieces, feature writing, how-to guides and opinion columns. BlogPosting is a direct child of Article, meaning it inherits every property its parent defines and adds one narrower claim, this piece of writing lives in a blog, published in date order, usually under a single author’s name.
Because BlogPosting extends Article, there is no property available to one that the other cannot use. headline, author, datePublished, image, publisher, all of these behave identically on both types. The schema type label is a declaration about what the content is, not a switch that unlocks different fields.
What the hierarchy actually tells a parser
When a search engine reads your JSON-LD, the type declaration comes first. Saying BlogPosting signals that the content is a dated, chronological post from a blog feed. Saying Article signals something written and published editorially, without necessarily implying that date-order context. Neither declaration changes what the parser does with your field values, it just frames them slightly differently before processing begins.
Think of it like labelling a folder. The contents are identical; the label tells whoever opens it what they should expect to find inside.
Does Google treat them differently?
Google’s structured data documentation groups Article, BlogPosting, NewsArticle and several sibling types together under a single set of rich result guidelines. The eligibility rules, author byline in search results, headline snippet, thumbnail image, apply equally to all of them. Google does not publicly document a ranking advantage for one type over another, and there is no evidence in Google’s own published guidance that swapping between the two moves a page up or down in results.
What does affect rich result eligibility is whether required fields are filled in accurately and completely. A BlogPosting with a missing author field will be less useful to Google than an Article with every recommended field populated correctly. The type label matters far less than the quality of the data inside it.
Where a mismatch creates a real problem
Using Article on a page that is clearly a dated blog post is not going to trigger a manual action. However, structured data is supposed to reduce ambiguity, not introduce it. If the type declaration conflicts with what the page actually is, you are adding a layer of imprecision to markup that exists specifically to remove guesswork. It probably causes no measurable harm today, but “probably no harm” is not the same as “correct”.
The cleaner approach is to match the type to the content. A technical guide with no author byline and no publish date visible to readers is better served by Article. A personal post in a blog feed, dated and attributed to one person, belongs as BlogPosting. Accuracy in structured data is a habit worth building regardless of whether Google penalises inaccuracy right now.
How to choose the right type
The decision does not need to be complicated. Start with what the page actually looks like to a reader.
- The page lives in a blog feed ordered by publish date, has a visible date, and is attributed to one author. Use
BlogPosting. - The page is a guide, resource, or editorial piece without a chronological context. Use
Article. - The page is primarily news reporting with time-sensitive information. Consider
NewsArticle, which is another child ofArticleand the type Google specifically names for news content.
If you run a WordPress site and your schema is generated by a plugin, check what it outputs by default. Most plugins apply Article to all post types and leave BlogPosting as an option you select manually. Neither default is wrong, but knowing what your site actually declares helps you audit it sensibly.
The fields that genuinely move the needle
Regardless of which type you choose, the structured data properties below are the ones Google actually uses to generate rich results and assess content quality signals.
headline, keep it under 110 characters and match the visible page titleauthor, use aPersonorOrganisationtype with anameand, where possible, aurldatePublishedanddateModified, ISO 8601 format, accurate to the dayimage, at least one high-resolution image object; Google recommends 1200px wide minimum for rich resultspublisher, anOrganisationtype with alogoproperty
Get those right and the type label becomes a secondary concern. Leave them incomplete and no amount of type-fussing will compensate.
AI search and structured data signals
Search is shifting. AI-powered results from Google, Bing and large language models read structured data not just for rich result eligibility but to understand entity relationships on a page. Author entities, publication dates and content type declarations all feed into how a piece of content gets represented in AI-generated summaries and cited in model outputs.
This is where getting your schema accurate starts to carry more weight than it used to. A content team we work with found this out directly when building out entity-level markup for a publishing client, vague or mismatched type declarations made it harder for models to confidently attribute authorship and content category. A common issue we see is schema that validates cleanly but describes the page loosely, which is fine when results are link-based and less fine when an AI is deciding whether to surface and cite a specific piece of writing.
Accuracy in structured data is no longer just a technical hygiene task. It is part of how content gets understood beyond the traditional blue-link result.
One practical check worth doing now
Open Google’s Rich Results Test on a few of your key pages and look at the type being declared. Then check whether the type matches what a reader would actually call that page. If you have guides marked as BlogPosting or blog posts marked as Article for no particular reason, correct them. It takes minutes per page and removes an unnecessary layer of ambiguity from your markup.
After that, run the same pages through Google Search Console’s Enhancements report. Any structured data warnings there will tell you far more about what is affecting your rich result eligibility than a debate over Article versus BlogPosting ever could.