AI Search Optimization (AEO) · focused work
Product schema for AI search
Assistants and generated summaries read a page's structured data before they read its prose. Product markup is where a store states, in a form nothing has to interpret, what an item is, what it costs, whether it can be bought today and who stands behind it. Most catalogs emit markup that is incomplete, printed twice by two different apps, or quietly out of date.
This is the right work if
- Two apps, or a theme and a plugin, each print their own Product block on the same page
- The price in the markup is cached and disagrees with the price shown to the shopper
- Sizes and colors are marked up as separate unrelated products with nothing connecting them
- The store wants assistants to state its stock and price correctly and has no way to check what they read
What it is
What product schema work covers
This work publishes one correct, complete and current block of Product markup for every item in the catalog, and keeps it that way. The core is a Product object with an Offer carrying price, currency, availability and condition, plus the attributes needed to match the item to a question: brand, GTIN where one exists, MPN, SKU and the fields that say what the thing is. Around it sit the objects that give the page context: BreadcrumbList, Organization, and rating objects only where genuine reviews appear on the page.
The reason it matters more for AI search than it did for rich results is that a generated answer restates facts. A summary that quotes a price takes it from a field, not from a sentence, so a stale figure in the markup becomes a wrong figure in the answer. Assistants also need to know that a size and a color belong to one item rather than three. So the job is as much governance as authoring: decide what emits the markup, make it read from the live product record, and check it after every theme change and app install.
How it is done
The work, in order
What changes
- Every page carries one block of markup, generated from the live product record
- Shopping surfaces and assistants read the same price and stock the shopper sees
- A size or color question resolves to the right item instead of a near match
- Markup breaking after an app update is caught by monitoring, not by a drop in listings
Audit what the site emits today
Crawl the catalog with JavaScript rendering on and extract every structured data block per URL. Count the blocks per page, list the fields present per template, and compare each value against what the page displays. The output is a table of templates with their gaps and their duplicates.
Choose a single source of markup
Pick one place that emits structured data, normally the theme or template, and switch off the other producers. A page with two Product blocks forces a parser to guess. Whatever remains must build its values from the live product record at render time rather than from a saved copy.
Complete the merchant listing fields
Fill the attributes a shopping result needs: name, image, description, brand, an identifier, and an Offer with price, currency, availability and condition. Add shipping details and a return policy object only where the store can state them accurately for the region the page serves.
Model variants the way the URLs work
If every size sits on one URL, describe the item as a group with its variants attached and say which attribute they vary by. If variants have their own URLs, give each one its own Product block with its own identifier and price, and link them to the parent so an assistant can tell they are one range.
Validate, then keep validating
Test one page per template in a structured data validator before release, then watch the enhancement reports in Search Console for errors appearing across the catalog. Add a scheduled crawl that compares the markup price and availability against the page and raises a flag when they diverge.
Platform notes
Shopify
Themes usually print Product markup from a snippet while review and feed apps add their own, so the first task is finding every producer; variant pricing changes with the URL parameter and the markup has to follow it.
WooCommerce
Core emits Product markup for you and SEO plugins often emit a second graph over the top, so one has to be disabled; variable products keep every variation on a single URL, which suits the grouped model.
Headless
Markup has to be rendered on the server with the page rather than injected by the browser after load, and the field values need to come from the same query that renders the visible price and stock.
Does adding structured data put a store into AI answers?
No. Markup makes a page eligible and unambiguous; it does not decide what an assistant recommends. Think of it as removing the reasons a system would skip or misread the product. The recommendation itself still depends on relevance, price, availability and how well the page explains the item.
Should reviews be marked up when they come from a review app?
Only when the reviews are real, belong to the store's own customers and are visible on the same page as the markup. A widget that reports a rating the visitor cannot see on the page is the most common cause of a structured data penalty in the review reports.
What identifier should a product carry when it has no GTIN?
Own-brand goods that were never assigned a barcode can be identified with brand plus MPN, with SKU as a supporting field. Say so consistently in both the markup and the product feed rather than inventing a code, because a fabricated identifier will match another manufacturer's item.
How often should product markup be rechecked?
After every theme release, app install and platform update, and on a schedule otherwise. Markup rarely breaks loudly. It breaks when a new app takes over the price field or a template edit drops availability, and nothing on the visible page looks any different.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.