Ecommerce Structured Data That Earns Rich Results

Structured data has a credibility problem. Half the ecommerce sites we audit in India have schema on every template, zero rich results in Search Console, and nobody who can explain the gap. The markup validates. It just does not earn anything.

Markup is a machine readable statement of what is already on the page. Google rewards a small set of those statements with a visible result. Everything else is either infrastructure or noise. Knowing which is which saves a lot of developer time.

What each type can actually win

• Product. The container. On its own it wins nothing. It becomes useful only when it carries an offer, a rating, or both.
• Offer. Price, currency, availability. This produces the price and stock line under your result, and feeds merchant listing experiences and Shopping surfaces.
• AggregateRating. The star rating. The highest impact snippet for click-through on a crowded results page, and the one most often implemented wrongly.
• Review. Individual reviews. Feeds the same star treatment and gives AI systems quotable sentiment they can attribute to you.
• BreadcrumbList. Replaces the raw URL in your result with a readable path. Small visual gain, real structural gain, because it tells crawlers how your catalogue nests.
• Organization. No rich result of its own on most pages. It carries legal name, logo, sameAs profiles and contact details, which is raw material for a knowledge panel and for any system deciding whether you are a real company.
• FAQPage. Google deprecated FAQ rich results on 7 May 2026, and Search Console reporting for them was removed the following month. The markup is still valid schema.org and other crawlers still read it, so keeping it is defensible. Expecting a search feature from it is not.

Required versus recommended

Google splits properties into required and recommended, and the distinction is stricter than most teams treat it. Required means the item is ineligible without it. Recommended means the feature can appear with less detail, and often with less prominence.

For Product, the practical floor is name, image, and at least one of offers, review or aggregateRating. If you use offers, then price and priceCurrency are required inside it. For an Indian store that means INR and a price matching exactly what the customer sees, tax inclusive, after any displayed discount.

The recommended set is where the value hides: brand, sku, gtin, description, availability, itemCondition, shippingDetails and hasMerchantReturnPolicy. Shipping and returns fields are worth the build because they can surface as extra lines on merchant listing experiences, and because they are precisely what a shopper checks before committing.

For AggregateRating you need ratingValue plus either reviewCount or ratingCount. If your scale is not 1 to 5, declare bestRating and worstRating explicitly.

For Organization, name, url and logo are the base. Add sameAs pointing at your verified profiles, your marketplace storefronts, your LinkedIn, your Wikidata entry if one exists. Add legalName, foundingDate and a real address. This work is unglamorous and it compounds.

The validation errors we keep finding

• Rating marked up but not visible. The most common and the most dangerous. If the user cannot see the rating on the page, it is a policy violation, not an optimisation.
• Price mismatch. Markup says 1,299 rupees, the page shows 1,099 after a promotion, because schema is generated from a cached field. Google flags this and can suppress the whole item.
• Aggregate rating on a category page. Ratings belong to the product they describe. Rolling a category average into AggregateRating on a listing page is not eligible and reads as manipulative.
• Availability left as InStock on out of stock items. A fast way to lose merchant trust across the account.
• Duplicate and conflicting blocks. A plugin injects one Product block, the theme injects another, the two disagree on price. Crawlers pick one, usually not the one you wanted.
• priceValidUntil set in the past. An expired date can quietly disqualify the offer.
• A rating with no reviews behind it, or a review count of zero. Ship markup only when the underlying data exists.

Test in this order. Rich Results Test for eligibility. Schema Markup Validator for syntax. Search Console Enhancements reports for what Google actually sees at scale, which is the only one of the three reflecting your live site across thousands of URLs rather than one you chose to paste in.

The honest limits

Structured data does not improve rankings. Google has said this repeatedly and our own data agrees. It changes how your result looks and how machines understand it. Both are real advantages. Neither is the same as ranking better.

It also cannot rescue a page with nothing on it. Markup describes content. If the content is thin, the markup describes thin content accurately.

Eligibility is not entitlement either. You can be perfectly valid and still get no stars, because Google decides per query whether the feature helps the user. Teams burn weeks chasing a rich result Google has simply chosen not to show for their category. Check whether competitors in your exact vertical are getting it before you invest.

What has genuinely changed is the second audience. AI assistants and AI Overviews parse structured data as one signal among many when working out what a page is and whether to cite it. Clean Product and Organization markup does not guarantee a citation. Absent or contradictory markup makes you harder to read and easier to skip. In a channel where being named at all is the outcome, that is reason enough to keep it correct.

Practical sequence for a mid sized Indian catalogue: fix Organization once, sitewide. Fix Product and Offer on templates, not on individual pages. Add BreadcrumbList. Add AggregateRating only on products where visible reviews exist. Then leave it alone and monitor the Enhancements report monthly rather than rebuilding it every quarter.