How GEO works: make catalogs readable by AI

How does generative engine optimizationGEO is the practice of making your content and catalog data easy for generative engines like ChatGPT, Perplexity and Google AI Mode to retrieve, cite and reuse in their answers.Read more work? For ecommerce, it makes product information easier for ChatGPT, Gemini, Perplexity, Copilot, and AI Overviews to retrieve, parse, verify, and connect to checkout-capable records where supported.

A missing barcode can make one running shoe harder to match with the same shoe on another marketplace.

This guide is for ecommerce merchants who want to know how catalog data becomes readable by AI answer and shopping engines. If your store has 420 SKUs, 17 size variants on a shoe line, or a sale price that changes every Friday, the practical question is simple: can those systems read the product facts without guessing?

By the end, you will know how Generative Engine Optimization, or GEO, works at catalog level: retrieval, structured fields, taxonomy alignment, feed consistency, and freshness. Engines decide citations and shopping surfaces; your controllable job is a catalog that agents can read, match, and buy from where checkout handoff is supported; for a broader 2026 view, see this guide to generative engine optimization for ecommerce.

The first fix is catalog truth

The terms are less mysterious than they sound. GEO means Generative Engine Optimization, the work of making business information retrievable and usable in AI-generated answers. A merchant feed is a file or API record with one product offer per row or object. GTINThe GS1 Global Trade Item Number, the identifier that lets engines merge your offer with the same product sold elsewhere. A valid GTIN is numeric, 8 to 14 digits, with a GS1 check digit.Read more means Global Trade Item Number, the unique barcode identifier on many retail products. MPN means Manufacturer Part Number, the maker’s own product code.

Think of it like a stockroom.

A buyer can find the right box faster when every shelf label uses the same name, size, color, barcode, price, and location. AI answer and shopping engines work in a similar way: cleaner product records give them fewer conflicting facts to interpret.

Product facts matter before prompt tracking

A prompt set can be useful, but brand-mention counts alone are not a catalog GEO program. The evidence does not support stopping at prompt measurement: Google product structured data, the Google Merchant Center product data specification, the OpenAI commerce product feed spec, and Microsoft product feed documentation all describe explicit product fields that help systems parse merchant catalogs.

Google Search Advocate John Mueller said in 2025 that he was "not aware of any search engine that uses llms.txtA proposed convention: a markdown file served at /llms.txt that gives language models a curated map of a site's most useful content.Read more," according to Search Engine Roundtable's coverage of his Bluesky comments. Treat that as a caution, since the exact weight of llms.txt in commerce systems is not public; the useful role is a content map, with no confirmed ranking mechanism.

Here is the shop-floor checklist before the deeper work starts.

Methodology note: this guide maps merchant actions to primary documentation from Google Search product structured dataMachine-readable schema.org markup (Product, Offer, AggregateRating) embedded in a page as JSON-LD. It is the canonical way to hand engines unambiguous product facts.Read more, Google Merchant Center, schema.org, OpenAI commerce feeds, Microsoft Merchant Center, RFC 9309 robots.txt, and the llms.txt proposal. It avoids invented visibility benchmarks because answer selection weights are proprietary.

AI engines need retrieval before citation

A price changed from $64.00 to $49.00 this morning, a size 8 went out of stock at 14:07, and a barcode was corrected after a supplier update. These are illustrative SKU events, and they require current retrieval from pages, feeds, or indexed records.

Retrieval-Augmented Generation, or RAG, means an engine fetches or looks up current records before writing an answer grounded in those records. For ecommerce, records commonly come from the open web and structured merchant systems such as product feedsA structured export of the catalog (id, title, description, link, image, price, availability) in the Google Merchant Center spec, the format most shopping surfaces ingest.Read more, although each platform controls its own source mix.

Map every surface that can read your catalog today:

The pitfall is assuming model training data will carry live SKU facts. Training data may remember that your brand exists, but it cannot know that the blue linen shirt in size M is out of stock today.

Each SKU needs one canonical record

A messy catalog creates weak matching. If “Nike Air Zoom Pegasus 41,” “Pegasus41 blue,” and “NIKE running shoe women” are treated as unrelated items, an engine has less evidence that they are variants of the same product family.

The operational action is to normalize brand, model, title, category, variants, identifiers, condition, and URL into one source of truth. When Veliu’s agent readies a catalog, it builds one cleaned record per product and maps it to a standard category path that shopping systems can trust.

That is the catalog equivalent of putting every box in the warehouse on the right shelf, with the same label format.

Veliu’s agent also grades how confidently each product mapped to its category: an exact category path is strongest, a single plausible leaf is usually usable, a fuzzy match needs evidence, and a record that resolves only to a broad top-level bucket needs human review before it supports comparisons. A merchant selling “Roma Sandal 38 Black” should know whether the system resolved it to apparel footwear or only to a broad fashion bucket.

The pitfall is treating duplicate or variant listings as separate unrelated products. Use item_group_id for variant families and keep size, color, material, and condition explicit.

