Generative engine optimization: what AI can read in 2026

Schema.org's Product type has existed since 2011, and generative engine optimization for ecommerce still begins with the same unglamorous task: making every SKU page machine-readable.

Start with the catalog.

For an AI system to mention a product in 2026, it first needs stable facts: brand, product name, GTIN or MPN, size, color, material, availability, shipping terms, return window, and images whose filenames and alt text say something more useful than IMG_4831. ChatGPT, Gemini, Perplexity, and Copilot can increasingly read structured product data when it is available, although each engine decides its own citation and answer behavior.

The appeal is obvious: one llms.txt file feels faster than fixing 5,000 messy product pages. The evidence does not support it. Google Search Central says structured data can make content eligible for search features, while the KDD 2024 GEO paper studied GPT-3.5-era answer construction, not 2026 retail retrieval across live shopping systems.

Catalog structure decides whether AI can use you

Generative engine optimization for ecommerce is mostly entity hygiene. Schema.org Product and Offer give machines a consistent way to parse a product page, while Google's structured data documentation explains the same point in plainer language.

Google Search Central is blunt: "structured data doesn't guarantee that your page will appear in search results." That line matters because it separates comprehension from demand. Veliu's job sits on the comprehension side, where better product facts make a catalog more readable, more matchable, and more buyable by AI systems.

Three fields do most of the heavy lifting:

• Unique identifiers such as GTIN, ISBN, or MPN. Without one of them, a "black leather boot" can refer to many catalogs at once.
• Variant logic that stays consistent across title, URL, schema, and visible copy. A model cannot reliably match "navy" in the title to "blue" in the spec table if the page never resolves the difference.
• Policy facts that live as text on-page, instead of staying trapped inside a cart flow. Return windows, delivery timing, and stock state often decide whether a machine can present a product confidently.

Google Merchant Center's product data specification reads dry, but it is useful GEO reading because it forces attribute discipline across 40-plus common product fields and variant rules.

A single missing identifier can pollute a whole family of products. In a catalog with 12 black boots, for example, the absence of GTIN or MPN turns model-level matching into guesswork when pages, feeds, and marketplace listings use different names.

AI visibility starts with fields ChatGPT and Gemini can parse

AI visibility in ecommerce depends on whether machines can extract the same product facts a buyer would need before purchase. ChatGPT, Gemini, Perplexity, Copilot, and AI Overviews increasingly read structured content, merchant feeds, schema.org markup, and crawlable page copy when forming answers, while final citation and answer selection remain engine decisions.

That makes the job narrower than many teams assume. GEO does not require a new brand voice for every product page; it requires fewer contradictions between the feed, the PDP, the return policy, the variant selector, and the support answers. If a sneaker page says "women's size 7" in the title, "unisex EU 38" in the schema, and "runs large" only inside a review carousel, a machine has to reconcile three different signals before it can even describe the item.

The operational stake is readability. A catalog that exposes model number, compatibility, size system, material, delivery timing, and return window gives AI engines cleaner evidence to quote or compare. A catalog that hides those details in images, session-only widgets, or expired PDFs makes the same product harder to understand.

This is the bridge.

For merchants, the implication is practical: treat AI-readable product data as infrastructure, like payment status or stock state. You cannot control how a generative engine ranks an answer, but you can control whether the facts it needs are present, aligned, and reachable.

What does generative engine optimization change in ecommerce?

The unit of competition shifts from the page alone to the product fact pattern. A classic SEO page can still win traffic with broad copy, internal links, and backlinks, but how generative engine optimization works for catalogs depends on a compact, trustworthy set of fields an AI system can quote, compare, or reconcile across sources.

That is the shift.

In ecommerce, that usually means moving important facts out of tabs, accordions, and image-only tables. It also means writing product Q&A in sentences a machine can lift with minimal repair. A 58-word answer to "Does this jacket run small?" is far more usable than a 230-word brand story that never addresses sizing.

A strong FAQ block helps here, especially when it follows Google's FAQPage guidance and mirrors actual buyer prompts such as shipping times, compatibility, care instructions, or return conditions. The goal stays narrow: make the catalog answerable for AI systems. Promotion sits outside that scope.

The same logic applies to collection pages. A category page for "ceramic nonstick pans" should explain coating type, oven-safe temperature, induction compatibility, diameter, warranty, and care constraints in plain text. Those details help machines distinguish a 10-inch induction-ready pan from a visually similar 9.5-inch model that works only on gas or electric coils.

Why do most ecommerce catalogs fail AI retrieval?

Most failures are boring, and that is useful news.

