Product structured data: the step-by-step guide to auditing JSON-LD in Search Console

Product structured data: the step-by-step guide to auditing JSON-LD in Search Console

Editor's note: this article describes specific Search Console interface behaviors (segmentation of the Enhancements reports, update latency of the aggregated report) and Rich Results Test behaviors (indication of which properties were read) based on the author's practical experience. These claims aren't documented in the official source consulted, which covers only the concept of Product structured data, and they may vary or change without notice. The conceptual content about schema (snippets vs. merchant listings, the overlap between them, the Organization block, and the use of feed data) was checked and matches Google's official documentation.

Google's Product structured data documentation lists the fields that determine whether a product page appears in rich results and in Shopping, but a large share of Brazilian e-commerces still publish incomplete JSON-LD. Here's how to audit, fix, and revalidate it in Search Console.

Google Search Central's official documentation on Product structured data (updated on December 10, 2025) separates two markup paths: product snippets, for pages that don't sell directly, and merchant listing data, for those who sell. The two overlap: filling in the merchant attributes usually qualifies the page for snippets as well. In practice, this means that anyone who only marks up the basics (name, image, price) is leaving eligibility on the table, both in the Shopping card and in the search experiences that read the same structured source.

The problem isn't new to schema: it's maintenance neglect. The catalog grows, a review field disappears in a redesign, the Merchant Center feed diverges from the page's JSON-LD, and no one notices until the product drops off the shopping card. This step-by-step is the path I'd follow to find and close those gaps using only Search Console and Google's own tools.

What's minimum and what's a bonus

The documentation's introductory page doesn't settle on a single list of 'minimum fields' per markup; that level of detail lives on the specific requirements pages for each type, which aren't part of the source consulted here. In implementation practice, though, the summary below reflects the common market recommendation for what tends to block eligibility and what is optional enrichment:

Shipping (shippingDetails), price drop, and pros/cons (positiveNotes/negativeNotes inside review) are enhancements: they improve how the result looks, but their absence doesn't bring down basic eligibility. Confusing the two types of fields is the most common mistake I see in e-commerce audits.

Step 1: start with the report Google already gives you

In Search Console, open the Enhancements reports for product snippets and merchant listings. In my auditing experience, this type of report tends to segment items by status and by problem type, which helps locate the affected URLs faster; it's worth checking directly in the dashboard how the categorization appears in your case, since this specific behavior isn't documented on the Product structured data page consulted here.

This report is aggregated and can take days to reflect a recent fix, but it's the cheapest starting point: it tends to segment the problem by the type of missing field, without you having to scan the entire catalog manually.

Step 2: check the JSON-LD line by line

For each URL pattern found in step 1, run the Rich Results Test (search.google.com/test/rich-results) with the page's real URL. In my experience, the tool tends to indicate which properties of @type: Product were read and which were left out, which helps locate the problematic field, although this specific behavior isn't described in the official documentation consulted here.

A complete Product block for merchant listing data usually looks like this:

{
 "@context": "https://schema.org/",
 "@type": "Product",
 "name": "Tênis Trail Runner X",
 "image": "https://exemplo.com.br/img/tenis-x.jpg",
 "description": "Tênis de corrida para trilha, solado em EVA.",
 "sku": "TRX-42-PT",
 "brand": { "@type": "Brand", "name": "Marca Exemplo" },
 "offers": {
 "@type": "Offer",
 "price": "399.90",
 "priceCurrency": "BRL",
 "availability": "https://schema.org/InStock",
 "priceValidUntil": "2026-12-31",
 "shippingDetails": {
 "@type": "OfferShippingDetails",
 "shippingRate": { "@type": "MonetaryAmount", "value": "0", "currency": "BRL" }
 }
 },
 "aggregateRating": {
 "@type": "AggregateRating",
 "ratingValue": "4.6",
 "reviewCount": "128"
 }
}

If the test shows that aggregateRating or offers.priceCurrency wasn't read, the problem is usually syntactic: a missing comma, the wrong @type inside the nested object, or the application/ld+json script pointing to a different page than the one tested (common in templates with aggressive caching).

Step 3: don't forget the Organization schema

Return policy and loyalty program don't live inside Product: they live in a separate Organization block, with hasMerchantReturnPolicy and, when applicable, a MemberProgram. A perfect product page without that block still won't show the return badge in the Shopping card. It's worth auditing the footer or header template where this JSON-LD is usually centralized, because it's easy to forget when the team only looks at the product page.

Step 4: fix, publish, and request reindexing

After adjusting the JSON-LD:

1. Push the fix to production.
2. Run the Rich Results Test again on the already-published URL to confirm that all fields show as valid.
3. Use the URL Inspection tool in Search Console to check the page's status and, if the feature is available in your account, request reindexing in an attempt to speed up the recrawl of that specific page.
4. If the e-commerce also uses a Merchant Center feed, check whether the feed's price and availability match the page's JSON-LD: according to the documentation, Google may use pricing data from the feed when it's absent from the schema, so keeping both sources aligned helps avoid inconsistencies that could hurt the quality of the data displayed.