Page markup must match what buyers see

Google’s product structured data documentation and schema.org’s Product and Offer types explain the mechanism: named fields help machines extract offer facts from a page. JSON-LD, a script format used to place structured data in HTML, is the usual implementation pattern for Google Search.

For a product page, implement Product with Offer, and add AggregateRating or Review only when the reviews are visible and truthful on the page. Key fields include price, priceCurrency, availability as a schema.org ItemAvailability URL such as https://schema.org/InStock, sku, mpn, gtin, and brand as a Brand object.

For merchant listing eligibility, include fields such as shippingDetails and hasMerchantReturnPolicy when your store can state them accurately. A product page for a “Bialetti Moka Express 3 Cup” should not leave currency implicit; an illustrative value such as 19.90 without EUR or GBP is not enough context for a machine comparing offers across countries.

The pitfall is markup that disagrees with visible content. If the page says €39.00, the schema says €34.00, and the feed says out of stock, the problem is source-of-truth divergence that requires Google Shopping feed optimization.

Feeds often carry the cleanest shopping facts

Human shoppers can interpret a polished product page. Shopping agents and commerce surfaces often work better with structured feeds because feeds carry current price, availability, images, identifiers, and eligibility in predictable columns, with each platform deciding how those fields are used.

For Google Merchant Center, the required fields include id, title, description, link, image_link, availability, and price. Add brand, gtin, or mpn when applicable, identifier_exists for genuinely identifier-less goods, condition, item_group_id for variants, google_product_category, product_type, shipping, and shipping_weight where relevant.

Microsoft Merchant Center uses comparable feed discipline for Microsoft commerce and advertising surfaces, and its documented product feeds should be kept consistent with the page. OpenAI’s commerce product feed spec for ACP, the Agentic Commerce Protocol, includes product attributes plus eligibility fields such as is_eligible_search and is_eligible_checkout when a merchant implements those paths.

Do not rely on HTML alone.

The pitfall is thinking the product page is the whole catalog. For AI shopping agents, a feed can be the cleaner source for “is this exact SKU available at this exact price?”

Taxonomy beats title stuffing

Category alignment is how engines compare like with like. Your internal “Weekend kit” category may make sense to loyal customers, but Google Product Taxonomy needs a standardized path that places a waterproof hiking backpack near other waterproof hiking backpacks.

Keep both fields: the human category in product_type, and the standardized category in google_product_category. Then express material, size, gender, age_group, pattern, product_detail, and product_highlight in the right fields instead of cramming them into the title.

For example, “TrailFlex jacket women black M” should become a record with brand, model, color black, size M, gender female, material if known, and a taxonomy path for apparel outerwear. If a category match comes back fuzzy, check whether the evidence came from the title, the breadcrumb, or supplier data before approving it.

The pitfall is keyword stuffing. A title like “best waterproof breathable hiking jacket cheap sale women black M” adds noise while still failing to state clean fields.

Freshness is a trust problem

A stale feed can turn a good catalog into a bad answer. Measure propagation latency: the time from a store admin change to the product page, JSON-LD schema, merchant feed, and any commerce endpoint reflecting the same fact.

Check page, feed, and schema consistency for price and availability. Validate the availability enum, the price currency, sale_price and sale_price_effective_date when a promotion runs, and availability_date for preorder or backorder items.

A concrete illustrative failure: the feed says a £129 stroller is in stock, the page says “sold out,” and checkout blocks the cart. Google’s Merchant Center documentation describes feed-page consistency as a policy issue that can lead to item-level problems, and an answer engine that retrieves the stale record can repeat the wrong stock status.

The pitfall is assigning freshness to one person on sale day and forgetting the long tail. The 11 slow-moving SKUs in “clearance accessories” still need truthful price and stock.

Retrieval bots need deliberate access

Robots.txt, standardized in RFC 9309, tells compliant crawlers which paths they may fetch. For GEO, the practical question is whether citation-relevant retrieval bots can read the product pages that support your catalog.

Review access for Googlebot, OAI-SearchBot, PerplexityBot, and Bingbot where relevant. Separate training controls where desired: GPTBot is different from OpenAI’s search bot, Google-Extended is a Google training-use control, and Applebot-Extended is an Apple training-use control.

The popular belief is that blocking every AI-looking user agent protects the shop with no commercial cost. The mechanism says otherwise: if you block retrieval crawlers, you can also prevent engines from fetching the product pages they may use to understand catalog facts; each engine still decides whether and how citations appear.

Llms.txt can be published as a Markdown content map at /llms.txt, following the llms.txt proposal. It is optional, it is not access control, and no major shopping engine has confirmed it as a production ranking mechanism.

AI visibility depends on readable catalog evidence

ChatGPT, Gemini, Perplexity, Copilot, and AI Overviews increasingly work from retrievable sources, structured product records, feeds, and citations. A cleaner catalog can be easier for those systems to read and verify because the facts are not trapped in theme text, JavaScript widgets, or inconsistent feed rows; each engine still decides whether and how to cite sources.