The common breakpoints show up in four places. First, merchant feeds and page content drift apart over time, so the feed says "oak" while the page says "natural wood" and the image alt text says nothing at all. Second, variants inherit one generic description, which erases the differences between sizes, bundles, or finishes. Third, policy text sits in a 2022 PDF or a cart widget. Fourth, reviews overwhelm the core specification, so the machine sees sentiment before it sees facts.

One loose thread from the opening matters here: visibility shortcuts. They stay tempting because they compress work into one file or one prompt, but catalog ambiguity does not disappear because a crawler gets a cleaner map. It disappears when the underlying attributes stop disagreeing with each other.

A useful audit checks the failure at source level. Pick 20 products with support tickets from the last 90 days, then compare the visible page, Product schema, merchant feed, support FAQ, and shipping policy. The limitation is obvious: 20 SKUs will not represent every seasonal, bundled, or marketplace-specific variant, but the sample is large enough to reveal repeated drift.

In many audits, the first fix is naming. A "Classic Crew" in Shopify, "Classic Cotton Sweatshirt" in Google Merchant Center, and "unisex fleece pullover" in a size guide can all refer to the same SKU. Machines need a stable anchor before they can use synonyms safely.

llms.txt helps governance, with limits

The llms.txt project is best understood as a documentation aid. For software companies with long docs sets, a curated text map can help a model locate canonical pages. For ecommerce, its value is narrower and more operational: point machines toward policy pages, care guides, compatibility notes, and other evergreen references that clarify a catalog.

The appeal is obvious: publish llms.txt and hope for broader inclusion. The evidence does not support it: no public 2026 replication has established llms.txt as a visibility lever for commercial answers, and Bing or Seer observations are still directional snapshots.

Use it if your documentation is sprawling. Keep schema, feeds, on-page attributes, and FAQ blocks as the primary work.

A practical llms.txt for a store might list the canonical return policy, shipping policy, product care hub, size guide, warranty page, and compatibility guide. It should avoid sending machines to stale campaign pages or duplicate blog posts that contradict current product specifications.

Evidence for GEO is still immature

Aggarwal et al. presented the GEO paper at KDD 2024 using GPT-3.5-era answer generation on a benchmark sample that predates today's shopping stacks. The paper is worth reading for one reason: it treats answer visibility as measurable. It also deserves a large caveat. The study is position-dependent, tied to 2023 model behavior, and not a 2026 replication across live retail catalogs.

That limitation should cool down grand claims.

Bing examples and Seer experiments are useful as directional evidence from named teams and dated tests, but they are not substitutes for merchant-level logging. If a team cannot trace which product fields were available on-page, in schema, and in feeds on the day a result was captured, the lesson is usually anecdotal.

The safer operating model is simple. Track coverage of identifiers, variant completeness, policy text availability, FAQ presence, and image metadata across your top catalog pages; then use GEO tools for ecommerce to compare those verifiable inputs with mentions, citations, prompts, competitors, and sentiment in AI answers. Those are inputs you can verify.

Method matters here. For a 2026 ecommerce GEO audit, define the SKU set, record the crawl date, preserve the rendered HTML, export the feed version, and save the exact AI answer or search surface that triggered the review. The named limitation is retrieval opacity: ChatGPT, Gemini, Perplexity, Copilot, and AI Overviews do not expose every source weighting decision to merchants.

That opacity does not make measurement useless. It means the cleanest KPI is input quality: what percentage of revenue-critical SKUs have valid identifiers, aligned variant names, crawlable delivery and return text, complete image metadata, and concise product Q&A.

Start with 50 SKUs this week

Begin with the 50 SKU pages that already carry the most revenue, support volume, or catalog complexity.

Then check five things, in this order:

1. The visible page, the schema, and the feed all use the same product name, brand, identifiers, and variant labels.
2. Availability, delivery timing, and return conditions appear as crawlable text on the page.
3. Images have descriptive filenames and alt text, including model, color, or compatibility where relevant.
4. Each page answers 2 or 3 real buyer questions in 40 to 70 words, with language specific enough to lift verbatim.
5. Optional files such as llms.txt point toward the canonical documentation that explains care, fit, warranty, or compatibility.

Add one owner and one date to each correction. A catalog cleanup without ownership becomes another drift source within a quarter, especially when merchandising teams change names for campaigns and operations teams change shipping promises during peak season.

We publish ongoing field notes in the Newsletter (EN).

The shortcut from the opening closes here: fix GTIN, variant labels, return text, and two product questions on your top 50 SKU pages before anyone spends another hour on visibility files.