You’re adding JSON-LD schema to your blog post. You open the Schema.org documentation and find two options that seem almost identical: Article and BlogPosting. Both describe written content. Both have the same fields. So which one should you use?

The short answer: it depends on the content type. The longer answer matters more than most people realize.

What Schema.org says

In Schema.org’s hierarchy, BlogPosting is a subtype of Article. Specifically:

Thing > CreativeWork > Article > SocialMediaPosting > BlogPosting

This means every BlogPosting is technically an Article, but not every Article is a BlogPosting. The relationship is like squares and rectangles: all squares are rectangles, but not all rectangles are squares.

Article is the generic type for any written content: news articles, opinion pieces, research papers, magazine features, reports, and yes, blog posts.

BlogPosting is specifically designed for posts published on a blog. It carries the implicit context of a blog: chronological publishing, personal or brand voice, ongoing series of posts on a website.

How LLMs interpret the difference

In practice, most LLMs treat Article and BlogPosting very similarly. Both contain the same core fields (headline, author, datePublished, description) and both are extracted the same way.

The difference is subtle but real: the schema type acts as a content classification signal. When a model encounters BlogPosting, it knows this is part of a blog, likely opinionated or educational, published as part of an ongoing series. When it encounters Article, the model has less context about the content’s nature.

For citation purposes, this classification can influence how the model attributes the source. A BlogPosting might be cited as “according to [Author]‘s blog” while an Article might be cited as “according to [Publication].” The distinction is small but affects perceived authority in the response.

When to use Article

Use the Article type for:

News content. If you’re a news publication or publishing time-sensitive reporting, Article is the appropriate type. BlogPosting would misrepresent the content.

Research and whitepapers. Formal, authoritative content that isn’t part of a blog. Reports, case studies, and technical documentation fit Article better.

Guest contributions. Content published on your site by external authors that doesn’t fit the “blog” format.

Corporate content. Press releases, company announcements, and institutional publications. These aren’t blog posts even if they’re published chronologically.

Pillar pages. Comprehensive, evergreen resource pages that serve as reference material rather than timestamped commentary.

For more specific news content, consider NewsArticle (a subtype of Article) which signals breaking or timely reporting.

When to use BlogPosting

Use BlogPosting for:

Blog posts. The obvious case. If it lives on a /blog/ section and is published as part of a series of posts, it’s a BlogPosting.

Opinion pieces on your blog. Personal takes, hot takes, commentary, and analysis published under your blog.

How-to guides on your blog. Tutorials and step-by-step guides that are part of your blog’s content stream.

Product updates published as blog posts. Changelogs, feature announcements, and release notes that appear on your blog.

The key indicator: if you’d describe the content to someone as “a blog post about X,” use BlogPosting.

What about other subtypes?

Schema.org offers several Article subtypes beyond BlogPosting:

NewsArticle - For news reporting. Signals timely, factual content. Google uses this for its News features.

TechArticle - For technical content with a specific audience. Includes a proficiencyLevel field. Rarely used but semantically precise for developer documentation.

ScholarlyArticle - For academic papers. Rarely appropriate for commercial websites.

Report - For formal reports and studies. A better fit than Article for whitepapers and research documents.

In practice, Article and BlogPosting cover 95% of use cases. The other subtypes are worth knowing about but only necessary if your content genuinely fits their specific definitions.

The practical recommendation

For most websites with a blog, the strategy is simple:

Blog posts → BlogPosting. Every post on your /blog/ gets BlogPosting schema. This is semantically accurate and gives AI systems the most specific type information available.

Everything else → Article. Landing pages, resource pages, guides that aren’t part of the blog, corporate content. Article is the safe, correct choice.

Don’t overthink it. Both types work. Both get extracted. Both support the same fields. Using Article on a blog post is not wrong; it’s just less specific. Using BlogPosting on a non-blog page is technically incorrect but won’t cause serious problems.

What matters more than the type

Whichever type you choose, the fields you fill matter far more than the type itself. A BlogPosting with complete metadata (headline, author with URL, datePublished, dateModified, image, description, publisher) will dramatically outperform an Article with only a headline.

Focus on completeness:

• headline - matches the H1 and title tag
• author - includes name and URL (LinkedIn or author page)
• datePublished and dateModified - both present, both accurate
• image - the hero/featured image URL
• description - 1-2 sentence summary
• publisher - organization name and logo

Generate complete schema for either type with the hey-eye JSON-LD generator and verify it’s detected correctly by running your page through hey-eye.

The type is the label. The fields are the content. Get both right, but prioritize the fields.