The Core Distinction: Format vs. Vocabulary
JSON-LD is a syntax format — a way of embedding structured data into a webpage using a script tag containing linked data notation. BlogPosting Schema is a vocabulary type — a specific set of properties defined by Schema.org that describes a blog article. One is the container; the other is the content that goes inside it.
The relationship is similar to the difference between HTML and the words you put inside it. You write BlogPosting Schema using JSON-LD syntax. You can also write BlogPosting Schema using Microdata or RDFa syntax, but JSON-LD is the format Google recommends. Conflating the two is a common error that causes developers to implement one while thinking they've implemented both.
How JSON-LD Works as a Format
JSON-LD structured data lives inside a `<script type="application/ld+json">` tag placed anywhere in the HTML — typically in the `<head>` or at the bottom of `<body>`. The tag is invisible to visitors but fully readable by crawlers. The `@context` key declares the vocabulary namespace (usually schema.org), and `@type` declares what kind of thing is being described.
JSON-LD can express any Schema.org type: Product, FAQPage, BreadcrumbList, Organization, Article, BlogPosting, and hundreds more. A single page can include multiple JSON-LD blocks, each wrapped in its own script tag. The format supports nesting, so a BlogPosting can embed an Author object, which itself embeds a sameAs link to a social profile — all inside one JSON-LD block.
Because JSON-LD sits in a script tag rather than being woven into the visible HTML, developers can add or update it without touching the page's visual markup. This makes it the lowest-friction format for retrofitting structured data onto an existing ecommerce blog.
How BlogPosting Schema Works as a Vocabulary
BlogPosting is a Schema.org type that sits in the inheritance chain: Thing > CreativeWork > Article > SocialMediaPosting > BlogPosting. It inherits all properties from those parent types, which is why properties like `author`, `datePublished`, `headline`, `image`, and `publisher` are all valid on a BlogPosting even though they're technically defined higher up the chain.
The properties that matter most for Google's rich result eligibility on a BlogPosting are `headline` (under 110 characters), `image` (minimum 1200px wide recommended), `datePublished`, `dateModified`, and `author` with a nested `Person` or `Organization` type. Missing or malformed values in these fields are what typically cause a valid JSON-LD block to fail rich result qualification.
For ecommerce stores that publish editorial content — buying guides, product comparisons, how-to posts — BlogPosting Schema signals to Google that the page is a time-stamped editorial piece. This influences how Google displays the result: publication dates may appear in the snippet, and the page becomes eligible for Top Stories carousels on mobile.
Where They Overlap and Where They Diverge
Overlap: both are required simultaneously to get BlogPosting-type rich results from Google. A page with JSON-LD syntax but no Schema.org type declared (`@type` missing) gives crawlers nothing to interpret. A page with BlogPosting vocabulary written in Microdata syntax is valid but not JSON-LD. Google can read Microdata, but its own documentation consistently recommends JSON-LD as the preferred format.
Divergence: JSON-LD is format-agnostic about what it describes. The same JSON-LD tag on a product page would use `@type: Product` with entirely different properties. BlogPosting, by contrast, only describes one thing: a blog article. You cannot use BlogPosting on a category page or a product detail page without sending incorrect signals to search engines.
The practical divergence matters in ecommerce: the store's product pages need JSON-LD with Product and Offer schema; the blog pages need JSON-LD with Article or BlogPosting schema. Both use the same format syntax, but the vocabulary switches entirely based on page type. A single theme or CMS template cannot apply the same JSON-LD block to both page types.
Article vs. BlogPosting: The Sub-Comparison Ecommerce Operators Miss
Within the JSON-LD + Schema.org ecosystem, ecommerce content teams face a second comparison: Article vs. BlogPosting. Both are valid Schema.org types. Google's documentation treats them as functionally equivalent for most rich result purposes, including Top Stories eligibility. The difference is semantic: Article is broader and suits news stories, long-form editorial, and evergreen guides. BlogPosting specifically implies conversational, time-indexed blog content.
For an ecommerce brand that publishes structured buying guides or comparison posts it intends to keep updated, `@type: Article` is arguably more accurate than `@type: BlogPosting`, which carries the connotation of a dated post. Either choice produces the same structured data properties and the same Google eligibility — the decision should reflect what the content actually is, not which type sounds more SEO-friendly.
Implementation Checklist for Ecommerce Blog Pages
To implement BlogPosting Schema correctly using JSON-LD, every blog post page needs: a `<script type="application/ld+json">` tag, `@context` set to `https://schema.org`, `@type` set to `BlogPosting` (or `Article`), and populated values for `headline`, `image`, `datePublished`, `dateModified`, `author` (nested with `@type: Person` and `name`), and `publisher` (nested with `@type: Organization`, `name`, and `logo`).
Validate every implementation using Google's Rich Results Test before deploying at scale. The test will confirm whether the JSON-LD syntax is parseable and whether the BlogPosting properties meet Google's eligibility thresholds for rich results. Pay particular attention to image dimensions — submitting an image below the minimum width is the most common reason a syntactically valid BlogPosting block fails to generate a rich result.