Magento 2 emits product structured data as inline microdata in the page HTML rather than JSON-LD, and it commonly omits fields Google treats as required, including offers.availability and priceValidUntil. The fix is to emit JSON-LD from a single controlled source. A Hyvä migration is the natural moment to do it, because the template changes break the inline markup anyway.
Structured data has quietly become more important than it was five years ago. It is no longer only about star ratings in a search result. It is the machine-readable version of your catalog that both search engines and AI answer engines read when deciding what your product is, what it costs, and whether it is in stock. Getting it wrong means being invisible in exactly the surfaces that are growing.
What Magento gives you by default, and why it disappoints
Magento 2 ships some structured data. The problem is its form and its completeness.
It is microdata, not JSON-LD. The default output uses itemscope and itemprop attributes woven through the visible HTML. That format is valid, and Google still reads it, but it has three practical drawbacks. It is fragile, because any template change can sever an attribute from its parent scope. It is hard to audit, because the markup is scattered across templates rather than sitting in one readable block. And it is harder for crawlers that expect a clean JSON payload in the head.
It is incomplete. The fields teams most often find missing or malformed are offers.availability, priceValidUntil, and aggregateRating. Each of these produces a warning or an outright ineligibility in testing. A product page missing availability is the most consequential, because availability is central to whether a page qualifies as a merchant listing at all.
It breaks on theme changes. This is the one that catches Hyvä migrations. Because the markup lives inside the templates, replacing the frontend replaces the markup. Teams that migrate to Hyvä without auditing structured data can lose rich results and not notice for weeks, since nothing on the page looks wrong.
The distinction most implementations miss
Google documents two different classes of product structured data, and conflating them is the most common strategic error.
| Product snippets | Merchant listings | |
|---|---|---|
| For pages where | The product cannot be bought directly | The product can be bought |
| Typical use | Editorial reviews, roundups, comparisons | Product detail pages on your store |
| Strengths | Review detail, pros and cons | Price, availability, shipping, returns, variants, sizing |
| What you should target | Only for non-transactional content | Every product detail page |
Per Google’s merchant listing documentation, merchant listings support the detailed commercial properties that matter to a shopper comparing options: shipping cost, return policy, apparel sizing, and product variants. Google’s product structured data guidance also makes a useful point that removes a lot of agonising: the two overlap, and supplying the properties required for merchant listings makes your pages eligible for product snippets too. So the practical advice is to emit rich merchant listing data and stop worrying about which bucket you are in.
What to actually emit
Work from the schema.org Product type and treat these as your baseline on a product detail page.
Product level. name, image (multiple, high resolution), description, sku, brand, and a stable identifier such as gtin or mpn where you have one. Identifiers matter more than most merchants assume, because they let engines match your listing to the same product elsewhere.
Offer level. price, priceCurrency, availability, priceValidUntil, url, and itemCondition. Availability is the field to get right first. It must reflect actual stock state and it must update when stock changes, which means it cannot be hardcoded or cached indefinitely.
Ratings and reviews. aggregateRating with a genuine ratingValue and reviewCount, plus individual review entries where you have them. Only emit this if the ratings are real and visible on the page. Marking up ratings that a user cannot see is a policy violation, not a clever trick.
Shipping and returns. These are increasingly the differentiators in a merchant listing, and most Magento stores omit them entirely.
Variants. If you sell configurable products, model the variant relationship properly rather than emitting a single ambiguous product.
Beyond the product page, two more types earn their keep. Breadcrumb markup helps engines understand your category structure, and Magento handles this reasonably by default. FAQ markup on content pages gives you a direct route into answer surfaces, which is why we structure our own articles with an explicit question and answer section.
Doing it properly on a Hyvä frontend
A Hyvä migration is the right moment to fix this, for a reason that is more opportunity than risk.
Because Hyvä replaces the templates, the inline microdata goes with them. That forces the question rather than letting it drift. Instead of reproducing scattered microdata in a new theme, emit a single JSON-LD block from one place. The advantages are concrete: the payload is readable in one view, it is testable in isolation, a designer changing markup cannot break it, and adding a field later is one change rather than a hunt through templates.
Two cautions specific to Hyvä and to Magento generally.
Caching. Structured data containing price and availability must not be served from a stale full page cache. This is the same class of problem as showing customer-specific pricing on a cached page, and the same techniques apply. We covered the mechanics in showing live ERP pricing and stock on a Hyvä storefront.
Migration parity. Add structured data to your migration acceptance criteria explicitly. It belongs on the same checklist as URL structure and metadata, and it is routinely forgotten. Our Luma to Hyvä migration checklist treats data-layer and SEO parity as a gate rather than a nice-to-have.
Why this matters more for AI answers than for star ratings
The traditional argument for structured data was the rich result: stars, price, and stock shown under a blue link. That is still worth having, but it undersells the current situation.
AI answer engines are assembling responses about products, and they need to resolve three things quickly: what this item is, what it costs, and whether it can be bought. A page that states those facts in clean, machine-readable JSON is easier to quote confidently than one where the same facts are inferred from rendered HTML. Ambiguity does not usually produce a wrong answer. It produces no answer, because the engine cites a source it can parse instead.
This is also where product identifiers earn their place. A gtin or mpn lets an engine match your listing to the same product described elsewhere, which is how you end up in a comparison rather than being treated as an unrelated page. Merchants who omit identifiers are effectively asking to be evaluated in isolation.
The practical implication is a shift in priority. If you have limited engineering time, completeness and accuracy of the commercial fields beat breadth of schema types. One product page with correct price, availability, identifiers, shipping, and returns is worth more than five schema types each half-populated.
Testing, and what “valid” actually means
Run every template type through Google’s Rich Results Test: product detail, category, CMS page, and your article template. Then watch the structured data reports in Search Console over the following weeks, because the test tells you a page is parseable while Search Console tells you what is happening at scale.
Be precise about the difference between three states. Markup can be valid and still be useless, if it is missing recommended fields that make it competitive. It can be eligible and still not appear, since rich results are never guaranteed. And it can be accurate today and wrong tomorrow, which is the failure mode that matters most, because availability and price change constantly. Monitoring beats a one-time validation pass.
The most common real-world failure we see is not invalid syntax. It is markup that is technically correct and semantically stale: a price that no longer matches, an availability value frozen at InStock, or an aggregateRating left over from a review extension that was uninstalled a year ago.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner. We treat structured data as part of the build rather than an SEO afterthought bolted on later, because the durable version of it is emitted from the application, not injected by a tag manager.
Our Hyvä development services cover emitting clean JSON-LD as part of a frontend build, and our Magento and Adobe Commerce development practice covers the catalog and caching work that keeps it accurate under load. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and the review, search, and feed tools that feed your markup come from our technology partner ecosystem.
More about the team is on the about Bemeir page, or start a conversation from the Bemeir homepage.
Frequently asked questions
Does Magento 2 have structured data built in?
Partly. Magento 2 outputs some structured data, including breadcrumbs and basic product information, but it does so as inline microdata using itemscope and itemprop attributes rather than JSON-LD, and it commonly omits fields Google expects, notably offers.availability and priceValidUntil. Most stores that rely on the default output do not qualify for the richer merchant listing treatment.
Should I use JSON-LD or microdata on Magento?
JSON-LD. It sits in a script tag in the page head, separate from the visible HTML, so template and design changes cannot silently break it. It is also far easier to audit, because the entire payload is readable in one block rather than scattered across templates. Google reads both formats, but JSON-LD is the more maintainable choice and is what we implement on new builds.
Will migrating to Hyvä break my structured data?
It can, and this is a real risk worth planning for. Because Magento’s default markup is woven into the templates as microdata, replacing the frontend replaces the markup. Nothing looks broken on the page, so teams often do not notice until rich results disappear. Put structured data parity on your migration acceptance criteria alongside URL structure and metadata.
What is the difference between a product snippet and a merchant listing?
Product snippets are for pages where the product cannot be purchased directly, such as editorial reviews, and they offer richer review handling including pros and cons. Merchant listings are for pages where a shopper can buy, and they support price, availability, shipping cost, return policy, sizing, and variants. Supplying the properties required for merchant listings also makes your pages eligible for product snippets, so on a store you should target merchant listings.
Which structured data field is most often missing on Magento stores?
offers.availability. It is the field most likely to make a product page ineligible, and it is also the one most likely to go stale, because it has to reflect live stock state rather than a cached value set at deploy time. priceValidUntil and a properly sourced aggregateRating are the next two most common gaps.
