Product Feed Optimization for AI Search: What Structured Data Actually Does

Most of the advice pointed at Shopify merchants right now says the same thing: add more schema, and AI assistants will start citing your products. Product feed optimization barely gets a mention. Google’s documentation contradicts that ordering in a single, prominent sentence.

That line comes from Google’s guide to optimizing for generative AI in Google Search, and the same guide immediately names the exception that matters to anyone selling something: “Using products like Merchant Center (such as Merchant Center feeds) and Google Business Profiles can help your products and services to be visible in both AI responses and other Google Search results.”

Read those two sentences together and the whole confused conversation resolves. Structured data isn’t an AI ranking input. It is a documented feed input, and the feed is a documented input to the surfaces that decide what an AI assistant shows a shopper. Product feed optimization is where the effort pays, and your on-page markup earns its keep by keeping that feed correct rather than by charming a language model.

Every number, quote, and requirement below links to the primary vendor document it came from. Where a vendor is describing its own product, we say so. We’re not going to re-caveat every paragraph or cite figures we can’t link.

This piece covers the technical half: markup, feeds, and the documented paths into AI shopping surfaces. The authority and answer-engine half, the content and citation side of the same problem, is covered in our guide to generative engine optimization for Shopify stores. You need both. This one is about the plumbing.

Google’s AI features and your website page repeats the point in three different ways. “You don’t need to create new machine readable files, AI text files, or markup to appear in these features.” “There’s also no special schema.org structured data that you need to add.” And on eligibility: “To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet.”

The same page adds “There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary.” It also describes the retrieval mechanism as a “query fan-out” technique, issuing multiple related searches across subtopics and data sources. Note the scope: that page is overwhelmingly about content pages rather than product listings, and the one piece of commerce advice it does offer isn’t about markup at all. It tells you to keep your Merchant Center and Business Profile information up to date.

The optimization guide handles llms.txt with the same bluntness. You don’t need to create machine-readable files or Markdown to appear in Google Search including its generative AI capabilities, “as Google Search itself doesn’t use them,” and creating them “will neither harm nor help your site’s visibility or rankings in Google Search, as Google Search ignores them.” No shopping surface from any vendor documents reading another site’s llms.txt file.

So what about the studies that claim schema-bearing pages get cited more? The measurement that exists comes from SEO tool vendors running their own citation-tracking products as the instrument, the published results point in opposite directions, and one of the more rigorous designs found a small negative effect. There is no primary, non-vendor evidence establishing that schema causes AI citation, which is why no citation-rate number appears anywhere in this post.

None of that means your markup is wasted. It means the mechanism people assume is the wrong one.

Here’s the mechanism Google does document. Merchant Center will build a product feed out of the structured data on your site, through the feed input method called website crawl. Google’s help page on adding products automatically from your online store breaks it into three stages: “Discovering products: We scan your website to find product pages. Extracting information: We read the structured data on those pages to understand product details like title, price, and availability. Submitting to Merchant Center: We format that information and deliver it to your Merchant Center account.”

The cadence is published on the same page: “Google checks your website at least once every 24 hours for new products.” Products already covered by another data source won’t be duplicated. Prerequisites are equally concrete: implement structured data, grant Google permission to collect it, and verify and link your website to the Merchant Center account. If the option doesn’t appear, Google tells you to check that your markup is correct, that the account isn’t suspended, and that Googlebot isn’t blocked in robots.txt.

Then comes the requirement that turns markup into a product feed optimization task rather than an SEO nicety. Google’s page on setting up structured data for Merchant Center states it flatly: “Specifying the following schema.org values is required for automatic item updates: price, priceCurrency, availability and condition.” The landing page has to contain a Product object with a nested Offer in the offers field, and Google recommends JSON-LD because it’s “distinct from any user-facing code, which makes it easier to maintain.”

Automatic item updates are the feature that stops your feed from getting disapproved when a price changes on the site before it changes in the feed. Google’s page about structured data markup for Merchant Center names the two uses directly: automatic item updates, and automated feeds via website crawl. Four schema values keep your catalog from going stale between feed pushes. That’s not decorative markup.

