By Ronen Abudi · Ecommerce GEO and AI-search consultant

I’ve been auditing ecommerce structured data since it became a real ranking factor, and schema markup mistakes that keep stores invisible to AI search are rarely obvious from the front end. Your product pages look fine. Google Search Console shows no crawl errors. But when you check the Rich Results Test or look at your Enhancement reports, you see warnings, missing eligibility notices, or simply nothing at all. The same patterns show up on every site I look at, and that’s what this article covers: what I actually find and what I do about it.

What AI Engines Actually Do With Your Structured Data

AI engines use structured data to surface real-time product information, and the stores they cite almost always have clean, complete schema markup. When a shopper asks an AI assistant which running shoe to buy under $150, the model doesn’t rely solely on training data. It pulls live product information, reviews, and availability, and stores with well-formed schema get cited while the rest don’t appear.

Google’s structured data documentation for Product schema defines which fields are required for rich result eligibility and which are recommended. Required means required. Missing even one, like a price or an availability value, is enough to disqualify your product from shopping rich results and AI-powered product cards. I’ve seen this happen on sites with otherwise solid technical SEO, simply because nobody connected the schema layer to the actual product data feed.

The way AI systems like Google’s AI Overviews, Perplexity, and ChatGPT shopping answers work is by building confidence in their source data. When your schema says one thing, your visible page says another, and your structured data block says a third, the system loses confidence and either skips your product or cites a competitor with cleaner signals. Schema is a trust signal, not just a formatting layer.

The Required Product Fields Most Stores Get Wrong

The core required fields for Product schema are name, image, and an Offer containing price, priceCurrency, and availability. Miss any of these and you’re immediately ineligible for Google Shopping rich results. What I see most often is stores that include a price but forget priceCurrency, or that include availability as visible text on the page but omit it from the Offer object entirely. The schema.org Product type definition spells out exactly which properties belong on which objects and in what format.

PriceCurrency deserves its own callout because the mistake is so specific and so common. You must use the ISO 4217 three-letter currency code: “USD” not “$”, “GBP” not “£”. The price value field must be a number, not a string with a currency symbol attached. I’ve found markup on live Shopify stores where the price was formatted as “$49.99” as a string, which is technically invalid and causes the Offer to fail validation without any visible error on the storefront. The Schema.org validator catches this instantly, but only if you actually run it.

Availability is another field stores routinely skip because it feels redundant when the page already shows “In Stock” in visible text. But search engines and AI engines parse schema independently of what users see. If your Offer doesn’t include schema:availability with a value like “https://schema.org/InStock”, you’re missing availability badges in Google merchant results and giving AI systems a weaker signal about whether your product is actually purchasable right now.

Category Pages and the Wrong Schema Type

One of the most consequential errors I see is applying Product schema to category or collection pages. This is extremely common on Shopify stores that use themes with schema baked into templates. The theme outputs Product schema for every page it can match to a product object, including your /collections/ pages, which display 24 or 48 products at once. Google’s guidelines are explicit: Product schema belongs on individual product detail pages. For listing pages, the correct type is ItemList.

The failure mode here is subtle. You don’t always get a manual action or even a warning in Search Console. What happens instead is a silent suppression: Google recognizes the intent mismatch between a collection page and schema claiming it represents a single Product, and simply ignores the markup. The page continues to rank where it ranks, but it earns no rich result treatment and passes no useful structured data signals to AI systems trying to understand your catalog.

ItemList schema on a category page tells search and AI engines: “This page is a curated set of items, here are their names, URLs, and positions in the list.” That’s accurate, useful information. It helps AI assistants understand the breadth of your catalog at a glance. Switching from Product to ItemList on collection pages is one of the first structural fixes I make during a full-site schema audit, and it often resolves a class of suppression issues that had no obvious cause in Search Console.

Schema Markup Mistakes That Keep Stores Invisible: Stale Data and Duplicate Scripts

Stale schema and duplicate scripts are two of the most common ways stores quietly lose rich result eligibility. Static schema is markup written once, either hardcoded into a template or injected by a plugin, and never connected to your live product database. Over time, prices change, products go out of stock, variants get discontinued, and sale events end. If your schema doesn’t reflect those changes in real time, you have a conflict between what the page shows users and what the markup tells search engines. Google has stated publicly that schema must accurately represent the content visible on the page. When it doesn’t, rich result eligibility gets revoked, quietly and without appeal.