What can go wrong

In short: the fix in the code is rarely the point that fails; the delay is in what comes after it. Some recurring stumbling blocks:

• The page has noindex or is blocked in robots.txt: no structured data is read, no matter how correct the JSON-LD is.
• The CDN or page cache serves the old version for hours after deployment, so the Rich Results Test appears to fail even though the code is already correct.
• Search Console's aggregated report takes a while to update: per-URL spot validation is more reliable in the short term than waiting for the overall dashboard's number to change.
• Large catalogs fix the template, but older products generated by static snapshot keep serving the old JSON-LD until the next build.

How to measure whether it worked

The most direct signal is the Enhancements report itself counting that item as valid again, no longer as an error. For the effect on traffic, compare clicks and impressions for that group of URLs in the Search Console's Performance report in the weeks before and after the fix.

One caveat is worth noting: Google's documentation doesn't name AI Overviews as direct consumers of this schema. But since those surfaces and Shopping tend to rely on the same structured content signals from the page, it's reasonable to assume, in my reading, that a complete Product JSON-LD helps the page be read with more confidence by any layer that synthesizes a result, generative or not. That's an inference, not a guarantee documented by the source.

Source 1: Google Search Central — Product structured data (https://developers.google.com/search/docs/appearance/structured-data/product)

Intro to Product Structured Data on Google | Google Search Central | Documentation | Google for Developers

Skip to main content

Search Central

English

Deutsch

Español

Español – América Latina

Français

Indonesia

Italiano

Polski

Português – Brasil

Tiếng Việt

Türkçe

Русский

العربيّة

हिंदी

ภาษาไทย

中文 – 简体

中文 – 繁體

日本語

한국어

Sign in

Documentation

Search Console

Home

Send feedback

Introduction to Product structured data

When you add structured data to your product pages, your product information can appear in richer ways in Google Search results (including Google Images and Google Lens ). For example, users can see price, availability, review ratings, shipping information, and more right in search results.

Deciding which markup to use

There are two main classes of product structured data. Follow the requirements for the type that best suits your use case:

Product snippets : For product pages where people can't directly purchase the product. This markup has more options for specifying review information, like pros and cons on an editorial product review page.

Merchant listings : For pages where customers can purchase products from you. This markup has more options for specifying detailed product information, like apparel sizing , shipping details , and return policy information.

Note that there is some overlap between the two product features. In general, adding the required product information properties for merchant listings means that your product pages can also be eligible for product snippets. Both features have their own enhancements, so be sure to review both when deciding which markup makes sense in the context of your site (the more properties you can add, the more enhancements your page can be eligible for).

In addition to structured data for the individual products that you sell, we also recommend you add structured data defining the policies of your ecommerce business, nested under Organization markup:

Merchant return policy : Specify the return policy (or policies) for your business.

Loyalty Program : Specify the loyalty program that you offer.

How shopping experiences can appear on Google Search

Here's how shopping experiences can appear in Google Search results. This list is not exhaustive—Google Search is constantly exploring new and better ways to help people find what they're looking for, and the experiences may change over time.

Product snippet

A text result that includes additional product information such as ratings, review information, price, and availability

Popular products

Visually rich presentation of products for sale

Shopping knowledge panel

Detailed product information with a list of sellers (using details such as product identifiers)

Google Images

Annotated images of products available for sale

Result enhancements

Search result enhancements are shown at the discretion of each experience, and may change over time. For this reason, it is recommended to provide as much rich product information as available, without concern for the exact experiences that will use it. Here are some examples of how product rich results may be enhanced:

Ratings : Enhance the appearance of your search result by providing customer reviews and ratings .

Pros and Cons : Identify pros and cons in your product review description so they can be highlighted in search results.

Shipping : Share shipping costs , especially free shipping, so shoppers understand the total cost.

Availability : Provide availability data to help customers know when you have a product in stock.

Price drop : Price drops are computed by Google by observing price changes for the product over time. Price drops are not guaranteed to be shown.

Returns : Share return information , such as your return policy, fees involved in returns, and how many days customers have to return a product.

Providing product data to Google Search

To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both. The Search Central documentation focuses on structured data on web pages.

Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data. Some experiences combine data from structured data and Google Merchant Center feeds if both are available. For example, product snippets may use pricing data from your merchant feed if it's not present in the structured data on the page. The Google Merchant Center feed documentation includes additional recommendations and requirements for feed attributes.

In addition to Google Search, learn more about eligibility to the Google Shopping tab by reading the data and eligibility requirements in Google Merchant Center .

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-12-10 UTC.