Google documents the rest of the chain in two hops, and both are on the record. The Shopping Graph draws on “information retailers share directly via Google Merchant Center or from what retailers and brands post across the web,” per Google’s own explainer, which describes it as an ML-powered, real-time data set of the world’s products and sellers. Google’s sources of shopping info page names the same direct-submission channels: “Brands, retailers, and other content providers send their product info directly to Google through tools like Merchant Center.”

Hop two is the AI connection. In its May 2025 Shopping and AI Mode announcement, Google said the experience “brings together Gemini capabilities with our Shopping Graph to help you browse for inspiration, think through considerations and narrow down products.” The same post put the Shopping Graph at more than 50 billion product listings, with more than 2 billion of those listings refreshed every hour.

Feed to Shopping Graph, Shopping Graph to AI Mode, both documented by Google. That’s as far as the evidence goes, and it’s further than any other AI surface has published.

What Google has never said is that a Merchant Center feed is required to appear in AI Mode. Plenty of advice asserts it as a hard rule. Google’s published language is softer and more useful: feeds “can help your products and services to be visible in both AI responses and other Google Search results.” An absent alternative isn’t a stated requirement, and product feed optimization doesn’t need the overclaim to justify itself.

There’s still a reason serious merchants run an actual feed rather than trusting the crawl. Google’s share your product data guidance lists what a Merchant Center feed buys you over markup alone: a guarantee that Google knows about all your products, because web crawling is not guaranteed; control over update timing at weekly, daily, or hourly cadence; the ability to share data that isn’t on the website at all; and eligibility for the Google Shopping tab. On conflicts between the two, Google’s advice is to let Merchant Center “automatically update its copy of your product data based on the website contents.”

That’s the honest architecture. Run the feed for coverage and control. Run the markup so the feed stays true to the page.

Shopify’s entire product structured data in the Dawn theme is one line. In Dawn’s main product section, the JSON-LD script tag contains nothing but {{ product | structured_data }}. There’s no hand-built object, no property list, and nothing for a merchant to edit inside the theme.

The structured_data Liquid filter documentation says it works on the product and article objects. Products without variants emit schema.org Product. Products with one or more variants emit ProductGroup. Articles emit Article.

Shopify publishes one example of the filter’s output, and it’s a Product. It contains @context, @id, @type, brand with a nested name, category, description, image, name, offers (with @id, @type, availability, price, priceCurrency, and url), and url. In Shopify’s own example, category and description are both empty strings.

Compare that against Google’s merchant listing requirements and the verdict is good news with a ceiling. Product requires name, image, and offers. The nested Offer requires price (which must be greater than zero for merchant listings) and priceCurrency, and it has to be an Offer rather than an AggregateOffer, with you as the seller. Shopify’s example clears every one of those. Eligibility is scoped too: “Only pages where a shopper can purchase a product are eligible for merchant listing experiences, not pages with links to other sites that sell the product.”

Clearing required is the floor, not the finish line. Google’s recommended tier is where the differentiating data lives, and that’s where Shopify’s published example stops.

Be precise about what that table proves. Shopify publishes one example, and a single example isn’t an exhaustive contract. The filter’s behavior on a product that has a barcode set is undocumented, so “not in the published example” is the claim we can support and “Shopify never outputs GTIN” is not. Run your own product URL through the Rich Results Test and read what your store actually emits.

One omission has a consequence beyond rich results. itemCondition isn’t in Shopify’s published example, and condition is one of the four schema.org values Google requires for automatic item updates. If your rendered output matches the published shape, you’re missing a quarter of the set that keeps your feed synchronized with your site.

Google’s own merchant listing example shows the fuller shape, reproduced here exactly as Google publishes it. It carries a priceValidUntil date that has since passed and a UsedCondition value on an otherwise new-looking product, which is Google’s example rather than our recommendation.

What counts as ecommerce structured data? In practice, it’s the Product, ProductGroup, Offer, Review, AggregateRating, OfferShippingDetails, and MerchantReturnPolicy types on your product pages, expressed as JSON-LD. Google’s structured data policies accept JSON-LD, Microdata, or RDFa and recommend JSON-LD, and they set the rules that get sites into trouble: don’t block structured data pages with robots.txt or noindex, don’t mark up content that isn’t visible to readers, and specify all required properties for your rich result type.