This is the bridge from “GEO report” to “GEO fix.” ChatGPT brand visibility dashboards can show that a competitor appears more often for “best trail running shoe for wet roads,” but the fix may be a missing GTIN, a vague taxonomy path, or a feed that lacks size and color variants.

Veliu’s promise sits there, and the promise belongs to the brand agent: it studies how engines read the store, readies the catalog, and sells to the people and to the AI shopping agents that come asking. Each engine still controls its own recommendations and rankings, and market factors such as price, reviews, stock, and demand still matter. A catalog that agents can read, match, and buy from is the agent’s working material, the reason it can answer a shopping query with the current price and a valid variant, backed by 50K+ customers, 300K+ delegated transactions, over €100M transacted, and over a year of R&D.

Verification works only when catalog checks improve

Use a defined prompt set for visibility, but do not make it the only metric. Improving ChatGPT brand visibility by fixing catalog gaps requires the checks below to show whether the catalog substrate is improving.

Early academic work on GEO, including the KDD 2024 paper by Aggarwal and colleagues, is useful for understanding that AI answer visibility can change when sources are better structured or phrased. Treat it carefully for ecommerce decisions: the study was position-dependent, used a 2023 GPT-3.5 environment, and has no 2026 replication across today’s shopping surfaces.

Common failure modes are field-level problems

A catalog can be visible to humans and unreadable to machines. The product cards look polished, but the HTML lacks Product and Offer fields, and the feed is incomplete; fix it by adding valid JSON-LD and a complete merchant feed.

A sofa can show an illustrative $899 on the page and $949 in the feed. The engine must choose between conflicting records, and merchant platforms can flag the item; fix it by making the store admin or product information system the source of truth for page, schema, feed, and endpoint.

Identifiers can be missing or fabricated. GTIN fields that are blank, zero-padded, or invented for private-label items weaken matching; fix it with manufacturer GTINs where assigned, or MPN plus brand where no GTIN exists.

Categories can be too vague for comparison. If 800 products sit under “Accessories,” a shopper asking for a stainless steel lunch box for children gives the engine too little category, material, or age-group evidence.

Measurement can find the issue while the catalog stays broken for 90 days. Prompt tracking can surface symptoms; catalog repair addresses the underlying data issues.

How is GEO different from SEO in 2026?

SEO is still part of the system in 2026. Technical crawlability, structured data, helpful content, links, and entity trust can matter because AI Overviews, Gemini, Copilot, Perplexity, and ChatGPT Search use retrievable sources and indexes in ways that are partly public and partly proprietary.

Ecommerce GEO adds another layer: feed completeness, identifiers, taxonomy alignment, price and availability freshness, and agent-actionability. A merchant still needs a fast, indexable product page, and the product also needs to exist as a clean, structured offer that shopping systems can compare.

If you already work on SEO, keep the crawl discipline. Then add catalog discipline.

How should a merchant run GEO as a repair loop?

The practical sequence is compact: audit retrieval access, normalize the catalog, validate schema, complete feeds, align taxonomy, reconcile page-feed-endpoint truth, monitor factual accuracy and citation share, and fix gaps continuously.

For a store with 2,300 apparel SKUs, that may start with item_group_id, size, color, gender, and age-group cleanup. For a resale merchant, it may start with canonical brand/model identity, condition, MPN plus brand, and evidence-backed pricing notes.

The barcode problem from the opening closes here: one missing identifier is rarely the whole GEO problem, but it is often the first visible crack in the matching layer.

This article focuses on the operating layer: the fields, feeds, bots, and checks that make the catalog legible.

What to do next

• Pick 25 live SKUs across bestsellers, variants, and long-tail products.
• Compare page, schema, feed, and checkout for price, currency, stock, URL, image, GTIN or MPN plus brand, and category.
• Fix the first field that disagrees across those sources, then repeat the same check after the next sale or inventory update.

For practical guides on making ecommerce catalogs readable by AI shopping engines, join the newsletter.

Sources

• Google product structured data: https://developers.google.com/search/docs/appearance/structured-data/product
• Google Merchant Center product data specification: https://support.google.com/merchants/answer/7052112
• Google Product Taxonomy: https://support.google.com/merchants/answer/6324436
• schema.org Product and Offer: https://schema.org/Product and https://schema.org/Offer
• OpenAI commerce product feed spec: https://developers.openai.com/commerce/product-feeds/spec
• OpenAI bots documentation: https://developers.openai.com/api/docs/bots
• Microsoft Merchant Center product feed documentation: https://help.ads.microsoft.com/#apex/ads/en/51084
• robots.txt RFC 9309: https://www.rfc-editor.org/rfc/rfc9309
• llms.txt specification: https://llmstxt.org
• John Mueller llms.txt comment coverage: https://www.seroundtable.com/google-llms-txt-39273.html
• KDD 2024 GEO paper: https://doi.org/10.1145/3637528.3671900