Duplicate schema is a closely related problem and worse in practice. I regularly audit stores running two or three schema sources simultaneously: one from the theme, one injected by an SEO app, one added by a shopping feed integration. Each outputs a full Product schema block with its own price and availability values. Parsers don’t average conflicting values or pick the best one. They encounter multiple contradictory truths on the same page and typically surface no rich result at all. The fix is to audit what’s actually being output using the Google Rich Results Test and disable everything except one authoritative schema source that pulls from live product data.

The same principle applies to product variants. If your schema describes a parent product but the URL the user lands on reflects a specific variant with its own SKU, price, and stock status, the markup needs to reflect the selected variant’s data, not the parent’s defaults. Getting variants right means your schema has to be generated dynamically, server-side per variant, not templated once at the theme level.

Review Ratings, JavaScript Rendering, and the Remaining Technical Gaps

The AggregateRating gap is one of the highest-value fixes available to most ecommerce sites. I’ve audited product pages with 200 verified customer reviews visible on the page and zero structured data representing them. To implement it correctly, include an AggregateRating object in your Product schema with a numeric ratingValue, a reviewCount, and bestRating and worstRating context values. One rule you can’t skip: only mark up ratings that are actually visible to users on the page. Marking up hidden or suppressed reviews violates Google’s structured data quality guidelines and can get your rich results suspended.

JavaScript-only schema is a technical trap specific to headless and heavily client-rendered storefronts. If your JSON-LD is injected client-side after page load, Googlebot may or may not process it depending on crawl budget and the rendering queue. The safest approach is to output schema server-side so it appears in the raw HTML response. If your architecture makes that difficult, the Schema.org validator and the Google Rich Results Test both show you the rendered output, so you can confirm whether the markup is actually being parsed rather than assuming it is.

Check your URLs too. Schema properties that reference URLs, including product page URLs, image URLs, and breadcrumb items, should always be absolute rather than relative. A relative path like /products/running-shoe-v2 may resolve correctly in a browser but creates ambiguity in structured data that parsers can sometimes handle incorrectly. Using full absolute URLs is a small habit that prevents a class of subtle errors I see on roughly half the sites I work with.

Frequently Asked Questions

What are the schema markup mistakes that keep stores invisible to AI search most often?

The most common mistakes are missing required Offer fields like priceCurrency and availability, applying Product schema to category pages instead of ItemList, running duplicate schema from multiple plugins or theme scripts, and using static markup that drifts out of sync with live product data. Each issue prevents rich result eligibility and weakens the signals AI engines use to cite and recommend products.

Does Shopify’s default schema cover everything needed for rich results?

Shopify’s default schema covers the basics for individual product pages but has known gaps around variant handling, collection page types, and AggregateRating. Themes often inject schema through Liquid in ways that are hard to keep in sync with live inventory and pricing. I always recommend auditing your actual rendered output with the Rich Results Test rather than trusting the platform to handle it.

How do I check whether Google is actually parsing my schema?

Use three tools together. The Google Rich Results Test shows the rendered structured data Google sees, including validation errors and eligibility status. Search Console’s Enhancements reports track performance across your full site. The Schema.org validator checks detailed syntax and property formatting. Run all three on a sample of product pages before and after any schema change to catch problems early.

Why does schema markup matter for AI tools like Perplexity or ChatGPT?

AI search tools build product knowledge from indexed content, structured data signals, and real-time retrieval. Complete schema gives these systems explicit, machine-readable answers: what’s the price, is it in stock, how is it rated. Stores with clean markup are easier for AI to cite accurately. That’s why schema quality is central to any GEO strategy for ecommerce, not just traditional SEO.

How often should I audit my ecommerce schema markup?

Audit schema after any major platform update, theme change, or new plugin installation, since those events frequently introduce duplicate or conflicting markup. A quarterly review of your Search Console Enhancement reports catches most drift between live data and schema output. Large catalogs with frequent price changes or complex variants need continuous automated monitoring rather than periodic manual checks.

If you want to see exactly where your schema stands before making changes, I’ve put together a free ecommerce schema audit checklist you can work through on your own. If what you find points to something more involved, my structured data audit service gives you a prioritized fix list built around your specific platform and catalog.