The consequence of breaking those rules is narrower than most people fear. Google’s policy page states that violations cost a page “eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.” A structured data manual action is a rich results problem, not a rankings problem.

The most useful single page for this entire exercise is Google’s supported structured data attributes and values, which maps Merchant Center feed attributes onto schema.org properties one for one. That mapping is the practical core of product feed optimization on Shopify, because it tells you exactly which markup change moves which feed column.

The sale price row is the one merchants get wrong most consistently. Your offers.price carries the current price, and the original price goes in a priceSpecification with "priceType": "https://schema.org/StrikethroughPrice", bounded by validFrom and priceValidUntil. Google’s published fragment looks like this.

You can’t mark up a price drop, though, and a lot of advice suggests otherwise. Google’s intro to Product structured data says price drops “are computed by Google by observing price changes for the product over time.” You publish an honest price consistently, and Google draws its own conclusion.

That intro page also maps the experiences your markup can qualify for: product snippets, merchant listing experiences, popular products, the shopping knowledge panel, and Google Images annotations. A product snippet is defined as “a text result that includes additional product information such as ratings, review information, price, and availability.” The useful direction of travel is stated on the same page: “adding the required product information properties for merchant listings means that your product pages can also be eligible for product snippets.” Build for merchant listings and snippets come along.

The requirement gap between the two tiers explains why a store that “has schema” still isn’t getting the richer treatment. Product snippets require only name plus at least one of review, aggregateRating, or offers, with price required on the Offer and priceCurrency merely recommended. Merchant listings require name, image, and an Offer carrying both price and priceCurrency. One property tier apart, two very different results.

Shopify puts every variant of a product on one canonical URL with a ?variant= query parameter, which is precisely Google’s documented single-page pattern for product variant structured data. In that pattern you publish one ProductGroup at the canonical URL and nest each variant under hasVariant. ProductGroup requires only name. Everything that makes it useful sits in the recommended tier: productGroupID, described by Google as the parent SKU, plus variesBy (with values like https://schema.org/size and https://schema.org/color), hasVariant, brand, description, aggregateRating, and review.

The multi-page alternative applies when each variant has its own URL. There you duplicate the full self-contained markup on every page, there’s no single canonical parent URL, and variants point back with isVariantOf and an @id reference. Google also requires each variant to carry a unique identifier such as sku or gtin, and warns that JavaScript-generated markup should account for increased crawl traffic against your server.

Shopify’s filter documentation says variant products emit ProductGroup, but it publishes no ProductGroup example. Whether Shopify’s output includes productGroupID, variesBy, or hasVariant isn’t documented anywhere we could verify, so inspect your own variant product URL rather than assuming either shape.

The identifier itself has a specific home in Shopify’s data model. GTIN lives in the barcode field on ProductVariant, described as the barcode, UPC, ISBN, or GTIN associated with the variant, exposed on the Storefront API since the 2022-01 version and readable on the Admin APIs. That’s per variant, which matches Google’s per-variant GTIN expectation exactly.

Get the identifiers right and stop there. Google’s GTIN guidance accepts values of 0, 8, 12, 13, or 14 digits, ignores spaces and dashes, allows up to 10 values per product, requires a correct GS1 check digit, and tells you to avoid restricted prefixes (02, 04, 2) and coupon prefixes (05, 98, 99). Its hardest line is the one people violate to fill a column: “Don’t submit a GTIN for a product that doesn’t have one.”

If Merchant Center flags limited performance due to missing identifiers, the documented fix is to give the product either an accurate GTIN or both an MPN and a brand, working from the Needs attention tab and the affected-products CSV. Genuinely one-of-a-kind or vintage products are exempt and get declared through the identifier-exists attribute. And a number you generated yourself isn’t a fix: Google’s rule is “Only provide a GTIN if you’re sure it’s correct. When in doubt don’t provide a GTIN (for example, don’t guess or make up a value).”

Ratings are the highest-leverage recommended property most Shopify stores skip, and the requirements are short. Per Google’s review snippet documentation, a Review requires author, itemReviewed and its name (omit when nested), and reviewRating.ratingValue. An AggregateRating requires itemReviewed, ratingValue, and, in Google’s words, “At least one of ratingCount or reviewCount is required.”

There’s a widely repeated misreading of the self-serving review policy that costs merchants ratings they’re entitled to. Google’s rule is that “if the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible.” That clause names LocalBusiness and Organization, and Product is a supported host type on the same page. Marking up customer reviews on a product page is fine. Fake reviews are not, and the policies page prohibits marking up “irrelevant or misleading content, such as fake reviews.” Reviewer names have to be valid names for a Person or Team, so a “50% off on Black Friday” author value fails.

Shipping and returns are the two properties that most directly change how a shopper reads a result. shippingDetails takes an OfferShippingDetails with a shippingRate (a MonetaryAmount with value and currency, where free shipping is a value of 0), a shippingDestination with addressCountry, and a deliveryTime split into handlingTime and transitTime as QuantitativeValue ranges with a unitCode of DAY.

Returns work the same way through hasMerchantReturnPolicy, with applicableCountry, a returnPolicyCategory of MerchantReturnFiniteReturnWindow, MerchantReturnNotPermitted, or MerchantReturnUnlimitedWindow, plus merchantReturnDays, returnMethod, returnFees, and returnShippingFeesAmount. Google recommends nesting the MerchantReturnPolicy under the Organization type when one policy covers everything you sell, overriding at product level only where a product genuinely differs. That’s a single edit to your theme layout instead of a per-product field.

Loyalty pricing is the newest layer and it’s country-limited. Google’s loyalty program documentation has you declare a MemberProgram on your OnlineStore via hasMemberProgram, with name, description, and hasTiers required, and each MemberProgramTier requiring name and hasTierBenefit. Per-offer member prices then reference a tier through validForMemberTier on a UnitPriceSpecification. Google documents availability in Australia, Brazil, Canada, France, Germany, Mexico, the UK, and the US, on desktop and mobile, and flags membershipPointsEarned as beta on the merchant listing page.

Google states this rule in three separate documents, worded three different ways, and it kills the structured-data-to-feed path outright when broken.

Google’s Merchant Center structured data setup page requires markup in HTML served by the server, not generated by JavaScript. The supported attributes page repeats it: “Structured data markup must be present in the HTML returned from the web server. The structured data markup can’t be generated with JavaScript after the page has loaded.” And the mismatched product price troubleshooting page states the consequence: “If data on your website is passed dynamically with JavaScript after the page is loaded, this will trigger an error. Prices reflected in the HTML need to match exactly the prices uploaded in Merchant Center.”

Three more conditions travel with it, all from the same setup documentation. Either the landing page has a single offer, or every offer carries a matching SKU or GTIN identifier. The page can’t change based on user data. And the structured data has to match the values shown to the customer, with Google adding elsewhere that “your landing page can’t change based on information about the customer, such as if you adapt prices based on a customer’s IP address or browser type.”

On Shopify, that list indicts a specific set of apps. Geolocation currency converters that rewrite prices client-side, discount and bundle apps that inject a promotional price into the DOM after load, subscription widgets that swap the displayed price on selection, and JavaScript variant switchers that update price without a server round trip all put your rendered price out of step with your served HTML. The markup Google reads is the markup in the response body, not the markup in your browser’s inspector.

The same conflict shows up on the availability side. Google’s mismatched product availability page states that the submitted availability value and the landing page must match, and names the common root cause as “the time difference between updates on your website and updates of your product data.” Its recommended fixes are to enable automatic item updates for frequently changing data and to schedule feed updates so they coincide with website changes. Automatic item updates, again, need price, priceCurrency, availability, and condition in your markup.

Verify with the tools Google names rather than by eye. The Rich Results Test shows which rich results a page qualifies for, and Google recommends it specifically for checking price data on landing pages. The Schema Markup Validator checks schema.org syntax without Google-specific validation, which makes it the right tool for catching malformed JSON before you debug eligibility.

Markup is half the job. The Merchant Center product data specification sets the other half, and every attribute in it is a lever. Required for every product: id (max 50 characters, ideally your SKU, kept stable across updates), title (max 150 characters), description (max 5,000 characters), link, image_link, availability, and price with an ISO 4217 currency code matching your landing page and checkout.

Two deadlines and one labeling rule sit inside that spec and are easy to miss. The minimum image size of 500 by 500 pixels starts being enforced on January 31, 2027. The certification attribute became required for EU, EFTA, and UK products needing energy efficiency labels as of April 2025, in the format EC:EPREL:code, superseding energy_efficiency_class except in Switzerland, Norway, and the UK. And AI-generated copy has to be labeled in the EU, India, and New York using structured_title and structured_description with digital_source_type set to trained_algorithmic_media, with IPTC metadata left intact on AI-generated images.

The conditionally required attributes are where most feeds bleed reach. brand is required for new products except movies, books, and sound recordings. mpn is required only when the product has no manufacturer-assigned GTIN. condition is required for used or refurbished items.

availability_date is required for preorders. item_group_id is required for variants in select countries and required outright for free listings, which is the row that quietly excludes variant catalogs from organic Shopping surfaces.

Apparel carries its own set. color, size, gender, and age_group are required for apparel in Brazil, France, Germany, Japan, the UK, and the US, with color also required whenever a product comes in multiple colors, and material and pattern required when they distinguish a variant. Feed hygiene at this level is unglamorous and it’s the largest single source of recoverable impressions we find in audits.

Then there’s the part of product feed management that most stores never touch: the optional attributes that give an AI shopping surface something to reason about. product_detail supports up to 100 specifications, product_highlight supports 2 to 100 highlights of up to 150 characters each, question_and_answer supports up to 30 pairs, additional_image_link supports up to 10 images, and video_link accepts 6 to 240 second clips at 720p minimum. Google made the intent explicit at Google Marketing Live in May 2026 with “conversational attributes,” a tool to help retailers optimize product descriptions for natural-language search.

That’s Google telling merchants, in its own product roadmap, to write feed copy for the way people talk to an assistant. Product feed optimization for AI surfaces looks less like schema tricks and more like filling in the attributes that answer a shopper’s actual question.

Shopify’s Google & YouTube channel requirements add store-level rules on top of Google’s. “If a product has a GTIN (Global Trade Item Number), then you need to add it before you can publish the product,” entered in the variant details. Products without a GTIN need an MPN and brand added in the channel.

Music, movies, and video games require a UPC, EAN, or JAN. Books require an ISBN.

Three limitations on the same page cause real incidents. Product options including variants “need to be in English to sync with Google.” Multi-client Merchant Center accounts can’t sync products through the channel. And connecting the channel overwrites existing product feeds to prevent conflicts, so a hand-built feed you rely on is gone the moment you connect.

Until recently there was no first-party answer to “how are my products doing in AI results.” There is now, for Google. AI performance insights in Merchant Center reports share of voice against competitors, classifies shopping queries into a Discovery, Evaluation, and Ready to Buy funnel, and shows the frequency of search types and which of your products appeared. Google names the surfaces it covers: AI Mode and AI Overviews.

Availability is limited and specific. The live documentation covers English-language queries for Merchant Center accounts in Australia, Canada, India, New Zealand, and the United States. Google’s own optimization advice on that page is plain: “Provide high quality data and keep your Merchant Center account updated,” and “Add the relevant search terms into your product titles and descriptions, and populate any missing attributes.”

The asymmetry is the honest takeaway. Google will tell you how your products perform on Google’s AI surfaces, from Google’s own data. No vendor publishes an equivalent for ChatGPT, Copilot, or Perplexity, and third-party AI visibility trackers are estimating from outside the system rather than reporting from inside it.

For classic Search, use the right report. Google split the old Product report into a Merchant listings report and a Product snippets report under a Shopping section in Search Console. Merchant listings covers pages where shoppers can buy. Google’s merchant listing documentation explains how the two reports relate: the Merchant listings report “includes checks for product snippets that include Offer structured data, so the Product snippets report only needs to be consulted for non-merchant listing pages.” If you sell directly, one report is your report.

Google is the only surface with a fully documented chain, but it isn’t the only one with a documented feed. Here’s what each vendor has actually published, and where the documentation stops.

OpenAI runs a product feed program with a published specification. The commerce documentation hub covers agentic checkout, delegated payment, and product feeds as three separate specifications, and states the feed’s purpose plainly: “Provide a structured product feed so ChatGPT accurately indexes and displays your products with up-to-date price and availability.” The gate is in the getting started guide: “Onboarding product feeds in ChatGPT is currently available to approved partners,” with applications through a form at chatgpt.com/merchants.

The file upload product spec publishes nine required fields, and the shape will look familiar to anyone who maintains a Google Shopping product feed.

Two practical details make this cheaper than it looks. OpenAI’s own format is JSONL, but it publishes a Google-compatible path that takes a UTF-8, tab-delimited .txt or .tsv file or a comma-delimited .csv, plus gzipped variants of all three. Your Merchant Center feed work carries over. Delivery is by SFTP per the file upload overview, with full snapshots at least daily, up to 500,000 items per shard, and target shard files under about 500MB.

Eligibility flags decide what your products can do. OpenAI states that “Search defaults to enabled and checkout to disabled. Ads defaults to disabled unless your feed has an Ads default configured,” controlled by is_eligible_search, is_eligible_checkout, and is_ads_eligible. Promotions data can only be provided via the API, and the products API spec uses a different structure again, requiring id and variants at the product level with id and title on each variant.

Search eligibility and checkout eligibility are separate switches, which matches how OpenAI documents the two integrations. The key concepts guide treats checkout as its own implementation, opening with “Supporting Instant Checkout in ChatGPT requires a merchant to implement three flows.” A feed gets your products into discovery. Transacting inside the assistant is a separate build, governed by the Agentic Commerce Protocol: maintained by OpenAI and Stripe, Apache 2.0 licensed, in beta, with a latest stable version of 2026-04-17 and changelog entries running through 2026 covering cart, feed, orders, authentication, and MCP.

Note the boundary carefully. Across every OpenAI commerce document we read, there’s no statement that ChatGPT reads on-page schema.org markup to build product results, and no statement of how products get selected or ranked. That’s an absence of published detail, not a published denial. The lever OpenAI documents is the feed.

Google’s answer to ACP is the Universal Commerce Protocol, announced on 2026-01-11 as an open-source standard for agentic commerce, developed with Shopify, Etsy, Wayfair, Target, and Walmart and endorsed by over 20 global partners including Adyen, American Express, Best Buy, Stripe, and Visa. Its first documented merchant requirement is an active Merchant Center account, which is the cleanest statement anywhere that the feed is the entry ticket to Google’s agentic stack. Google expanded it at Marketing Live in May 2026 with Universal Cart across multiple retailers, BNPL through Affirm and Klarna in Google Pay, and checkout expansion into Canada, Australia, and the UK. We go deeper on what agents transacting means for your store in our piece on agentic commerce for Shopify merchants.

Microsoft has published the single clearest sentence about how any of this works. On its agentic commerce page, Microsoft describes UCP as “a complementary layer to Merchant Center feeds that turns product data into executable commerce actions,” then draws the line: “Feeds primarily enable discovery (products showing up in AI responses), while UCP enables transactions.”

On organic results, Microsoft says “We leverage both information found on the web and from a merchant’s feed in the Microsoft Merchant Center.” Both, not either. Documented onboarding runs through Microsoft Merchant Center with a UCP-compliant feed, through payment processors including PayPal and Stripe for eligible merchants, or through Shopify, which auto-enrolled merchants with admin controls. Microsoft’s stated eligibility requirements, scoped on its page to Copilot Checkout rather than to feeds, are English-language merchants selling to US buyers in USD, meeting privacy standards and maintaining merchant-of-record status.

Microsoft’s earlier Copilot Merchant Program announcement framed the value the same way, inviting merchants to “share key product specifications with us, ensuring we have up-to-date details on all your items, so that they are suggested to customers properly.” No feed format or field list appears in it. Any specific Copilot field requirements you see circulating aren’t coming from Microsoft.

Perplexity runs a Merchant Program. Both its announcement post and its merchant program terms of service exist as live URLs, and both returned HTTP 403 to us on 2026-09-03, so we can’t verify a word of their contents.

That leaves a real gap in the record, and it’s the gap most confidently filled by advice you’ll find elsewhere. Every specific claim in circulation about Perplexity’s feed format, delivery method, identifier handling, retailer selection, and commission structure traces back to SEO vendor blogs rather than to Perplexity. We’re not repeating any of it. Perplexity has a merchant program, and it has not published requirements we were able to verify.

Here’s our position after working through every primary document above. Effort spent on markup pays in proportion to how directly it touches the feed, and effort spent on speculative AI signals pays nothing anyone can demonstrate.

The work that pays, roughly in order. First, get price, priceCurrency, availability, and condition into server-rendered JSON-LD, because those four are what Google requires for automatic item updates and they’re the difference between a synchronized catalog and a disapproval queue. Second, fill in identifiers, so sku and the correct gtin variant map onto Merchant Center’s id and gtin.

Third, add shippingDetails and hasMerchantReturnPolicy, nesting the return policy under Organization if one policy covers your catalog. Fourth, add aggregateRating and review where you genuinely have them.

Fifth, and this is where most Shopify stores have the largest untapped surface, populate the feed attributes that describe the product in a shopper’s own language: product_detail, product_highlight, question_and_answer, and richer titles and descriptions. Google is shipping conversational attributes to help with exactly this, and its documented advice for AI performance is to add relevant search terms to titles and descriptions and populate missing attributes.

The cargo cult, equally plainly. Building an llms.txt file for shopping visibility, when Google says Search ignores such files and no shopping surface documents reading them. Adding schema types with no defined rich result because “AI likes structure.” Chasing published ranking factors for AI Mode, ChatGPT, Copilot, or Perplexity, none of which exist from any vendor.

Two more belong on the list. Attempting to mark up a price drop that Google computes on its own. And adding pros and cons markup to a merchant product page, when Google restricts that appearance to editorial product review pages, “not merchant product pages or customer product reviews.”

Also on the cargo cult list: treating the feed as a setup task. Prices move, stock moves, apps get installed, and a theme update changes what your pages render. Product feed management is a recurring hygiene job with a diagnostics queue attached, and Merchant Center’s Needs attention tab is the queue.

None of this replaces a product page that converts once a shopper arrives. Discovery through an AI surface still ends on your PDP, which is where the money is won or lost, and we’ve written up the five product page tests worth running on that. If you’re working the broader question of how your brand gets surfaced and cited across assistants, our answer engine optimization approach covers the non-commerce half of the same problem.

Run your top-selling product URL through the Rich Results Test and read the extracted JSON-LD. Check whether price, priceCurrency, availability, and itemCondition are all present, and whether the price in the served HTML matches the price a shopper sees after your apps finish loading. If it doesn’t, that’s your first fix and it isn’t a schema problem.

Then open Merchant Center’s Needs attention tab and clear the identifier and mismatch issues before you add anything new. Then look at your feed’s optional attributes and ask whether a shopper’s question about that product could be answered from the data you’re sending. Then, if you’re in Australia, Canada, India, New Zealand, or the US, turn on AI performance insights and start reading the Discovery, Evaluation, and Ready to Buy funnel against the products you actually care about.

Schema markup isn’t the shortcut into AI search that it’s sold as. It’s the thing that keeps the feed honest, and the feed is the documented path. That’s a less exciting story and a far more useful one.

If your Shopify catalog is running on Dawn’s default markup and a feed nobody has audited since launch, that’s a fixable gap and usually a fast one. Our Google Shopping and Performance Max management team lives in these feeds every day. Want to know what’s actually broken before you commit to anything? Schedule a free Growth Audit and we’ll show you exactly where your product data is costing you visibility, and what it takes to close it.