# AgentMint.net > Full-text export: every published handbook page and blueprint inline, for agents that prefer a single fetch. Evidence tags are load-bearing: marks how each factual claim is sourced. --- # How AI Shopping Agents Choose Products https://agentmint.net/how-ai-agents-choose-products/ {/* Updated: 2026-07-11 - folded in ACES v3 (December 2025 model cohort, arXiv 2508.02630v3) */} {/* Updated: 2026-09-18 - added position-bias tension (arXiv:2608.22697), brand/incumbent bias (arXiv:2606.17443), and role-assignment sponsorship pointer (arXiv:2609.17989); settled ACES at v3 */} {/* Updated: 2026-09-18 (signals refresh) - added the position mechanism (Lost in the Middle, arXiv:2307.03172), two LLM-recommender order-bias studies (arXiv:2508.02020, arXiv:2608.03091), a live-surface sourcing measurement (Profound, 2026-06-24), an abstract-vs-body clarification on the ACES position figures, and the per-platform absence-of-evidence note */} ## Key takeaways - AI shopping agents rank on structured signals (position, price, rating, endorsement, and description text), not on brand recognition. - The strongest public evidence is the academic ACES framework: a controlled simulation of six frontier models across two 2025 snapshots, choosing from a mock storefront rather than from real sales data. - Position bias is layout- and model-dependent, not a constant: ACES found a large, version-unstable grid effect (the slot GPT-4.1 favored most is the one GPT-5.1 favors least), while a newer hotel-listing study found only a weak, non-monotonic effect in a one-dimensional list. - Rewriting a product description raised share on five of the six models tested but moved Gemini 3.0 Pro Preview essentially not at all, and in a few cases it backfired, so treat rewrites as something to test, not a guarantee. - The levers you actually control are feed completeness, product schema, titles, and crawler access. ## The short answer (signals, not brand habit) When an AI shopping agent picks a product, it is reading a scorecard, not recalling a brand. In the strongest evidence available today (the academic ACES framework, covered below), the levers that moved an agent's choice were all structured attributes: where the product sat in the results grid, its price, its star rating, whether it carried a platform endorsement, and how its description was written. That is why the question of [agent selection](/glossary/#agent-selection) (why an agent chooses one store or offer over another) comes down to legible product data, not reputation. We read the evidence to mean that an agent's pick is driven by machine-legible product signals rather than the brand familiarity that sways human shoppers, which is how a small store with complete, well-structured data can beat a household name it would never outrank in a person's memory. This page is the selection chapter of the broader [agentic commerce optimization](/agentic-commerce-optimization/) guide; the [platform playbooks](/platforms/) then show how each engine weights these signals in practice. ## What the evidence shows: the ACES framework The most rigorous public work on how buying agents choose is a 2025 study whose framework is called **ACES**. ACES, introduced in the paper "What Is Your AI Agent Buying?", was authored by Allouah and colleagues across MyCustomAI, Columbia Business School, and Yale, and is a provider-agnostic method for auditing agent decisions: a mock storefront is shown to vision-language-model shopping agents in repeated randomized trials, and their selections are analyzed with regression. Because the storefront and every attribute are controlled, the study can isolate what actually shifts a choice. The work has also cleared peer review: a short-paper version of ACES was published in the Proceedings of the ACM Web Conference 2026 (WWW '26) on 12 April 2026; the figures on this page continue to cite the fuller arXiv revision, which carries the complete tables. That December 2025 revision (v3) is the paper's current version as of September 2026; no later revision has been posted. Keep two caveats in mind before the numbers. The paper's December 2025 revision evaluates six focal models at two snapshots: an August 2025 cohort (Claude Sonnet 4, GPT-4.1, and Gemini 2.5 Flash) and a December 2025 cohort of their successors (Claude Opus 4.5, GPT-5.1, and Gemini 3.0 Pro Preview), all inside a controlled simulation rather than a record of real-world sales. And every effect it found is model-specific: the same signal has a different weight on each agent, and, as the newer cohort shows, on each generation. The sections that follow report the paper's numbers exactly, each one carrying that simulation caveat. ## Position & layout bias The single largest effect ACES found is where a product sits on screen. For a Claude Sonnet 4 agent, a product in the bottom-right corner of the grid was selected about 4.5% of the time; moving that same product to the second or third column of the top row raised its selection rate roughly fivefold, while moving it to the top-left corner produced only about half that increase. This is two-dimensional grid position, not a one-dimensional list rank. The ACES abstract states only that the models exhibit strong position biases that vary across providers and model versions and persist even in text-only, "headless" interfaces; it puts no position coefficient in the abstract. The slot percentages here and the table coefficients below come from the paper's body, so read them as body figures rather than as durable, abstract-level results. And the effect is not universal. Position bias varied by provider and persisted even in text-only, "headless" interfaces, undermining any single notion of a "top" rank. For a merchant that means placement inside an agent's result surface is powerful but rarely something you set directly; what you control is being eligible to appear at all, which loops back to feed quality and crawler access. See [position bias](/glossary/#position-bias) in the glossary. The newest evidence shows that bias can flip outright between versions. Comparing the two cohorts, GPT-4.1's top-row coefficient was +1.045 (Table 2), but its successor GPT-5.1's is −0.701 (Table 3): the paper describes the two generations' position biases as almost opposite, with the slot GPT-4.1 favors most being the one GPT-5.1 favors least and vice versa, while Gemini 3.0 Pro Preview's top-row coefficient is strongly positive at 2.146. A model update did not merely resize the position bias here; it reversed its sign. A second controlled study, run on a different layout, finds a much weaker position effect. A hotel-booking simulation of 100 listings randomized across 5,000 AI agent sessions, comparing four large language models against human field data, reports that "Position still predicts which listings are inspected, but weakly and non-monotonically: the middle of a results page has the lowest probability of inspection, not the bottom." The same paper adds two behaviors worth noting. Its agents "search more deeply than humans and never decline to buy," and across the four models they "converge on the same undominated listing." For merchants, the paper's own summary is the useful part. "For agentic search, the attributes displayed on a results page matter more than placement within it." Why the middle and not the bottom? That specific shape has an established explanation in how language models read their input. Across models, performance "is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades" when the relevant item sits in the middle, even for models built for long contexts. That finding is from 2023 and predates every shopping study here, which makes it a stronger explanation rather than a weaker one: the middle-minimum the hotel simulation measured is the same pattern a general language-model result predicts, so it is not a quirk of one storefront or one layout. The same order sensitivity shows up when language models are used as recommenders. One study reports that large-language-model recommenders "suffer from position bias, where the order of candidate items in a prompt can disproportionately influence the recommendations," with "high sensitivity to input orders." A follow-up from the same authors is sharper about what that means for anyone trying to correct it. Input order shifts the scores, pairwise preferences, and rankings these models produce, and "reducing marginal exposure skew is insufficient to establish ranking-function validity." The practical reading is that you cannot neutralize an order effect just by evening out how often each item is shown; the honest merchant posture is to measure and control for position, not to try to engineer it away. These findings do not cancel each other out, and neither study refutes the other. ACES measured a strong effect in a two-dimensional product grid with a 2025 model cohort; the hotel study measured a weak, non-monotonic one in a one-dimensional list with a newer cohort. Those are different layouts and different model generations, which is enough to explain why the measured strengths diverge. The honest reading is that position bias in agent selection is layout-dependent and model-generation-dependent rather than a fixed constant, so a merchant should not treat any single published position coefficient as durable. What both studies agree on is more useful anyway. The listing attributes this page covers (price, rating, reviews, and description text) are what a merchant can actually influence, and they carry more weight than a slot number a merchant cannot set. A measurement of a live surface shows how tightly sourcing and ordering are coupled in practice, as long as it is read for exactly what it is. A third-party measurement of the live ChatGPT surface reports that roughly 99.9% of feed-sourced product citations appeared in the first carousel position, and that product-feed retrieval rose from 4.3% to about 20% of shopping retrievals since November 2025. That describes how ChatGPT sources and orders its carousel, not evidence that position causes the choice, and a merchant who reads it as proof of a position effect has been misled. What it does support is the value of the feed pathway, which now carries a growing share of what ChatGPT cites, rather than any attempt to chase a slot. One distinction matters before you act on any of this: every controlled study cited above tests a model, not a live shopping product. No controlled study of position effects on a live shopping surface exists for Google AI Mode, Perplexity, Copilot, or Claude; the evidence is model-level, and a result about a model is not a result about the consumer product that model may power. The Profound measurement is the closest thing to a live-surface data point, and even it describes sourcing and ordering rather than a causal position effect. ## Price sensitivity Agents respond to price, and how strongly depends on the model. For the August 2025 cohort, ACES estimated log-price (ln Price) coefficients of −1.623 for Claude Sonnet 4, −1.612 for GPT-4.1, and −2.190 for Gemini 2.5 Flash, negative everywhere (cheaper wins, all else equal), with Gemini the most price-sensitive of that cohort. In the December 2025 cohort the ln Price coefficients are −1.886 for Claude Opus 4.5, −2.798 for GPT-5.1, and −2.249 for Gemini 3.0 Pro Preview, all negative, making GPT-5.1 the most price-sensitive of all six models. Price competitiveness matters across agents, then, but the same discount buys more selection lift on some engines than others. Because these coefficients are model-specific and drawn from a simulation, treat them as directional evidence that price is a real lever, not as a pricing formula. ## Ratings & review depth Star ratings move selection, and they move it most on the most rating-sensitive models. For the August 2025 cohort, raising a product's rating by 0.1 stars lifted a baseline 10% selection probability to 15.4% for Claude Sonnet 4, 20.3% for GPT-4.1, and 16.0% for Gemini 2.5 Flash, a large swing for a small rating change, with GPT-4.1 the most rating-sensitive. ACES also models review *count* as a signal distinct from the average score, and reports it as a positive selection factor across the models tested, which points to review depth mattering beyond the headline rating. In the paper's conditional-logit estimates (Table 2 of the current revision), the log review-count coefficient is positive for every model tested: 0.415 for Claude Sonnet 4, 0.739 for GPT-4.1, and 0.501 for Gemini 2.5 Flash, each statistically significant (p below 0.001), with GPT-4.1 weighting review depth most heavily. The December 2025 cohort weights both signals in the same direction: rating coefficients of 11.148 for Claude Opus 4.5, 9.247 for GPT-5.1, and 4.224 for Gemini 3.0 Pro Preview, and log review-count coefficients of 0.979, 0.800, and 0.669 respectively, all statistically significant (p below 0.001). The paper reports these newer figures only as coefficients, so there is no baseline-lift percentage to quote for the December models. As with the price coefficients above, these are model-specific logit coefficients from a simulation: directional evidence that more reviews raise selection odds, not a percentage lift you can bank. Either way, genuine ratings and review volume remain among the few selection levers you can influence honestly and directly. ## Brand familiarity, and the small rating edge that beats it Brand recognition biases agents, but a separate controlled study shows how little it takes to overturn. In skincare experiments across GPT-4o-mini, Claude Sonnet, and Gemini 3 Flash, well-known brands "get recommended 100% of the time (IAI = 10.0) when all products have the same specifications, but this dominance disappears with less than a +0.1-star rating advantage for a competitor." A brand monopoly that holds only while every specification is identical is a fragile one. The same study shows the ranking surface can be gamed, which is a risk to plan for rather than a tactic to copy. Authority-style marketing language, including fabricated clinical-evidence claims, "breaks this monopoly at a Bias Surplus Value equal to +0.17 rating points, with each model responding differently." Inventing clinical evidence is fabrication, and this site does not recommend it; the value of the result is the warning it carries, that the surface is manipulable and therefore has to be defended, not exploited. The authors also describe a collective trap, where "when all brands adopt the same optimization strategy, individual payoff falls from +0.802 to +0.007 in our payoff proxy, and non-participating brands receive zero recommendations in our tests." Two limits bound how far this travels. The experiments are in skincare, an experience good whose quality a buyer cannot verify before purchase, and the authors test generalization only as a robustness check on search goods rather than establishing it as a result. The manipulation finding, likewise, describes what moves a model, not what a merchant ought to do. For a challenger brand, the rating threshold is the opening. A small, genuine rating advantage appears to overcome a large brand-recognition gap, which makes review quality and rating accuracy a higher-leverage investment for a challenger than spending to build brand name recognition. That points back to the ratings and reviews above as the lever a smaller store can actually pull. ## The "Sponsored" penalty & endorsement lift Two counterintuitive findings sit together: agents *penalize* paid-looking tags and *reward* platform endorsements. For the August 2025 cohort, tagging a product "Sponsored" pushed a baseline 10% selection probability down to 8.9% (Claude Sonnet 4), 8.0% (GPT-4.1), and 7.9% (Gemini 2.5 Flash), a consistent penalty across all three models. In the other direction, the same cohort's "Overall Pick" endorsement lifted the baseline 10% to 24.3% (Claude), 19.9% (GPT-4.1), and 42.6% (Gemini), with Gemini rewarding endorsement most strongly. Both effects survive the generation change and, if anything, grow stronger. In the December 2025 cohort the Sponsored coefficients are −0.340 (Claude Opus 4.5), −0.371 (GPT-5.1), and −0.623 (Gemini 3.0 Pro Preview), each more negative than its August predecessor, while the Overall Pick coefficients rise to 1.865, 1.342, and 2.144 respectively. The scarcity tag ("Only X Remaining") was negative or null for the August 2025 cohort, significantly so only for Gemini 2.5 Flash (−0.342), but for Gemini 3.0 Pro Preview it flips to slightly positive and significant, at 0.219 (p below 0.05). This is evidence that a model generation can flip even the sign of an effect. The honest implication (and it is an inference, not a growth hack) is that the winning move is to earn legitimate endorsement signals, not to fabricate them; manufacturing badges or gaming "pick" markers is exactly the dark pattern this result would tempt a merchant into. That penalty is not fixed by the tag alone. A separate controlled study reports that whom an agent is told it serves changes how it treats a sponsored listing, finding that platform delegation "significantly attenuates the penalty that agents apply to sponsored listings and weakens the skepticism that disclosure triggers in their reasoning traces." How sponsorship, disclosure, and delegation interact is its own subject, taken up in [sponsored placement and agent selection](/sponsored-placement-and-agent-selection/). ## The description-rewrite experiment The one lever on this list a merchant fully controls is the words on the product, and ACES tested it directly. A minimal AI seller agent rewrote a single randomly chosen focal product's description in each category, using competitor sales data as input; GPT-4.1 acted as the seller agent optimizing against the August 2025 buyer models, and GPT-5.1 against the December 2025 buyer models. The rewrite moved share on most, but not all, of the buyers. Averaged across categories, the focal product's market share rose by +3.66 percentage points on Claude Sonnet 4, +8.37 pp on GPT-4.1, +14.79 pp on Gemini 2.5 Flash, +7.38 pp on Claude Opus 4.5, and +14.89 pp on GPT-5.1, all statistically significant; on Gemini 3.0 Pro Preview it moved +0.32 pp, which was not statistically significant, leaving the effect significant in five of the six buyer models. On the newest Gemini, the one-shot rewrite did essentially nothing. That single null result is enough to reject any pitch that description rewrites reliably work everywhere: on at least one current frontier model, this one did not. The averages also hide how uneven the effect is. Across category-model pairs spanning all six buyer models, 67% saw no statistically significant change from the one-shot rewrite, while the remaining 33% produced large gains. One category shows what a large gain looks like. An office lamp was the only category with consistent, significant gains across all six buyers, ranging from +7.1 pp on Gemini 3.0 Pro Preview to +80.4 pp on GPT-5.1. The authors hypothesize the mechanism: the original description did not place the query keyword "Office" early, so it was truncated on the mock storefront and the agents overlooked it; the rewrite front-loaded "Office". That is the same reason where a keyword sits in your title and feed text can decide whether an agent ever registers it. Rewrites are not risk-free. In a few cases the AI-rewritten description reduced market share, for a stapler under Claude Opus 4.5 and a mousepad under Gemini 3.0 Pro Preview. The lesson is continuous testing, not a set-and-forget rewrite. ## Behavior is model-dependent (and changes on updates) Every effect above has a different size on each model, and the ranking is not stable over time. ACES found agents concentrate demand on a handful of "modal" products and never select some brands at all, with the pattern differing by model. More unsettling for anyone optimizing to a single engine: the authors documented that a model update can drastically reshuffle market shares, as it did between Gemini 2.5 Flash Preview and Gemini 2.5 Flash. The December cohort makes that reshuffle concrete. In the fitness-watch category, the Fitbit Inspire's share of agent picks rose from 45% under Claude Sonnet 4 to 77% under Claude Opus 4.5, while falling from about 25% under GPT-4.1 to 6% under GPT-5.1. Among iPhone 16 Pro covers, GPT-4.1's modal pick (Mikeke, 62.6%) collapsed to 5% under GPT-5.1, which instead picks ESR 95% of the time. The paper also observes that this choice homogeneity, with agents piling onto a few products, is more pronounced in the latest models. This is why AgentMint.net types every model-behavior claim by source and date: what an agent rewards this quarter it may weight differently after the next release. Treat agent behavior as a moving target: the per-engine [platform playbooks](/platforms/) track where the engines currently diverge. ## Baseline rationality has matured The newer models are better at the basics. On single-attribute tests, the share of trials where an agent failed to detect a +0.1-star advantage fell from 28.7% for Claude Sonnet 4 and 15.1% for GPT-4.1 in August 2025 to below 1.7% for the December 2025 models, which the paper reports almost never miss such single-dimension comparisons. The reading for merchants: agents now reliably read the scorecard, so getting scored correctly is table stakes; what stays model-dependent and durable is how each agent weights that scorecard (position, badges, and the attribute sensitivities above), so legibility gets you scored and weighting decides who wins. ## What this means for merchants: the practical levers You cannot set where you land in the list or force an endorsement, but you can control the inputs those signals are computed from. The levers below translate the evidence above into work you can start this week: - **[Make your product feed AI-readable](/make-product-feed-ai-readable/)**: completeness and structure are what make you eligible to be scored at all. - **[Ship product schema (JSON-LD) for AI shopping](/product-schema-for-ai-shopping/)**: the machine-readable layer agents trust when your page and feed disagree. - **[Write product titles AI agents match](/product-titles-for-ai-agents/)**: the description-rewrite experiment above showed title and description text can move share by double digits on some models and next to nothing on others, so the words are a real but uneven lever. - **[Manage AI crawlers, robots.txt and llms.txt](/ai-crawlers-robots-llms-txt/)**: block the crawlers and you delete the supplemental page data agents read beyond your feed. - **Deliver those signals fast and lean**: even complete data loses if an agent cannot fetch it quickly or has to dig through filler to reach it. Two infrastructure chapters cover that layer, [serving agent traffic](/handbook/serving-agent-traffic/) (caching and reachability, so being open to agents does not cost you) and [raising information density](/handbook/information-density/) (packing the decision facts into fewer tokens). Together these are the inputs to the scorecard. The [platform playbooks](/platforms/) then show how ChatGPT, Gemini, and Perplexity weight them differently. ## Caveat: simulation, not sales Every number on this page comes from one controlled study, and its limits matter as much as its findings. ACES is a simulation: vision-language-model agents choosing from a mock storefront in randomized trials, across a fixed set of six models at two snapshots (Claude Sonnet 4, GPT-4.1, and Gemini 2.5 Flash in August 2025; Claude Opus 4.5, GPT-5.1, and Gemini 3.0 Pro Preview in December 2025), not a record of real purchases on live stores. Read these effects as evidence of *what kinds of signals* agents weigh and *how differently* they weigh them, not as guaranteed conversion math for your catalog. One methodological detail bounds how far the numbers travel. ACES ran every agent at minimal or disabled reasoning (thinking off for Claude Sonnet 4 and Gemini 2.5 Flash, a 500-token thinking budget for Claude Opus 4.5, and low reasoning effort for GPT-5.1 and Gemini 3.0 Pro Preview) at temperature 1.0, settings chosen to mirror latency-constrained deployments. Production assistants that reason for longer or search the web may weight these signals differently, so read the coefficients as a minimal-reasoning baseline rather than a description of every chat-based shopping assistant. ACES is also no longer the only testbed pointing this way. ABxLab, a framework from a team including MIT Media Lab researchers, independently probes agent purchasing choices by manipulating price, ratings, and persuasive nudges under controlled conditions, and reports that agent decisions shift predictably and substantially in response. A second simulation reaching the same broad conclusion (structured signals, deliberately varied, move what an agent buys) does not remove the simulation caveat, but it does mean the pattern no longer rests on a single study. The methodology is inspectable (the ACES simulator is released under the MIT license). AgentMint.net runs no experiments of its own and publishes no measured results, so treat ACES as the best available map of how agents choose, and your own measured [agent win rate](/glossary/#agent-win-rate) as the territory. --- # ChatGPT Shopping Optimization https://agentmint.net/chatgpt-shopping-optimization/ ## Key takeaways - ChatGPT surfaces products over the ACP/Stripe data rails plus its feed partners, and since March 2026 most purchases complete on the merchant's own site or app, with an in-chat Instant Checkout option still shown for some eligible products. There is no dashboard toggle that 'adds' your store; you improve the signals it already reads. - The work is the same catalog work that wins across every agent: a complete feed, titles that match how shoppers phrase queries, and open crawler access. This page routes each to its own playbook rather than repeating it. - The clearest evidence for the GPT family is the ACES study: GPT-4.1 was the most rating-sensitive model tested, penalized 'Sponsored' tags, and rewarded genuine platform endorsements (in a controlled simulation, not live ChatGPT sales). - If your store is already set up and still not appearing, that is a diagnostic problem, not an optimization one. This page is the proactive playbook; the troubleshooting page is the decision tree. - Treat 'am I winning in ChatGPT?' as a number you measure over time, not a box you check once. Agent behavior shifts with every model update. ## How ChatGPT surfaces products ChatGPT does not keep a directory you submit to. It assembles shopping answers from product data that reaches it over a defined rail, and then runs its own selection over what it can read. The Agentic Commerce Protocol (ACP), announced by OpenAI and Stripe on 29 September 2025, launched as the open standard behind Instant Checkout, an in-chat purchase flow that debuted with US Etsy sellers and single-item purchases. The checkout half of that story has since changed. By early March 2026, OpenAI had scaled back the standalone in-chat checkout, routing purchases through merchants' own sites and apps instead. OpenAI's merchant page now states the model plainly: it is "moving away from a standalone Instant Checkout experience" to prioritize shopping discovery and merchant-owned checkout, so shoppers discover and evaluate products in ChatGPT and complete purchases on the merchant's own website or app; ACP today supports product discovery and personalized recommendations through shared product data, and is planned to expand toward the full shopping journey over time. Read that next to OpenAI's shopping help article, which still describes an in-chat option. For some eligible products and merchants, ChatGPT may also show an Instant Checkout option that lets a shopper complete checkout in ChatGPT. Both statements hold: the standalone Instant Checkout experience was retired while an in-chat checkout option persists for eligible products and merchants, so treat in-chat checkout as a narrowing case, not a closed door. For a merchant, the shift raises the stakes on this page's subject rather than lowering them: ChatGPT is now purely a discovery and selection surface, and the conversion happens on the site you already run. The feed rail, plus OpenAI's feed partners, is still the pipe your catalog travels through. See [ACP](/glossary/#acp) in the glossary for the two-sentence definition. OpenAI now describes how results are chosen in its shopping help article, not only in the 2025 launch post. That article states that product results are selected independently by ChatGPT, are not ads, and are not influenced by any OpenAI partnerships, and that ads are separate from product results. That separation matters now, because ads exist on this surface. On 16 September 2026 OpenAI began testing Sponsored Agents, which let people start a conversation with a business-sponsored agent after clicking an ad in ChatGPT, and states that the conversation with a Sponsored Agent is distinct from ChatGPT's independent answers and separate from the original conversation that the user started in ChatGPT. Keep the scale honest before you plan around any of it. OpenAI's help article says Sponsored Agents are currently available only to selected advertisers in a limited alpha test, and that OpenAI is not accepting early access requests at this time. There is nothing here for most merchants to act on yet. Ads make the case for this page's work stronger, not weaker, and the first statement is why: product results stay separate from paid placement, so improving the signals ChatGPT reads is still what moves an organic pick. The rail getting your data to ChatGPT is not the same as ChatGPT choosing you, and the protocol says so plainly. ACP's own FAQ says implementing it does not guarantee automatic product listings: each AI platform "will manage their own process" for how businesses can participate. That sentence is the whole game. Eligibility (being connected and parseable) is table stakes; *winning* the pick is a separate layer, and it is decided by the quality of the signals ChatGPT reads once you are eligible. Everything below is about that second layer. ## What OpenAI says it weighs For most of this site's life the selection factors for ChatGPT had to be inferred. OpenAI now publishes them. When determining which products to surface, ChatGPT considers structured metadata from first-party and third-party providers (for example, price and product description) and other third-party content, the model responses it generates before it considers any new search results, and OpenAI's safety standards and product policies, alongside the shopper's query and context such as Memory or Custom instructions. Two of those inputs sit outside a merchant's reach. The one you own outright is the structured metadata, which is why the feed and page work below is where a merchant has room to move. Weighting is not fixed across queries. OpenAI states the emphasis shifts with the shopper's intent: if a shopper specifies a budget of $30, ChatGPT focuses more on price, whereas if price is not mentioned it may focus on other aspects instead. A merchant cannot pick the query, so the working read is that price competitiveness decides some queries while your non-price attributes have to carry the rest. When several merchants sell the same item, OpenAI describes a separate ranking step. Merchants are ranked on factors like availability, price, quality, and whether they are the maker or primary seller of that item, and the merchant list is generated by ChatGPT from merchant and product metadata supplied by third-party providers or directly by the merchants themselves. OpenAI also flags that this is not settled: it expects merchant ranking to evolve, including by personalizing rankings further to user preferences. The maker-or-primary-seller factor is the actionable one, and this site has not covered it before. If you make the product, that is a ranking advantage you already hold, and the job is to make it unambiguous in your data: sell under your own brand and keep your catalog the authoritative record, so a thin reseller listing does not represent your product better than you do. If you resell an identical item, this factor is a structural headwind, which pushes the win back onto the levers you do control: availability, honest price, genuine quality signals, and a listing complete enough to be the cleanest record of the product. It is the clearest first-party sign that who you are in the supply chain, not only what your page says, feeds the pick. How the price is displayed has its own mechanics worth knowing before you read too much into what a shopper sees. Prices shown in ChatGPT's initial response typically reflect the price from the first merchant listed, which may not be the lowest available price. Labels are not a reliable price ranking either. A "Best price" label may mark the lowest option, but OpenAI notes that if another label such as "Instant checkout" applies, the lowest-price option may not also show a "Best price" label. Freshness lags too. When price and shipping change, there may be some delay before it is reflected. So keep feed price and shipping accurate and current, because the surface shows what it last ingested, not what your site shows this minute. ## There is no "enroll" button Merchants keep looking for the switch. There isn't one. Optimizing for ChatGPT is not an enrollment action but a data-quality action: you cannot flip a setting to make ChatGPT prefer you, because what it prefers is computed from the completeness and legibility of the product signals it already ingests over ACP and from your pages. The absence of a switch is now OpenAI's own stated mechanic, not just our reading: OpenAI's commerce documentation states that onboarding product feeds in ChatGPT "is currently available to approved partners", with merchants applying through the merchant form, and that listed products must meet OpenAI's product policies (legal, safe, and suitable for general audiences, with categories such as weapons and prescription-only products excluded). An application and an approval, not a toggle. Practically, that reframes the whole task: you are not applying for placement, you are making yourself the easiest product to score favorably. The three levers below are where that happens, and each has a dedicated playbook so this page stays the map rather than the manual. ## Lever 1: Fix the feed The feed is the structured surface ChatGPT reads first, and gaps in it are the most common reason a product that could have been picked is skipped. Leading titles with category and use-case, filling every attribute agents parse, and keeping availability and price consistent are the moves that matter, but the field-by-field work belongs on its own page. Start with [make your product feed AI-readable](/make-product-feed-ai-readable/), and reconcile any page-versus-feed disagreements with [product schema (JSON-LD) for AI shopping](/product-schema-for-ai-shopping/) so the agent is not left to guess which source to trust. The completeness bar is no longer a guess, because the feed spec itself is public. OpenAI's product feed specification caps `title` at 150 characters and `description` at 5,000, requires `availability` as an enumerated value (`in_stock`, `out_of_stock`, `pre_order`, `backorder`, or `unknown`), and reserves optional review fields (`star_rating`, `review_count`, `store_star_rating`) alongside return and fulfillment fields such as `accepts_returns` and `return_deadline_in_days`. The optional fields are the selection-relevant tail: every one you fill honestly is a signal ChatGPT reads directly instead of scraping or skipping. The feed spec also carries the eligibility flags that decide where a product can appear at all, and a new one arrived with the ads test. Beside `is_eligible_search` and `is_eligible_checkout`, the spec documents `is_ads_eligible`, a boolean that is conditionally required for Ads processing (legacy alias `is_eligible_ads`): set it true for products ads should process, false to opt out. Setting `is_eligible_search=false` also disables checkout eligibility. For a merchant not in the ads alpha, `is_ads_eligible` is mostly a default to leave alone, but the cascade is the part to remember: turn search eligibility off and you turn checkout off with it. ## Lever 2: Match titles to queries ChatGPT matches a shopper's phrasing against your title text far more literally than a human browsing a shelf would. A brand-first name like "The Luna" gives the query nothing to latch onto; a title that opens with the category, the defining attributes, and the use-case does. The full formula, the evidence behind it, and the honest note that the direct measurement is about descriptions rather than titles all live on [product titles that AI agents match](/product-titles-for-ai-agents/). ## Lever 3: Open crawler access ChatGPT reads more than your feed. It also reads the supplemental page data its crawlers fetch, and if those crawlers are blocked in robots.txt, you delete that signal without realizing it. The commerce allow-list (the OpenAI crawler tokens and what each one does), and what an llms.txt file adds, are covered on [AI crawlers, robots.txt and llms.txt for stores](/ai-crawlers-robots-llms-txt/). Getting this wrong is a silent failure, which is exactly why it belongs in the diagnostic flow too. ## What ACES suggests about the GPT family The most rigorous public read on how GPT-family agents choose comes from the academic **ACES** study, which tested GPT-4.1 alongside Claude and Gemini agents in a controlled storefront simulation. It is the closest evidenced proxy we have for ChatGPT's shopping behavior, with one honest caveat. The exact model and weighting behind ChatGPT's shopping answers are not public and change with each update, so we read ACES's GPT-4.1 results as directional evidence for the GPT family, not as a spec of ChatGPT's live behavior. The distance is growing, too: OpenAI announced GPT-5.6 in August 2026, several model releases past the cohort ACES tested. The further the live line drifts from the tested cohort, the more directional these numbers become. With that framing, four GPT-4.1 findings are worth acting on. Raising a product's rating by 0.1 stars lifted a baseline 10% selection probability to 20.3% for GPT-4.1, the most rating-sensitive model ACES tested. Price pulls in the expected direction: GPT-4.1's log-price (ln Price) coefficient was −1.612 (negative), meaning cheaper wins all else equal. Two tag effects run counter to intuition: tagging a product "Sponsored" pushed GPT-4.1's baseline 10% selection probability down to 8.0%, while a platform endorsement such as an "Overall Pick" badge lifted that same baseline 10% to 19.9% for GPT-4.1. Hold all four numbers with the study's own limit in mind. ACES is a simulation (vision-language-model agents choosing from a mock storefront in randomized trials), not a record of real purchases in ChatGPT. What a merchant should do with them: earn genuine ratings and legitimate endorsement signals, keep price honest, and never manufacture a "Sponsored" look or a fake "pick" badge. The endorsement result is precisely the finding that would tempt a dark pattern. The full cross-model breakdown, including how Claude and Gemini weight these same signals differently, sits on [how AI shopping agents choose products](/how-ai-agents-choose-products/). ## Check eligibility (official, link out) Before optimization has anything to bite on, your store has to be connected and eligible on OpenAI's side. That onboarding is OpenAI's own turf, and its merchant page now states the top-level mechanics itself. Merchants apply through a form and join a waitlist; Shopify and Etsy sellers' catalogs are already integrated with no application needed; shopping in ChatGPT is currently live for US users, with more regions planned; feeds are accepted over SFTP, APIs, and leading commerce platforms and feed providers; and a self-serve merchant platform for data integration is planned for later in the year. The commercial terms moved with the checkout model: the September 2025 launch post said merchants pay a small fee on completed in-chat purchases, while the current merchant page states there are no fees on purchases that start in ChatGPT. The canonical eligibility boundary still lives on OpenAI's merchant page at [chatgpt.com/merchants](https://chatgpt.com/merchants); the detailed criteria are OpenAI's to define and they change on OpenAI's schedule, so read them at the source. Treat the official page as the source of truth for *whether you can appear*; treat this page as the source for *how to be chosen once you can*. That distinction also decides which of our pages you need next. This page is the proactive playbook, the moves that improve your odds. If your products are genuinely missing from ChatGPT and you need to find out *why*, that is a troubleshooting job with a different shape: a diagnostic decision tree, checked in order. Go to [why you're not in ChatGPT shopping](/store-not-in-chatgpt-shopping/) for that. Optimizing and troubleshooting are different tasks: use the playbook to get better, the decision tree to get unstuck. The same feed, title, and crawler work reaches [Gemini and Google AI Mode](/gemini-shopping-ranking/) and [Perplexity](/perplexity-shopping-optimization/) too, over their own rails; the protocol differences are compared on [UCP vs ACP](/ucp-vs-acp/). ## Measure your ChatGPT win rate None of the levers above come with a guaranteed conversion number, and we will not invent one. What you can do is measure the outcome directly: run a repeatable set of shopping prompts through ChatGPT and track how often your product is the one recommended: your [agent win rate](/glossary/agent-win-rate/) for that engine. That turns "are we optimized?" from a feeling into a baseline you can move and re-check after each change. The protocol is published in [how to test agent selection](/handbook/how-to-test-agent-selection/), and it is written to be run on your catalog rather than ours. This site publishes no measured results of its own. --- # Serving Agent Traffic Without Breaking Your Origin https://agentmint.net/handbook/serving-agent-traffic/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It reads this chapter, audits your store against it, and reports before changing anything. Review everything your agent changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Apply this chapter to my store The agent audits your store against the chapter, then implements what you approve. ```text Fetch and read the full document at https://agentmint.net/handbook/serving-agent-traffic.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are applying this chapter to this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first and change nothing yet. Inventory which of the chapter recommendations apply to this store, evaluate the current state against each, and produce a report: already done, missing with the concrete fix, or not applicable with a reason. Name the recommendation each finding maps to. Then, only after I approve, implement the safe, non-destructive changes in small, reviewable steps. Stop and ask before anything ambiguous or destructive, or anything that changes customer-facing content. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: what is already in place, what you changed or propose, and the exact data or decisions you need from me. ``` You keep an origin healthy while staying open to AI agents by caching the cheap, near-static surfaces agents read most and reserving your compute for the offer data that has to be fresh, not by blocking the agents that would have selected you. ## Key takeaways - A live, user-triggered agent fetch hits your origin at question time while a shopper waits, so the cost of being open is real, but the answer is caching, not blocking. - Retail is one of the sectors AI crawlers hit hardest, and crawl-to-refer ratios can be extremely lopsided, so plan for the fetch load instead of being surprised by the bill. - Edge-cache the near-static machine surfaces (llms.txt, Markdown mirrors, feeds, mostly-static product pages) and keep price and availability on a short leash so an agent never quotes a stale offer. - Access control (throttling unverified spoofers) is not content variation (serving different content by user-agent, which is cloaking); allowlist the verified agents and rate-limit only the fakes. - If your store sits behind a CDN, read its defaults: Cloudflare began blocking the Agent class by default on ad-bearing pages for new domains on 2026-09-15, and a training block there can take Googlebot with it. > **This chapter is about affording openness, not blocking agents** > > Every load figure below is a reason to cache smarter, never a reason to slam the door on an agent that would have selected you. Rate-limiting here targets unverified spoofers only. The verified shopping and answer agents should always get through. ## Why agent traffic strains an origin differently A scheduled search crawler and a live shopping agent load your server on opposite economics. A classic index crawler visits on its own timetable, so its cost is smooth and predictable: fetch once, and the engine can send you many shoppers off that one visit. A live agent fetch is the reverse. It fires the moment a real person asks a question, it is tied to that person waiting for an answer, and nothing guarantees the work sends a visitor back. That second mode is growing fast. Cloudflare recorded "user action" crawling, meaning bots that simulate a human action rather than run a scheduled index, growing more than 15x across 2025, and more than 21x from the start of January to early December. The return on that traffic can be lopsided. Cloudflare reported that Anthropic's crawlers had the highest crawl-to-refer ratios it saw, reaching as high as 500,000 fetches for every visitor referred back, while Perplexity's were the lowest. That is a range across engines, not a fixed toll. What it tells a merchant is that "being crawled" and "being sent shoppers" are not the same size, so budget for the fetch load on its own terms. A newer Cloudflare analysis puts per-operator numbers on the same imbalance. Using July 2025 data, Cloudflare measured crawl-to-refer ratios of 38,065.7 to 1 for Anthropic, 1,091.4 to 1 for OpenAI, 194.8 to 1 for Perplexity, and 5.4 to 1 for Google, and estimated the purpose of AI bot crawling at roughly 80% model training, 15% search, and 3% user actions. The two Cloudflare measurements cover different periods and methods, so keep both, each with its date. For planning they agree: most agent fetches will never send a visitor back, and the door still has to be cheap to hold open. Retail sits squarely in the blast radius. Retail and computer software were consistently the two sectors that drew the most AI crawler traffic, together just over 40% of all AI crawler activity Cloudflare observed. If you sell online, you are in one of the sectors AI crawlers hit hardest, so this is your bill to plan for. One caveat before you quote any of these numbers: the Cloudflare figures report Cloudflare's own network traffic, which is a large first-party sample rather than a census of the whole internet. Treat the direction and shape of the trend as the signal, and hold the exact percentages loosely. The other side of the ledger is what an agent referral is worth when it does arrive. A peer-reviewed study of 973 e-commerce websites over twelve months (August 2024 through July 2025), comparing more than 50,000 ChatGPT-referred transactions against 164 million from traditional channels, found that ChatGPT referrals converted better and earned more revenue per session than paid social but less than every other traditional channel, performed strongest in complex product categories, and improved in conversion over time while average order value declined. A referral channel in the middle of the pack is not a reason to close the door. It is a reason to serve the traffic at a cost that matches what it returns, which is what the rest of this chapter is for. The cost is not hypothetical. 404 Media reported that Anthropic's ClaudeBot hit iFixit nearly a million times in a single day, thousands of requests a minute for several hours, after which iFixit blocked it in robots.txt. Read the Docs reported a single crawler downloading 73 TB of zipped HTML in one month (roughly 10 TB of it in a single day) at a bandwidth cost of over $5,000; after it blocked the abusive crawlers, downloaded-file bandwidth fell about 75% (from roughly 800 GB/day to roughly 200 GB/day), which it estimated at about $50 a day, or $1,500 a month, in avoided cost. Both operators reached for a block because the traffic was unmanaged, not because the agents were unwelcome in principle. This chapter is about the option they did not have time to build: making the surfaces agents read cheap enough that an open door stops hurting. ## Scheduled crawl vs live user fetch Every AI engine loads you in one of two modes, and the difference decides what you can safely cache. The first is the scheduled index crawl: a bot walks your pages on its own schedule to build or refresh an index, so its requests are periodic, predictable, and easy to serve from cache. The second is the live user fetch: the request that fires the instant a shopper's question reaches your URL, while the person waits for the agent to answer. For selection, the live fetch is the one that counts, because a shopper is mid-decision when it happens. It is also the harder mode to reason about, since it can arrive at any moment and sometimes carries a unique query string. The reassuring part is that most of what a live fetch actually reads is still your ordinary, slow-changing pages, which are exactly the ones you can cache. One caveat rides on top of that. What a live fetch reads is only what arrives in the HTML it gets back, and not every agent runs your JavaScript to build the rest. Google documents that its rendering of JavaScript is queued and deferred rather than immediate, notes that "not all bots can run JavaScript," and recommends server-side rendering or pre-rendering so critical content sits in the initial HTML. If your price, stock, or specifications only appear after client-side script runs, the surface you worked to make cheap can still reach an agent empty, so put the facts an agent needs in the HTML it receives and then cache that. There is early evidence that speed is more than a cost concern: it can be a selection factor in its own right. In Microsoft Research's Magentic Marketplace, an open-source simulation of a two-sided market of buyer and seller agents, the authors report severe first-proposal bias: buyer agents favored the first response they received, creating advantages of 10x to 30x for response speed over quality. That is a simulated agent marketplace, not a live shopping engine, so treat it as directional. The direction, though, points the same way as this whole chapter: surfaces that answer fast get considered first. Which [AI crawler](/glossary/#ai-crawler) user-agent token belongs to which mode is a table we already maintain, so we will not restate it here. See the [AI shopping crawlers reference](/reference/ai-shopping-crawlers/) for the per-engine tokens (which are index crawlers, which are live user fetches) and how to verify each one. ## What is cheap to serve, and what is not Split your surfaces into two buckets before you touch a cache setting. Cheap to serve are the near-static machine surfaces: your [llms.txt](/glossary/#llms-txt), any [Markdown mirrors](/blueprints/product-markdown-mirror/) of your pages, RSS or Atom feeds, and the mostly-static parts of a product page (the description, the specifications, the care instructions). These change slowly and look identical to every requester, so you can generate them once and serve the same bytes to thousands of fetches. They are also the dense, fact-heavy surfaces covered in [information density for agents](/handbook/information-density/), which is the other half of this decision: pack them with verifiable facts, then make them cheap to serve. Expensive, and not safely cacheable for long, is the live offer data: current price, stock status, and the delivery window for this shopper. This is the information that changes often and that an agent most needs to have correct. The trap is the long tail. Wikimedia reported that at least 65% of its most resource-consuming traffic came from bots even though bots were only about 35% of pageviews, because crawlers bulk-read many low-popularity pages that human readers rarely open and that therefore miss the cache. It also reported that bandwidth for multimedia downloads grew 50% since January 2024, driven largely by automated scrapers rather than human readers. The lesson for a store: the requests that hurt are usually not the homepage, which is always warm in cache, but the thousands of deep product and variant URLs a crawler will read once and a shopper almost never will. Cache those on purpose, or they find your origin every time. ## Edge-caching the machine surfaces This is the part you hand to a developer, and it is deliberately short, because the caching directives themselves are documented by the CDN and web-server vendors and we link straight to them. The behavior you want is simple to state: serve the cached copy instantly, and refresh it in the background. Two mechanisms give you that. Cloudflare serves stale content while it revalidates only if your origin's Cache-Control header includes stale-while-revalidate; when that is set, the first request after the cached copy expires triggers an asynchronous background revalidation and immediately receives the stale content marked with an UPDATING status, instead of blocking on the origin. On nginx, proxy_cache_use_stale with the updating parameter serves a stale cached response while that entry is being refreshed, which minimizes upstream requests (it is off by default); since version 1.11.10 nginx can also honor a stale-while-revalidate directive from the upstream, at lower priority than the proxy_cache_use_stale settings. These are two separate implementations, not one feature: nginx's serve-stale-while-refreshing is not identical to Cloudflare's asynchronous UPDATING flow, so test the one you actually run rather than assuming they behave the same. If you want the edge to hold a copy longer than a browser does, Cloudflare's cache-control guidance is to send max-age together with stale-while-revalidate from the origin and set a separate Edge Cache TTL in a Cache Rule, and it warns against combining s-maxage with stale-while-revalidate. A minimal starting point for one near-static surface: > Illustrative config, not a spec requirement. For an llms.txt file or a Markdown mirror, the origin can send `Cache-Control: max-age=3600, stale-while-revalidate=86400`. The nginx equivalent is `proxy_cache_valid 200 1h;` together with `proxy_cache_use_stale updating;`. The directives and their behavior above are documented and exact; the specific numbers (one hour fresh, then up to one day of stale-while-revalidate) are an illustrative editorial choice, not a spec requirement, so set them to match how often that surface really changes. For anything past this, follow the vendor docs rather than a recipe from us. The two Cloudflare pages and the nginx page linked above are the source of truth, and they move. If you run (or want to add) a CDN edge worker in front of your origin, the [edge-worker machine-surfaces blueprint](/blueprints/edge-worker-machine-surfaces/) has a complete stale-while-revalidate worker built on the same directives above. ## The freshness tradeoff: never serve price and availability long-stale Stale-while-revalidate is a gift for low-churn surfaces and a liability for offer data. Our stance is a hard line: cache descriptions, specs, and llms.txt generously, but keep price and availability on a short TTL, or bypass the cache for them entirely, so an agent can never read and then quote an offer you no longer honor. The reason is selection, not correctness alone. An agent that surfaces a price you have since raised, or shows "in stock" for something you have sold out of, hands the shopper a bad checkout, and that mismatch is exactly the kind of thing an engine learns to stop trusting you for. The same freshness discipline you apply to your [product feed](/make-product-feed-ai-readable/) has to apply to the offer fields on the live page, because an agent may read either one. When your page and your feed disagree on price, you have given the agent a reason to doubt both. ## Allowlist verified bots; rate-limit only unverified spoofers Two different levers get confused here, and the whole argument depends on keeping them apart. Access control decides who gets in and how fast: allow, deny, or throttle a request based on the verified identity of the client. Content variation decides what a given client sees: serving one version of a page to one user-agent and a different version to another. That second lever, when you swap the actual content by user-agent to manipulate what an engine indexes, is cloaking, and it is covered in [information density for agents](/handbook/information-density/). Throttling a request is not content variation: rate-limiting changes how much a client can fetch, never what the page says, so it is not cloaking. Say that plainly to anyone who worries the two are the same thing. Know what your robots.txt actually does before you rely on it. Perplexity documents two tokens with opposite robots.txt behavior: PerplexityBot, its indexing crawler, respects robots.txt, while Perplexity-User, the fetch a shopper's own question triggers, "generally ignores robots.txt rules" because a user requested it. A robots.txt block on Perplexity shapes indexing but does not stop a user-triggered fetch from reaching your pages when someone asks. That is not the engine misbehaving. A user-directed fetch that ignores robots.txt is a defensible and increasingly common design, and other engines document the same for their own user-triggered fetchers. Robots.txt governs crawling, not user-triggered retrieval, so it is the wrong tool for controlling what a shopper's agent can reach, and access decisions belong at the layer that actually sees each request. Our recommended stance is narrow. Allowlist the verified shopping and answer agents and let them through, and reserve rate limits for traffic you cannot verify: clients that claim to be a known agent but fail that engine's published verification method. Rate-limiting the verified agents that select you would be self-defeating. How to verify each engine's bots (their published IP ranges and reverse-DNS checks) is in the [AI shopping crawlers reference](/reference/ai-shopping-crawlers/). There is a limit to what documentation will tell you here. Google publishes its crawler IP ranges and a reverse-DNS method so you can confirm that a request claiming to be Googlebot really is, which is what an allowlist needs, but it does not document what a Google crawler sees when it meets a WAF challenge, a rate limit, or a geoblock. That silence matters because a merchant tends to assume a block produces a visible error somewhere, and nothing says it does. A rule that quietly turns an agent away usually shows up in your own logs before it shows up anywhere the engine reports, which is why the 403 count is on the measurement list below. Verification itself is gaining a stronger mechanism worth watching. Beyond IP ranges and reverse DNS, agents are starting to sign their requests cryptographically. Cloudflare's signed-agents program has bots authenticate themselves using the proposed Web Bot Auth mechanism, built on HTTP Message Signatures, with OpenAI's ChatGPT agent among the first participating cohort. Google states it is experimenting with the Web Bot Auth protocol for its agent traffic, using the https://agent.bot.goog identity. Web Bot Auth is an emerging proposal, an individual IETF Internet-Draft rather than a working-group-adopted or ratified standard, so keep each engine's published verification method as your source of truth for now. If the ecosystem lands on signed requests, the spoofer-vs-verified problem this section wrestles with largely dissolves. For context on how far operators under real pressure have gone, look at what some open-source projects reached for. Anubis is an MIT-licensed reverse proxy by Xe Iaso that issues a SHA-256 proof-of-work challenge to browser-like clients (those whose user-agent contains "Mozilla") before the request reaches the backend, and its documented adopters include GNOME's GitLab, the Linux kernel mailing-list archives, FFmpeg, Wine, UNESCO, FreeCAD, ScummVM, and Duke. That is a response to scraping abuse by projects without a budget to absorb it, and it is context here, not our advice. For a store that wants to be selected, a proof-of-work wall that challenges every browser-like client is the opposite of the goal: the aim is to make the door cheap to hold open, not to close it. ## Check what your CDN blocks by default Access control is not only what you set. It is also what your CDN decides on your behalf, and for a large share of stores that CDN is Cloudflare. Its default posture toward AI traffic changed on a dated schedule, and the change can work against selection if you leave it unread. Cloudflare stated: "On September 15, 2026, we'll be setting new defaults for each of these three classifications. For all new domains onboarding to Cloudflare, the categories of Training and Agent will be blocked by default on the pages that display ads, while Search will remain allowed by default." Its stated rationale was that "an ad is a signal that a website owner meant for a person to land there and see it." Read the scope before you react. This default is for new domains onboarding to Cloudflare, and it applies on pages that display ads, not site-wide and not as a silent switch thrown on every existing customer. An opt-out lives in the Security settings. The catch for a store is placement: if your ad-bearing product pages are where a shopping agent would land, a default that blocks the Agent class is a default that turns away the buyer's proxy. The sharper edge is what a training block does to a general search crawler. From the same date, Cloudflare judges "multi-purpose crawlers (specifically those that combine Search with Training)" by "all of their behaviors", so "multi-purpose crawlers such as Googlebot, Applebot, and BingBot will be blocked by customers who have selected to block Training." A merchant who once ticked a box to block AI training can lose Googlebot along with it. If you set a training block anywhere, confirm what else travels with it. The taxonomy underneath is now configurable by every customer, the Free tier included, and it sorts bot behavior three ways. In Cloudflare's own words: - Search is "any behavior that collects or indexes your content, so it can answer questions about it later." - Agent is "automated behavior that is acting, usually in real time, on a person's behalf, to get something done right now. This includes chat fetch bots (e.g., ChatGPT-User) and browser-use agents (e.g., Gemini or Claude driving Chrome)." - Training is "a crawler taking your content to train or fine-tune a model." The Agent class is the shopping-agent class. It is the ChatGPT-User fetch and the browser-driving agent working for a real shopper mid-decision. Block it and you have closed the door on the exact traffic this chapter is about keeping open. An older assumption also needs dropping: that a Verified label settles the question. Cloudflare stated that "non-verified bots are still default blocked, but we are no longer viewing Verified as 'default allowed.' Now, the Verified label makes a bot allowable with its relevant category." Verified now means allowable within a category, not allowed outright, so confirm that the categories you permit actually cover the agents you want in. Cloudflare also extended its robots.txt content signals with a use level that states how far a bot may reuse what it reads. Cloudflare defines these levels, least to most permissive, as `immediate` ("interact, but store and reuse nothing"), `reference` (the default, "index, excerpt, and link back"), and `full` ("summarize and reproduce"), carried by a new optional field such as `Content-Signal: search=yes,ai-train=no,use=reference`; it notes the signals express a preference rather than enforcement, and that "bots that reproduce in full cannot have the Verified status." Set the level that matches how you want your content reused, but treat it as a stated preference, not a lock. One more piece is still an experiment. Cloudflare is testing a reuse of the RFC 7239 `Forwarded` header, for example `Forwarded: for="openai"` or `Forwarded: for="openai";use="reference"`, so an allow decision can survive an intermediary that passes the request along. Watch it, but do not build against it as a requirement yet. The reason this is worth an afternoon is reach. Cloudflare stated that more than 20% of web domains sit behind its network. So turn it into a short task: - Find out whether your CDN classifies Agent traffic separately from Search, and whether the Agent class is currently allowed. - Check what your ad-bearing pages allow, since that is where the new default bites first. - Confirm that any "block AI training" setting you turned on is not also blocking Googlebot, Applebot, or Bingbot. ## What to measure Four numbers tell you whether you are affording openness or quietly paying for it. - Cache-hit ratio on the machine surfaces. Measure it per surface (llms.txt, Markdown mirrors, feeds, product pages) at your CDN or in your access logs. A low hit rate on a near-static surface means you are serving from the origin what you should be serving from the edge. - Origin egress and bandwidth, tracked before and after you add caching. This is the bill the Read the Docs and Wikimedia numbers describe, and the clearest sign your caching is working. - Crawl-to-refer ratio per agent. Compare requests from each engine's bots against the visits or conversions you can attribute to that engine. A very lopsided ratio is not a reason to block; it tells you which agents are worth the most caching effort and which you are subsidizing. - 403s (and any other blocks) returned to verified agents. This is the block you did not mean to ship: a WAF rule, a bot manager, or a plugin quietly rejecting an agent you wanted. Grep your access logs for these tokens and confirm they get 200s on a live product URL. If verified agents are being blocked and your products are missing from an engine's results, start the full diagnosis in [why your store is not in ChatGPT shopping](/store-not-in-chatgpt-shopping/), then step back to [how AI shopping agents choose products](/how-ai-agents-choose-products/) for the selection signals that decide the outcome once your origin is healthy and open. --- # Markdown Mirror for WooCommerce https://agentmint.net/integrations/woocommerce/markdown/ Markdown Mirror for WooCommerce is a free plugin that serves a read-only Markdown copy of each WooCommerce product page at the product URL plus a `.md` suffix, so an agent that prefers token-light text reads the same facts your product page shows. It is the reference implementation of this site's [product markdown mirror blueprint](/blueprints/product-markdown-mirror/): the format the blueprint specifies, shipped as installable code you can read and audit. ## Key takeaways - It serves a distinct .md URL beside every product page (for example /product/ceramic-dripper.md), carrying the same identifiers, specs, price, and availability the HTML page shows, ordered so the decision-relevant facts come first. - The mirror can never contradict the page. There is no agent-only content setting, so a mirror cannot say something a shopper does not see. - It is read-only and makes no remote requests: no telemetry, no analytics, no store writes. Mirrors are virtual URLs, generated on request and cached. - Ship it because it is cheap and standards-shaped, not because it is a proven ranking lever: no shopping agent documents fetching product Markdown today. ## Get the plugin Markdown Mirror for WooCommerce is free, published by AgentMint under the GPLv2 or later license, and listed in the WordPress.org plugin directory. [Get Markdown Mirror for WooCommerce](https://wordpress.org/plugins/markdown-mirror-for-woocommerce/) Free, GPLv2 or later. On the WordPress.org plugin directory. The quickest way to install it is from your own dashboard: go to Plugins, Add New, search for "Markdown Mirror for WooCommerce", then install and activate. Source code, the commit history, and the issue tracker live in the [GitHub repository](https://github.com/Abdalsalaam/markdown-mirror-for-woocommerce). ## What each mirror contains Each product mirror leads with the facts an agent selects on and omits any section with no data rather than padding it. A mirror can carry: - Identifiers: GTIN (WooCommerce's core field), SKU, and brand. - Classification: categories as hierarchical paths and tags, each linked to its archive or to its own `.md` mirror when taxonomy mirrors are on. - Specifications: visible attributes, weight, and dimensions. - Price with currency, sale end dates, and your store's tax display. - Availability using your store's own stock display, with a line per variation on variable products. - Reviews: the real average rating and review count, shown only when reviews exist. - Images: the main and gallery image URLs with their alt text. - The short and full product descriptions as plain text. Every mirror ends with a canonical link back to the product page and the product's real last-updated date. Sections with no data are omitted automatically, never invented. ## Discovery, canonical headers, and caching So agents can find the mirror, each product page gains exactly one `rel="alternate"` link tag pointing at its `.md` URL. The plugin adds no other markup and changes no titles or canonicals. Every mirror sends a canonical `Link` header pointing back at the HTML page and an `X-Robots-Tag: noindex` header, so the mirror never competes with your product page in search. Mirrors are cached with a short TTL and refreshed by invalidation hooks when a product changes, so a mirror does not drift out of step with the live page. ## Taxonomy mirrors Product categories, brands, and tags get `.md` mirrors of their archive pages too, each behind its own toggle. A category mirror carries the term name and description, its subcategories with their own mirror links, and its product list paginated at 100 per page (`/page/2.md`, `/page/3.md`, and so on), with the previous and next links stated in the document and an honest 404 past the last page. Category paths stay hierarchical, so `/product-category/clothing/shirts.md` reads as a path. Term mirrors follow the same archive visibility rules as the archive page, so catalog-hidden products stay out. ## What you control Everything is on by default. Under WooCommerce, Settings, Products, Markdown mirrors you can switch off any product mirror section (identifiers, classification, specifications, price, availability, variants, reviews, images, and the short and full descriptions) and any taxonomy group. Turning a section off only omits it; nothing turns a mirror into content your page does not carry. The plugin's settings section in WooCommerce: a green Good conflict status, the master mirror toggle, per-section content checkboxes, and taxonomy mirror toggles *The plugin's settings screen under WooCommerce, Settings, Products, Markdown mirrors, captured in a demo store.* The same screen carries a Status row that reports conflicts: if another active plugin also serves `.md` URLs, the row names it and explains why to keep only one. The plugin raises no admin notices. When you uninstall, everything it stored is removed (settings, cached mirrors, and term cache versions, across every site of a multisite network), and nothing else is touched. ## Scope and boundaries ### What it does It generates and serves a plain-Markdown copy of each product and taxonomy page from data your store already holds, orders it so identifiers and specifications come first, and makes each mirror discoverable and cacheable like any other URL. It reads your catalog; it does not add to it. ### What it never does - It never writes to your products, your theme, or your database content. Mirrors are virtual URLs, generated on request and cached. - It never sends anything anywhere. There is no telemetry, no analytics, and no remote requests: everything is generated inside your site and served from your site. - It never lets the mirror say something your page does not. There is no agent-only content setting, on purpose. Serving agents different content than shoppers is [cloaking](/handbook/information-density/), and the plugin makes that structurally impossible, because the mirror always reflects the same product data your shoppers see. ### The honest boundary Ship the mirror because it is cheap to serve and standards-shaped, not because it is proven to win selection. We have found no verified public source showing that a shopping agent (ChatGPT Shopping, Perplexity, or Gemini) fetches a Markdown representation of a product page. Treat product Markdown as proven for documentation and coding agents and unverified for shopping agents, and do not attribute a selection outcome to the mirror. The blueprint's [honest boundary](/blueprints/product-markdown-mirror/) carries the fuller, sourced version of this argument. ## Requirements - WordPress 6.5 or newer - WooCommerce 9.2 or newer - PHP 7.4 or newer - Pretty permalinks (Settings, Permalinks, anything except Plain), which the `.md` URLs need ## Where this fits The [product markdown mirror blueprint](/blueprints/product-markdown-mirror/) documents the format itself and the reasoning behind the section order. For the infrastructure around it, [serving agent traffic without breaking your origin](/handbook/serving-agent-traffic/) covers caching these surfaces, and [information density for agents](/handbook/information-density/) covers packing them with verifiable facts and staying on the right side of cloaking. To place a mirror in the wider readiness picture, work through the [agentic readiness checklist](/tools/agentic-readiness-checklist/) and the [agent selection checklist](/tools/agent-selection-checklist/). --- # Make Your Product Feed AI-Readable https://agentmint.net/make-product-feed-ai-readable/ ## Key takeaways - An AI-readable feed is one an agent can parse without guessing: every attribute filled, in the fields agents already look for. - Being parseable is table stakes: it makes you eligible to be scored. Being complete is the lever we argue can shift which product actually wins. - The fields agents read are the ones open commerce protocols already standardize: product identifiers, price, availability, and fulfillment options. - Gaps (a missing GTIN, a blank availability field, a brand-only title) are the most common reason an agent skips a product it could have picked. - You cannot judge feed completeness by eye; treat it as a number you track, the way you would track any ranking signal. ## What "AI-readable" actually means A feed that reads fine to a person can still be opaque to an agent. A human shopper fills gaps from context: they know "The Luna" is a sleep mask because of the photo and the shelf it sits on. An AI shopping agent has no shelf. It has your fields, and it scores what those fields say. "AI-readable" means the machine can extract every attribute it needs to compare you (identity, price, availability, category, use-case) without inferring anything. That gap between "looks fine" and "parses cleanly" is measurable, and it is wide. Retail product pages score an average of 66 out of 100 on Adobe's machine-readability index (meaning roughly a third of a typical product page is not cleanly machine-readable) versus 74 for category pages and 75 for homepages. The [product feed](/glossary/#product-feed) is where you close that gap most directly, because it is the one surface you hand agents in a fully structured form. See also the [machine-readability score](/glossary/#machine-readability-score) in the glossary. ## The attributes agents parse (and where they're defined) You do not have to guess which fields matter, because the open commerce protocols already enumerate them. The Agentic Commerce Protocol (ACP), the open checkout standard behind ChatGPT Instant Checkout, standardizes the core product attributes an agent reads, including product identifiers such as GTIN, price, and availability. The exact field names and syntax are the protocol's turf; we link the primary spec rather than reproduce it, because copying a schema teaches nothing about winning. What matters here is the *completeness* of those fields, not their syntax. Fulfillment is part of that set, and it has been for longer than most merchants assume. ACP has modeled shipping and fulfillment options since its September 2025 launch, and its current spec also exposes pickup, local delivery, delivery windows, and return-policy fields. So a feed that leaves shipping speed or availability blank is not omitting a "nice to have": it is leaving standard, expected fields empty where an agent went looking for them. (Eligibility to appear at all still depends on each platform's own onboarding, covered in the [platform playbooks](/platforms/).) ## Title anatomy: lead with the words shoppers type The single field agents lean on hardest is the title, because it is the text most directly matched against a shopper's query. The pattern that survives that matching is **category first, then defining attributes, then use-case, with the brand name last**: the opposite of the evocative, brand-forward titles built for human browsing. > Illustrative example, not measured data. A title built for a human catalog versus one built for an agent's query match: - **Before:** "The Luna" - **After:** "Organic Cotton Weighted Sleep Mask: Lavender, Adjustable Strap (The Luna)" The second title still carries the brand, but it now opens with the words a shopper actually types (the category, the material, the use-case) instead of a name only existing customers would recognize. This page treats titles as one field in the larger completeness picture; the full formula, the evidence behind it, and the "literal match" failure mode live on [product titles that AI agents match](/product-titles-for-ai-agents/). ## Completeness as a selection lever, not just an eligibility checkbox Here is the distinction most feed advice misses. There are attributes required to be *seen* (pass validation, clear the platform's minimums, become eligible), and there are attributes that plausibly shift which product an agent *selects* once several are eligible. Those are not the same list, and the second one is where the leverage is. We argue that feed depth is a selection lever and not merely an eligibility checkbox: once two products both clear a platform's minimum feed requirements, the one whose attributes are more completely and accurately filled gives the agent more signal to score in its favor, so completeness competes even among products that are all technically eligible. This is an inference, not a measured result. It follows from the [hub's evidence on how agents choose](/how-ai-agents-choose-products/): the study there shows agents rank on structured signals (price, rating, description text), and every one of those signals is only as good as the field feeding it. A blank field is a signal you declined to send. We cannot yet tell you *how much* each additional filled attribute is worth, and no public dataset does either. Treat completeness as a lever with a known direction and an unknown magnitude: worth pulling, worth measuring, not worth overclaiming. ## Google's conversational attributes: optional fields built for agents Google added a set of feed fields aimed squarely at AI shopping surfaces, and they map onto the selection question this page keeps returning to. Google's conversational product attributes are `question_and_answer`, `document_link`, `related_product`, `item_group_title`, `variant_option`, and `popularity_rank`, described as completely optional, complementing the core product data specification, and submitted through the feed or the Merchant API for AI Mode in Search and other surfaces. These are selection levers rather than eligibility checkboxes, because each hands the agent a signal it would otherwise have to infer or would miss. `related_product` and `variant_option` let an agent see the substitutes and options in your own catalog instead of reaching for a competitor's. `popularity_rank` gives it an in-catalog preference order it would otherwise have to reconstruct. `question_and_answer` puts your answers where an agent reads, in the structured feed, rather than in an on-page widget it may never reach. Google reports one figure on how often these fields get used, and it is worth reading with its caveat. Google states that in testing with lululemon, conversational attributes submitted by the brand were incorporated 50% of the time in relevant product recommendations in AI Mode. That is a single named test Google reported itself, with no methodology disclosed, so read it as directional evidence that the fields get used, not as a hit rate you can expect for your own catalog. Two more Google feed levers sit alongside them. The `video link` attribute powers shoppable visual ad formats, and connecting loyalty data in Merchant Center surfaces member perks and pricing across Google. On the payoff of feed discipline in general, Google reports that on average, merchants adopting core Merchant Center feed best practices see a 5% increase in conversions the following month, again a self-reported first-party number with no method disclosed. ## The gaps that make agents skip you Most feeds fail not on exotic fields but on the obvious ones left empty or stale. The most common reasons an agent skips a product it could otherwise have picked are missing or malformed identifiers, a blank or stale availability field, a price that disagrees between feed and page, and a brand-only title with no category the query can match. Each one is our inference from how agents parse feeds, not a measured failure rate. In practice the recurring gaps are: 1. **Missing product identifiers.** No GTIN (or a wrong one) removes the anchor agents use to match and de-duplicate your product across sources. 2. **Empty or stale availability.** An unfilled availability field, or one that lags real stock, is a reason to drop you rather than risk recommending something out of stock. 3. **Feed-and-page price disagreement.** When the feed and the on-page data conflict, the agent has to pick which to trust, and inconsistency itself is a demotion signal. Reconciling that mismatch is the job of [product schema for AI shopping](/product-schema-for-ai-shopping/). 4. **Brand-only titles.** A title like "The Luna" gives the query nothing literal to match; the category and use-case are missing entirely. 5. **Blank fulfillment fields.** Leaving shipping speed, delivery window, or fulfillment options empty forfeits fields the protocol already reserves for you. ## Apply it in ChatGPT and Gemini The same completeness work pays off across engines, but they ingest feeds through different pipes. ChatGPT surfaces products through ACP and its feed partners; Gemini and Google AI Mode draw on Merchant Center and Google's protocol stack. The field discipline is shared even where the plumbing is not, so fix the feed once, then read the engine-specific detail in [ChatGPT shopping optimization](/chatgpt-shopping-optimization/) and [Gemini & Google AI Mode shopping ranking](/gemini-shopping-ranking/). ## Feed completeness by destination Fixing the feed once gets you the shared core, but "valid feed" is not a single bar. The same catalog is read by more than one rail, and each destination validates it against its own spec, so a feed that clears one can still be incomplete for another. Start with the base every destination needs to render you and match you to a query. Google's Merchant Center product data specification requires id, title, description, link, image, availability, and price on every item, and lists brand, GTIN, MPN, and condition as conditionally required attributes. The [ACP](/glossary/#acp) product feed that supplies ChatGPT requires a stable item id, price, and availability on every item. The overlap of those specs is the practical shared core an agent needs on any rail: a stable id, a query-matchable title, a description, an image, price, availability, and identifiers, because an item missing any of them cannot be rendered or matched regardless of which destination you are optimizing for. Where the two specs diverge is where "completeness" stops being one number. _Feed completeness by destination: the shared core plus what each rail additionally requires or leans on. Every field in the table is sourced in the prose around it._ | Destination (rail) | Field-level spec it reads | Beyond the shared core, it keys on | | --- | --- | --- | | ChatGPT (Instant Checkout) | ACP product feed spec | Search, checkout, and advertising eligibility flags; a return policy plus seller privacy-policy and terms links on any checkout-eligible item; GTIN or MPN unless identifier_exists is no; per-item shipping (handling and transit days) | | Google AI Mode and Gemini | Merchant Center product data spec (UCP declares transactability) | Conditional attributes (brand, GTIN, MPN, condition); price and availability that match the landing page, structured data, and checkout | On the ChatGPT side, the ACP feed carries fields specific to its rail. The ACP product feed requires per-item search and checkout eligibility flags and a return policy on any item flagged checkout-eligible, and it carries per-item shipping fields down to handling and transit days. The eligibility flags now include one for advertising. OpenAI's product feed adds `is_ads_eligible`, a boolean that is conditionally required for Ads processing and keeps the legacy alias `is_eligible_ads` accepted, sitting beside `is_eligible_search` and `is_eligible_checkout`; setting `is_eligible_search` to false also disables checkout eligibility. The search flag is the master switch, then: turn it off and the product drops out of both organic search and checkout, whatever the other flags say. It also requires a `gtin` or `mpn` unless `identifier_exists` is set to no, and requires `seller_privacy_policy` and `seller_tos` links on checkout-eligible items. The identifier rule restates gap number 1 above as a hard requirement. On the Google side, the added weight is on consistency. The Merchant Center product data specification requires that price match across your landing page, structured data, and checkout, with the same parity required for availability and sale prices, so a Google-surface feed is only complete when all three surfaces agree. Getting those three surfaces to agree is the subject of [product schema for AI shopping](/product-schema-for-ai-shopping/). UCP does not change this field picture; it sits above it. On the Google side, UCP is a capability manifest at /.well-known/ucp declaring services, capabilities such as checkout and fulfillment, payment handlers, and signing keys: it governs whether an agent can transact with you, not which per-product fields you send. The per-product fields for that destination stay the Merchant Center specification above, so UCP is the transactability layer on top, which is why the two-rail comparison lives on [UCP vs ACP](/ucp-vs-acp/). Because each rail adds its own required and emphasized fields on top of that shared core, a feed that passes one destination's validator is not automatically complete for another: completeness is per-destination, and an honest feed audit checks the catalog against every rail you want to be picked on, rather than only the rail you happened to validate first. ## Feed fields ChatGPT reads that merchants treat as page content Several things a merchant files under "the product page" are, for ChatGPT, feed fields. Get them right on the page but leave them blank in the feed and the agent reads the blank. Seller identity is the plainest case. The feed requires `seller_name` and accepts `seller_url`, `store_country`, `seller_privacy_policy`, and `seller_tos`. Who you are is a feed field here, not only an About page an agent may never open. Reviews transfer, but not their full shape. The feed accepts `review_count` and `star_rating` on a 0 to 5 scale with two decimals, plus store-level `store_review_count` and `store_star_rating`. It has no star-distribution field and no recency field, and OpenAI states the reviews are not verified by OpenAI. The count and the average move; the distribution and how recent the reviews are do not. Since the agent reads unverified numbers you supplied, supply the true ones. Returns move the same way. The feed carries `accepts_returns`, `return_deadline_in_days`, `return_policy`, and `accepts_exchanges`. A generous return window stated only on a policy page is invisible to the comparison unless it is also in these fields. The description and title have hard ceilings. The feed asks for a factual product description of at most 5,000 characters and a title of at most 150 characters, with `variant_dict`, `size`, `color`, and `material` carrying variant detail, and it bars placeholder values. A field padded with "N/A" to clear a validator is worse than blank, because the agent reads it as a fact. These are the same facts you also express in on-page structured data, and the two copies have to agree. ChatGPT reads product data from the ACP feed, not from your page's Product and Offer markup. Google reads the on-page markup; ChatGPT reads the feed. So a correction applied only to your structured data leaves ChatGPT serving whatever the feed still says, and a stale price or return window survives a crawl-only fix. Update both, or you have fixed the version one engine never reads. ## The market gate: eligibility before ranking The costliest miss is not a badly ranked product. It is a product that was never eligible to appear, because it sells outside the market the engine serves. Two engines document that boundary in their own specs, independently, and neither treats it as a ranking factor, because it is not one. The OpenAI feed carries `target_countries` in ISO 3166-1 alpha-2 and a `store_country`, so a product is selectable only in the markets its feed declares. Microsoft states that only English-language merchants selling to US buyers in USD are eligible for its agentic commerce surfaces at this time. A merchant outside the served market can do everything else this page asks and still never appear. No amount of feed depth moves a market boundary, because the boundary sits before ranking, not inside it. Track it as its own gate: the [market eligibility signal](/signals/market-eligibility/) records which engine serves which country, language, and currency. ## Loyalty: a price the agent cannot see is a comparison you can lose Google gives loyalty its own feed attribute, and the benefit can surface inside an AI answer. Google documents a `loyalty_program` attribute and states that loyalty benefits are eligible to be shown on AI Mode and Gemini Apps, in the US only. The selection point is an asymmetry. A member price that only appears after a shopper signs in is invisible at the moment an agent lines up offers, so the agent can compare your list price against a rival's real price and rank you under an offer you would have beaten. Declaring the benefit through the loyalty attribute puts the price the shopper would actually pay where the comparison happens. Leave it behind a login and you can lose on a price you were never going to charge. The [loyalty benefits signal](/signals/loyalty-benefits/) tracks where this surfaces. ## Measure it, don't eyeball it Completeness is a number, so treat it like one. Scanning a feed by eye will not tell you what fraction of your catalog is missing a GTIN or carrying a brand-only title; a completeness audit will. Track it the way you track any ranking signal: as a baseline you can move and re-measure. How we structure those measurements, and the metrics we hold ourselves to, is documented in [how to test agent selection](/handbook/how-to-test-agent-selection/). This site publishes no measured figures of its own; the protocol is there so you can produce yours. --- # Information Density: Facts Per Token on Machine Surfaces https://agentmint.net/handbook/information-density/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It reads this chapter, audits your store against it, and reports before changing anything. Review everything your agent changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Apply this chapter to my store The agent audits your store against the chapter, then implements what you approve. ```text Fetch and read the full document at https://agentmint.net/handbook/information-density.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are applying this chapter to this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first and change nothing yet. Inventory which of the chapter recommendations apply to this store, evaluate the current state against each, and produce a report: already done, missing with the concrete fix, or not applicable with a reason. Name the recommendation each finding maps to. Then, only after I approve, implement the safe, non-destructive changes in small, reviewable steps. Stop and ask before anything ambiguous or destructive, or anything that changes customer-facing content. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: what is already in place, what you changed or propose, and the exact data or decisions you need from me. ``` ## Key takeaways - On a machine surface the scarce resource is the agent's token budget, so the page that packs the most verifiable facts per token, the specs, price, GTIN, availability, and policies, gives the agent the most to decide on. - Serving the same content in a different format (Markdown instead of HTML) at the same URL is standard HTTP content negotiation. Serving different content depending on the user-agent at one URL is cloaking, a Google Search spam violation. - Same-URL Accept-header negotiation and distinct .md mirror URLs are complementary implementations, not rivals. AgentMint ships distinct .md mirrors as a valid, conservative choice, not because they are safer. - Markdown content negotiation is documented and working for coding and documentation agents. We have no verified evidence that shopping agents send Accept: text/markdown, so do not build catalog strategy on it yet. > **Doctrine: format negotiation is legitimate; content-swapping by user-agent is cloaking** > > Two things that look alike are not the same. Serving the same content in a different representation at one URL, HTML for a browser and Markdown for an agent that asks for it, is ordinary content negotiation. Serving materially different content depending on who is asking, one thing to a search engine and another to a person, is cloaking. We read Markdown content negotiation as sitting outside Google's cloaking definition, because that definition turns on serving different content with intent to deceive, whereas format negotiation delivers equivalent content in a machine-preferred representation at the same URL. This is our reasoned synthesis of the primary definitions below, not a verbatim ruling from any search engine. The sourced version of that argument is a few sections down. ## What information density means for an agent An agent does not read your page the way a shopper does. It pulls text into a context window, and that window is a fixed budget it spends across your page, competing pages, the user's request, and its own reasoning. Every token your page uses on filler is a token the agent cannot spend on a fact. So the useful unit here is not word count or reading time but verifiable facts per token: how much an agent actually learns for each token it pays to read you. Vendors publishing guidance on serving Markdown to agents through 2026, including Vercel, Cloudflare, and Mintlify, each state that agents operate under context-window and token budgets, and that converting HTML to Markdown cuts token consumption and cost while preserving the decision-relevant content. That is the mechanical case for stripping page weight: a lighter representation of the same facts costs the agent less to read. The commerce case goes one step further, and it is our inference, not theirs. Structured, verifiable facts (specs, price, GTIN, availability, return and shipping policy) plausibly carry more decision weight per token than qualitative marketing prose, because they are the fields an agent can match against a shopper's query and compare across stores. A sentence of adjectives is expensive to read and hard to act on; a spec line is cheap and directly comparable. This is the practical core of a page's [machine-readability score](/glossary/#machine-readability-score): not how much you say, but how much of what you say an agent can use. ## Lead with verifiable facts; cut the marketing prose The move that follows from this is blunt: put the facts first and the prose last, or nowhere. On a surface built to be read by machines, lead with the fields that decide selection, the exact specifications, the price and currency, the GTIN, the availability, and the shipping and return policy, and treat brand-voice copy as optional garnish rather than the opening. The facts an agent needs are the same facts you already publish through your other channels, so there is no new content to write here, just a reordering and trimming of what exists. > Illustrative example, not measured data. A product page opens with "Sleep like never before with our revolutionary, cloud-soft comfort experience, lovingly crafted for the modern lifestyle." An agent reading that spends tokens and learns nothing it can act on. Rewrite the same page to lead with the facts: "Weighted sleep mask. 3D contoured, organic cotton, machine washable. GTIN 0123456789012. 24.99 USD, in stock, ships in 1-2 business days, 30-day returns." Every token now carries a fact an agent can match against a query. This is an illustration of the principle, not a measured result. Those verifiable facts do not live only on the page. The same fields belong in the two structured channels that agents read first: your [product feed](/make-product-feed-ai-readable/), which is the merchant-controlled data an engine ingests directly, and your [Product schema](/product-schema-for-ai-shopping/), which lets a crawler read the same facts off the live page. Information density is not a fourth place to keep your data; it is the discipline of making every surface that faces an agent lead with the facts and waste as few tokens as possible getting there. ## Content negotiation is legitimate; cloaking is not The moment you serve a machine-friendly version of a page, someone will ask whether that counts as cloaking. The answer depends entirely on what varies, and the primary definitions draw a clean line. Google defines cloaking as "the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users." The violation is in the word different: two audiences, two contents, one deceptive intent. Google's own example of cloaking is "Inserting text or keywords into a page only when the user agent that is requesting the page is a search engine, not a human visitor," which names user-agent-conditional content as the violation directly. Now hold that against what content negotiation actually is. MDN defines content negotiation as "the mechanism that is used for serving different representations of a resource to the same URI," selected by the client's Accept header, which lists the media types it is willing to receive. Different representation of the same resource is precisely not different content. It is the same facts, encoded once as HTML and once as Markdown, chosen by an honest signal the client sends about what it can parse. Bing's Webmaster team made a compatible point in 2018: returning server-rendered content to bots and client-rendered content to people is acceptable and not cloaking, as long as you make a good-faith effort to return the same content to every visitor. Treat that as dated corroboration of the principle, not current policy, since it is a 2018 blog post. Bing's current Webmaster Guidelines state: "Showing different content to search crawlers than to users is a manipulative practice that undermines trust and visibility. Sites should not rely on cloaking or serving materially different experiences to crawlers and visitors." As of 2026-07-08 the live guidelines no longer carry the 2018 good-faith wording, and they list cloaking among the practices that reduce ranking eligibility and grounding visibility across Bing and Copilot experiences. The boundary is still content equivalence, now extended explicitly to Copilot and grounding; the current guidelines say nothing about dynamic rendering, so do not read Bing as endorsing that technique today. Put the three together and you get the doctrine at the top of this page: format negotiation keeps the content equal and only changes the encoding, so it does not meet Google's different-content-plus-intent test for cloaking. What would cross the line is trivial to describe. If you served an agent a Markdown page stuffed with keywords or claims that never appear in the HTML a shopper sees, that is different content by user-agent, and it is cloaking. The rule is not the format. The rule is equivalence. ## Two honest ways to serve a machine format There are two well-documented ways to hand an agent a Markdown copy of a page, and they are not rivals. Pronovix, writing in March 2026, frames same-URL Accept negotiation and distinct .md URLs as complementary rather than competing, recommends pairing a Markdown alternate with a canonical link so search engines still consolidate on the HTML page, and notes that its own module does not push Markdown to bots that never requested it. The first way is same-URL negotiation: the page at `/product/weighted-sleep-mask` returns HTML by default and Markdown when the request sends `Accept: text/markdown`. One URL, two representations, chosen by the header. The second way is a distinct mirror URL, for example `/product/weighted-sleep-mask.md`, that always returns Markdown regardless of the header. The llms.txt spec's v2 revision accepts both spellings of that mirror URL: appending `.md` to the full filename (`page.html.md`) or replacing the extension (`page.md`). For agents that cannot send an Accept header, both approaches lean on the same discovery hint. Vercel recommends advertising the Markdown alternate with a `` element so an agent that cannot negotiate can still find it. What began as vendor practice is now in the spec. The llms.txt spec's August 2026 v2 revision standardizes that discovery layer: a page advertises its Markdown version with `rel="alternate" type="text/markdown"` and points at the llms.txt file that covers it with `rel="describedby"`, delivered either as link elements or as HTTP Link headers. Developer handoff: point the alternate at the Markdown resource and keep a `` on the HTML page so ranking signals stay consolidated there. AgentMint itself ships distinct .md mirror URLs rather than same-URL negotiation. We treat that as a valid, conservative choice, not a safer one: it needs no Accept-header branching at the edge, it caches and links like any other URL, and it stays discoverable through a rel=alternate reference. Same-URL negotiation is equally legitimate; the two are implementation options, not a safety ranking, and no source we verified ranks one above the other. Read our own worked examples at [/llms.txt](/llms.txt) and by appending `.md` to any page URL. ## The honest boundary This is where the chapter has to be careful, because the evidence stops short of where the hype wants to go. The vendors documenting working Accept: text/markdown negotiation through 2026 are documentation and developer-tooling platforms, and the consumers they describe are coding and documentation agents. That is a real, proven pattern in that context. It is not proven for shopping. We have found no verified public source showing that a shopping agent (ChatGPT Shopping, Perplexity, or Gemini) sends Accept: text/markdown, or otherwise negotiates a Markdown representation of a product page. Treat content negotiation as proven for doc and coding agents and unverified for shopping agents, and do not assume a shopping agent will fetch your Markdown just because you serve it. Re-checked 2026-07-08: the primary crawler documentation from OpenAI, Perplexity, and Anthropic documents robots.txt as the control mechanism and never mentions Accept-header Markdown negotiation, and OpenAI's Agentic Commerce product feed spec describes a structured feed file, not page-format negotiation. Google's AI-features optimization guide, updated in June 2026, states: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search." All of that is absence of documentation, not proof that no agent ever sends the header. Ship the machine format because it is cheap and standards-compliant. Do not attribute a selection outcome to it. If your products are missing from an engine's results, the format of an alternate representation is far down the list of likely causes; walk the real diagnosis in [why your store is not in ChatGPT shopping](/store-not-in-chatgpt-shopping/) first. ## Apply it: llms.txt, schema, and feeds The same facts-per-token discipline shapes the one machine-index format with a public spec. The llms.txt spec, revised to v2 in August 2026, fixes the file's order: an H1 with the site or project name (the only required element), then an optional blockquote one-line summary, then zero or more non-heading Markdown blocks, then zero or more H2 sections, each an unordered list of links written as `[name](url): optional notes`. v2 also clarifies scope: a file covers the pages under its path, and the most specific file applies. The format itself is owned by llmstxt.org and we link out to it rather than restate it; what belongs here is the judgment about what goes in which slot. Order is your only lever, and the spec now leans on it less than it once did. Under the 2024 v1 spec, an H2 section titled "Optional" marked links whose URLs could be skipped when a shorter context was needed; the August 2026 v2 revision removes that skip mechanism (and the context-expansion tooling built on it), keeps "Optional" only as a plain convention for secondary links, and instead expects an agent to view or search the file and follow the links relevant to its task. That leaves ordering as an editorial discipline rather than a spec mechanism, and we keep it anyway: order your link lists by decision weight, not by site-map convenience, with the pages that carry buying-relevant facts near the top and the secondary material under "Optional," because an agent scanning the file top to bottom still meets your best surfaces first. The spec sets no explicit maximum file size, token, or byte cap, so density is a discipline you impose, not a limit the spec enforces. For how llms.txt fits alongside your crawler policy, see [AI crawlers, robots.txt and llms.txt for stores](/ai-crawlers-robots-llms-txt/). Two vendor figures get quoted a lot in this space, and both are illustrations rather than benchmarks. In one Vercel example, negotiating Markdown cut a page from roughly 500KB of HTML to about 3KB, which Vercel put at about a 99.37% payload reduction. That is a single illustrative figure from Vercel, not a benchmark you should expect to reproduce. Cloudflare's edge feature converts HTML to Markdown on the fly when a request sends Accept: text/markdown, and returns `x-markdown-tokens` and `x-original-tokens` response headers so the token difference is measurable per response. Cloudflare did not date this reference page precisely, so we record its date as approximate. If you want a number for your own catalog, that header pair is where to read it, on your own pages, rather than borrowing a vendor's example figure. The step-by-step machine-surface runbooks now live in the [blueprints](/blueprints/) hub: [llms.txt for e-commerce catalogs](/blueprints/llms-txt-for-ecommerce-catalogs/), the [product markdown-mirror template](/blueprints/product-markdown-mirror/), and [token-efficient product JSON-LD patterns](/blueprints/token-efficient-product-json-ld/) carry the build steps, and this chapter carries the doctrine they implement. ## What to measure - Facts in the first screen of tokens. Take a product page's HTML or Markdown, keep the first 200 words, and count how many verifiable facts appear (spec, price, GTIN, availability, policy). If the answer is near zero because the opening is brand copy, reorder. - Payload delta, read on your own pages. If you serve a Markdown representation through Cloudflare, read the `x-markdown-tokens` and `x-original-tokens` headers on a real product URL and record the ratio. Do not quote a vendor's example figure as if it were yours. - Equivalence check, the cloaking guard. Diff the facts in your Markdown or .md mirror against the HTML a shopper sees. Any fact, price, or claim present in one and absent from the other is a cloaking risk; fix it so the two are equivalent. - llms.txt order audit. Confirm the buying-relevant pages sit at the top of the file and the low-value URLs under "Optional," which since the spec's v2 revision is a plain secondary-links convention rather than a skip directive. Read your live [/llms.txt](/llms.txt) and rank it by decision weight, not by navigation. - Alternate discoverability. Verify each HTML page exposes a `` to its Markdown resource and a `` to itself, so agents can find the format and search engines still consolidate on the page. Once these surfaces exist, the next question is keeping them fast and fresh for agents that refetch often. Continue with [serving agent traffic](/handbook/serving-agent-traffic/), and return to [how AI shopping agents choose products](/how-ai-agents-choose-products/) for where density sits among the other selection signals. --- # WooCommerce and agentic commerce: what actually ships today https://agentmint.net/integrations/woocommerce/agentic-commerce/ A WooCommerce store cannot complete a sale through a shopping agent today on WooCommerce's own code alone: the agentic features shipped in core are for store management, while the two shopper-facing checkout rails WooCommerce points at, Google's UCP and OpenAI's ACP, are still marked coming soon and are reached through partner extensions or third-party plugins. ## Key takeaways - WooCommerce's live agentic features (MCP and the Abilities API) let a merchant's own AI assistant read the store. No shopping agent buys through them. - WooCommerce lists Google's UCP and Stripe's ACP as coming soon, and routes them through the Google for WooCommerce and Stripe for WooCommerce extensions. - Core releases 11.0 and 11.1 shipped no agentic features, and the public request for native UCP support has sat open since January with no update. - The work that helps regardless of rail comes first: accurate real-time stock, shipping and returns on the product page, and a clean Merchant Center feed. ## What WooCommerce says ships today WooCommerce publishes its own protocol status, and it is the honest starting point because it separates what is live from what is not. _WooCommerce's own agentic-commerce status, summarized from its protocol table. The live rows are quoted verbatim and sourced in the prose below._ | Status | Protocol | WooCommerce's wording | | --- | --- | --- | | Live | Model Context Protocol (MCP) | AI assistants can read your store's products, orders, and settings. Shipped in WordPress 6.9 and WooCommerce 10.3 with 9 built-in abilities. | | Live | Abilities API | Your store declares what it can do in a format any AI agent understands. Built into WordPress core. | | Coming soon | Universal Commerce Protocol (UCP), Google | Google's protocol for AI-powered shopping, built on Merchant Center and structured data. | | Coming soon | Agentic Commerce Protocol (ACP), Stripe | Connects your catalog to multiple AI agents through the Stripe Agentic Commerce Suite. | WooCommerce's agentic-commerce page marks MCP as live, describing it as letting "AI assistants can read your store's products, orders, and settings," and stating it "Shipped in WordPress 6.9 and WooCommerce 10.3 with 9 built-in abilities". The same page marks the Abilities API as live, describing it as the way a store "declares what it can do in a format any AI agent understands," built into WordPress core. The version numbers in that MCP line are WooCommerce's own wording, quoted here rather than restated as a shipping date. The two shopper-facing rails are a different column. The page lists Google's Universal Commerce Protocol and OpenAI and Stripe's Agentic Commerce Protocol as "coming soon," and names two sync extensions, Google for WooCommerce and Stripe for WooCommerce, as the path to them. WooCommerce's own setup steps for those extensions are its documentation to write and keep current, so this page links to them rather than reproducing them. ## Store management is not a shopper-facing rail The single most common misreading of this table is that live MCP means a WooCommerce store is now buyable inside ChatGPT or Gemini. It is not, and the distinction matters. WooCommerce's developer roadmap states that "As of WooCommerce 10.3, an early version of the WooCommerce MCP integration is in beta and ready for broader testing". What that integration exposes is a store's own data to a merchant's own AI assistant: reading products, orders and settings. We read this as store management rather than a selection rail. It lets you point an assistant at your own store, but no shopping agent completes a purchase for a shopper through it, so installing MCP does not place a store inside a shopping agent's results. If the goal is to be selected and bought by a shopper's agent, MCP is not the mechanism, and treating it as one wastes the quarter. ## What WooCommerce tells merchants to do WooCommerce's own merchant guide is the useful part of its output here, because most of it holds no matter which rail arrives first. WooCommerce's merchant prep guide tells stores to keep real-time stock from a single source, put shipping and return details on the product page, use the Stripe for WooCommerce extension as the ACP on-ramp, feed Google Merchant Center through the Google for WooCommerce extension, and re-test quarterly in ChatGPT, Gemini and Perplexity. One constraint in that guide is specific and easy to miss. The guide states that stores using WooPayments cannot use the Stripe ACP path yet. If you are on WooPayments and were counting on the Stripe extension for the OpenAI rail, that is a plan you cannot execute today. For the substance behind those steps, [make your product feed AI-readable](/make-product-feed-ai-readable/) covers the feed, and [UCP vs ACP](/ucp-vs-acp/) covers what each rail actually standardizes. ## Where the gap is WooCommerce's agentic push is real, but it lives outside core releases, and the honest reading of the release history matters to anyone planning a roadmap. WooCommerce 11.0 covered foundations cleanup, guest checkout and analytics, and shipped no agentic, AI, MCP, UCP, ACP or feed features. WooCommerce 11.1 covered variation image galleries, EU order-withdrawal rights, a 30-42% speedup to the Store API and REST API, and an experimental product-gallery video, and likewise shipped no agentic, AI, MCP, UCP, ACP or feed features. The agentic capability that exists came from the 10.3 MCP integration and from partner extensions, not from a recent core release. The clearest signal of where native support stands is a request WooCommerce has left open. The public feature request for native UCP support was submitted on 2026-01-13, carries 34 votes and 9 comments, and its status is still open with a last update of 2026-01-13, as read on 2026-09-18. So the agentic-commerce page says UCP is coming soon while the public request for it sits open and unanswered eight months on. We read this as native agentic support that is signalled but not scheduled. A merchant who needs an agent checkout rail this quarter should plan for the extension path or a third-party plugin, not wait on a core release. That is a statement about timing, not a criticism of the approach: WooCommerce's open architecture is a genuine argument for adopting protocols on your own schedule, and the Stripe and Google extensions it points at are real, shipping code. ## The WordPress layer underneath WooCommerce's agentic features build on primitives that live in WordPress core, and that layer is moving on its own track. WordPress 7.0 adds a provider-agnostic PHP AI Client, giving plugins a single interface to call model providers. WordPress 7.0 also adds a client-side JavaScript Abilities API and a Connectors API, building on the Abilities API introduced in WordPress 6.9. For a store, the practical point is that the machine-readable declaration WooCommerce leans on is a WordPress-level capability, so it will keep growing under any commerce plugin, not only under WooCommerce. ## The third-party plugin path Until WooCommerce ships native UCP and ACP, community plugins are how a store gets on the Google and OpenAI rails, and at least one is worth looking at as a concrete example of what that involves. An independent GPL-2.0 plugin, ucp-for-woocommerce, implements both UCP (spec v2026-04-08) and OpenAI's ACP (spec v2026-04-17) for WooCommerce, with HTTP Message Signatures, JSON-validated product feeds and Stripe Shared Payment Tokens. Its maintainer states that it "Passes the official UCP conformance suite: 75/75 (2 expected skips)". That figure is the maintainer's own claim and is not independently verified here. Other community plugins target the same gap; this page examined only the one linked above and does not endorse any of them. Treat any of these the way you would treat any code that touches checkout. A plugin that handles a live checkout flow and holds signing keys deserves a security review before it goes near a production store. That is not a knock on any project; it is the baseline for code that can move money. ## What to do today The ordering below puts the work that pays off regardless of which rail arrives first, then the rail-specific work that depends on someone else shipping. 1. Fix the product-page fundamentals first. Keep real-time stock accurate from a single source, and state shipping and return terms on the product page. WooCommerce names accurate single-source stock and shipping and return details on the product page as prerequisites for selling through AI. This is available now and helps every agent that reads your store. 2. Publish a clean Merchant Center feed through the Google for WooCommerce extension. Available now, and it is the same feed work UCP will build on. See [make your product feed AI-readable](/make-product-feed-ai-readable/) for what "clean" means field by field. 3. Add the ACP on-ramp when you need it, through the Stripe for WooCommerce extension, remembering that WooPayments stores cannot use that path yet. This depends on the extension, not on WooCommerce core. 4. If you need an agent checkout rail before native support lands, evaluate a third-party UCP or ACP plugin, and put it through a security review first. This is the option that does not wait on anyone else. 5. Re-test quarterly. Agent behavior and protocol status both move, so a working setup is a thing to re-check, not a thing to finish. [Serving agent traffic without breaking your origin](/handbook/serving-agent-traffic/) and [information density for agents](/handbook/information-density/) cover the infrastructure and content sides of keeping those surfaces cheap and legible. The split we would keep in mind: steps one and two are available today and depend only on you, while steps three and four depend on a partner extension or a plugin author, and native support depends on WooCommerce shipping it. --- # Product Schema (JSON-LD) for AI Shopping https://agentmint.net/product-schema-for-ai-shopping/ ## Key takeaways - Product JSON-LD isn't a ranking trick: it's how you hand an agent the selection signals (price, availability, reviews) in a form it can read without guessing. - When your live page and your submitted feed disagree, we expect an agent to trust the machine-readable layer on the page, because it is unambiguous where scraped text is not. - The schema fields that matter are the ones that map to selection signals (Offer price and availability, and genuine review or rating fields), not decorative markup. - Retail product pages average only 66 out of 100 for machine readability, so how completely your structured data is filled in is a real lever, not a checkbox. - Never ship empty or misleading schema: fabricated reviews, prices your page doesn't show, or FAQ/HowTo markup that misrepresents the page is a dark pattern that risks trust and manual actions. ## Why product schema is the agent's tie-breaker An AI shopping agent doesn't read your product page the way a person does. It parses it. The cleanest thing on the page to parse is the structured-data block: the JSON-LD an agent can lift field by field without interpreting your layout, your marketing copy, or your CSS. Product, and the nested Offer type it carries, are defined by the open schema.org vocabulary, the same structured-data standard search engines have read for years. That vocabulary is official-docs turf: the exact field names and their syntax are schema.org's to define, and we link to them rather than restate them. What's left for this page is narrower, and it is our territory: *which* of those schema signals actually shift whether an agent selects you, and why an agent leans on schema in the first place. The reason is ambiguity. Everything an agent needs to score you (is this in stock, what does it cost, how well is it reviewed) is exactly the data that structured markup states unambiguously and that free-text page copy states messily. Those selection signals, and the evidence behind them, are the subject of the hub for this cluster, [how AI shopping agents choose products](/how-ai-agents-choose-products/); this page is about how you hand those signals over in a form an agent trusts. ## Which schema fields carry selection weight Not every field on a Product node changes an outcome. The ones that do are the ones that map directly to a signal an agent is already scoring: 1. **`Offer` with `price` and `priceCurrency`**: price is one of the strongest, most model-variable selection levers, so an unambiguous machine-readable price beats a number an agent has to scrape out of your page copy. 2. **`Offer` `availability`**: an agent that can't confirm you can fulfil an order has an easy reason to skip you; stating availability in schema removes that doubt. 3. **`review` and `aggregateRating`**: rating depth moves selection, so genuine review data belongs in structured form. Only mark up ratings that are real and visible on the page (see the anti-pattern section below). 4. **Product identifiers** (`gtin`, `brand`, `sku`): these help an agent resolve your item to a known product and reconcile it against a feed rather than treating it as an unknown. This field set is not frozen, and the direction of travel matters: Google keeps widening what merchant-listing markup can state. In July 2026 Google added `category` property support to merchant listing structured data, accepted as text or as a category code, and documented sale-price timing through the `validFrom`, `validThrough`, and `priceValidUntil` properties. Both map straight onto selection signals: `category` gives a query one more literal surface to match, and dated sale pricing tells an agent exactly when the price it read stops being true, which is the offer-consistency problem in miniature. The point of listing these is not to teach the markup: schema.org already does that better than we could. The point is that these are the fields worth auditing first, because they are the ones tied to a decision. And completeness is itself the lever: on Adobe's AI Content Visibility Checker, retail product pages score an average of 66 out of 100 for machine readability, meaning roughly a third of a typical product page is not machine-readable to an agent at all. The gap between a page that scores well on its [machine-readability score](/glossary/#machine-readability-score) and one that doesn't is usually the fields above, left empty. ## Feed versus schema: what an agent trusts when they disagree Most stores expose product data through two channels at once. One is the **feed**: the structured product data you submit to a platform (a Merchant Center feed, or a protocol product feed), covered in depth in [make your product feed AI-readable](/make-product-feed-ai-readable/). The other is the **schema** an agent reads off your live product page. When both agree, this is academic. When they disagree (a stale feed, a price the page updated but the feed didn't), an agent has to pick a version. When a store's feed and its live product page disagree, the machine-readable layer an agent can parse directly from the page is the version we expect it to trust, because on-page JSON-LD is the current, unambiguous state of the item, where a feed can lag and page copy can mislead. We label that an inference, not a measured fact. But it is why schema is worth shipping even when you already run a clean feed: it is the tie-breaker that keeps a data mismatch from quietly costing you the selection. > Illustrative example, not measured data. A shopper's agent is comparing two sleep masks. Your feed, refreshed nightly, still lists last week's price and "out of stock." Your product page (updated this morning) shows the new lower price and "in stock," and says so in its Product/Offer JSON-LD. The agent that reads the page has an unambiguous, current answer; the agent that only trusts the stale feed skips you over a problem you already fixed. Keeping schema and feed in sync closes that gap. ## What not to do: no empty or misleading markup This is the section where the temptation to game schema is strongest, and where doing so backfires. The rule is simple: **mark up only what is true and visible on the page.** - **No fabricated reviews or ratings.** Inventing `aggregateRating` values, or marking up reviews that don't exist on the page, is exactly the kind of fake signal our whole approach exists to argue against, and it is a well-known trigger for search manual actions. Google is tightening this seam explicitly: in July 2026 Google updated its review snippet documentation to address fake reviews and undisclosed incentivized reviews. - **No phantom fields.** Don't state a price, availability, or offer in schema that the page itself doesn't show. Empty or contradictory markup is a mismatch an agent can catch, and it erodes the trust that made schema a tie-breaker in the first place. - **No misleading FAQ or HowTo markup.** It is tempting to wrap thin content in these types to look richer. It no longer even earns the visual payoff: Google retired HowTo rich results in 2023. FAQ rich results were first restricted to authoritative government and health sites that same year, then fully retired for all sites effective May 7, 2026, so marking up how-to steps or FAQs on a store page no longer produces a rich result in search for anyone. This is also why every how-to page on this site uses `TechArticle`, not `HowTo`: the type should describe what the page genuinely is. The honest version of "richer schema" is completeness of the true fields, not decoration, and never invention. ## Validating your schema (link out for the syntax) Validation is official-docs turf, and the tools are free, so use theirs rather than a rewrite of ours. Paste a product URL into [Google's Rich Results Test](https://search.google.com/test/rich-results) to see what Google parses, and check the shape of your markup against the [schema.org Product reference](https://schema.org/Product) and [Offer reference](https://schema.org/Offer). The goal isn't a passing badge: it's confirming that the fields that carry selection weight are present, accurate, and match what a shopper sees on the page. If you're starting from a blank page, the [token-efficient product JSON-LD blueprint](/blueprints/token-efficient-product-json-ld/) ships verified single-product and multi-variant skeletons with the fields above already in place. ## Apply this in ChatGPT and Gemini Schema is one of the levers, not the whole game. It works alongside a complete [product feed](/make-product-feed-ai-readable/) and titles a shopper actually searches, and which engine reads which data over which rail is its own decision. See [UCP vs ACP: which gets you selected](/ucp-vs-acp/). To turn this into per-engine work, pair it with the platform playbooks: [ChatGPT shopping optimization](/chatgpt-shopping-optimization/) and [Gemini and Google AI Mode shopping ranking](/gemini-shopping-ranking/). Ship the true fields, keep them in sync with your feed, validate with the official tools, and let the machine-readable layer speak for you when the agent is deciding. --- # Why You're Not in ChatGPT Shopping https://agentmint.net/store-not-in-chatgpt-shopping/ ## Key takeaways - A store missing from ChatGPT shopping is almost always a data-legibility problem, not an eligibility one, so work the causes in a fixed order instead of changing everything at once and refreshing to see what happens. - Diagnose in sequence, most fundamental cause first: does the engine serve your market at all, can the crawlers reach your pages, is the feed complete enough to represent a buyable item, do your titles and categories carry the words a shopper types, and only then, have you cleared the official eligibility bar? - The cheapest check comes first: confirm the engine serves your country, language, and currency. Outside the served market you are not eligible, and no data work changes that. - Rule out the silent blocker early: confirm the surfacing crawlers (OAI-SearchBot, ChatGPT-User) can actually fetch a live product URL. A WAF, a CDN bot-manager, or a stray Disallow returning a 403 is just as fatal as being ineligible, and far easier to miss. - Most misses resolve at the feed and title steps: a feed row with no availability can't be represented as buyable, and a title without the words a shopper types has nothing to match against. - There is no hidden 'enroll' switch to flip. Once you've ruled out the data causes and cleared eligibility, stop diagnosing and measure. This page finds the cause, and the ChatGPT optimization playbook is where the fixes live. ## The diagnostic order When your products don't appear in ChatGPT, the instinct is to change everything at once: rewrite titles, resubmit the feed, edit robots.txt, and refresh to see what sticks. Resist it. The causes sit in a dependency chain, and fixing a downstream one while an upstream one is still broken changes nothing you can observe, which is how stores waste weeks chasing the wrong lever. Work the causes in this order, stopping at the first one that's true: 1. **Does the engine serve your market at all?** Country, language, and currency. Outside the served market you are not eligible, so this free check comes first. 2. **Can ChatGPT's crawlers reach your pages?** If they're blocked, nothing downstream is visible. 3. **Is your product feed complete enough** to represent the item as a purchasable offer? 4. **Do your titles and categories contain the words a shopper actually types?** 5. **Have you cleared OpenAI's own eligibility process?** This page is the reactive "why am I not showing?" flow. Each branch below tells you how to confirm whether it is *your* cause, then hands you off to the page that fixes it. It diagnoses, it does not re-teach the fix. When you want the proactive, do-all-of-this-up-front version instead, that is the [ChatGPT Shopping Optimization playbook](/chatgpt-shopping-optimization/), which is this page's sibling: one troubleshoots, the other optimizes. ## 1. Are you in a served market? Before touching a feed or a line of markup, rule out the cheapest cause: the engine may not serve your market at all. Check three things against what the engine publishes, the countries your feed declares, the language your listings are written in, and the currency you price in. OpenAI's feed carries `target_countries` in ISO 3166-1 alpha-2 and a `store_country`, so a product is selectable only in the markets its feed declares. Microsoft states that only English-language merchants selling to US buyers in USD are eligible for its agentic commerce surfaces at this time. If you fall outside that box you are not ranked badly, you are not eligible, and no feed or markup work changes it. This is a market boundary that sits before ranking, so confirm it before spending a day on structured data. The [market eligibility signal](/signals/market-eligibility/) records which engine serves which country, language, and currency. ## 2. Are the crawlers blocked? Two separate pipes carry your products into ChatGPT (your structured [product feed](/glossary/#product-feed) and your live pages), and the fastest miss to rule out is that ChatGPT simply can't read the second one. OpenAI documents the agents that surface sites inside ChatGPT: OAI-SearchBot, which indexes and links pages and carries a named user-agent token that robots.txt can allow or disallow, and ChatGPT-User, the fetch triggered when a user's own request reaches your URL, whose robots.txt rules may not apply because that fetch is user-initiated rather than a crawl. A `Disallow` blocks OAI-SearchBot outright, but ChatGPT-User needs a different lever: because robots.txt may not govern it, a merchant who wants to control that fetch has to look at a web application firewall, a CDN "bot manager," or a "block AI bots" plugin at the edge instead. Both paths (a robots directive or an edge-layer block) add up to the same failure mode: an agent that is shut out cannot see your catalog at all, and every later step is moot. The diagnostic is concrete: fetch a live product URL the way one of those agents would, and confirm it returns the page and not a block. If it doesn't, that's your cause, and the allow-list that fixes it, plus the edge-layer gotchas that cause most accidental blocks, live in [AI crawlers, robots.txt & llms.txt for stores](/ai-crawlers-robots-llms-txt/). Fix it there, then come back and check whether the products appear before touching anything else. ## 3. Are there gaps in your product feed? If the crawlers can reach you and you're still missing, the next cause is a feed too thin for an agent to treat your item as a real, buyable offer. The Agentic Commerce Protocol (the open standard OpenAI and Stripe use for ChatGPT commerce) defines the product-feed fields an agent consumes, including availability and price, so an item can be represented and transacted. A feed row that leaves availability blank can't be shown as in stock, and one with no category is hard to file under the category a shopper is browsing. Those are legibility gaps, not eligibility failures: the item is allowed, it's just under-described. OpenAI's own feed spec makes that bar concrete enough to audit against. The product feed specification requires `item_id`, `title`, `description`, `brand`, `image_url`, `price` with an ISO 4217 currency, an enumerated `availability` value, `seller_name`, `target_countries`, and a product `url` that returns HTTP 200; `gtin` or `mpn` is required unless `identifier_exists` is set to no; and each item carries `is_eligible_search` and `is_eligible_checkout` flags, with `seller_privacy_policy` and `seller_tos` required once an item is flagged checkout-eligible. Two diagnostic reads follow. A row missing any required field is not a complete offer, however good the product. And the two eligibility flags mean surfacing is per-capability: an item can be flagged for search but not for checkout, so check which flags your feed actually sets before concluding you are invisible everywhere. `is_eligible_search` defaults to true, and setting it to false also disables checkout eligibility. So a single feed flag can pull a product out of both search and checkout silently; confirm it is not set to false before you assume the miss is a data gap. This is a data-completeness problem, and the fix is a checklist rather than a switch. Rather than repeat it here, walk it in [make your product feed AI-readable](/make-product-feed-ai-readable/), which covers exactly which attributes to fill and why the gaps are what make agents skip you. Return here only if a complete feed still doesn't surface you. ## 4. Do your titles and categories match the query? With the crawler and the feed both cleared, the remaining common cause is subtler: you're eligible, visible, and complete, but nothing you publish contains the words the shopper is actually typing. Agents match a shopper's query against your title and category fairly literally, so a brand-led title like "The Luna" has nothing to match for a query like "organic cotton weighted sleep mask", which is how a perfectly eligible product can stay invisible for the exact search it should win. This is the one cause that looks like an eligibility problem but is really a matching one, and it's why "we did everything right and still don't show" is so common. The fix (the title formula that leads with category, attribute, and use-case) is in [product titles that AI agents match](/product-titles-for-ai-agents/); this page's job is only to point you there once the three upstream causes are ruled out. ## 5. Have you cleared the official eligibility bar? Only after the three data causes are genuinely excluded is it worth suspecting eligibility, and even then, eligibility is the one branch we deliberately link out on rather than teach, because it is official-docs turf and it changes. The Agentic Commerce Protocol's own FAQ says implementing it does not guarantee automatic product listings: each AI platform "will manage their own process" for how businesses can participate, so passing the protocol's technical bar and clearing a platform's eligibility review are two different things. OpenAI runs its own merchant eligibility process, and its shape is now stated in OpenAI's own developer docs. OpenAI's commerce documentation states that onboarding product feeds in ChatGPT "is currently available to approved partners", with merchants applying through the merchant form, and that listed products must meet OpenAI's product policies (legal, safe, and suitable for general audiences). The merchant page itself now states the mechanics that decide this branch. Applicants who have already applied are on a waitlist; merchants selling through Shopify or Etsy have their catalogs already integrated, with no application needed; shopping in ChatGPT is currently live for US users only, with more regions planned over time; and a self-serve merchant platform for data integration is planned for later in the year. Three diagnostic reads follow. If you sell through Shopify or Etsy, this branch is already cleared for you, so your cause is upstream in the data steps. If you applied and heard nothing, you are queued, not rejected. And if your shoppers are outside the US, absence is currently expected regardless of data quality, so stop debugging and watch the region rollout instead. For everyone else: if you never applied, or applied and were not approved, that is your cause, and no amount of feed or title work changes it. The canonical place to apply and confirm your status is OpenAI's merchant page at [chatgpt.com/merchants](https://chatgpt.com/merchants). We deliberately do not restate the detailed criteria here; they are OpenAI's to define and they change on OpenAI's schedule, so confirm the current requirements on the official page rather than relying on any restatement, ours included. What eligibility is *not* is a hidden toggle buried in a dashboard: there is no secret "turn me on" switch that a merchant is failing to find. Once you've met the published requirements and your data is legible, you are in the candidate set, and everything that decides whether you actually get recommended from there is selection, not eligibility. ## When to stop guessing and measure Once you've walked the tree and fixed what you found, resist the urge to keep eyeballing ChatGPT and hoping. Being in the candidate set (eligible and legible) is not the same as being the product the agent recommends; that is a separate outcome, and it moves. The disciplined next step is to measure it: run a repeatable protocol and track your [agent win rate](/glossary/agent-win-rate/) rather than reacting to a single lucky or unlucky prompt. [How we test agent selection](/handbook/how-to-test-agent-selection/) gives you the prompts, sampling, and error bars to do that honestly, so a fix you shipped shows up as a real, repeatable change and not a coincidence. ## This page diagnoses; the playbook optimizes Keep the two jobs separate. This page is the reactive decision tree: the flow you run *after* you notice you're missing, to find the single cause. [ChatGPT Shopping Optimization](/chatgpt-shopping-optimization/) is the proactive playbook: the feed, title, and crawler work you do up front so you never end up here. They are deliberate siblings: diagnose on this page, fix on that one. The same five-branch logic applies to the other engines on different rails: [Gemini and Google AI Mode](/gemini-shopping-ranking/) and [Perplexity](/perplexity-shopping-optimization/) each have their own troubleshooting surface, reached from the [platforms hub](/platforms/). --- # Gemini & Google AI Mode Shopping Ranking https://agentmint.net/gemini-shopping-ranking/ ## Key takeaways - Google's own agentic-commerce protocol is UCP, announced at NRF 2026 and starting with native checkout. It standardizes how a purchase completes and says nothing about which product an agent shows first, which is the layer you still have to win. - UCP is confirmed as the rail reaching Gemini and Google AI Mode: Google's own developer documentation states that adopting UCP enables agentic actions on both surfaces, starting with direct buying. - Whatever the plumbing, the lever you control is the same one you already run for Google: a complete, accurate Merchant Center feed and broad Shopping Graph coverage, not ad spend. - In the ACES simulation, Gemini was the most price-sensitive model tested and rewarded platform endorsements the most strongly of the three. - Gemini's behavior is a moving target: the study documented a model update that reshuffled market shares, which is why this page carries a last-verified date. ## How Google AI Mode surfaces products Google already runs the two systems that matter for agentic shopping: the Merchant Center feed merchants submit, and the Shopping Graph that indexes billions of product listings across the web. Conversational surfaces (Gemini and AI Mode in Search) layer on top of that existing product understanding rather than replacing it. So the merchant question is not "how do I get into a new system," it is "how completely is my catalog represented in the systems Google already has." The newer piece is the protocol layer. Google introduced the Universal Commerce Protocol (UCP) at NRF 2026 on 11 January 2026, describing it as "open, agnostic, built together with industry leaders Shopify, Etsy, Wayfair, Target and Walmart", built to keep the customer relationship front and center "from the moments of discovery to decision and beyond", and starting with native checkout, with the retailer remaining the merchant of record. Google's announcement says nothing about which product an agent puts in front of a shopper. UCP standardizes how a purchase is carried out; the choice that precedes it sits outside the protocol, and that is the layer a merchant has to win. See [UCP](/glossary/#ucp) in the glossary. The rail question is now settled. Google's own UCP developer documentation states that adopting UCP enables agentic actions on AI Mode in Google Search and Gemini, starting with direct buying, layered on the Merchant Center feeds merchants already run. That confirms UCP as the rail this page is written around, so the strategy below rests on a documented fact, not an inference. The rail has also kept growing since launch. In March 2026 Google announced UCP Cart (multi-item carts from a single store), Catalog (agents retrieving real-time variants, inventory, and pricing), Identity Linking for loyalty benefits, and a simplified UCP onboarding flow in Merchant Center, described as rolling out over the coming months. For a merchant the practical read is unchanged: the feed you already maintain is the substrate all of it consumes. The merchant-facing side of the rail expanded again in September. Google states that UCP already enables direct checkout for hundreds of thousands of brands and retailers across Google, and its Merchant Center integration hub now lets merchants enable cart transfer to their own site and test an enhanced checkout flow, with analytics coming soon, on a gradual US rollout and Australia and Canada early next year. Google names Tapestry, the owner of Coach and Kate Spade, as a merchant selling this way across Search, AI Mode, and the Gemini app. This is still eligibility plumbing, not a selection lever: it changes how you transact, not whether an agent picks you. ## UCP in one minute You do not need to implement UCP to read this page, but you should know where it sits. UCP is Google's answer to the same problem OpenAI and Stripe's ACP solves for ChatGPT: a standard way for an agent to move from finding a product to paying for it. The scope differs, and which protocol reaches which engine is the whole point of choosing where to invest. We lay the two side by side in [UCP vs ACP: which gets you selected](/ucp-vs-acp/). The short version for a Google-focused merchant: UCP is the Google-native rail, ACP is the ChatGPT-native one, and the practical move for most catalogs is to be legible to both rather than betting on one. Being UCP-ready is an eligibility step, not a ranking one. Passing a readiness check makes you transactable; it does not make an agent choose you. The gap between "an agent can buy from me" and "an agent does buy from me" is the selection layer this handbook is about, and on Google that layer is fed almost entirely by the quality of your existing product data. ## Feed quality is the lever, not ad spend Because Gemini and AI Mode draw on the Merchant Center feed and Shopping Graph, the highest-leverage work is the same feed discipline you would do for Google Shopping, pushed to completeness rather than mere validity. On Google surfaces the dominant selection lever available to a merchant is feed quality and Shopping Graph coverage (filling every attribute an agent can score and keeping price and availability accurate) rather than paid placement, because the agent is reasoning over structured product data, not an ad auction. This is an inference from how agents weigh structured signals, not a measured ranking rule; treat it as a direction with an unknown magnitude. What that looks like in practice is covered in depth in [make your product feed AI-readable](/make-product-feed-ai-readable/): lead titles with the category and use-case a shopper actually types, fill product identifiers and availability, and reconcile any price that disagrees between feed and page. The point specific to Google is that you are not building a new feed: you are raising the completeness of the one Merchant Center already ingests, so the Shopping Graph has more to match against a conversational query. ## What ACES suggests about Gemini specifically The strongest public evidence on how a Gemini agent chooses comes from the academic ACES framework, a controlled simulation in which vision-language-model agents pick from a mock storefront, analyzed with regression. Every figure below is from that simulation, not from live Google sales, and each is specific to the Gemini model ACES tested (Gemini 2.5 Flash). Read them as evidence of *what kinds of signals* Gemini weighs and *how its weighting differs* from other engines, not as a ranking formula for your catalog. Two patterns stand out for Gemini. First, price. ACES estimated a log-price (ln Price) coefficient of −2.190 for Gemini 2.5 Flash, the most price-sensitive of the three models it tested, notably stronger than the −1.6 range it found for Claude Sonnet 4 and GPT-4.1. Second, endorsement. A platform endorsement such as an "Overall Pick" badge lifted a baseline 10% selection probability to 42.6% for Gemini, the strongest endorsement response of any model in the study. The other two signals move Gemini in the same directions the other engines showed, at Gemini's own magnitudes. Raising a product's rating by 0.1 stars lifted Gemini's baseline 10% selection probability to 16.0%, and, consistent with agents penalizing paid-looking tags, tagging a product "Sponsored" pushed Gemini's baseline 10% down to 7.9%. Put together, these point a Google-focused merchant at competitive pricing and *legitimately earned* endorsement signals as the two levers with the most apparent pull on a Gemini agent. The standing caveat: manufacturing endorsement badges is the dark pattern this finding tempts, not a tactic we endorse. The general per-model comparison, including the position and description-rewrite effects, lives on [how AI shopping agents choose products](/how-ai-agents-choose-products/). ## Why model updates can reshuffle your ranking Nothing above is stable. The single most important caveat for optimizing to Gemini is that its selection behavior shifts when the model changes. The ACES authors documented that a model update can drastically reshuffle market shares, observing exactly that between Gemini 2.5 Flash Preview and Gemini 2.5 Flash. A discount or a description that wins today can matter less (or more) after Google ships the next Gemini revision. And Google keeps shipping them. On 21 July 2026 Google released Gemini 3.6 Flash and Gemini 3.5 Flash-Lite, said Gemini 3.5 Pro was testing with partners ahead of broad availability, noted that pre-training had begun on Gemini 4, and stated that 3.5 Flash-Lite is also rolling out in Google Search. The Gemini models ACES measured (2.5 Flash in the figures above; the newer cohorts are covered on [how AI shopping agents choose products](/how-ai-agents-choose-products/)) now trail Google's shipping line by multiple releases. Read the coefficients on this page as directional evidence about which signals Gemini-family agents weigh, not as the current model's exact weights, and note that Google does not document which Gemini revision powers AI Mode shopping at any given moment, so neither do we. This is why AgentMint.net types every model-behavior claim by source and date, and why this page carries a last-verified stamp above. Do not treat any single quarter's Gemini behavior as a fixed target; treat it as a reading you re-take. The durable strategy is the feed-quality work in the section above, which pays off regardless of how the model reweights its signals; the model-specific coefficients are the volatile part. ## What Google now reports about your AI visibility Google has started showing merchants where they appear in AI shopping answers, and it helps to know exactly what those reports measure before you optimize to them. On 16 September 2026 Google made AI performance insights in Merchant Center generally available across Australia, Canada, India, New Zealand, and the US. The report defines share of voice as your number of AI impressions divided by the total impressions across the competitors you define in Merchant Center plus your own, shown for related queries, and adds Competitors' Average Share, Frequency, Products Showing, and a funnel split of Discovery, Evaluation, and Ready to Buy, covering AI Mode and AI Overviews for English-language conversational shopping queries only. Read what that number is before you chase it. Share of voice counts how often you were shown against a competitor set you named. It is an impression ratio, not a record of being chosen, and Google publishes no ranking-algorithm disclosure next to it. The distance between appearing in an AI answer and being the product the agent recommends is the selection layer this page is about. A rising share of voice tells you your feed is eligible and visible; it does not tell you that you won the pick. A second Google report covers your site rather than your catalog, and it is easy to confuse with the first. As of 31 August 2026 Google rolled out its Generative AI performance report in Search Console to all websites worldwide, reporting impressions across AI Mode and AI Overviews combined, with no clicks, click-through rate, position, or query data. The reading is the same as the Merchant Center report: it confirms you were shown, not that you were picked. Treat both as visibility instrumentation for the eligibility layer, and keep your selection measurement separate. ## A new place shoppers ask: Business Agent Google is opening one more surface where a shopper reasons before buying. Google's Business Agent, introduced in Search earlier in 2026, is now in a US beta for YouTube ads, where it embeds directly in the ad so viewers can conduct self-driven research, ask complex product questions, and get tailored guidance without leaving their YouTube context. It points back to what runs through this whole page: another surface where the completeness of your product data decides how well an agent can answer for you, and how confidently it can put you forward. ## Measure your Gemini win rate Because the model moves, the only way to know how Gemini treats *your* catalog is to measure it rather than infer it from a study. Track your [agent win rate](/glossary/#agent-win-rate) (the share of agent shopping sessions in which your product is the one recommended or bought) on Gemini and AI Mode specifically, and re-take that reading after major model updates. The repeatable protocol we use, including prompts, sampling, and honest error bars, is documented in [how to test agent selection](/handbook/how-to-test-agent-selection/). This site publishes no measured figures of its own, and this page will never fill that gap with an invented one. --- # The Agent Selection Maturity Model https://agentmint.net/handbook/agent-selection-maturity-model/ The agent selection maturity model sorts where your store sits in the work of getting picked by AI shopping agents, on a five-level ladder that runs from invisible to an agent up to consistently selected and measured. It is our editorial framework for deciding what to fix next, not a validated or measured maturity scale, so read the levels as a way to prioritize work rather than a score anyone has benchmarked. ## Key takeaways - The five levels ascend from level 1 (an agent cannot fetch or find you) to level 5 (you run the win-rate protocol and iterate), and each level is a prerequisite for the one above it. - Levels 1 and 2 are eligibility, the ground official validators and protocol docs already cover; levels 3 to 5 are the selection work this handbook exists for, which no validator scores for you. - This is an editorial framework for prioritizing work, so there are deliberately no 'percent of stores at level N' figures and no win-rate numbers on this page. - Each level maps to specific Agent Selection Checklist categories and selection signals, so you can turn 'we are at level 3' into a concrete next task. > **This is a prioritization framework, not a measured benchmark** > > The levels below are our organizing model for sequencing work. They are not a tested scale, and nobody has measured how stores distribute across them. Where a level cites how agents behave, that claim is typed and sourced on its own terms; the ladder itself is our framing. ## How to read the ladder Treat each level as a floor for the next. Review depth and price position (level 4) do you little good if an agent still cannot read your delivery terms (level 3), and none of it matters if your pages are blocked or unparseable (level 1). So the useful question is never "how many boxes can we tick," but "what is the lowest level we have not fully cleared," because that is your real ceiling until you fix it. The failure mode we expect most often is stopping at level 2, because that is exactly where eligibility validators stop reporting: they confirm you are readable and then fall silent on whether you win. Everything from level 3 up is judgment an agent makes when it compares you against a competitor who is equally eligible, which is the layer covered in [how AI shopping agents choose products](/how-ai-agents-choose-products/). ## The five levels at a glance _The five levels of the agent selection maturity model. This is an editorial prioritization framework, not a measured or validated scale._ | Level | What an agent sees | Checklist focus | Signal coverage | | --- | --- | --- | --- | | 1: Unreachable | Cannot fetch or find you (blocked crawlers, no feed, JS-only pages) | Readiness: crawler access, feed presence | Crawl directives, origin serveability, crawlable content | | 2: Eligible | Fetches you and reads a valid, parseable feed | Readiness: product identity, offer markup, validation | Product identity, offer markup completeness, validation hygiene | | 3: Legible | Reads a complete, comparable offer without starting checkout | Selection: offer legibility, delivery & returns, product content | Offer cost legibility, delivery ETA, returns, facts per token | | 4: Preferable | Has reasons to pick you over an equally legible peer | Selection: trust & policy, price position | Review depth, endorsement (not sponsored), price awareness | | 5: Measured | You know whether agents pick you, and iterate | Selection: measurement | Win-rate measurement, answer presence, retest on updates | ## Level 1: Unreachable At level 1 the agent gets nothing usable: a blocked request, a page that renders only after JavaScript an agent never runs, or a catalog that appears in no product feed. The most common self-inflicted version is blocking the wrong bot. OpenAI documents distinct agents for distinct jobs: GPTBot (crawls to train models), OAI-SearchBot (surfaces and links sites inside ChatGPT), and ChatGPT-User (the fetch triggered by a user's own request), so a blanket disallow can hide you from the very agent that decides whether a shopper sees you. The work here is eligibility groundwork, not selection: confirm verified agents get a 200, publish a feed, and render content server-side. The crawler-access items in the [Agentic Shopping Readiness Checklist](/tools/agentic-readiness-checklist/) cover it, [serving agent traffic](/handbook/serving-agent-traffic/) explains how to afford being open instead of reaching for a block, and the [AI shopping crawlers reference](/reference/ai-shopping-crawlers/) lists which token to allow. If you suspect you are stuck here, start the diagnosis at [why your store is not in ChatGPT shopping](/store-not-in-chatgpt-shopping/). ## Level 2: Eligible Level 2 is table stakes: an agent can fetch you, and your feed and markup validate. Product identity, price, and availability parse cleanly, and a rich-results or feed validator passes. This is the ceiling that official docs and validators are built to certify, and it is a real, necessary achievement. It is also where the guidance most sites follow runs out. A validator confirms your data is present and well-formed; it never tells you whether an agent, comparing you against three equally valid competitors, has any reason to choose you. Getting a feed and schema clean is covered in [make your product feed AI-readable](/make-product-feed-ai-readable/) and [product schema for AI shopping](/product-schema-for-ai-shopping/). Everything past this point is the layer this handbook owns, and the rest of the ladder is about earning the pick, not passing the check. ## Level 3: Legible At level 3 an agent can read your complete, comparable offer without starting checkout: all-in landed cost, a delivery estimate to a real destination, the return window and who pays, complete category specs, and descriptions that answer the questions buyers actually ask. The mechanism for the fulfillment half is documented. Google's shipping structured data expresses handling time and transit time as ranges an agent assembles into an "arrive by" estimate, rather than as literal dates. Return-policy structured data carries the return window (merchantReturnDays), return fees, and refund type, so an agent relaying "can I return it?" has a machine-readable answer. This maps to three Agent Selection Checklist categories: offer legibility, delivery and returns signals, and product content for comparison. The density discipline behind it, packing verifiable facts into each surface, is [information density for agents](/handbook/information-density/), and the page-level version is the [product detail page anatomy](/product-detail-page-anatomy/). A store can pass every validator (level 2) and still fail here, because legibility is about completeness and comparability, which no validator grades. ## Level 4: Preferable Level 4 is where you give an agent a reason to choose you over a peer who is equally legible: genuine review depth and distribution, legitimate platform endorsement, a known all-in price position, a reachable seller identity, and awareness that each engine weights those differently. The strongest public evidence for these levers is a controlled study. In the ACES simulation, agents rewarded genuine platform endorsement, penalized a self-applied "Sponsored" tag, and showed a large but provider-specific grid-position effect. Read that as a simulation across a fixed model set, not live sales, so treat the direction as the signal and the exact magnitudes as provisional. The honest move at this level is to earn the signals, not fake them: a self-designed lookalike "verified" badge is neither legitimate endorsement nor durable. This maps to the trust and policy and price position categories of the [Agent Selection Checklist](/tools/agent-selection-checklist/); the mechanics are in [how AI shopping agents choose products](/how-ai-agents-choose-products/), the price-specific case in [lowest price but not recommended](/lowest-price-but-not-recommended/), and one engine's take in [Gemini and Google AI Mode ranking](/gemini-shopping-ranking/). ## Level 5: Measured Level 5 is the only level you cannot reach by shipping features, because it is defined by measurement: you run the manual win-rate protocol across ChatGPT, Gemini, and Perplexity, track whether each engine names your store for your category queries, record where you land when results render as a grid, and re-test on a cadence. The re-test discipline is not optional. ACES documents that model updates can drastically reshuffle which products agents pick, so a win measured last quarter can quietly evaporate. That is a simulation finding, not a measured claim about your catalog, which is exactly why you measure your own. This maps to the measurement category of the checklist. The protocol itself is [the agent-selection measurement methodology](/handbook/how-to-test-agent-selection/), the metric it produces is [agent win rate](/glossary/agent-win-rate/), and when a change does not move that number, the diagnostic path is [shown but not selected](/shown-but-not-selected/). A store at level 5 is not "finished"; it has simply replaced guessing with a measured range it can act on. ## Where the validators stop, and this ladder begins The single most useful line to draw on this ladder sits between levels 2 and 3. Below it, eligibility validators and protocol docs do the grading, and we link out to them rather than restate them. Above it, no external tool scores you, and the judgment is comparative: an agent weighing you against an equally eligible competitor. That gap is why we treat [agent selection](/glossary/#agent-selection) as its own discipline, and why the levels above 2 are the whole reason this handbook exists. The full catalog of the signals referenced across these levels lives in the [signals database](/signals/). ## What to measure Turn the ladder into a repeatable check, not a one-time self-rating. - Place yourself honestly. Run both tools: the [Agentic Shopping Readiness Checklist](/tools/agentic-readiness-checklist/) scores levels 1 and 2, and the [Agent Selection Checklist](/tools/agent-selection-checklist/) scores levels 3 to 5. Your lowest category with unmet items, not your highest, is your current level. - Fix the lowest gap first. Adding a level-4 signal while a level-3 gap remains open is wasted effort, because the agent stalls at the missing floor. Sequence bottom-up. - Convert "we reached level 5" from a claim into a measurement. Run the [win-rate protocol](/handbook/how-to-test-agent-selection/) per engine and report a range with a stated sample, never a single confident number, since no measured data exists to back a point figure. - Re-score on a cadence and after every major model update, and log the date each time. A level you cleared last quarter can slip when either your data or the model changes. > Illustrative example, not measured data. A fictional outdoor-gear store passes every feed validator (level 2) but never states shipping cost or a return window in readable text, so an agent cannot assemble a dated delivery-and-returns answer. It sits at level 2 with a level 3 gap, and the fix is legibility work, not more schema validation. A section-by-section walkthrough of a store like this is the [companion worked example](/handbook/agent-selection-audit-example/). --- # Product Titles That AI Agents Match https://agentmint.net/product-titles-for-ai-agents/ ## Key takeaways - Your product title is usually the first and most prominent text an agent reads, so leading it with the category, key attributes, and use-case makes the product legible to a query-matching agent. - In the ACES study the rewritten field is the product's displayed title/description text (one field in its mock storefront), and the paper describes the winning rewrites as title changes, with query keywords moved to the front of the title the most consistent driver. - Even so, the effect was concentrated (most product-and-model pairs saw no change while a minority saw large gains), so a title rewrite is a skewed bet, usually neutral and occasionally decisive. - Write titles in the words a shopper actually types, and keep the brand name after the descriptive words rather than in place of them. - Because the payoff is uneven, test a rewrite on your own catalog rather than trusting a formula. The protocol for running that test is published; no measured result on this site stands in for it. ## How an agent reads your product title A shopping agent does not skim. It reads structured product data field by field and scores each product against what the shopper asked for. Your title is usually the first and most prominent text field in that record, so it does much of the work of telling the agent what the product actually is. The rest of the record ([your feed](/make-product-feed-ai-readable/) and [your product schema](/product-schema-for-ai-shopping/)) fills in the price, availability, and attributes around it. We read the public evidence to mean that an agent weighs how closely your product text answers the shopper's actual query, which puts a title written in the shopper's words at an advantage over one written in a brand's private language. Be precise about what that rests on: in the controlled evidence later on this page, the rewritten field is the product's combined title/description text (a single field in the study's storefront), and the paper itself frames the winning rewrites as title changes. What remains unmeasured is a separate title-versus-description comparison, and everything below keeps that line visible. ## On ChatGPT, your title is an input, not the label One major surface does not always show shoppers the title you wrote. OpenAI states that ChatGPT may generate simplified product titles and descriptions from the information it receives from third-party providers, to make results easier to read, because merchants often use varying titles and descriptions for the same product. On ChatGPT, then, your title is an input the model rewrites, not the exact string a shopper reads. That bounds what title work can do here without making it pointless. Because the displayed title is generated from the metadata you supply, the words and attributes you put in your title still feed the rewrite, so a title that clearly states category, attributes, and use-case gives the model better material to simplify; what a merchant cannot do on this surface is control the final wording a shopper sees. OpenAI does not publish how the rewrite weighs its inputs, so treat this as the ceiling on title optimization for ChatGPT, not a formula: supply clean, complete, query-matching text, and accept that the phrasing shown is the model's. The model also writes the labels shoppers read as signals. Feature labels such as "Budget-friendly" or "Most popular" are generated by the model and are not guarantees or verified statements; a "Budget-friendly" label might mean that reviewers frequently mention good value, not necessarily that the product is the lowest price available. You cannot request those labels, and you should not write copy that pretends to have earned one. None of this undoes the rest of this page. Everywhere else your title text is read more literally, and even on ChatGPT it is the raw material the rewrite starts from, so the same query-aligned wording still helps. ## The literal-match problem Human shoppers forgive a clever product name because they read the photo, the price, and the star rating around it and infer what the thing is. An agent resolving a query has less room for that inference. When a title omits the words a shopper used, it risks being scored as a weaker match to the query (the literal-match problem) because the agent has fewer cues to connect your product to the request. This is a claim about mechanism, consistent with the rewrite evidence below, and it is the crux of [agent selection](/glossary/#agent-selection) at the title level: be the text that most obviously answers the query. > Illustrative example, not measured data. A brand sells a weighted sleep mask under the name "The Luna." A shopper asks an agent for an "organic cotton weighted sleep mask for side sleepers." The title "The Luna" shares none of the shopper's words. A title like "Organic Cotton Weighted Sleep Mask, Blackout, for Side Sleepers" repeats the query's own language, and the brand can still ride along: "Luna Organic Cotton Weighted Sleep Mask, for Side Sleepers." The point is to lead with what the shopper searched, not with the codename. ## The title formula: category, attributes, use-case If the goal is to repeat the words a shopper is likely to type, a reliable ordering is to lead with the category, follow with the attributes that distinguish the product, and close with the use-case or fit. This is our recommended structure, not a rule any agent enforces: 1. **Category first.** The plain noun a shopper searches ("weighted sleep mask," "USB-C car charger"), so the product is legible before any modifier. 2. **Distinguishing attributes.** Material, size, colour, capacity, or compatibility: the words that separate your product from the rest of its category ("organic cotton," "65W," "blackout"). 3. **Use-case or fit.** Who or what it is for ("for side sleepers," "iPhone 15/16"), which is often exactly how a shopper phrases the underlying need. 4. **Brand where it helps, not instead.** Keep the brand name if it earns trust, but let it follow the descriptive words rather than replace them. The same title then feeds every engine that reads your catalog, so the fix is write-once. How a given platform surfaces that title differs. The [ChatGPT shopping playbook →](/chatgpt-shopping-optimization/) covers applying this where OpenAI's agent reads your feed. ## Before and after: title rewrites The formula is easier to trust once you see it applied. Each pair below takes a title written in a brand's private language and rewrites it in the words a shopper types, leading with the category and the attributes that set the product apart. We expect the rewritten titles to answer more queries, because every descriptive term you add (material, size, capacity, compatibility, fit) is one more attribute an agent can check against a request, while a bare model name offers almost none. The brands, models, and specs below are invented to keep the pattern clear. > Illustrative example, not measured data. A cookware listing titled "Norvane Signature 10" gives an agent a brand and a model number and little else. Rewritten as "Norvane Nonstick Ceramic Frying Pan, 10-Inch, PFAS-Free, Induction Compatible," it names the pan type, the coating, the size, the safety property, and the stovetop compatibility, so a query for an "induction-safe nonstick pan" has concrete attributes to match instead of a code. "Auralen Drop 3" names a product without saying what it is. "Auralen Wireless Noise-Canceling Earbuds, Bluetooth 5.3, 30-Hour Battery, IPX4 Water Resistant" keeps the brand but leads with the category and then the specs a shopper filters on, so a request for "noise canceling earbuds with long battery life" can line up against the connectivity version, the battery figure, the noise-canceling feature, and the water-resistance rating. "Ostwick Executive" reads as a trim name, not a category. "Ostwick Ergonomic Mesh Office Chair, Adjustable Lumbar Support, 300 lb Capacity" turns that codename into the chair type, the back material, the ergonomic feature, and the weight rating, so a shopper asking for an "ergonomic office chair with lumbar support" finds four matchable terms where there were none. "Trailwen Summit" tells an agent nothing about the footwear. "Trailwen Waterproof Hiking Boots, Men's Wide Fit, Ankle Support" surfaces the boot type, the waterproofing, the gender and fit, and the support feature, so a query for "wide waterproof hiking boots" can match on each detail without inferring it from a name. The move is the same in every pair: nothing about the product changed, only how legibly the title states what it is and how many of its attributes an agent can pair with a query. ## The evidence: text rewrites shifted selection The reason to take title wording seriously is that changing product *text* measurably moved which product an agent picked in the strongest public study we have. One structural fact matters throughout: in the ACES storefront, a product's displayed title and description are a single text field, so the paper uses "title" and "description" for the same rewritten text. In the ACES simulation, rewriting a product's description to better fit the shopper's query raised its market share in the agents' picks by an average of +3.66 percentage points for Claude Sonnet 4, +8.37 pp for GPT-4.1, and +14.79 pp for Gemini 2.5 Flash, all statistically significant. ACES is a controlled simulation (vision-language-model agents choosing from a mock storefront in randomized trials, not a record of real purchases on live stores), so read these as evidence that text *can* move selection, not as guaranteed conversion math for your catalog. From there, the step to titles is shorter than we once framed it, because the paper itself makes it. In ACES the rewritten field is the product's displayed title/description text, a single field; the paper's current revision instructs its seller agent to change the product title without inventing features or adding spurious keywords, describes the winning rewrites as title edits that can materially shift selection shares, and identifies relocating the query's own terms to the beginning of the title (keyword front-loading) as the most consistent driver of the gains. One caveat stays ours: ACES never ran a title and a long-form description as two separate fields, so a field-versus-field comparison remains unmeasured. What the evidence shows is that rewriting the product's title text moved selection. ## Why the effect is concentrated, not uniform A rewrite is not a lever that pays out every time. The description-rewrite effect was concentrated rather than uniform: in 67% of the category-model pairs a one-shot rewrite produced no significant change, while 33% produced large gains. Where it did land, the upside was real: the biggest outliers reached +52.0 pp for an office lamp on Gemini 2.5 Flash and +30.3 pp for an office lamp on GPT-4.1. For a title that means the expected value is skewed: most rewrites will do little, a minority will do a lot, and you cannot tell in advance which product falls where. Treat a query-aligned title as a low-cost bet with an occasional large payoff, not a reliable percentage lift you can bank across a catalog. ## From a title to a test Because the payoff is uneven (mostly neutral, sometimes large), a title rewrite is a hypothesis about your specific catalog, not a guarantee, and the only honest way to know is to measure it. The protocol for measuring it on your own catalog is in [how to test agent selection →](/handbook/how-to-test-agent-selection/). Run it before you rename a catalog on faith, and read [how AI shopping agents choose products →](/how-ai-agents-choose-products/) for the full set of signals a title sits inside. --- # Shown but Not Selected: Why an Agent Picks a Competitor https://agentmint.net/shown-but-not-selected/ ## Key takeaways - Appearing in an AI answer is eligibility; being the recommended pick is selection. If you show up but lose, work the selection causes, not the eligibility ones you already cleared. - Diagnose which of four gaps is yours before touching anything: you are not comparable against peers, your review depth is thin, you look sponsored instead of endorsed, or it is provider-specific grid position, not your offer at all. - Three of the four are content gaps you can close. The fourth, position bias, is a measurement problem first, so measure where you land before you re-guess your content. - This page finds the cause. The fixes live in the catalog and platform pages it hands you to, and the honest test of any fix is your agent win rate, measured per engine. ## Appearing is eligibility; being chosen is selection This page is for the harder half of the funnel: you already appear in AI shopping answers, but the agent keeps recommending someone else. That is a different problem from being absent. If your products never surface at all, you have an eligibility or legibility gap, and the flow for that is [why you're not in ChatGPT shopping](/store-not-in-chatgpt-shopping/), not this one. Stay here only if you can see yourself in the candidate set and still lose the pick. The open commerce protocols draw this line themselves: the Agentic Commerce Protocol states that implementing it does not guarantee automatic product listings, and that each AI platform "will manage their own process" for how businesses participate. So clearing the protocol bar and being the [product an agent recommends](/glossary/#agent-selection) are two separate outcomes. Eligibility gets you shown; selection decides who wins, and no public spec governs it. That means "shown but not selected" is almost never fixed by re-validating your feed or hunting an enrollment switch. It is fixed by finding the specific signal a stronger competitor carries that you do not. The instinct is to change several things at once and refresh the agent to see what sticks. Resist it. Work the four causes below in order, stop at the first one that is true for you, and hand yourself off to the page that fixes it. This page diagnoses; it does not re-teach [how agents choose](/how-ai-agents-choose-products/) or restate the fixes. ## Cause 1: you are not comparable against your peers The most common reason a shown product loses is that it is under-described relative to the listings it is being compared against. You filled the fields your platform marked "required" and stopped, while the category leaders also filled weight, dimensions, material, compatibility, and use-case. We expect an agent comparing within a category to favor the item it can actually compare on. Every attribute your peers expose and you leave blank is a comparison you sit out, so a complete listing can beat yours even when your product is better. This is a judgment against your peers, not against a validator, which is exactly why no eligibility check flags it. To check it, pull up the top three competing listings for the query you are losing and write down every attribute they expose. Then diff that list against your own listing and against your feed. The fields they fill and you do not are your gap. Read your descriptions the same way an agent relays them: do they answer the concrete questions a buyer actually asks (fit, compatibility, use-case), or do they trade in adjectives that carry no comparable signal? The fix is completeness measured against category norms, not against the minimum. Close the attribute gaps in your feed and structured data, and rewrite descriptions to answer buyer questions in plain sentences. The how lives in [make your product feed AI-readable](/make-product-feed-ai-readable/), and the reasoning behind why completeness moves selection is in [how AI agents choose products](/how-ai-agents-choose-products/). This is the cause to rule out first, because a thin listing loses on every other signal downstream. ## Cause 2: your review depth is thin Having a star rating at all is eligibility; the depth behind it is a selection lever. A lone average with no count, or three testimonials that have sat unchanged for years, reads as thin next to a rival showing scale and recent activity. In the ACES simulation, a product's rating was one of the levers that shifted which item agents chose, alongside price, grid position, and endorsement. ACES is a controlled simulation over a fixed model set (Claude, GPT-4.1, and Gemini variants), not live sales, so read it as a pattern to watch. From that, we expect complete, recent, well-distributed review data to read as more credible depth than a bare number, giving a rating-sensitive agent more to weigh in your favor. Check what your review markup actually carries. Does it expose a truthful review count alongside the average, individual reviews with real publication dates, and a distribution rather than a single figure? If a shopper on the page can only see "4.6 stars" with nothing behind it, an agent parsing the same page sees no more than that. The fix is to carry count, recency, and distribution truthfully in both the visible page and the structured data, never a fabricated or inflated rating (that is both a rule violation and a weak signal). The markup shape is in [product schema for AI shopping](/product-schema-for-ai-shopping/); why depth beats a bare average is in [how AI agents choose products](/how-ai-agents-choose-products/). ## Cause 3: you look sponsored, not endorsed This one is counterintuitive, and it is where the dark-pattern temptation sits. If any part of your agent-visible page carries self-applied "Sponsored" or "Ad" styling, whether a leftover ribbon component from an old paid-placement test or a promoted-listing class that persisted onto the canonical page, it may be actively costing you. ACES reports that across its simulated trials, agents consistently penalized a "Sponsored" tag and rewarded platform endorsements such as an "Overall Pick" badge, with endorsement among the strongest content signals it tested. Again, this is a simulation, not measured live behavior. So chasing a paid-looking tag to court agents can backfire, and the durable move is the opposite: earn a genuine endorsement you qualify for on its own merits. Audit your templates and past A/B tests for any sponsored or ad styling still touching organic product pages, including classes and attributes inherited from ad-platform integrations. If a shopper never sees the badge but it lives in the markup, an agent still can. The fix is two-sided: remove the self-applied sponsored framing from organic listings, and pursue real editor's-pick, verified-seller, or platform-endorsement programs where you legitimately qualify, rather than designing a lookalike badge that implies one. Faking endorsement markup is a fabricated-signal dark pattern, not a shortcut. The endorsement-integrity reasoning is in [how AI agents choose products](/how-ai-agents-choose-products/). ## Cause 4: it is position bias, not your offer Before you conclude your content is the problem, rule out that you are simply losing to where the agent placed you. ACES reports that grid position was a large but provider-specific lever, and that this position bias persisted even in text-only interfaces, which the authors note undermines any universal notion of a "top" rank. That matters for diagnosis: a swing between winning and losing can reflect where a competitor's grid rendered rather than any content difference between you, and you cannot fully control placement. So if you keep re-editing content to fix what is actually a placement effect, nothing you observe will make sense. Stop changing things and measure. In repeated runs of the same prompt, record your on-screen position whenever results render as a grid, logged per engine rather than blended. If you keep losing from good positions, the cause is one of the content branches above. If your outcome swings with position while your content is unchanged, it is [position bias](/glossary/#position-bias), and the honest response is measurement, not another content guess. Note the neighboring case too: if you are specifically the cheapest offer and still lose, that has its own diagnostic, [lowest price but not recommended](/lowest-price-but-not-recommended/). The fix here is not a content edit at all; it is discipline. Establish where you land and which signals correlate with a position swing before attributing wins or losses to your own changes. The protocol for doing that, with prompts, sampling, and honest error bars, is in [how to test agent selection](/handbook/how-to-test-agent-selection/). > **Never fix selection by cloaking** > > Whatever the cause, the fix is never to show agents different content, prices, or badges than you show shoppers. Serving crawlers one thing and humans another is cloaking, a search-spam and trust violation, and a query-conditional edit only bots see is not testing. Close the real gap in content everyone sees. ## Stop guessing and measure your win rate Once you have found and closed your cause, resist eyeballing one engine and hoping. A single lucky or unlucky answer tells you nothing, and behavior reshuffles when models update. ACES documents that model updates can drastically reshuffle market shares, so a win you measured last quarter can quietly evaporate after a release. From there, discipline beats hope: track your [agent win rate](/glossary/agent-win-rate/) across engines with a repeatable protocol, so a fix you shipped shows up as a real, repeatable change rather than a coincidence, and re-test after every major model update. If your symptom is really that you appear in some engines and not others, or that your presence itself is inconsistent, that is a visibility question rather than a selection one: see [the AI engine visibility gap](/ai-engine-visibility-gap/). And if agents are quoting a stale price or wrong stock status for you, that is a data-accuracy fault worth fixing first, covered in [when AI shows the wrong price or stock](/ai-showing-wrong-price-or-stock/). ## This page diagnoses; the linked pages fix Keep the jobs separate. This is the decision tree you run after you notice you are shown but not chosen, to isolate the single cause. The fixes live elsewhere on purpose: the catalog work in [make your product feed AI-readable](/make-product-feed-ai-readable/), [product schema for AI shopping](/product-schema-for-ai-shopping/), and [product titles for AI agents](/product-titles-for-ai-agents/); the selection model in [how AI agents choose products](/how-ai-agents-choose-products/); and the measurement in [how to test agent selection](/handbook/how-to-test-agent-selection/). Its sibling diagnostics narrow the symptom further: [lowest price but not recommended](/lowest-price-but-not-recommended/), [the AI engine visibility gap](/ai-engine-visibility-gap/), and [wrong price or stock in AI answers](/ai-showing-wrong-price-or-stock/). ## Frequently asked questions ### My product appears in ChatGPT but it always recommends a competitor. Is that an eligibility problem? No. Appearing means you cleared eligibility; losing the recommendation is a selection problem. Work the selection causes on this page (comparability, review depth, endorsement framing, and position), not your feed's eligibility settings. ### Does adding a 'Sponsored' label help an AI agent pick my product? The opposite is likely. ACES, a controlled simulation, reports agents consistently penalized a 'Sponsored' tag and rewarded genuine platform endorsements. Remove self-applied sponsored styling from agent-visible pages and pursue endorsements you can honestly earn. ### How do I know if I am losing on content or just on grid position? You cannot tell from a single answer. Record your on-screen position when results render as a grid, per engine, across repeated runs. If you lose from good positions, it is content; if position swings with no content change, it is position bias. Measure it before re-guessing. --- # AI Crawlers, robots.txt & llms.txt for Stores https://agentmint.net/ai-crawlers-robots-llms-txt/ ## Key takeaways - AI shopping agents read two things about you: your structured product feed and your live pages. robots.txt is what decides whether they can read the second one. - Whether to allow the AI crawlers is a selection decision, not a bandwidth one: block them and you can remove the page-level detail an agent would otherwise read about your products. - The commerce allow-list is a specific set of real user-agent tokens, each owned by a named engine: GPTBot, OAI-SearchBot and ChatGPT-User (OpenAI), Google-Extended (Google), PerplexityBot and Perplexity-User (Perplexity). - Crawler access and your product feed are two separate pipes. Opening the crawlers does not replace a feed, and a feed does not make the crawlers unnecessary. - llms.txt is an emerging public spec (revised to v2 in August 2026) worth shipping as low-cost insurance, but there is no confirmed evidence yet that major shopping agents read it when choosing products. ## What each AI crawler actually does Deciding who to let in starts with a distinction: the AI crawlers do two different jobs, and the difference is what matters for a store. Some fetch and index your pages so an engine can *surface and cite* you later; others are a *live fetch* triggered the moment a user's request reaches your URL. We will not rehearse robots.txt grammar here (the syntax is owned by each engine's own documentation, which we link) because the useful question for a merchant is not how to write a directive but which of these agents you want reading your catalog and why. Take the three engines that dominate agentic shopping today. OpenAI documents several distinct agents, including: GPTBot, which crawls content to train its models; OAI-SearchBot, which surfaces and links sites inside ChatGPT search; and ChatGPT-User, the fetch triggered when a ChatGPT user's own request reaches your page. That split is the whole reason "should I allow AI crawlers?" has no single yes/no answer: GPTBot is mostly about training, while OAI-SearchBot and ChatGPT-User are the ones that decide whether a shopper sees you inside ChatGPT. Google-Extended is not itself a crawler but a robots.txt control token that governs whether content Google has already crawled may be used to improve Gemini Apps and Vertex AI generative models, and toggling it does not change how a site ranks in Google Search. For a store, that means the Google-Extended decision is purely an AI-usage decision, cleanly separable from your SEO. Perplexity documents PerplexityBot, which indexes pages so they can be surfaced and cited in answers, and Perplexity-User, the fetch triggered by a user's live query. Anthropic documents three bots: ClaudeBot, which collects web content that can contribute to model training; Claude-User, the fetch triggered when someone asks Claude a question; and Claude-SearchBot, which crawls pages to improve the quality of Claude's search results. Claude-SearchBot is the one that matters for selection: it is Anthropic's equivalent of OAI-SearchBot and PerplexityBot, the crawler behind whether Claude surfaces and cites a page at all. Our own site ships the same allow-list for these plus Anthropic's ClaudeBot, Claude-SearchBot and Claude-User (an older `anthropic-ai` token still shows up in some third-party lists, but it is not part of Anthropic's current documented set above), Apple's Applebot-Extended, Amazonbot, and Common Crawl's CCBot. You can read the exact file at [agentmint.net/robots.txt](/robots.txt), because a publication whose purpose is to be read by agents should practise what it preaches. Each bot-documentation link above was re-verified on 2026-07-08 and the per-token descriptions still match the operators' docs; the dated, token-by-token reference for every operator lives in [the AI shopping crawlers reference](/reference/ai-shopping-crawlers/). ## The allow-list decision For a store whose goal is to be found, quoted, and bought through AI agents, the sensible default is to allow the shopping and answer crawlers, and to treat *blocking* as the exception that needs a reason. The tokens above are your allow-list; the decision is which, if any, you deliberately close. The one nuance worth pausing on is training versus surfacing. Because OpenAI separates GPTBot (training) from OAI-SearchBot and ChatGPT-User (surfacing and live fetch), a merchant who is wary of feeding model training can, in principle, decline the training crawler while still letting the surfacing agents in. For most stores that middle ground is the pragmatic choice: you keep every path that puts you in front of a shopper and give up only the training use you were never compensated for. > **The block you didn't mean to ship** > > The most common way stores lock out AI agents is not a line in robots.txt at all. It's a web application firewall, a CDN "bot manager," or a "block AI bots" plugin quietly rejecting these user agents at the edge. If being selected by agents matters to you, audit those layers too: a crawler that gets a 403 is just as blocked as one you disallowed on purpose. ## What you lose by blocking Blocking the AI crawlers rarely makes a store vanish outright, which is exactly why the cost is easy to miss. The loss is quieter: closing the crawlers removes the supplemental page data an agent reads beyond your structured feed: the fuller description copy, specification details, review context, and availability nuance that live on your product page but never make it into a feed row. An agent that can only see your feed is choosing from a thinner picture of your product than one that can also read the page. > Illustrative example, not measured data. Two stores sell the same weighted sleep mask and both submit a clean feed, so both are eligible to appear. Store A allows the crawlers, so when a shopper asks an agent for "a breathable organic sleep mask for side sleepers," the agent can read the product page's fabric notes, the side-sleeper fit guidance, and forty reviews mentioning breathability. Store B blocks the crawlers, so the agent sees only the feed's title, price, and availability. When the query hinges on detail that lives on the page, Store A is the one with something to match against. This is a worked illustration of the trade-off, not a measured result. ## Crawler access vs your feed: two separate pipes It is tempting to think a good product feed makes crawler access optional, or that open crawlers make a feed redundant. Neither is true, because they are two different pipes into an agent. Your [product feed](/make-product-feed-ai-readable/) is the structured, merchant-controlled channel (titles, price, availability, GTINs) delivered to an engine's commerce surface. Crawler access is the unstructured channel: the live page an agent can read for everything the feed leaves out. The Google-Extended case makes the separation concrete. Because it is a usage-control token rather than a crawler, opening or closing it changes only whether your already-indexed content feeds Google's generative models. It touches neither your Merchant Center feed nor your search ranking. The lesson generalizes: audit the feed pipe and the crawler pipe independently, because a gap in one is invisible from the other. If your feed itself is thin, that is a separate fix: start with [making your product feed AI-readable](/make-product-feed-ai-readable/) and [the product schema agents trust](/product-schema-for-ai-shopping/). ## llms.txt for stores llms.txt is a public spec, published at llmstxt.org and revised to v2 in August 2026, for a root-level `/llms.txt` Markdown file that offers a large language model a curated, easy-to-parse map of a site's most important content. The idea is to hand an agent a clean index instead of making it infer structure from your navigation. Our site ships a generated [/llms.txt](/llms.txt) as a worked example; the format spec lives at llmstxt.org and we link out to it rather than reproduce it. If you want a copy-paste starting point for your own catalog, the [llms.txt for e-commerce catalogs blueprint](/blueprints/llms-txt-for-ecommerce-catalogs/) has a worked template and the section-ordering rationale. Here is the honest part, because this is where the hype outruns the evidence. There is no confirmed public evidence yet that ChatGPT, Gemini, or Perplexity read llms.txt when choosing products, so treat it as low-cost insurance for a future many expect, not as a ranking lever that moves selection today. Shipping one costs almost nothing and can only help if adoption arrives; building a strategy around it would be betting on behavior no engine has documented. One engine has now answered directly, and the answer is negative. Google's guide to optimizing for generative AI features, whose llms.txt guidance was added in June 2026, states that llms.txt files are not needed to appear in Google Search and that Google Search ignores them, so maintaining one neither helps nor harms a site's visibility or rankings there. Re-checked 2026-08-20: Google's stance stands and remains the only public engine position; we found no documentation from OpenAI, Perplexity, Anthropic, or Microsoft that any shopping agent reads `/llms.txt` when selecting products. ## Diagnose a store that's been blocked If your products are missing from an agent's results, an accidentally-closed crawler is one of the first things to rule out: a stray `Disallow`, a bot-manager rule, or a CDN returning 403s to these user agents. Check that the surfacing crawlers for your target engine (OAI-SearchBot and ChatGPT-User for ChatGPT, PerplexityBot for [Perplexity](/perplexity-shopping-optimization/)) can actually reach a live product URL before you go looking for subtler causes. That crawler check is only the first branch of a larger decision tree, though; missing products are far more often a data-gap problem than a blocking one. Walk the full diagnosis in order in [why you're not in ChatGPT shopping](/store-not-in-chatgpt-shopping/), and return to [how AI shopping agents choose products](/how-ai-agents-choose-products/) for the selection signals that decide the outcome once the crawler can see you. --- # Storefronts That Answer Tool Calls, Not Page Reads https://agentmint.net/handbook/storefronts-that-answer-tool-calls/ Almost every piece of advice on this site, and on every competing site, assumes an agent reads your page or your feed. A newer path breaks that assumption: on Shopify's Liquid storefronts an in-browser agent can call your store's tools directly, so selection stops being whether the agent can parse your HTML and becomes whether your tools return correct, current data when it asks. ## Key takeaways - WebMCP is a proposed web standard behind an origin trial in Chromium, not a shipped, universal standard. Treat it as an early path, not the default everywhere. - On every Shopify Liquid storefront it is live with nothing to install, so an agent can call tools like search and get_product instead of reading the page. - The merchant-side work moves from presentation to data correctness: a tool that returns stale stock or an incomplete variant set now fails visibly rather than degrading quietly. - Off Shopify there is nothing to adopt yet, and no engine has shown that answering tool calls well improves selection. The transferable lesson is that clean catalog data pays off on every rail. > **Scope: this is a proposal behind an origin trial, not a universal standard** > > WebMCP is described by Shopify as a proposed web standard, and it currently runs only in Chromium browsers through an origin trial. It is not something every agent in every browser can use today. Read the rest of this page as a change that has landed on one large platform, not as the new baseline for the whole web. ## What shipped on Shopify Shopify describes WebMCP as "A proposed web standard that lets a page register tools with the browser", so an in-browser AI agent calls those tools directly instead of reading the page and simulating clicks. It is live on every Liquid storefront and on the Hydrogen developer preview with "nothing to install or configure". The tool surface is documented, so this is a pointer rather than a restatement. The tools a storefront exposes include `search_catalog`, `browse_store`, `get_product`, `show_variant`, `get_cart`, `update_cart`, `cancel_cart`, `proceed_to_checkout`, `manage_orders`, and `search_shop_policies_and_faqs`, the feature is "limited to Chromium-based browsers", and the actions run against the shopper's live session. Shopify describes that browser limit as an origin trial. The exact argument shapes and return schemas belong in Shopify's own reference, and they will change, so link there rather than copying them. The important part for selection is the shift in what an agent has to do. Reading a page means the agent renders or parses your markup, guesses at ambiguous fields, and reconstructs a cart by clicking. Calling a tool means the agent asks a named function for a named thing and gets a structured answer back. The store, not the agent, now owns the accuracy of that answer. ## Shopify is folding its own tools onto the UCP shape Shopify is also consolidating its cart tooling. The `get_cart` and `update_cart` tools on the Storefront MCP endpoint are deprecated in favour of UCP-conforming Cart MCP tools at `https://{shop-domain}/api/ucp/mcp` (`create_cart`, `get_cart`, `update_cart`, `cancel_cart`, where `update_cart` uses replace semantics), and the deprecated tools were maintained until 2026-08-31. The direction matters more than the specific tool names. The interface agents use against Shopify merchants is converging on the [UCP](/glossary/#ucp) shape, so a merchant who invests in getting the cart contract right is investing in something wider than one vendor's endpoint. ## The catalog layer that decides whether you are even compared Tool calls sit on top of a catalog, and Shopify changed who can reach that catalog. Shopify removed the approval gate on Catalog access, so developers get it "with just an API key, no approval needed". Shopify describes Catalog as "the search infrastructure for shopping: a global, structured dataset that agents can search and understand, spanning billions of products", syndicated to "ChatGPT, Copilot, Shop app, and others". Shopify makes a first-party performance claim for that structured data, which belongs here as its own statement rather than as a measurement. Shopify states, first-party and unaudited, that "AI searches powered by Shopify Catalog convert at 2x the rate of those using scraped data." That is Shopify measuring its own product with no disclosed method, so treat it as a vendor claim, not evidence. Before any ranking happens, the catalog decides whether your listing is even placed beside a competitor. Shopify clusters "billions of product listings across millions of stores" under a Universal Product Identifier so an agent can tell that "one merchant's single listing and another merchant's twelve listings describe the same product line", using the rule that "If an attribute does not change the answer, it is a variant". This is the step that determines whether an agent compares your product against rivals or surfaces it on its own, and it happens upstream of anything you would think of as ranking. Clean [product feed](/glossary/#product-feed) data is what lets the cluster place you correctly. Two more Shopify controls are worth a quick mention. Shopify runs a trust-tier model in which "Higher trust tiers unlock broader access, including direct checkout completion", and a Universal Cart API that lets agents "collect items from any merchant, on or off Shopify, into a single, unified cart", in early access by waitlist. Catalog search can now filter by media type (`image`, `video`, `model_3d`) and returns video and 3D assets inline, so rich media becomes a filter criterion on the surfaces that support it. ## The same pattern shows up outside Shopify This is not only a Shopify story. Anthropic published an Apache-2.0 reference implementation of a shopping agent that searches, compares, plans, and fills a cart, plus a staff-facing merchant agent. It hands off to the merchant's own checkout: "The checkout card links to your own checkout route, or to the platform's hosted checkout URL... the backend returns the URL and the host renders it; the model never sees it." Payment processing is deliberately excluded. Read that for what it is and nothing more. The reference describes the pipeline functionally and gives no ranking, comparison, or selection algorithm, so it tells you how such an agent is wired, not how it decides. It also does not connect Anthropic to Shopify; no Shopify source names Anthropic, and I am not asserting an integration. What the two have in common is the shape: an agent that searches and builds a cart against structured interfaces, then hands the shopper to the store's own checkout. ## What changes when selection is a tool call Here is the argument, and it is inference rather than a documented finding. When an agent parses a page, ambiguous markup costs you a guess, and a wrong guess degrades quietly: the agent picks the likelier reading and moves on. When an agent calls a tool, the contract is explicit, so the failure modes change. A tool that returns stale stock, an incomplete variant set, or a policy lookup with nothing behind it fails visibly, at the moment the shopper is deciding, rather than blurring into a slightly-wrong page. The merchant-side work stops being presentation and becomes data correctness and API behaviour under a sequence of calls. That reframes most of the "make your page legible" advice in this handbook. Legibility still matters wherever agents read pages, which is still nearly everywhere. But on a tool-calling surface, the payload your tool returns is the product, and a well-written page around a tool that returns wrong stock does not save you. The discipline shifts toward the same place [serving agent traffic](/handbook/serving-agent-traffic/) and [information density](/handbook/information-density/) already point: correct, current, structured facts, now delivered through a function call instead of a fetch. ## What a merchant should do now On Shopify the honest answer is short: this is largely on by default, so the work is making sure the data behind those tools is right. Check that stock reflects reality, that every variant an agent can request actually resolves, and that your policy and FAQ content is real enough to answer `search_shop_policies_and_faqs`. If you target Google surfaces, keep your [UCP](/glossary/#ucp) profile and cart contract clean too, since Shopify's own cart tooling is moving to that shape. Off Shopify there is nothing here to adopt yet. WebMCP is a proposal behind an origin trial, and no other platform ships an equivalent by default. The transferable lesson is the one that already holds on every rail: the catalog correctness that makes a tool answer well is the same correctness that makes a feed or a page selectable. Say where this stops. No engine documents that answering tool calls well improves selection outcomes, and this page publishes no number that says it does. The case for doing the work is that correct data cannot hurt you on any surface, not that a measured lift exists. This is a shift in the interface, not a proven new ranking lever. ## What to measure Four checks tell you whether your tools would answer an agent well, and none of them require a live agent to run. - Stock accuracy at the tool boundary. Compare what `get_product` and `search_catalog` would return against your true inventory for a sample of SKUs, and track the rate of "in stock" answers for items you cannot actually ship. This is the freshness discipline in [offer consistency](/handbook/serving-agent-traffic/) applied to a function return instead of a page. - Variant resolution completeness. For a sample of products, confirm every purchasable variant an agent could request resolves to a real, buyable option, and count the ones that dead-end. An incomplete variant set is a tool failure a shopper sees mid-decision. - Policy and FAQ coverage. Ask the questions `search_shop_policies_and_faqs` is meant to answer (returns, shipping, warranty) and record how many return nothing usable. Empty policy lookups are a visible failure on a tool-calling surface. - Catalog cluster placement. Where you can inspect it, check whether your listings are grouped with the right product line rather than split off or merged with the wrong one, since that placement decides whether an agent compares you at all. If your products are missing from an engine's results despite clean tool data, start the wider diagnosis in [how AI shopping agents choose products](/how-ai-agents-choose-products/), and if the problem is your origin turning agents away, work through [serving agent traffic](/handbook/serving-agent-traffic/) first. --- # Lowest Price but Still Not Recommended by AI Agents https://agentmint.net/lowest-price-but-not-recommended/ ## Key takeaways - Price is necessary but not sufficient: being the cheapest for a query does not win agent selection by itself, so a pricier rival can still get recommended. - There are four reasons your price edge fails to convert: price is weighted differently per model, a non-price lever (reviews or endorsement) outscores it, your all-in cost is not legible before checkout, or your listing is not comparable enough for the price to be weighed at all. - Two of the four are directly fixable this week: make your total landed cost readable on a cold product page, and earn genuine review depth and endorsement instead of a self-applied 'best value' tag. - If none of the four fit, the problem is not price. Stop re-checking your discount and hand the general appear-but-not-picked question to the shown-but-not-selected diagnostic. ## Price is necessary, but never sufficient The instinct when you lose to a pricier competitor is that the agent got it wrong, or that the number it read was stale. Sometimes that is true, and when the agent is [quoting a wrong price or stock figure](/ai-showing-wrong-price-or-stock/) you have a data-freshness bug, not a selection one. But far more often the agent read your lower price correctly and still chose someone else. Being the cheapest for a query is necessary but not sufficient: a low price keeps you in contention, but on its own it does not win the recommendation. The reason sits in how agents actually decide. In the ACES framework, a controlled simulation of shopping agents choosing from a mock storefront, price was one of several weighted signals (alongside grid position, star rating, platform endorsement, and description text), and its weight differed from model to model rather than dominating the decision. Price is a lever, not the lever. When you are cheapest and still lose, one of the other levers outscored your discount. The rest of this page is the four ways that happens and how to tell which one is yours. This is the [agent selection](/glossary/#agent-selection) question at its sharpest, and it is why the ACES per-model numbers live on the [how AI agents choose products](/how-ai-agents-choose-products/) cornerstone rather than being repeated here. ## Cause 1: price is weighted differently on every engine The first trap is assuming a discount that won you the recommendation on one engine will win it on another. ACES found that price sensitivity varied sharply across the models it tested, so the same markdown can move one engine's selection rate noticeably and barely register on another. A price edge is real, but it is not worth a fixed amount of selection everywhere. In practice, if you set one price strategy and judge it from a single blended, all-engine number, you can be genuinely winning on a price-sensitive engine and losing on a price-insensitive one, and the blend hides both. The signal to track here is [model-specific price sensitivity](/signals/model-specific-price-sensitivity/), and the discipline is on the [selection checklist](/tools/agent-selection-checklist/#b-price-position-03): test a price change isolated to one engine, then compare that engine's before-and-after win rate. The per-engine differences themselves belong to the [Gemini and Google AI Mode playbook](/gemini-shopping-ranking/) and its siblings, not here. ## Cause 2: a non-price lever is outscoring your price edge You can be cheapest and still be the thinner listing. ACES reported that star rating and review depth are positive selection levers, and that agents reward legitimate platform endorsements while penalizing a self-applied "Sponsored" tag. Put those together and a pricier competitor with a deep, recent review history and a genuine platform endorsement can outscore your lower price, because the agent is adding up several weighted signals and your advantage sits in only one of them. The fix is not to drop your price further, which chases the one lever you are already winning. It is to close the gap on the levers you are losing: [review depth](/signals/review-depth/) that is truthful and current, and a real [platform-endorsement signal](/glossary/#platform-endorsement-signal) you actually qualify for. The tempting shortcut, a self-applied "best value" or "sponsored" badge, is the exact move the [earn endorsement, do not self-label](/signals/endorsement-not-sponsored/) signal warns against: it reads as promotional and can cost you selection rather than buy it. ## Cause 3: your "lowest" is not legible as the lowest all-in cost An agent can only credit a price advantage it can compute. If your sticker price is the lowest but shipping, tax, or fees only surface once the agent starts checkout, the agent cannot compare your landed total against a rival whose all-in cost is readable up front, so it either estimates you high or drops you. Your real advantage exists, but it is invisible at the moment of comparison. This is a legibility problem, not a pricing one, and it is the most fixable cause on the list. The [offer-cost-legibility](/signals/offer-cost-legibility/) signal and the [make total landed cost readable](/tools/agent-selection-checklist/#b-offer-legibility-01) checklist item both target it: show the current price, any sale window, shipping, and fees as plain, parseable numbers on a cold product page, and make every figure match what checkout later charges. The full field-by-field fix lives in [make your product feed AI-readable](/make-product-feed-ai-readable/); this page's job is only to tell you that a hidden shipping cost, not your price, may be why the cheaper offer loses. ## Cause 4: you are not comparable, so the price is never weighed The last cause is the quietest: the agent never got far enough to weigh your price at all. If your listing is missing the attributes the top offers in your category expose, the agent has nothing to line you up against, so a lower price on an under-described product loses to a fully-described one it can actually compare. Completeness against your peers, or [facts per token](/signals/facts-per-token/), is what earns you a place in the comparison in the first place. Grid position can hide a price advantage the same way. ACES found grid position to be a large but provider-specific selection lever, so where an engine renders you can swamp a modest price difference. Both of these, comparability and [position bias](/glossary/#position-bias), are the general appear-but-not-picked problem rather than the price paradox, so this page hands them off. If tightening your price changes nothing and none of causes 1 to 3 fit, that is the signal to switch diagnostics: work the [shown-but-not-selected](/shown-but-not-selected/) decision tree, which owns comparability and position in full. ## How to check which cause is yours You cannot tell these apart by staring at the result once. Run a small, repeatable check on the engine that is picking your competitor: 1. Ask the buying question the way a shopper would, and record who the agent recommends and, if results render as a grid, where each offer sits. 2. Open the recommended competitor and your own listing side by side, and compare on the four dimensions above: can the agent read each product's all-in cost, its review depth, its endorsement status, and its attribute completeness? 3. Note the one dimension where the competitor is clearly ahead. That is your most likely cause, and it points at the matching fix above. 4. Repeat the query enough times to separate a real pattern from one lucky or unlucky run, and read your [agent win rate](/glossary/agent-win-rate/) per engine rather than reacting to a single answer. The full sampling-and-error-bars protocol (how many runs, how to log them, how to be sure a change is real) is in [how to test agent selection](/handbook/how-to-test-agent-selection/); it is the same protocol you use to confirm any fix below actually moved the result. ## How to fix it, in priority order Work the cheapest, highest-certainty fixes first: 1. **Make your all-in cost legible** (cause 3): surface price, sale window, shipping, and fees in parseable text that matches checkout. Details in [make your product feed AI-readable](/make-product-feed-ai-readable/). 2. **Close the non-price gaps** (cause 2): earn genuine review depth and a real endorsement, and remove any self-applied sponsored or "best value" styling. 3. **Fill your comparability gaps** (cause 4): list the attributes your top competitors expose, complete yours truthfully, then hand the rest to [shown-but-not-selected](/shown-but-not-selected/). 4. **Test price per engine, not in aggregate** (cause 1): isolate a price change to one engine and read that engine's win rate. Notice what is not on the list: cutting your price again. When you are already the cheapest, another markdown spends margin on the one lever you are winning and leaves the losing levers untouched. ## When the answer is "price was never the problem" The uncomfortable finding is often that your discount was fine all along. Because price is only one weighted input, a pricier competitor winning is usually evidence that it is stronger on a different input, not that your price is too high. Chasing a lower number is the most expensive way to not fix that. If you have ruled out all four causes and still lose, the problem has moved past price entirely: you may be [absent from the engine altogether](/ai-engine-visibility-gap/), or the agent may be [quoting a wrong price or stock figure](/ai-showing-wrong-price-or-stock/) that erases your real advantage. Both are their own diagnostics. The broader "I appear but never get picked" case belongs to [shown-but-not-selected](/shown-but-not-selected/); this page ends where the price question does. ## Frequently asked questions ### If I have the lowest price, why does the AI agent recommend a more expensive product? Because price is necessary but not sufficient. The agent scores your offer on several weighted signals at once (reviews, endorsement, and whether it can read your full landed cost), and controlled tests show it weights price differently from model to model. A thin listing, or a shipping cost hidden until checkout, can outweigh a lower sticker price. ### Will cutting my price further make the agent pick me? Not reliably. In the ACES simulation, price sensitivity varied by model, so the same discount moves engines differently and a deeper cut on one engine can barely move another. Test a price change on one engine at a time and read that engine's win rate before rolling it out everywhere. ### Should I add a 'lowest price' or 'best value' badge so agents notice my deal? No. ACES reported that agents penalize a self-applied 'Sponsored'-style tag and reward genuine platform endorsements, so a promotional badge you apply yourself can cost you selection. Earn a real editor's-pick or verified-seller status, and state your price and shipping as plain, parseable numbers instead. --- # Perplexity Shopping Optimization https://agentmint.net/perplexity-shopping-optimization/ ## Key takeaways - Perplexity is an answer engine: it retrieves sources at query time and cites them, so the products it can surface are the ones it can crawl and quote. This is our operating model, grounded in how answer engines work, not measured Perplexity data. - Citable and structured are the same work: the clean specs, schema, and consistent price and availability that make any page machine-readable are also what let Perplexity quote you accurately. - Keep Perplexity's crawler allowed in robots.txt: blocking it removes the page data it would otherwise cite. The full crawler allow-list lives on our crawlers page. - The free Perplexity Merchant Program is the one documented direct data rail: its own terms enumerate the product data merchants supply (price, availability, shipping lead times, returns policies), the same fields this handbook tells you to make legible everywhere. - Honest caveat: the strongest public selection study, ACES, did not include Perplexity, so every recommendation here is a crawlability-and-citability hypothesis, not a measured Perplexity finding. - Because no public dataset measures Perplexity's selections, treat your own agent win rate on Perplexity as the number that matters, and measure it directly. ## How Perplexity recommends: crawl, then cite Perplexity is built as an answer engine rather than a catalog: it responds to a shopping question by retrieving sources and citing them at answer time. A merchant data program exists (covered below), but it feeds Perplexity's index rather than replacing retrieval. That framing is where the merchant leverage lives, and it is the premise we reason from. If Perplexity assembles a recommendation from sources it retrieves and cites at answer time, then a product page it cannot crawl (or one whose facts it cannot pin to a clear, quotable passage) is one it is unlikely to surface, however good the offer is. That mechanism runs through the whole page, and we say plainly where the reasoning ends and measured evidence would need to begin. This is the same [agent selection](/glossary/#agent-selection) problem the rest of AgentMint.net covers (why an engine picks one store over another), but Perplexity leans harder on retrieval and citation than the feed-first engines do, even with its Merchant Program as a direct data rail. That makes it, in our reading, the platform where general [answer engine optimization](/glossary/#aco-aeo) discipline maps most directly: be crawlable, be structured, be quotable. The shared signal set and the per-engine differences are laid out across the [platform playbooks](/platforms/); the [ChatGPT](/chatgpt-shopping-optimization/) and [Gemini](/gemini-shopping-ranking/) pages cover the engines that reach you over a commerce protocol rail, which Perplexity, on the evidence we have, does not obviously do. ## Make your product pages citable If Perplexity recommends what it can quote, the work is making each product page trivially quotable. The same structured, machine-readable product data that helps any agent parse you (explicit specifications, product schema, and a price and availability that agree between page and feed) is what lets Perplexity extract an accurate, citable fact instead of guessing or skipping, so citability and structure move together. A page that buries its key facts in prose, an image, or a script an answer engine cannot read gives it nothing clean to cite. Concretely, that means the machine-readable layer is doing double duty here: it earns eligibility with feed-driven engines and it earns *quotability* with a citation-first engine. Ship the [product schema (JSON-LD) for AI shopping](/product-schema-for-ai-shopping/) that states your `Offer`, price, availability, and review fields in a form a machine can lift verbatim, and keep the on-page facts consistent with it, because an answer engine that finds two prices has to choose which to trust, and inconsistency is a reason to cite a competitor instead. We label this direction a hypothesis on purpose: it follows from how citation works, and it is not a measured Perplexity result. ## Keep Perplexity's crawler in your robots.txt Retrieval only reaches what it is allowed to fetch, so crawler access is the precondition for everything above. Blocking an answer engine's crawler in robots.txt deletes the supplemental page data it would otherwise retrieve and cite, so a disallow line can quietly remove you from the set of products Perplexity is able to recommend at all. Perplexity publishes a [bot guide](https://docs.perplexity.ai/guides/bots) for the user agents it operates, and the practical move is to keep `PerplexityBot`, the indexing crawler, allowed in robots.txt for your product URLs, since that is the token whose access actually determines what gets crawled and cited later. Perplexity distinguishes PerplexityBot, an indexing crawler that honors robots.txt, from Perplexity-User, a user-triggered fetcher that generally ignores robots.txt because a real user initiated the request, so a disallow line mainly affects PerplexityBot's indexing, not a user's live, on-demand fetch. The complete, cross-engine crawler allow-list (GPTBot, OAI-SearchBot, Google-Extended, and Perplexity's agents) and what `llms.txt` adds live on [AI crawlers, robots.txt and llms.txt](/ai-crawlers-robots-llms-txt/); this page only flags that a crawl-and-cite engine is the one you can least afford to block. ## The Merchant Program: the one direct data rail Retrieval is not the only path into Perplexity's index. Perplexity's shopping launch announcement introduces the Perplexity Merchant Program as free for merchants, built so large retailers can share product specs directly and keep live product details in Perplexity's index, and states it is distinct from Perplexity's sponsored-questions ad products; the listed benefits are a better chance of appearing as a recommended product (because richer data helps Perplexity judge quality and relevance), payment integrations that include a merchant in the one-click Buy with Pro checkout, free API access, and a dashboard with search and shopping trends for the merchant's products. TechCrunch reported at the program's launch that Perplexity said it was not taking an affiliate cut from purchases at the time. The buying side is narrower than the discovery side. Buy with Pro is Perplexity's one-click checkout for Pro users in the US, covering select products from select merchants on Perplexity's site and app, with free shipping on Buy with Pro orders and a redirect to the merchant's own site when it is not available; the same announcement states that product cards are not sponsored and that the discovery experience is powered by platform integrations including Shopify stores that sell and ship to the US. What should a merchant actually prepare? The program's contract answers that more concretely than any blog post. The Merchant Program Terms define the Product Data a merchant supplies as its product catalog including title, price, description, brand or source, model, weight, in-stock and availability status, country of origin, shipping lead time, shipping options and origination, dimensions, images, warranties, returns and exchange policies, and required warnings, notices, labels, and compliance certificates. Read that list against the rest of this handbook and it is the same legibility work: Perplexity contractually expects availability, shipping lead times, and returns policies in the data a merchant hands over, which means the offer-legibility and delivery-and-returns signals you build for every other engine are literally the enrollment package here. ## The evidence gap: ACES did not test Perplexity This is the least-evidenced platform page on the site, and saying so is the point. The most rigorous public study of how buying agents choose (the ACES framework) never tested Perplexity. ACES audited a fixed set of frontier models, Claude Sonnet (up to version 4), GPT-4o and GPT-4.1, and Gemini 2.0 and 2.5 Flash, in a controlled storefront simulation, and Perplexity was not among the models it evaluated. So none of the measured selection effects you will see quoted elsewhere on AgentMint.net (position bias, price elasticity, the sponsored-tag penalty, endorsement lift) can be attributed to Perplexity. They are findings about other agents. > **What this page is, and is not** > > Every recommendation here is a hypothesis grounded in general crawlability and citability, not a measured account of Perplexity's behavior. We would rather ship an honest gap than borrow another engine's numbers and imply they describe Perplexity. That is the difference between this page and a vendor blog that asserts Perplexity specifics it cannot source. Because no public dataset measures how Perplexity ranks or selects products, the responsible guidance for it is the engine-agnostic foundation (be crawlable, be structured, be quotable) rather than any Perplexity-specific weighting we cannot evidence. The one documented direct rail is the free Merchant Program above, and its announcement and Terms are the final word on what it offers and expects; beyond what they state, we make no claim about enrollment specifics or any commerce-protocol rail, because no primary source documents them. ## Measure it on your own catalog With no measured Perplexity data to lean on, the substitute is your own catalog. Rather than trust a directional hypothesis, put real products in front of Perplexity for the queries you care about and record how often it recommends or cites you, your [agent win rate](/glossary/#agent-win-rate) on that specific engine. That is a number you can move and re-measure, where a borrowed benchmark would only be a guess. The repeatable protocol (the prompts, the sampling plan, and the error bars that keep the result honest) is documented in [how to test agent selection](/handbook/how-to-test-agent-selection/), which covers Perplexity alongside ChatGPT and Gemini. AgentMint.net publishes no measured Perplexity figures and will not invent one to replace the hypotheses on this page. Run the protocol and the number you get is yours. --- # Anatomy of a Citable, Comparable Product Detail Page https://agentmint.net/product-detail-page-anatomy/ ## Key takeaways - An AI agent does not browse your product page, it extracts it: title, all-in price, availability, specs, and reviews become one structured row it lines up against every competitor. - A page that reads fine to a person can be un-comparable to an agent. If an element is missing from the text or markup, the agent guesses or drops you on that axis. - The individual parts are taught on their own pages; this is the whole-page view: which elements matter and how an agent assembles them into a comparable offer. - Under all of it sits server-rendered HTML plus structured data. Get the substrate wrong and every element above is invisible, however complete it looks to a human. ## The whole-page view: your PDP becomes one comparable row When an AI shopping agent reads a product detail page, it is not browsing it the way a person does. It is extracting it: pulling the title, the price, what shipping adds, whether the item is in stock, the specs, and the reviews into a single structured record it can line up next to every competing offer. A product detail page an agent can cite and compare is one where that whole record is readable from the page itself, with nothing left for the agent to infer. The strongest public evidence, the academic ACES framework, found that what moved an agent's choice were structured attributes (grid position, price, star rating, platform endorsement, and description text) in a controlled simulation of Claude, GPT-4.1, and Gemini agents rather than a record of real sales. In practice that finding is a whole-page requirement. We expect an agent can only compare you on the axes you make legible, so a page that reads fine to a person but leaves the all-in price, a key spec, or the review count out of its text and markup is a page the agent cannot fully place against its rivals. This page is the connective view over the catalog cluster. The individual elements each have their own page, linked in place below; here we walk the whole product detail page and how its parts combine into a comparable offer. For why these signals decide the pick at all, start at the hub, [how AI shopping agents choose products](/how-ai-agents-choose-products/), and the definition of [agent selection](/glossary/#agent-selection). ## The identity layer: title and product identifiers Before an agent can compare your offer, it has to match your product to the shopper's query and resolve it to a known item. Two elements do that work. The **title** is the text matched most directly against what the shopper typed, so it has to lead with the category and defining attributes a query can land on. That formula, and the literal-match failure mode behind it, is the whole subject of [product titles that AI agents match](/product-titles-for-ai-agents/), which this page does not restate. The **identifiers** (GTIN, brand, MPN) are what let an agent tie your listing to the same product sold elsewhere and de-duplicate it across sources. The open Agentic Commerce Protocol, the checkout standard behind ChatGPT Instant Checkout, standardizes the core product attributes an agent reads, including product identifiers such as GTIN, price, and availability. Where those identifiers belong in your markup is the job of [product schema for AI shopping](/product-schema-for-ai-shopping/), and keeping them filled and correct across every listing is the job of [your product feed](/make-product-feed-ai-readable/). The whole-page point is smaller: a title that matches but no identifier to anchor it, or an anchor with a brand-only title, leaves the agent with half of what it needs to place you. ## The offer layer: the all-in price, availability, and delivery An agent does not compare list prices, it compares offers, and the offer is the price a shopper actually pays plus whether and when the item can arrive. The single most common way a PDP becomes un-comparable is hiding the parts of that number until checkout. The **all-in price** (item price plus shipping, fees, and tax treatment) is the figure an agent lines up against competitors, so it has to be computable from the page before checkout starts, not revealed at the payment step. Surfacing it early is a selection lever the [agent selection checklist](/tools/agent-selection-checklist/) treats as its first offer-legibility item, and the field-level how-to sits in [make your product feed AI-readable](/make-product-feed-ai-readable/); this page only insists the page carry it. **Availability and delivery** answer the two questions an agent will not recommend around: can you fulfil this, and by when. A blank or stale availability field is an easy reason to skip you rather than risk recommending something out of stock. There is a hard constraint on all of it: the offer an agent reads must be the offer a shopper is charged. Google's structured-data policies require your markup to be a true representation of the content visible on the page. Its merchant-listing documentation defines the offer, shipping, and return fields an agent parses. Showing an agent one price and a shopper another is not a targeting tactic, it is a parity violation that can get products disapproved and erodes trust. Serving the same data in a machine format is fine; serving different data is cloaking, a boundary drawn in full on [raising information density](/handbook/information-density/). ## The comparison layer: the specs and reviews that break a tie Identity and offer get you into the comparison. What wins it, once several products are eligible, is the content an agent can actually rank on. Two elements carry most of that weight. **Specs and attributes** are the columns of the comparison table. An agent can only compare products on the attributes every candidate exposes, so the fields your category's leaders fill and you leave blank are silent losses, a completeness-versus-peers judgment no validator makes for you. That judgment, and the evidence that agents rank on structured attributes, live on the hub, [how AI shopping agents choose products](/how-ai-agents-choose-products/). **Review depth** is the trust column. In the ACES simulation, ratings were a strong selection lever and review count mattered as a signal distinct from the average score, so genuine depth (a truthful count, recent reviews, and a real distribution) plausibly gives a rating-sensitive agent more to weigh. Depth is the lever; fabricated ratings are both a rule violation and, on this evidence, a weak play. These are the fields worth auditing against your competitors first, because they are the ones tied to a decision rather than to a checkbox. And how completely they are filled is itself measurable. On Adobe's AI Content Visibility Checker, retail product pages score an average of 66 out of 100 for machine readability, meaning roughly a third of a typical product page is not cleanly machine-readable to an agent. The [machine-readability score](/glossary/#machine-readability-score) is where that gap becomes a number you can move. ## The substrate: server-rendered HTML and structured data Every element above is only as legible as the layer that carries it. Two things make up that substrate, and both are load-bearing for the whole page. **Structured data** (the Product and Offer JSON-LD) is the block an agent can lift field by field without interpreting your layout or your marketing copy. It is the tie-breaker an agent trusts when your page and feed disagree, and its fields and syntax are the subject of [product schema for AI shopping](/product-schema-for-ai-shopping/). **Server-rendered HTML** is the precondition under that: we expect a crawler or agent that does not execute JavaScript to miss any price, spec, or availability injected client-side, so a fact locked in a script-rendered widget, a PDF, or a product image reads as absent even when a human plainly sees it. A price baked into a hero graphic, a spec table fetched only on click, a policy trapped in a PDF: to the agent, each is a blank cell. Whether agents can reach and afford to read that HTML at all is its own layer, covered in [manage AI crawlers, robots.txt and llms.txt](/ai-crawlers-robots-llms-txt/) and [serving agent traffic](/handbook/serving-agent-traffic/). The rule that ties the substrate together: state each decision fact as text or markup, not only as a picture, and keep image `alt` describing the product honestly rather than repeating keywords. What an agent cannot read, it cannot use, however good the page looks. ## How an agent assembles the offer Put the layers together and the mechanism is simple. The agent reads the page top to bottom, extracts each element it recognises, and assembles one comparable record. Every element you leave out of the text and markup is a cell it fills with a guess or leaves empty, and an empty cell is a reason to prefer a competitor whose row is complete. > Illustrative example, not measured data. Two sleep masks answer the same query. The agent tries to build one comparison row per store from each page: | Axis | Store A (complete PDP) | Store B (gaps) | | --- | --- | --- | | Identity | "Weighted sleep mask" + GTIN | "The Luna", no identifier | | All-in price | $24.99 + $4.99 ship, shown | $19.99, shipping hidden until checkout | | Availability | In stock, ships in 1-2 days | Blank | | Key specs | Weight, material, strap type | Marketing copy only | | Review depth | 4.6 from 1,842, recent | "4.6 stars", no count | Store B is cheaper on the list price, but the agent cannot fill three of its five cells from the page, so it cannot confirm the total cost, that the item ships, or how deep the reviews run. The completed row is the one it can recommend with confidence. We read the whole-page evidence to mean the least-legible element caps how well you place: the offer is only as comparable as its weakest-filled axis, because the agent has to reason about the row as a whole and one blank cell is enough to move it to a safer pick. That is why a complete PDP beats a marginally cheaper incomplete one, and why the elements above are worth treating as a set rather than a punch list. ## What to measure Do not eyeball this; build the row the agent builds. Take one product page and, with JavaScript disabled or from view-source, try to fill a five-column comparison table by hand: identity (title plus a GTIN), the all-in price to a real destination, availability and a delivery estimate, the top five specs your category's leaders expose, and the review count with a recency signal. Every cell you cannot fill from the raw HTML and structured data alone is an axis an agent cannot compare you on either. Count the blanks, close them, and re-run the check after any template change. Then confirm it moves the outcome that matters. Run the manual [agent win-rate protocol](/handbook/how-to-test-agent-selection/) across ChatGPT, Gemini, and Perplexity before and after you complete the row, log a win or no-win per engine, and keep the definition fixed so results stay comparable over time. This site publishes no measured numbers of its own, so your win rate is the honest test of whether a more complete page earned more selections. ## Frequently asked questions ### Does an AI agent read my product page, or only my feed? Both, and they can disagree. An agent reads the structured data and text on your live page as well as any feed you submit. When the two conflict, we expect the agent to trust the on-page machine-readable layer, which is why the page has to carry the whole offer, not lean on the feed to fill gaps. ### What is the difference between an eligible product page and a comparable one? Eligible means the page passes validation and can appear at all. Comparable means an agent can extract every axis it lines competitors up on (identity, all-in price, availability, key specs, review depth) from the page itself. A page can be fully eligible and still lose because one of those axes is blank. --- # Why You Show in One AI Engine but Not Another https://agentmint.net/ai-engine-visibility-gap/ ## Key takeaways - Showing in one AI engine but not another for the same search is almost never an eligibility problem, because one engine already proves your catalog is legible. It is an engine-specific gap: the wrong rail, a blocked crawler, or a hole in the one data source the missing engine reads. - The engines run on different rails. ChatGPT's checkout is on ACP, Gemini and Google AI Mode are on UCP over your Merchant Center feed, and Perplexity works from pages its crawler can fetch and cite. Implementing one rail does not enroll you on the others. - Per-engine 'not in Gemini' and 'not in Perplexity' are the same diagnosis run against a different engine, which is why this is one cross-engine page and not three near-duplicate ones. Diagnose the missing engine on its own terms. - One trap looks like absence but is not: you can be present on an engine yet never ranked first. Measure each engine separately before you conclude you are missing at all. ## The same store, one engine sees you and another does not This page is for a specific, confusing symptom: your store surfaces fine in one AI shopping engine but is missing from another for the same query, with the same catalog behind both. That differential is the whole diagnosis. If one engine can find and recommend you, your product data is legible enough to work, so the missing engine is not rejecting your store on quality. Something engine-specific is in the way. That framing also tells you when you are on the wrong page. If you appear in no engine at all, that is total absence, and the flow for it is [why you're not in ChatGPT shopping](/store-not-in-chatgpt-shopping/), which works one engine's absolute absence in order. If you do appear but keep losing the recommendation to a competitor, that is a selection problem, covered in [shown but not selected](/shown-but-not-selected/). Stay here only when the pattern is comparative: present in at least one engine, absent from another. There is a deliberate reason this is a single cross-engine page. "Not in Gemini," "not in Perplexity," and "not in ChatGPT" are the same diagnosis pointed at a different engine: find the rail, crawler, or data-source gap for whichever engine is missing. Splitting that into a page per engine would just repeat the four checks below three times, so we consolidate them here and hand off to each engine's playbook for the fix. Work the four causes in order, and stop at the first one true for the engine you are missing from. ## Cause 1: you built the wrong rail for the missing engine The engines do not share one commerce pipe, so implementing the plumbing for one does nothing for the others. ChatGPT's Instant Checkout runs on the [Agentic Commerce Protocol](/glossary/#acp) (ACP), the open commerce standard from OpenAI and Stripe. Google's own UCP developer documentation states that adopting the [Universal Commerce Protocol](/glossary/#ucp) (UCP) enables agentic actions on AI Mode in Google Search and Gemini, starting with direct buying, layered on the Merchant Center feeds merchants already run. Perplexity operates and documents its own crawler, PerplexityBot. Its shopping recommendations lean on pages that crawler can fetch and cite, so the entry point differs again from ACP or UCP. Because the transactional rails differ per engine, we expect building only one of them to leave the others unable to surface or transact you. A store that shipped an ACP feed and checkout for ChatGPT has done nothing that puts it on the UCP rail Gemini uses, and vice versa. So if the engine you are missing from runs a rail you never implemented, that is your cause, and it is a build task, not a wait. Do not re-derive the protocols here: the side-by-side comparison of what each covers is in [UCP vs ACP](/ucp-vs-acp/). The two readiness items to work are publishing a UCP profile if you are missing from Google surfaces and building the ACP feed and checkout if you are missing from ChatGPT. ## Cause 2: you blocked that engine's crawler, but not the others Each engine reaches your site through its own separately-named user agents, so a rule that blocks one leaves the others untouched, which is exactly how you end up visible in one engine and invisible in another. OpenAI documents OAI-SearchBot as the agent that surfaces pages inside ChatGPT, carrying a named user-agent token that robots.txt can allow or disallow; Google and Perplexity document their own distinct tokens the same way. So a `Disallow` for PerplexityBot while OAI-SearchBot is allowed, or a WAF rule that challenges one engine's crawler and not another's, produces precisely this split: present in the allowed engine, absent from the blocked one. The block is often accidental and lives below robots.txt, in a CDN bot manager, a "block AI bots" plugin, or a firewall rule that filters one range and not others. The exact tokens per engine, and which are search versus training crawlers, are in the [AI shopping crawler reference](/reference/ai-shopping-crawlers/); the practical move is to confirm the missing engine's crawler token is allowed in robots.txt and not being silently blocked at the edge. Allow the AI search crawlers explicitly, and verify your bot protection is not filtering legitimate agent traffic for the one engine you are missing. ## Cause 3: the one data source that engine reads has a hole Even with the right rail and an open crawler, an engine can only work from the source it actually reads, and those sources differ. Google's UCP documentation describes AI Mode and Gemini shopping actions as layered on the Merchant Center feeds merchants already run. That makes an incomplete or absent Merchant Center feed a Gemini-shaped hole specifically: ChatGPT can see you through your ACP feed and pages while Gemini, drawing on Merchant Center, has too little to represent you. Perplexity's readable source is different again. Because it recommends what its crawler can fetch and quote, we expect a store whose product facts only appear after client-side JavaScript, or behind a block, to be legible to a feed-based engine yet effectively blank to Perplexity. So match the fix to the missing engine's source. If Gemini is the gap, the lever is a complete, accurate Merchant Center feed carrying every required attribute. If Perplexity is the gap, the lever is server-rendered, crawlable product pages that state the facts in the HTML, plus a machine-readable mirror where you keep one. A hole in whichever source the missing engine reads is enough to erase you from that engine alone. ## Cause 4: you are present, just never ranked first Before you conclude an engine cannot see you, rule out that it can, and simply never places you where you looked. "Absent" and "present but never in the visible pick" look identical if you only ever check one answer. The ACES simulation reports that position bias varies by provider and persisted even in text-only interfaces, which the authors note undermines any universal notion of a "top" rank. ACES is a controlled simulation over a fixed model set, not live sales, so read it as a pattern to watch. Because ranking behavior differs per engine, we expect the same store to sit in a visible slot on one engine and be pushed out of view on another, reading as a visibility gap when it is really a ranking one. This case is measurement first, not a content edit. Run the same query repeatedly on the missing engine and check whether you appear at all lower in the results before assuming absence. If you are genuinely never returned, work causes one through three. If you are returned but never near the top, that is selection, and the reasoning behind it is in [how AI agents choose products](/how-ai-agents-choose-products/) with the full decision tree in [shown but not selected](/shown-but-not-selected/). Either way, retest after model updates: ACES documents that model updates can drastically reshuffle market shares, so an engine that carried you last quarter can change after a release. ## How to check which engine is failing, and why The differential is what makes this tractable, so run it as one procedure rather than eyeballing a single answer: 1. **Confirm the split is real.** Ask the same query on each engine several times, not once. A single miss can be sampling noise. You are looking for a consistent pattern where one engine returns you and another does not. 2. **Fetch a live product URL as the missing engine's agent would**, and confirm it returns the page, not a block. If it returns a 403 or a challenge for that engine's token while another engine's fetch succeeds, you have Cause 2. The tokens to test are in the [crawler reference](/reference/ai-shopping-crawlers/). 3. **Check which rail you built for the missing engine.** No UCP profile and you are missing from Google surfaces, or no ACP feed and checkout and you are missing from ChatGPT, points at Cause 1. 4. **Inspect the source that engine reads.** For Gemini, is the Merchant Center feed present and complete? For Perplexity, do the product facts render in server HTML without JavaScript? A gap there is Cause 3. 5. **Measure per engine, never blended.** Track your [agent win rate](/glossary/agent-win-rate/) for each engine separately with a repeatable protocol, so a real absence is distinguishable from a low rank and from a coincidence. The prompts, sampling, and error bars are in [how to test agent selection](/handbook/how-to-test-agent-selection/). > **Do not close the gap by serving engines different content** > > The fix for a per-engine gap is never to detect one engine's agent and hand it different content, prices, or availability than you show shoppers or the other engines. Varying content by user agent at one URL is cloaking, a search-spam and trust violation. Serving the same facts in a machine-preferred format at the same URL is fine; changing the facts per engine is not. ## How to fix it: on the missing engine's own rail Once you know which engine is failing and why, the fix lives on that engine's terms, which is why this page hands off rather than restating three playbooks. Missing from ChatGPT is worked in [ChatGPT shopping optimization](/chatgpt-shopping-optimization/); from Gemini or Google AI Mode in [Gemini shopping ranking](/gemini-shopping-ranking/); from Perplexity in [Perplexity shopping optimization](/perplexity-shopping-optimization/). The protocol question underneath Cause 1 is settled in [UCP vs ACP](/ucp-vs-acp/), and the [platforms hub](/platforms/) is the map when you are missing from more than one at once. Because per-engine absence is one diagnosis pointed at different engines, run this same tree for each engine you are missing from rather than treating them as separate mysteries. And keep the neighboring symptoms straight: if you appear on every engine but keep losing the pick, that is [shown but not selected](/shown-but-not-selected/); if you are the cheapest and still lose, it is [lowest price but not recommended](/lowest-price-but-not-recommended/); and if the engines are quoting a stale price or wrong stock for you, that is a data-accuracy fault covered in [when AI shows the wrong price or stock](/ai-showing-wrong-price-or-stock/). ## Frequently asked questions ### I show up in ChatGPT but not Gemini for the same search. Is that an eligibility problem? Usually not. If you already appear in one engine for that query, your catalog is fundamentally legible, so the gap is engine-specific plumbing: a different commerce rail, a blocked crawler token, or a hole in the one feed or page source the missing engine reads. Diagnose the missing engine on its own terms. ### Do I need a separate protocol for each AI shopping engine? For transactional surfaces today, largely yes. ChatGPT's checkout runs on ACP; Gemini and Google AI Mode run on UCP layered over the Merchant Center feed; Perplexity leans on pages its crawler can fetch and cite. Implementing one rail does not enroll you on the others, so a full cross-engine presence means covering each engine's rail. ### Why is this one page instead of a separate 'not in Gemini' and 'not in Perplexity' page? Because they share one diagnosis: find the engine-specific rail, crawler, or data-source gap for whichever engine is missing. A page per engine would repeat the same four checks. The different case, where you appear in no engine at all, is total absence and has its own flow. --- # How to Test Agent Selection https://agentmint.net/handbook/how-to-test-agent-selection/ ## Key takeaways - The metric is agent win rate: the share of repeated, independent agent shopping sessions in which your product is the one recommended or bought, a proportion, not a rank. - Method basis: this protocol adapts the ACES academic audit method, which is a controlled simulation of agent choice, not a record of real sales, so run the same idea against both a simulator and live engines and report the two separately. - One query proves nothing: an engine's answer to the same prompt shifts run to run, so score win rate over many repetitions and report a confidence interval, never a single number. - Control for the things that move selection for reasons unrelated to your product (mainly on-page position and option order) by randomizing and counterbalancing them. - Record the engine, the model version, and the date beside every number you produce. An agent win rate without those three is not reproducible, and it stops being true the next time a model ships. ## What to measure The single number this protocol produces is your **agent win rate**: the share of agent shopping sessions, for a defined query, in which your product is the one the agent recommends or buys. It is a proportion between 0 and 1, measured over many sessions: not a search-style rank, not impressions, and not click-through. The metric and its honest edge cases are defined in full on [agent win rate: definition and how to measure →](/glossary/agent-win-rate/); this page is the measurement machinery behind that definition. Win rate is the right unit because it maps directly onto the choice a shopping agent actually makes. When a shopper asks an agent for "a quiet desk fan under $60," the agent returns a small set of picks, often one. Over many such sessions, the fraction of times your product is in that set is a signal you can track, compare across engines, and try to move. That is the whole of what [agent selection](/glossary/#agent-selection) comes down to from a merchant's seat: not where you appear in a list a human scrolls, but how often the agent chooses you. ## Prompt set and query sampling A win rate is only meaningful relative to a fixed set of prompts. Pre-register yours before any run, so the questions cannot be quietly reshaped to flatter a result. - **Query frame.** Start from the real purchase intents your catalog competes for: the category, the constraints (price ceiling, size, use-case), and the phrasing a shopper types. Turn each frame into a small family of paraphrases, because agents respond to wording, and one phrasing is not the population. - **Prompt templates.** For every query, hold a fixed template and vary only the shopper's words, so differences in win rate trace to the query, not to scaffolding you introduced. - **Sample size by target precision, not by a round number.** Do not pick a prompt count for its looks. Choose the number of repetitions from the precision you need: enough independent sessions that the confidence interval around the win rate is narrower than the effect you care about detecting. Small effects need many more sessions than large ones, so state that target width in your sampling plan up front. > **Pre-register your counts before you run** > > Freeze the precise query list and per-query repetition counts before the first run, so the sample cannot grow or shrink until a result "looks right." Writing them down in advance is what stops a moving target from turning noise into a finding. ## Engines and sessions Run the same pre-registered prompt set against each shopping surface you cover (ChatGPT, Google's Gemini / AI Mode, and Perplexity) and treat each as its own measurement, never averaged into one "AI" number. The per-engine playbooks live at [ChatGPT shopping →](/chatgpt-shopping-optimization/), [Gemini shopping →](/gemini-shopping-ranking/), and [Perplexity shopping →](/perplexity-shopping-optimization/). Design each session to be independent and reproducible: - **Fresh, uncontaminated sessions.** Run every prompt in a clean session with no carried-over memory, personalization, or prior conversation, so one answer cannot prime the next. - **Recorded in full.** Capture the complete response, the products named, and the order they appear in (not just whether you "won"), so the raw record can be re-scored later without re-running. - **Stamped with engine, model version, and timestamp.** Because agent behavior is not stationary, tag every session with which surface, which model version (where exposed), and when. ACES reports that model updates can drastically reshuffle which products win, so any measurement is tied to a specific model version at a specific time. Any number without those three stops being reproducible the moment a model ships. One evidence gap worth flagging: the academic study this protocol adapts did not test Perplexity. A live test can include Perplexity anyway, because it is a real shopping surface, but the simulation-derived expectations below transfer to it only as hypotheses, not as findings. ## Controlling for position and order The hardest part of measuring selection is separating "the agent chose your product" from "the agent chose the slot your product happened to sit in." That confound is not hypothetical. ACES found that where a product sits on the page changes how often agents pick it (for one model, moving a product from the bottom-right corner to the top row raised its selection rate roughly fivefold), and that this position bias differs from model to model. The ACES numbers come from a controlled simulation rather than live stores, but the mechanism is exactly the nuisance you have to neutralize. So do not let position ride along as a hidden variable: - **Randomize placement.** Across sessions, randomize the order and, where the surface presents a grid, the grid position of the candidate set, so no product enjoys a permanent good seat. - **Counterbalance.** Give every product comparable time in strong and weak positions, so position averages out rather than loading onto one item. - **Change one thing at a time.** When you test whether a product-side change (a title, a description, a schema field) moves win rate, hold everything else in the candidate set fixed, so the change is the only plausible cause of a difference. Because a single prompt's answer varies run to run and is skewed by placement, only a win rate measured over many randomized, counterbalanced sessions is a stable enough signal to compare between products or across engines. ## Statistics and error bars Win rate is a proportion, so report it like one, with uncertainty attached, never as a bare percentage. - **Confidence intervals, not point estimates.** Report each win rate with a confidence interval appropriate for proportions (for example a Wilson or Agresti-Coull interval), so a reader sees the precision, not just the number. A win rate of "1 in 3" from 12 sessions and from 1,200 sessions are not the same claim, and the error bar is what says so. - **Differences with their own uncertainty.** When you compare two conditions (engine A versus engine B, or a rewritten description versus the original), report the *difference* in win rate and a confidence interval for that difference (bootstrapped over sessions), because a gap that fits inside the error bars is not a result. - **Pre-registration and multiple comparisons.** Fix the hypotheses and the primary comparison before data collection, and when you test many queries or engines at once, adjust for multiple comparisons, so you do not mistake noise across dozens of tests for a finding. - **Effect size over significance theater.** Lead with how big a shift is and how wide its interval, not with a p-value alone, because a "significant" but tiny move is not a lever a merchant should chase. ## Reproducing ACES versus testing live catalogs This protocol runs on two tracks with opposite trade-offs. Keep them separate and read each on its own terms. **Track 1: reproduce the simulation.** You can re-run the audit inside the same kind of controlled environment the academic method uses. The ACES framework audits agent decisions by showing vision-language-model shopping agents a mock storefront in randomized trials and analyzing their picks with regression, a controlled simulation of agent choice, not a record of real-world purchases. The ACES simulator is released under the MIT license, which permits reproducing and extending its code with attribution. The strength of this track is clean causal control: every variable is yours to set. Its limit is realism: a mock storefront is not your catalog on a live engine, and a simulated pick is not a sale. **Track 2: test live catalogs.** Run the pre-registered prompts against the real ChatGPT, Gemini, and Perplexity shopping surfaces, scoring win rate on live responses. The strength here is realism: these are the agents shoppers actually use. Its limits are noise and non-stationarity: live engines personalize, rate-limit, and change under you, so live win rates carry wider error bars and shorter shelf lives than simulation results. Neither track alone is the truth. Simulation says what *can* move a decision under control; live testing says what *is* moving on the surfaces that matter this month. Running both is more work than most teams will do at first, and a disciplined live test alone still beats an undisciplined one. ## Limitations Distrust the right things rather than trust the wrong ones. - **Simulation is not sales.** Track-1 results describe agent choices in a controlled sandbox, not revenue on your store. Never translate a simulated selection shift into a promised conversion or dollar figure. - **Live results expire.** Because model updates reshuffle outcomes, a live win rate is a snapshot of one engine at one time. Date every result you record, and treat an old one as a historical record, not current guidance. - **A sample is not the market.** A pre-registered query set and a set of test catalogs cannot represent every shopper intent or every store. Report the scope you tested and resist generalizing past it. - **You see outputs, not the ranking.** You measure what an agent chose, not the internal logic behind the choice. Explanations for *why* a product won belong in a hypothesis, never in a measured mechanism. - **Correlation guardrails.** Establishing that a specific product-side change *caused* a win-rate move needs a controlled A/B within this protocol, not a before-and-after on a shifting engine. Report uncontrolled comparisons as suggestive, not causal. Agent win rate is likely to differ by engine and to drift over time as models update, which is why per-engine, dated results beat a single blended "AI recommendation" score. --- # When AI Shows the Wrong Price or Stock for Your Products https://agentmint.net/ai-showing-wrong-price-or-stock/ ## Key takeaways - A wrong price or stock value in an AI answer is a data-drift problem, not a selection or visibility one: you are shown, but the agent read a number that no longer matches your live offer. Fix the drift; do not re-optimize your titles. - The stale value almost always comes from one of four places: a cached copy or Markdown mirror that never refreshed, surfaces (feed, structured data, page) that disagree, an inventory feed on too slow a batch, or an edge or geo branch that shows agents a different price. - Diagnose by diffing the same SKU across every surface an agent can read, then trace the stale one back to its source. This page finds the surface that drifted; the caching, schema, and feed pages it links to are where you fix it. - Never fix this by serving agents a different price or stock than shoppers see. That is cloaking and a parity violation, and it gets products disapproved. Make the surfaces agree instead. ## You are shown; the data is stale This diagnostic is for one specific failure: your product does appear in the AI answer, but the price, sale, or stock status the assistant quotes is wrong. That is a different fault from being absent (that is [why you're not in ChatGPT shopping](/store-not-in-chatgpt-shopping/)) and from being shown but passed over ([shown but not selected](/shown-but-not-selected/)). Here you are visible, and the number is simply out of date. A wrong price or stock value in an agent's answer is a synchronization problem: somewhere between your source of truth and the surface the agent actually read, a value went stale. So the fix is never to rewrite your titles or resubmit for eligibility; it is to find which surface drifted and why. The stakes are higher than a cosmetic lag: an agent that quotes a price you will not honor, or offers a buyer something that sold out, produces a failed or disputed checkout, which is exactly the outcome that teaches an agent to distrust your offers. Work the four causes below in order and stop at the first one that is true for you: 1. A cached copy or mirror of the page went stale. 2. Your surfaces disagree, and the agent trusted the wrong one. 3. Your inventory feed refreshes too slowly. 4. An edge, geo, or currency branch serves agents a different value. ## Cause 1: a cached copy or mirror went stale The quickest cause to rule out is that the agent never read your live page at all; it read a cached or mirrored copy that was generated once and never refreshed when your price or stock changed. If your JSON-LD is baked into a cached HTML snapshot, or you publish a Markdown mirror of the page, and that copy is regenerated on a long interval, then a price change on the live page will not reach the copy until the next rebuild, and any agent reading the copy quotes the old number. A `.md` mirror is a common culprit, because it feels static and tends to get a long cache lifetime, while price and availability are the two fields on the page that change most. To check it, fetch the exact representation an agent would read (the raw HTML, the JSON-LD block, and the `.md` mirror if you publish one) and compare the price and availability in each against your live offer. If the live page is correct but a cached copy or mirror is stale, that copy is your cause. The freshness rule that resolves this: low-churn machine surfaces can be cached hard, but price and availability must sit on a short cache lifetime or bypass the cache entirely, or a mirror will keep quoting an offer you no longer honor. The caching mechanics (which directives serve stale content, and how to hold a short freshness window on just the fields that move) belong in [serving agent traffic](/handbook/serving-agent-traffic/); this page only points you at the stale copy. ## Cause 2: your surfaces disagree with each other If every copy is current but the value is still wrong, the next cause is that your surfaces do not agree, and the agent trusted the wrong one. An agent can read your price and availability from several places at once (the visible page, the Product or Offer structured data, and your [product feed](/glossary/#product-feed)), and when those disagree, it has to arbitrate. We expect it to sometimes take the stale or worst-case reading, or to distrust all three, because it has no way to know which one you actually honor. This is not only an agent-trust question; it already breaks published rules. Google Merchant Center requires the price you submit to match the product's landing page and checkout, and a mismatch can get the product disapproved, so cross-surface agreement is an eligibility rule, not merely a trust nicety. Google's structured-data policies require your markup to reflect content that is visible to the reader, so a JSON-LD price that has drifted from the live offer violates them rather than being a harmless lag. To check it, diff the same SKU's price, availability, shipping, and return values across the visible page, the JSON-LD, and the feed row. Any field where the three disagree is a surface that needs to be driven from one source. The structured-data shape lives in [product schema for AI shopping](/product-schema-for-ai-shopping/) and the feed attributes in [make your product feed AI-readable](/make-product-feed-ai-readable/); the durable fix is to generate every surface from one source of truth so they cannot drift apart. ## Cause 3: your inventory feed refreshes too slowly A common special case of drift is stock: the item genuinely sold out, but your feed still lists it as available because the feed regenerates on a slow schedule. The Agentic Commerce Protocol feed is designed to be refreshed frequently rather than on a slow batch, so availability and price can stay current for the agents that read it. When a fast-moving product sells out but the feed waits hours for its next scheduled run, an agent reading the feed keeps offering a buyer something the warehouse can no longer ship, and that oversell is what turns a stock lag into a failed checkout. To check it, pick a fast-selling product, compare its current feed availability against real warehouse stock, and find out whether a stock change triggers a refresh or waits for the next batch. If the gap is wide enough to oversell, the cadence is your cause. Tightening it is feed work, covered in [make your product feed AI-readable](/make-product-feed-ai-readable/). ## Cause 4: an edge, geo, or currency branch serves agents a different value The last cause is the most dangerous, because its accidental and its deliberate forms look identical from the outside. A CDN rule, a country or currency branch, or a dedicated bot code path can hand an agent a different price than a shopper sees, for example a default-currency or pre-tax figure served to a request that arrives without a geo cookie. The agent then quotes a number no human meets at checkout, and your own logs show nothing obviously wrong. Accidental edge variance is a legitimate cause to check for. Making it deliberate is not a fix. Google defines cloaking as presenting different content to users and search engines to manipulate rankings and mislead people, and its policy names user-agent-based swapping directly, giving as an example "inserting text or keywords into a page only when the user agent that is requesting the page is a search engine, not a human visitor." > **Do not fix drift by cloaking** > > Never resolve a price or stock mismatch by serving agents one value and shoppers another. Showing crawlers a favorable price while humans see a different one at checkout is cloaking and a parity violation: it gets products disapproved and it destroys the agent trust you are trying to earn. The honest fix is always to make every surface show the same offer, never to special-case the agent. To check for accidental variance, request the product page the way an agent would, stripped of your usual geo and currency cookies, and confirm the price and availability match what a shopper reaches at checkout. If a geo, currency, or bot branch changes the value, that branch is your cause, and the fix is to make it serve one offer to everyone. This is the parity boundary the [content equivalence signal](/signals/content-equivalence-no-cloaking/) draws. ## The one diff that isolates the drift Rather than guess which cause is yours, run a single comparison and let it point you. Take one SKU whose price or stock you know an agent got wrong, and line the value up across every surface an agent can read: - the visible product page (the rendered HTML), - the Product or Offer structured data inside that page, - your product feed row, - and any Markdown mirror or cached copy you publish. Where they all agree and match your live offer, the surface is fine. The one that disagrees is your drift, and which one it is tells you the cause: a stale mirror or cache points to Cause 1, disagreement among otherwise-current surfaces to Cause 2, a feed that lags reality to Cause 3, and a value that only changes when you drop your geo or bot headers to Cause 4. Fixing the surface without tracing it back to its source only resets the clock, so follow the stale value to the system that generates it before you call it fixed. ## What to measure Freshness is not a one-time fix; a batch job slips, or a cache rule regresses. Turn the diff above into a standing check rather than a one-off: - On a schedule, pull the price and availability for a sample of fast-moving SKUs from each surface (page, JSON-LD, feed, mirror) and flag any that disagree with the source of truth. A surface that drifts repeatedly is a cache lifetime or a sync job to fix at the root. - Track how often the value an agent quotes matches your live checkout. When you test selection, record whether the price and stock the agent stated were correct, alongside whether you were picked, so a data fault cannot hide inside a selection metric. - Fold this into your [agent win rate](/glossary/agent-win-rate/) measurement rather than running it separately, and re-check after any change to your caching, feed cadence, or CDN rules. [How we test agent selection](/handbook/how-to-test-agent-selection/) gives you the repeatable protocol. ## This page finds the drift; the linked pages fix it Keep the jobs separate. This is the flow you run after you notice an assistant quoting the wrong price or stock, to isolate which surface drifted. The fixes live where the depth is: cache and freshness in [serving agent traffic](/handbook/serving-agent-traffic/), markup in [product schema for AI shopping](/product-schema-for-ai-shopping/), and feed cadence in [make your product feed AI-readable](/make-product-feed-ai-readable/). Its sibling diagnostics narrow a different symptom: [shown but not selected](/shown-but-not-selected/) when your data is right but a competitor wins, [lowest price but not recommended](/lowest-price-but-not-recommended/) when you are the cheapest and still lose, and [the AI engine visibility gap](/ai-engine-visibility-gap/) when you appear on some engines but not others. ## Frequently asked questions ### Why does an AI still show my old sale price after the sale ended? Because the value the agent read was cached, or came from a surface (a feed row, a JSON-LD block, or a Markdown mirror) that was not refreshed when the sale ended. Find the surface that still carries the old price, trace it to its source, and keep price and availability on a short cache lifetime so a stale copy cannot outlive the change. ### Is it ever acceptable to show agents a different price than shoppers? No. Serving crawlers one price and humans another to influence rankings is cloaking under Google's spam policy, and a price that does not match your landing page and checkout gets products disapproved in Merchant Center. Make every surface show the same offer instead of special-casing the agent. ### How fast do I need to update stock for AI shopping agents? There is no universal number, but availability should track reality closely. The Agentic Commerce Protocol feed is built to refresh frequently rather than on a slow batch, and a daily-batch feed is a common reason a sold-out item still shows as in stock. Tighten the cadence for fast-moving products so the feed does not oversell. --- # Category and Collection Page Legibility for AI Agents https://agentmint.net/category-page-legibility/ ## Key takeaways - Agents often reach your products by reading category and collection pages first, so an unreadable listing page can keep otherwise-eligible products out of the comparison. - Serve the product grid, its links, and the category description in raw server HTML: a JavaScript-assembled listing can reach a non-executing crawler as a near-empty shell. - Keep faceted navigation legible: give real collections stable URLs, and keep arbitrary filter permutations out of the crawlable set so they don't become a crawl trap. - A category page is only as useful as it is truthful. It should summarize what the category actually contains, and every product in the grid should belong there. ## Why category pages are an upstream selection lever Most advice about winning agent selection points at the product page, because that is where the offer lives. But a product page is not usually the first thing an agent reads about your catalog. When someone asks an agent for "waterproof hiking boots under $150," the agent has to assemble a shortlist for the whole category before it ever compares two specific boots, and one of the cheapest ways to assemble that shortlist is to read your collection and listing pages. We expect category and collection pages to be an upstream selection lever most merchants overlook: an agent building a shortlist for a category query often reaches individual products by crawling and reading listing pages first, so a collection page it cannot parse can keep otherwise-eligible products out of the comparison entirely. This is reasoning from how agents crawl and how the [hub explains agents choose](/how-ai-agents-choose-products/), not a measured effect. But the direction is clear enough to act on: category legibility is the layer that decides whether your products are even in the room when the choosing happens. This page is about the collection and listing pages themselves. The anatomy of an individual product page is [product detail page anatomy](/product-detail-page-anatomy/); the markup that makes each product parseable is [product schema for AI shopping](/product-schema-for-ai-shopping/); the structured export you hand agents directly is the [product feed](/make-product-feed-ai-readable/). Here the subject is the pages in between. ## Serve collection pages in raw server HTML The first question about any category page is whether an agent can read it at all. Category pages tend to be the most JavaScript-heavy templates a store runs: infinite scroll, client-side filters, lazy-loaded grids, personalized sorting. Every one of those can move the actual product list out of the initial HTML response. A collection page whose product grid, category description, and pagination are assembled by client-side JavaScript can render fine to a shopper and still reach a non-executing crawler as a near-empty shell, so the safest default is to serve the grid, its product links, and any intro copy in the raw server HTML. You can check this in seconds: load a top category URL with JavaScript disabled, or view source, and confirm the products and their links are already there. If the grid is empty without JavaScript, an [AI crawler](/glossary/#ai-crawler) that does not execute scripts sees an empty category. The mechanics of which crawlers reach you, and how to keep them unblocked, are covered in [AI crawlers, robots.txt, and llms.txt](/ai-crawlers-robots-llms-txt/). The industry averages show the headroom. Retail category pages score an average of 74 out of 100 on Adobe's machine-readability index, ahead of product pages at 66 and just behind homepages at 75. Category pages read better than product pages on average, but a score of 74 still means roughly a quarter of a typical listing page is not cleanly machine-readable, and the grid itself is the part most often lost. One thing you cannot do is route around an illegible category page with a side file. Google's own guidance states that machine-readable text files are not needed to appear in Google Search and that Google Search ignores llms.txt. The page has to carry its own structure. The question of what format to serve, and where content negotiation ends and cloaking begins, belongs to [information density for agents](/handbook/information-density/). ## Structure and name categories the way shoppers ask Once a category page is readable, its structure is what an agent uses to place it. A flat store where every product hangs off one giant "Shop all" page gives an agent nothing to match a category query against; a clear tree of categories and subcategories gives it a labeled map. Naming is the same discipline that shapes product titles, applied one level up. We expect a collection to compete better for a category query when its page name and heading use the plain words a shopper would type ("waterproof hiking boots") rather than an internal merchandising label ("The Trailhead Edit"), for the same near-literal query-matching reason that shapes product titles. The evidence behind that matching behavior lives on [product titles that AI agents match](/product-titles-for-ai-agents/); the point here is that a category's own name and URL are query surfaces too, not just decoration for a campaign. > Illustrative example, not measured data. A collection built for a seasonal campaign versus one an agent can place: - **Before:** URL `/collections/the-trailhead-edit`, heading "The Trailhead Edit" - **After:** URL `/collections/waterproof-hiking-boots`, heading "Waterproof Hiking Boots for Men and Women" The second version keeps the merchandising story in the intro copy if you want it, but the name, heading, and URL now say what the collection actually is, in the words a query would use. ## Faceted navigation an agent can follow, not a crawl trap Filters are where category legibility most often breaks. A faceted navigation that generates a fresh crawlable URL for every filter and sort combination can produce thousands of near-identical pages from one real category. We expect unbounded, crawlable filter permutations (every color, size, and price combination as its own indexable URL) to work against you: they multiply near-duplicate pages that blur which URL represents a real, nameable collection, and they spend a crawler's finite budget on permutations before it has mapped your actual catalog. The fix is not to hide filters from users. It is to decide which filtered views are real collections a shopper would ask for, give those a stable canonical URL, and keep the arbitrary permutations out of the crawlable, indexable set (canonicalizing them to the parent, or excluding them from crawling). The directive mechanics for doing that sit in [AI crawlers, robots.txt, and llms.txt](/ai-crawlers-robots-llms-txt/). Resist the temptation to solve this by showing crawlers a clean, filter-free version of a page while users get the interactive one. Serving materially different content based on who is asking is cloaking, not optimization, and the boundary between legitimate format negotiation and cloaking is drawn in [information density for agents](/handbook/information-density/). ## Internal links that let an agent map your catalog Category pages are also the wiring an agent uses to walk your catalog. A plain, crawlable path from category to subcategory to product is what lets it discover every item and understand how they relate. We expect a product reachable only through on-site search or a JavaScript-driven "load more" button to be effectively invisible to an agent mapping your catalog through category pages, whereas a plain, crawlable link path from category to subcategory to product lets it find and place every item. That has two practical consequences. Paginate collections with real, crawlable links rather than a scroll event, so products beyond the first screen are still reachable. And hunt for orphaned products: SKUs that no category links to, reachable only via search. The [product feed](/make-product-feed-ai-readable/) is a parallel discovery path that can carry products your navigation misses, but it does not excuse a catalog an agent cannot walk on the site itself. Giving each product one clean, stable, canonical URL keeps that map coherent as filters and campaigns come and go. ## Does your category page truthfully summarize its contents? The last lever is representativeness. An agent reading a listing page treats it as a summary of what your store carries in that category, and a summary that overreaches reads as a weaker signal. We expect a category page that misrepresents its contents (an intro claiming the widest range of something over a thin or off-topic grid, or products filed under a category they do not belong to) to read as a less trustworthy summary to an agent using the listing page to judge what your store actually stocks. Keep the category description matched to the grid beneath it: if the copy promises a range, the range should be there. Keep products in categories they genuinely belong to, so a "running shoes" collection is not padded with lifestyle sneakers. The accuracy of each individual product's own claims is a product-page concern, handled through [product schema for AI shopping](/product-schema-for-ai-shopping/) and [product detail page anatomy](/product-detail-page-anatomy/); at the category level, the job is making the page an honest index of what sits under it. ## What to measure Category legibility is checkable, so check it rather than assume it. On your top category pages, run these: 1. **Raw-HTML render.** Load each top category URL with JavaScript disabled (view source, not devtools) and confirm the product grid, its product links, and the intro copy are all present in the initial response. An empty grid without JavaScript is the finding, not a nuisance. 2. **Orphaned products.** Count SKUs that no category or subcategory page links to, reachable only through search. Those are products an agent walking your catalog may never reach. 3. **Facet URL explosion.** Crawl one busy category and count how many distinct filter and sort permutations are reachable and indexable. Decide which represent real collections worth a canonical URL and which should be kept out of the crawlable set. 4. **Representativeness.** For each top category, confirm every product in the grid genuinely belongs there and the intro copy matches the actual selection, with no promise the grid does not keep. Track these as baselines you can move and re-measure, the way you would track any ranking signal. How we structure agent-selection measurements, and the metrics we hold ourselves to, is documented in [how to test agent selection](/handbook/how-to-test-agent-selection/). This site publishes no measured figures of its own; the protocol is there so you can produce yours. --- # Sponsored placement and agent selection https://agentmint.net/sponsored-placement-and-agent-selection/ ## Key takeaways - Research finds AI agents discount listings labelled sponsored, and the size of that discount depends on whose interest the agent is told it serves, not on a fixed rule. - OpenAI began testing ads on ChatGPT in September 2026, but as a limited alpha with selected US advertisers that no merchant can self-serve today. - OpenAI states its ads are separate from product results, and that product results are selected independently and not influenced by any partnerships. - Because the ads sit outside product results, the research does not predict how they affect organic selection; the durable lesson is that a disclosure label becomes a model input, weighted by who the agent thinks it works for. ## What the research found When an AI agent shops on someone's behalf, a sponsored label stops doing the job it was designed to do. Two findings from 2026 sit side by side, and together they say something neither says alone: agents discount paid placement, but the discount is not a fixed property of the agent. The paper's framing is that agents "face a conflict of duty," because "sponsorship disclosures, designed to allow consumers to penalize paid placements, now reach the AI agent rather than the consumer, and the agent's evaluation of them is hidden from the consumer." The label still exists, but the reader it was written for is no longer the one who sees it. The central result is about who the agent thinks it serves. Assigning an agent a platform role rather than a consumer role "significantly attenuates the penalty that agents apply to sponsored listings and weakens the skepticism that disclosure triggers in their reasoning traces." A second experiment sharpened the same point. The authors report that "the divergence between the two delegates widens significantly when the paid placement is attributed to the platform," and that stricter terminology ("Sponsored" instead of "Promoted") "lowers choice of paid listings but does not close this gap when the platform is named." The authors report the pattern across several models and reasoning depths, and conclude that "disclosure mandates designed for human consumers cannot by themselves protect consumers in AI-mediated commerce." The paper reports specific magnitudes for these effects in its body tables; those figures are not stated in the abstract, so this page cites only the direction and stops there. ## The ACES baseline this builds on The penalty itself is not new here. This site already documents it in the selection hub, [how AI shopping agents choose products](/how-ai-agents-choose-products/), from the earlier ACES framework. In ACES, tagging a product "Sponsored" lowered its selection probability below baseline consistently across the models tested, in a controlled simulation of agents choosing from a mock storefront rather than a record of real sales. Read on its own, that looks like a stable trait: agents dislike a paid tag. The role-assignment work changes how you should read that. The penalty is real, but it is conditional on whose interest the agent is told to weigh, so a number measured on a consumer-delegated agent does not transfer to an agent operating inside a platform's own surface. That is the contribution worth carrying forward: the sponsored penalty is a variable, not a constant. ## What OpenAI actually shipped While the research landed, the surface it describes started selling placement. OpenAI is testing Sponsored Agents, which "let people start a conversation with a business-sponsored agent after clicking an ad in ChatGPT," and states that this conversation "is distinct from ChatGPT's independent answers and separate from the original conversation that the user started in ChatGPT." HubSpot is named as its first CRM partner and Shopify as its first ecommerce partner; US-based Shopify merchants can use a ChatGPT Ads app, with international availability starting September 23, 2026. The scale matters as much as the mechanics. OpenAI describes Sponsored Agents as "currently available only to selected advertisers in a limited alpha test" and states, "We're not accepting early access requests at this time." This is a limited alpha, not something a merchant can buy into today. OpenAI also draws an explicit line between ads and the organic results this site is mostly about. OpenAI states that "product results are selected independently by ChatGPT and are not ads, nor influenced by any OpenAI partnerships. Ads are separate from product results." Separately, the ads path has its own merchant control in the product feed. The feed carries an `is_ads_eligible` boolean that opts a product into ads processing, kept distinct from the flags that govern search and checkout eligibility. ## What this predicts, and what it does not The two threads are tempting to fuse, and worth keeping apart. The research studies agents evaluating a listing labelled sponsored inside a result set they are ranking. OpenAI states its ads sit outside product results entirely. Those are different architectures, so the sponsorship-bias findings do not predict what ChatGPT's ads will do to organic selection. A merchant reading the paper should not expect it to forecast the behavior of a surface built on a different separation. What the research does establish is more general, and more durable than any one product. When an agent mediates a purchase, a disclosure label stops being a signal aimed at a human and becomes an input to a model, and how heavily that input counts depends on who the model has been told it works for. That is the thing worth understanding before any agent surface starts selling placement, whatever architecture it chooses. ## What a merchant should do now The concrete advice is short, because the market is early. Buying placement on an agent surface is a limited alpha nobody can self-serve, so there is no campaign to build and no urgency to manufacture. The one live lever is knowing the ads path exists in your feed: the `is_ads_eligible` flag is worth understanding so you can set it deliberately rather than inherit a default, but it governs a channel most merchants cannot yet enter. The durable work is unchanged and sits on the organic side. The product data an agent reads when it ranks results independently is still the investment that compounds: a complete, current feed, covered in [make your product feed AI-readable](/make-product-feed-ai-readable/), and titles a shopper actually searches, in [write product titles AI agents match](/product-titles-for-ai-agents/). Winning [agent selection](/glossary/#agent-selection) on the unpaid path is the same problem it was before ads arrived, and per-engine tactics live in the [ChatGPT shopping optimization](/chatgpt-shopping-optimization/) playbook. ## The line this site won't cross One reading of the research is dangerous, so say the opposite outright. The finding that stricter labels reduce the choice of paid listings is not an argument for weaker labels. This site does not advise disguising paid placement, styling ads to read as organic, or removing a sponsored tag to escape a penalty an agent might apply. The healthy version of this work is earning genuine selection on the merits, not hiding how a placement was bought. --- # An Agent Selection Audit, Worked Through a Fictional Store https://agentmint.net/handbook/agent-selection-audit-example/ > **Illustrative example, not measured data** > > Everything below is a walkthrough on an invented store, Thistledown Sleep Co. The store, its products, its prices, and its data are made up to show the process. There are no win rates, no scores, and no measured outcomes on this page, because none have been measured. Any sample title or price is an illustrative field value, not a result. A real agent-selection audit is a walk through the checklist one category at a time: on each, you inspect what an agent can actually read, mark what passes and what is a gap, then fix the highest-leverage gap before touching anything else. This page shows that walk end to end so you can copy the motion, not a result. ## Key takeaways - An audit is a process, not a score: inspect what an agent can read, find the gap, fix the highest-leverage one first, then measure whether it moved anything. - The Agent Selection Checklist has six categories. Working them in order stops you from polishing reviews while a brand-only title quietly loses every match upstream. - Most gaps are the obvious fields left empty or stale, not exotic ones: a total cost you can only see at checkout, a return window that disagrees with the markup, a title only existing customers would recognize. - This page diagnoses on a fictional store. Run the same checklist on your own store with the live tool, and hold any fix to a measured agent win rate. ## Meet the store: Thistledown Sleep Co. > Illustrative example, not measured data. Thistledown Sleep Co. is an invented direct-to-consumer store selling three lines: a weighted blanket, an organic cotton sleep mask, and a buckwheat pillow. Its snapshot for this walkthrough: - The blanket ships in weight and size variants labeled "The Nimbus" and "The Nimbus Plus." - Prices show as plain text, but shipping is "calculated at checkout" and the returns page says "hassle-free returns, conditions apply." - Product pages carry a star average with no visible count, and descriptions lean on words like "cloud-soft" and "premium." - No one has ever checked what an AI shopping agent reads on the page, or whether an agent ever recommends the store. That snapshot is deliberately ordinary. It validates, it converts human shoppers, and it would pass a basic eligibility review. The audit is about the layer eligibility never checks: whether the store wins the [agent selection](/glossary/#agent-selection) once several eligible options sit side by side. ## How to read this walkthrough Each category below follows the same three-step motion: inspect what an agent can read, separate the passes from the gaps, and name the single highest-leverage fix. The point is the motion. A store that runs this loop honestly beats one that chases a checklist total, because the total hides which gap is actually costing you the pick. This is a diagnosis, not a re-teaching of every item. Where a fix needs its own chapter, this page hands you to it. To run the same six categories interactively on your own store, with weighted scoring and deep links to each item, use the [Agent Selection Checklist tool](/tools/agent-selection-checklist/). The reasoning behind why these signals move the choice at all lives in [how AI agents choose products](/how-ai-agents-choose-products/). ## 1. Offer legibility Inspect what an agent can compute before checkout. On a cold product page for The Nimbus, you can read the price as text, so the current-price and parseable-price items pass. But shipping is "calculated at checkout," so the store fails the item that matters most here: total landed cost readable before the agent commits. We expect an agent comparing offers to prefer the one whose all-in cost it can compute up front, and to guess high or drop a merchant whose shipping and fees surface only at the final step. The variant names are the second gap. "The Nimbus" and "The Nimbus Plus" tell a machine nothing it can map to a shopper's "queen, 15 lb, navy." Unit pricing does not apply to this catalog, so that item is not a gap, just out of scope. The highest-leverage fix is a text line near the price that states total cost to a destination and matches what checkout later charges. After that, rename the variants to lead with their real attributes. The how is in [make your product feed AI-readable](/make-product-feed-ai-readable/), and the checklist item to work is [total landed cost legibility](/tools/agent-selection-checklist/#b-offer-legibility-01). ## 2. Delivery and returns signals Inspect whether your data answers "when will it arrive?" and "can I return it?" without a human filling gaps. Thistledown states a vague "ships soon" and carries no order cutoff, so an agent cannot derive an estimated delivery date or tell a shopper "order in the next three hours to get it Thursday." Structured shipping data expresses handling and transit as ranges an agent assembles into an arrival estimate; when those fields are vague or absent, we expect the agent to defer to a competitor whose page does answer the date question. The returns page is worse than empty: its "conditions apply" hedge names no condition, and the prose window does not match the number in the markup. That inconsistency is its own demotion risk, because the agent has to arbitrate between two sources that disagree. The highest-leverage fix is to state concrete handling and transit ranges plus an order cutoff in text, then make the return window, cost, and method agree across prose and structured data. The relevant checklist items are the [order cutoff item](/tools/agent-selection-checklist/#b-delivery-returns-09) and the returns-consistency items beside it. ## 3. Product content for comparison Inspect completeness against your category, not against the platform minimum. Thistledown filled the required fields and stopped, while the listings it competes against also expose weight, dimensions, fill material, and fabric weight. We expect an agent comparing within a category to favor the item it can actually compare on, so every attribute your peers fill and you leave blank is a comparison you sit out. That is a judgment against peers, which is exactly why no validator flags it. The descriptions are the second gap. "Cloud-soft" and "premium" answer no concrete buyer question, and they carry no checkable specific an agent can quote. A targeted rewrite can help, but treat it as an experiment, not a guarantee. In the ACES simulation, rewriting a product description shifted recommendation share only in a minority of category-model pairs and did little in most, so gains were concentrated rather than universal. ACES is a controlled simulation over a fixed model set, not live sales. The highest-leverage fix is to fill the attributes category leaders expose and rewrite descriptions to answer the real fit and use-case questions in plain sentences. Work the [category-norms completeness item](/tools/agent-selection-checklist/#b-product-content-01); the title mechanics are in [product titles that AI agents match](/product-titles-for-ai-agents/). ## 4. Trust and policy signals Inspect whether your credibility reads as depth a machine can weigh. Thistledown shows a bare star average with no count and three testimonials that have not changed in a year. Having a rating is eligibility; the depth behind it is the lever. We expect complete, recent, well-distributed review data to read as more credible depth than a lone average, giving a rating-sensitive agent more to weigh in your favor. A truthful count and recent, dated reviews are the fix, never an inflated figure, which is both a rule violation and a weak signal. The subtler gap is a leftover "Sponsored" ribbon on some pages from an old promotion, still present in the markup even where shoppers never see it. That framing can actively cost the pick. ACES reports that across its simulated trials, agents consistently penalized a self-applied "Sponsored" tag and rewarded genuine platform endorsements, with endorsement among the strongest content signals it tested. This is a simulation, not measured live behavior. The highest-leverage fix is two-sided: remove the self-applied sponsored styling from organic listings, and pursue real editor's-pick or verified-seller programs you legitimately qualify for, rather than a lookalike badge. Start with the [review-depth item](/tools/agent-selection-checklist/#b-trust-policy-01); the endorsement reasoning is in [how AI agents choose products](/how-ai-agents-choose-products/). ## 5. Price position awareness Inspect whether you know where your total cost sits, not just your list price. Thistledown sets prices from instinct and has never tracked a competitor's all-in cost for the queries it wants to win. ACES reports price as a real but model-varying lever, so the same markdown can move one engine meaningfully and barely move another. Because it is a simulation over a fixed model set, read the direction, not a fixed magnitude. Without watching competitors' landed prices for your target queries, we expect you cannot judge your position or tell whether a discount is worth its margin. There is no cloaking shortcut here, and reaching for one fails the audit outright: showing an agent a different price than a shopper sees breaks price-parity rules and is a trust violation, not a growth tactic. The highest-leverage fix is a simple habit, a monthly sheet ranking your landed cost against a few named competitor offers per top query, tested per engine rather than blended. Work the [price-position item](/tools/agent-selection-checklist/#b-price-position-01). ## 6. Measurement Inspect whether you would even know if a fix worked. Thistledown has never run a shopping prompt against an agent, so every improvement above would ship on faith. That is the gap that makes the whole audit hollow: without measurement, "the fix helped" is a vibe. ACES documents that model updates can drastically reshuffle which products agents choose, and that grid position is a large, provider-specific lever, so a win measured one quarter can quietly evaporate after a release. Both findings come from a simulation, not live sales. The highest-leverage fix is to define and run the win-rate protocol: a fixed set of realistic prompts, run against each engine on the same day, logging a plain win-or-no-win per engine, with position recorded when results render as a grid. Then re-test after every major model update. Track your [agent win rate](/glossary/agent-win-rate/) as the honest measure of whether any change above earned the pick, using the [win-rate methodology](/handbook/how-to-test-agent-selection/), and start from the [win-rate protocol item](/tools/agent-selection-checklist/#b-measurement-01). ## The audit at a glance The same six-step motion, summarized. Read it as a map of the walkthrough above, not as a verdict on any store. _Illustrative audit summary for Thistledown Sleep Co. Process, not a score. Every row is a made-up example, not a measured finding._ | Category | What you inspect | What the gap looked like | Highest-leverage fix | | --- | --- | --- | --- | | Offer legibility | Can an agent read total cost before checkout? | Shipping only at checkout; variants named 'The Nimbus' | State total landed cost near the price; rename variants to real attributes | | Delivery and returns | Can it derive an ETA and a return answer? | 'Ships soon', no cutoff; return prose and markup disagree | Concrete handling, transit, and cutoff in text; reconcile return terms | | Product content | Complete vs category peers, not the minimum? | Missing weight and material; adjectives, no specifics | Fill peer-exposed attributes; answer real buyer questions in prose | | Trust and policy | Does credibility read as weighable depth? | Bare average, no count; leftover 'Sponsored' markup | Truthful count and recency; remove sponsored styling, earn endorsement | | Price position | Do you know your landed-cost rank? | Prices set from instinct; no competitor tracking | Monthly landed-cost sheet per top query, tested per engine | | Measurement | Would you know if a fix worked? | Never measured; no win-rate baseline | Run the win-rate protocol per engine; re-test on model updates | ## Run it on your own store The walkthrough is the transferable part. Take the same six categories to your own catalog: inspect what an agent reads on a cold page, mark the passes and the gaps honestly, and fix the highest-leverage gap in each before moving on. Do it in order, because a store that polishes reviews while a brand-only title loses every match upstream is optimizing the wrong end. The [Agent Selection Checklist tool](/tools/agent-selection-checklist/) runs all six categories interactively, with each item's evidence type and deep links to its chapter. When you appear in answers but still lose the pick, the four-cause diagnosis in [shown but not selected](/shown-but-not-selected/) narrows it fast. Whatever you change, hold it to a measured [agent win rate](/glossary/agent-win-rate/) rather than a checklist total, because the total tells you what you touched, and only the win rate tells you whether an agent changed its mind. --- # About the Author https://agentmint.net/about/ AgentMint.net grows directly out of my day-to-day work building and integrating the systems that run online stores. I'm a Palestinian Senior E-commerce Engineer with over 14 years of hands-on experience, most of it in WordPress and WooCommerce: custom plugins, shipping and payment integrations, and the Store and REST API that stores use to move product data. There is a fuller account on my [author page](/author/abdalsalaam-halawa/); I publish this site independently at [halawa.io](https://halawa.io), where all my links and contact details live. Building the systems that power a store means working inside the machinery that actually emits product data (feeds, structured markup, prices, availability) for real online stores. Shipping-integration work means living in GTINs, fulfillment options, delivery windows, and return policies: exactly the structured attributes that agentic-commerce protocols have started to read. Agent selection sits at the intersection of the two. ## Why agent selection Shoppers are starting to ask an AI agent (ChatGPT, Google's AI Mode and Gemini, Perplexity, Copilot, Claude) to find and compare products, and the agent returns a short list or a single pick. That pick is the new storefront. [Agent selection](/glossary/#agent-selection) is the question of why an agent chooses one store, product, or offer over another, and what a merchant or developer can do to be the one it chooses. AgentMint.net is deliberately narrow. Official protocol documentation (from the teams behind UCP, ACP, and the agentic payment rails) tells you how to become *eligible*: the fields to emit, the endpoints to expose, the specs to conform to. That work is essential, and we link to it rather than rewrite it. AgentMint.net covers the layer above eligibility: given that you are eligible, how do you actually get *selected*? It is the practitioner handbook for [agentic commerce optimization](/agentic-commerce-optimization/), closer to what webmaster-guidelines-era SEO writing was to Google's own documentation than to the specs themselves. ## How we source claims Model behavior and agentic-commerce specifications move fast, and the space is full of confident guesses. The thing that makes AgentMint.net worth trusting is that every factual claim on the site is labeled with where it came from. We use four evidence types, and you will see them attached to claims throughout: - **spec-fact**: stated in an official specification or first-party documentation. We link the primary source so you can verify it yourself. - **reported**: a finding from a named third party (an academic study, a vendor, or a news report). We name the source and give the date, because model behavior has a shelf life. - **hypothesis**: our own inference or framing. We phrase it as an inference and never dress it up as data. - **measured**: a result from controlled testing run here. There are no measured claims on this site, and there is no pending-results page waiting to hold one. AgentMint.net stopped running its own experiments rather than keep promising numbers it was not producing, and what it publishes instead is a protocol you can run on your own catalog. Two rules follow from this and are worth stating plainly: we never invent a number, a benchmark, a quote, or a testimonial; and any example that is illustrative rather than measured is labeled as such. When we cannot verify something, we say so rather than guess. One fabricated figure would undermine the entire premise of the site, so we treat that line as absolute. The measurement protocol is at [how to test agent selection](/handbook/how-to-test-agent-selection/), and what the site still does not know is listed in the [open questions register](/reference/open-questions/). ## How this site earns AgentMint.net is a static publication with no CMS, accounts, or backend, and no paid product, so there is nothing on it to buy. The one disclosed way it earns is the Hostinger hosting link in the footer, an affiliate link labeled as such. My professional work and contact details live off-site at [halawa.io](https://halawa.io), kept separate from what you read here. ## Contact and newsletter The best way to reach me is through [halawa.io](https://halawa.io). If you want new research and platform updates as they publish, [subscribe to the newsletter](/#newsletter), or use the Newsletter link in the header of any page. No spam, and you can unsubscribe at any time. --- # Agentic Commerce Optimization: The Complete Guide https://agentmint.net/agentic-commerce-optimization/ ## Key takeaways - Being eligible is not the same as being chosen: emitting the right feed and schema gets you into the running, but a separate set of signals decides which store an agent actually picks. - We argue the selection layer is an open space: the checkout and payment protocols say nothing about which product wins, and the readiness checkers measure preparedness instead (evidenced below). - Five levers move agent selection: product feed completeness, product schema, product titles, crawler access, and endorsement signals. - Agent behaviour is model-dependent and shifts when models update, so every claim here is evidence-typed and dated. - Official documentation teaches eligibility; this handbook teaches winning. We link out for spec syntax rather than rewrite it. ## What agentic commerce optimization is (and why it isn't SEO) Agentic commerce optimization (ACO) is the practice of getting a store, product, or offer chosen by an AI shopping agent (ChatGPT, Google's AI Mode and Gemini, Perplexity, Copilot, Claude) when a shopper asks it to find or compare products. It is the same job SEO did for the era of ranked blue links, moved to a world where a single agent reads your structured data and returns one pick or a short list. That shift changes the target. SEO optimizes a page for a human who scans a results list; ACO optimizes a catalog for a machine that parses your feed, your schema, and your product pages and then decides on the shopper's behalf. The unit of victory is no longer a click on rank three: it is being the one product the agent names. Learning why an agent makes that choice, and how to influence it, is what we mean by [agent selection](/glossary/#agent-selection). The reason a handbook like this can exist is that the choosing layer has no owner. No incumbent owns the selection layer of agentic commerce: no official protocol specifies how an agent should rank one product against another, every readiness checker states that it measures preparedness rather than selection, and the only rigorous selection research is academic and written for researchers, not merchants. Even the tools built to score your setup make that limit visible once you look at what they actually check. UCP Checker grades a store's Universal Commerce Protocol readiness across three weighted categories, discovery, conformance, and capability, combining what a store declares in its manifest with what an agent actually finds when it visits: a technical-readiness score, not a prediction of whether an agent would choose that store over a competitor. A second checker that once covered similar ground, UCP.tools, is no longer a working tool: as of this writing the domain is parked and listed for sale, so we do not cite it as a current example. That gap between preparedness and selection is exactly the ground this guide stands on: the practitioner layer of [answer engine optimization for ecommerce](/glossary/#aco-aeo). ## Why now: AI-referred retail traffic is surging The reason to work on this in 2026 rather than later is that agents are already sending buyers. Retail traffic from AI-driven sources rose 393% year over year in the first quarter of 2026, and in March 2026 that AI-referred traffic converted 42 percent better: a record, and a reversal from a year earlier. The demand is arriving faster than most catalogs are ready for it. On Adobe's AI Content Visibility Checker, retail product pages score an average of 66 out of 100 for machine readability, meaning roughly a third of a typical product page is not machine-readable to an agent at all. A rising channel hitting under-prepared catalogs is the window where optimization work pays back. > **Sourcing note** > > These figures are cited to Adobe Digital Insights' own first-party post (Vivek Pandya, Director, Adobe Digital Insights, published 2026-04-16), which TechCrunch and e-commerce.news covered at the time attributing the same Adobe data. ## The eligibility-to-winning seam There is a cliff in the middle of agentic commerce, and most merchants don't see it. You can pass every validator, expose every endpoint, and conform to every spec, and still never be the product an agent recommends. Passing validation makes you *eligible*. Being recommended makes you *selected*. The two are governed by different things, and nobody official lives on the selected side, because the protocols deliberately stop at eligibility. They say so themselves: - OpenAI and Stripe's Agentic Commerce Protocol states that implementing it does not guarantee your products will automatically be listed; each AI platform "will manage their own process" for how businesses can participate. - Google's AP2 specification places the Commerce Protocol's catalog and discovery details "outside the scope of AP2," defining only the payment-authorization layer that runs after an agent has decided what to buy. - Google describes its Universal Commerce Protocol as "open, agnostic, built together with industry leaders Shopify, Etsy, Wayfair, Target and Walmart," and states that under UCP "the retailer remains the merchant of record," owning and shaping the customer relationship rather than ceding it to the protocol. Read together, those disclaimers draw the boundary this handbook occupies. Official documentation is the authority on eligibility (the fields to emit, the endpoints to expose, the specs to conform to), and we link to it rather than rewrite it. What comes after eligibility is winning: given that you qualify, how do you become the choice? That is the layer webmaster-guidelines-era SEO writing was to a search engine's own documentation, and it is the only layer this site covers. ## The five levers of agent selection Winning is not one move; it is a small set of levers that make your catalog easier to read and harder to skip. Each has a dedicated playbook. - **Product feed completeness.** Lead your titles with what shoppers search and fill the attributes agents parse; incomplete data is, we argue, a prime reason a product gets skipped. See [Make your product feed AI-readable →](/make-product-feed-ai-readable/). - **Product schema.** Ship the JSON-LD an agent trusts when your page and your feed disagree. See [Product schema (JSON-LD) for AI shopping →](/product-schema-for-ai-shopping/). - **Product titles.** Write the words a shopper types, not a brand codename; agents appear to match queries to titles closely, though the direct evidence is for description rewrites, not titles. See [Product titles that AI agents match →](/product-titles-for-ai-agents/). - **Crawler access.** Don't block the bots that read the page data agents use beyond your feed. See [AI crawlers, robots.txt and llms.txt →](/ai-crawlers-robots-llms-txt/). - **Endorsement signals.** The credibility markers, such as genuine reviews and editorial picks, that can tip an agent's choice, and the dark patterns that backfire. How they work and what the evidence says is in [How AI shopping agents choose products →](/how-ai-agents-choose-products/). ## How selection actually works Agents do not browse the way people do. Independent research on shopping agents points to a consistent pattern: they read structured product data, score it, and concentrate demand on a few products, often ignoring the rest entirely. The signals that appear to move that score include price, availability, review depth, how completely your data is filled in, on-screen position, and endorsement markers. [How AI shopping agents choose products →](/how-ai-agents-choose-products/) breaks each one down with the sourced figures and caveats, and is the deepest place to understand the mechanism before you touch the levers. Underneath that, the path from your catalog to the agent's pick runs through five stages. Your data enters as a feed, gets crawled and parsed into fields the agent trusts, and is then compared against the shopper's request before the agent names a winner. The diagram below is where the levers above act: better feed and schema make the parse stage cleaner, and stronger endorsement signals move the compare stage in your favor. ## Which agents you're optimizing for You are not optimizing for one agent; you are optimizing one catalog for several. The same structured signals surface you across ChatGPT, Google's AI Mode and Gemini, and Perplexity, but each engine appears to weight them differently and reaches your store over a different rail, so ties break per engine. Most of the work is shared, and a thinner layer on top is engine-specific. Per-engine playbooks live in the [AI shopping platforms hub →](/platforms/). ## The protocol layer, in one minute Underneath all of this sit two kinds of protocol: checkout rails that let an agent complete a purchase, and payment rails that authorize it. OpenAI and Stripe's Agentic Commerce Protocol already powers ChatGPT's Instant Checkout. Google's Universal Commerce Protocol is the analogous open standard on its side. Which rail reaches which engine (and which one you should implement) is the whole subject of [UCP vs ACP: which gets you selected →](/ucp-vs-acp/). The payment protocols beneath them (AP2, Visa's Trusted Agent Protocol, and Mastercard Agent Pay) decide whether an agent can actually pay you; we cover those in [Agentic payment protocols, explained →](/agentic-payment-protocols/). None of these rails choose *which* merchant wins. That is the point of the seam above, and the reason the rest of this handbook exists. ## How we prove our claims The space around agent selection is full of confident guesses, so the thing that makes this handbook worth trusting is that every factual claim is labeled with where it came from. We use four evidence types you will see attached to claims throughout: **spec-fact** (stated in an official specification, linked to the primary source), **reported** (a finding from a named third party, with a date, because model behaviour has a shelf life), **hypothesis** (our own inference, phrased as such and never dressed up as data), and **measured** (a result from controlled testing run here). There are no measured claims on this site. AgentMint.net does not run its own experiments, and rather than keep a results page waiting on numbers that never arrive, the measurement work it does publish is a protocol you can run yourself: [how to test agent selection →](/handbook/how-to-test-agent-selection/). Every term used here is defined and typed in the [glossary](/glossary/). --- # Agentic Payment Protocols, Explained https://agentmint.net/agentic-payment-protocols/ ## Key takeaways - Agentic payment protocols are the trust-and-authorization rails that let an AI agent actually pay. They decide whether a purchase can be completed with you, not whether you get chosen. - AP2 (Google) structures an agent purchase around two signed Mandates, a Checkout Mandate and a Payment Mandate, and leaves how agents find and choose merchants outside its scope, acting as a security layer inside a separate Commerce Protocol. - Visa's Trusted Agent Protocol, Mastercard's Agent Pay, and American Express's Agentic Commerce Experiences work the identity and credential side: registering and verifying trusted agents, scoping tokenized payment credentials to them under consumer-set controls, and, in Amex's case, committing to cardholder protection for registered-agent purchases. - None of these rails rank merchants. Supporting them is table stakes to be transactable; winning the pick is a separate layer decided by your product signals, which is what the rest of this handbook is about. - Payment plumbing is fast-moving and partly announcement-stage. This page links the primary specs rather than reproducing them, and flags where a fact is reported rather than confirmed against a first-party source. ## Why payment rails matter to selection Before an AI shopping agent can buy anything on your behalf, it has to complete a payment it is authorized to make, and prove, after the fact, that it was allowed to. That is the job of the agentic payment protocols: they standardize how an agent is trusted, how its intent is captured, and how a card or account credential is scoped to a single purchase. They sit underneath the discovery-and-checkout protocols like UCP and ACP, on the "can this actually settle?" layer. For a merchant, the strategic point is narrow and important. A payment rail an agent cannot complete a purchase over is a reason for that agent to route around a merchant entirely, which makes rail support table stakes for being *selectable*, even though the rail itself never decides which of several eligible merchants an agent picks. In other words, these protocols are a floor you have to be on, not a lever you pull to win. The four below are the ones worth knowing by name. ## AP2: the Checkout and Payment Mandates AP2 is the payment layer built to sit alongside the agent-interoperability standards. Google announced the Agent Payments Protocol (AP2) on 16 September 2025 as an open, payment-method-agnostic protocol that extends the Agent2Agent (A2A) and Model Context Protocol (MCP) standards to cover how an agent is authorized to pay. Note the exact name: it is the Agent *Payments* Protocol (plural), and it is designed to work across payment methods rather than being tied to one card network. The part of AP2 a merchant actually needs to understand is its accountability model. The current AP2 specification (labeled v0.2) structures an agent-led purchase around two signed Mandates, a Checkout Mandate (the merchant's cryptographic proof the shopping agent is authorized to purchase the checkout) and a Payment Mandate (proof the agent is authorized to pay for it), verifiable credentials that together form an accountability trail recording what the shopper authorized and what was ultimately charged. The terminology has moved since AP2 first shipped: Google's original September 2025 announcement described the flow as three Mandates (Intent, Cart, and Payment); the specification has since consolidated to the two Mandate types above. None of that changes what AP2 is for. It produces a tamper-evident record that a purchase was legitimate, so that banks, networks, and merchants can accept agent-initiated transactions with confidence. It is infrastructure for *trust in the transaction*, not a system that steers demand toward any particular store. The full specification lives at [ap2-protocol.org](https://ap2-protocol.org). We link it rather than restate it, because the spec is the authoritative source for the field-level detail. AP2's governance changed after launch. Google donated AP2 to the FIDO Alliance in late April 2026, with the transition intended to keep the protocol platform-agnostic and community-led; standardization of the specification now continues inside the FIDO Alliance rather than as a single-vendor spec. That is a separate, later development from the original September 2025 announcement above, not a correction to it. The AP2 site names where that work now happens: standardization of the specification will continue within the Agentic Authentication Technical and Payments Technical Working Groups in FIDO. The same page also updates how AP2 places itself in the stack: it now describes AP2 as available as an extension for the open-source Agent2Agent (A2A) protocol and the Universal Commerce Protocol, keeps the two-mandate structure (Checkout and Payment, each in Open and Closed variants), and lists v0.2 as current with no dated release newer than the 16 September 2025 launch. ## Visa Trusted Agent Protocol Visa's contribution addresses a different question: how does a merchant know the "shopper" knocking on its checkout is a legitimate AI agent and not an abusive bot? Visa and Cloudflare announced the Trusted Agent Protocol on 14 October 2025; it lets merchants recognize and verify trusted AI agents through agent-specific cryptographic signatures, distinguishing legitimate shopping agents from ordinary bot traffic. This is an identity-and-attestation rail rather than a checkout schema. Its output is "this agent is who it says it is and is trusted to transact," which a merchant's existing fraud and acceptance logic can then act on. Trusted Agent Protocol is a distinct announcement from Visa's earlier "Visa Intelligent Commerce" push, unveiled 30 April 2025, about six months before Trusted Agent Protocol; the two are separate initiatives with separate scopes, not the same announcement under two names. Both initiatives have since moved from announcement toward pilots. By mid-December 2025, Visa reported hundreds of controlled, real-world agent-initiated transactions in live pilots, more than 30 partners actively developing in the Visa Intelligent Commerce sandbox, Akamai as the latest Trusted Agent Protocol supporter, and a target of bringing secure AI-enabled commerce to consumers by early 2026. Pilot progress as of that date, not general availability. ## Mastercard Agent Pay Mastercard's entry works the card-credential side of the same problem: making a tokenized payment credential safe to hand to an agent. Mastercard announced Agent Pay, its Agentic Payments Program, on 29 April 2025. The program introduces Mastercard Agentic Tokens, built on the tokenization stack behind contactless and card-on-file payments; it will require trusted AI agents to be registered and verified before they can pay on a user's behalf, give consumers complete control over what an agent is allowed to purchase, and make agent-facilitated transactions recognizable to consumers, issuers, and merchants alike. Microsoft is the first named platform collaborator, integrating Azure OpenAI Service and Copilot Studio, with IBM's watsonx Orchestrate on B2B use cases and acquirers like Braintree and Checkout.com on the tokenization side. Conceptually it is close to Visa's aim from the network side: registered, verified authority for an agent to pay under consumer-set limits, rather than a wide-open card number. Much of the program is announcement-framed: the release describes registration, consumer controls, and transaction recognition as what Agent Pay will do as it rolls out, not as features every issuer and merchant has today. ## Mastercard Agent Pay for Machines: adjacent, not a shopper rail Mastercard extended the Agent Pay line in mid-2026, and the extension is worth naming precisely so nobody wires it for the wrong job. On 10 June 2026 Mastercard launched Agent Pay for Machines with more than 30 industry leaders, including Adyen, Ant International, BVNK, Checkout.com, Cloudflare, Coinbase, Getnet by Santander, Global Payments, Lovable, OKX, Stripe, and Tempo, built around four capabilities: Credentialing (paired with Verifiable Intent), Permissioning, Transacting, and Settling, which it describes as reliable, guaranteed multi-rail settlement across cards, accounts, and stablecoins. Mastercard draws the boundary itself: where Agent Pay defines how trusted AI agents participate in payments, Agent Pay for Machines is designed for a complementary opportunity, automated, micro- and machine-driven transactions. For a store optimizing to be selected by a shopper's agent, the practical point is what this is not. It is a machine-to-machine settlement rail, not a consumer shopping-selection rail, so it does not sit in the path where a person's agent compares stores, picks one, and checks out. Supporting it does nothing for shopper checkout, and a merchant who integrates it expecting that will have wired the wrong layer. Keep it on the "adjacent, good to know it exists" shelf, not the "implement to get selected" one. ## American Express Agentic Commerce Experiences American Express joined the same layer in April 2026 with a bundle it calls Agentic Commerce Experiences (ACE). American Express introduced the ACE Developer Kit on 14 April 2026 for select developers, built around five integrated services: Agent Registration (verifying agents so only trusted ones transact on the Amex network), Account Enablement (Card Members registering their cards for agentic transactions), Intent Intelligence (capturing purchase intent to support authentication, authorization, and disputes), Payment Credentials (verified agents paying with tokenized credentials), and Cart Context (sharing cart details around a transaction); the announcement footnotes Agent Registration and Cart Context as services still in development. The kit half is familiar territory (registration, documented intent, tokenized credentials). The protection half is the newer move, and it is a commitment rather than a live program: under Amex Agent Purchase Protection, American Express says that in the future, when a Card Member authorizes a registered agent and that agent sends Amex the customer's authenticated purchase intent, it will protect eligible customers from charges caused by AI agent error, with terms and conditions to apply. That is a consumer-facing guarantee attached specifically to agent-initiated purchases, aimed at shopper trust rather than merchant plumbing. ## The four at a glance _Backers, dates, and functions are cited in the sections above, each against the protocol owner's own announcement or specification. 'Picks the merchant?' asks whether the protocol itself influences which store an agent chooses._ | Protocol | Backers | Announced | What it secures | Picks the merchant? | | --- | --- | --- | --- | --- | | AP2 (Agent Payments Protocol) | Google + partners | 16 Sep 2025 | Payment authorization via two signed Mandates (Checkout, Payment); extends A2A + MCP | No: catalog and discovery are outside AP2 scope | | Visa Trusted Agent Protocol | Visa + Cloudflare | 14 Oct 2025 | Agent identity: cryptographic signatures that mark an agent as trusted vs. a bot | No: identity/attestation only | | Mastercard Agent Pay | Mastercard (Microsoft first platform collaborator) | 29 Apr 2025 | Registered, verified agents paying with Mastercard Agentic Tokens under consumer-set purchase controls | No: card-token scoping only | | Amex Agentic Commerce Experiences | American Express | 14 Apr 2026 | Agent registration and verification, intent capture, tokenized credentials, plus a future cardholder-protection commitment | No: registration and protection only | The shared column is the last one. Whatever each protocol secures (authorization, identity, a scoped token, or a protected registration), none of them is in the business of deciding which store an agent recommends or buys from. That is not an oversight; it is the design. One provider has pushed that abstraction furthest for merchants who already use it. Stripe states that any seller already processing payments with Stripe automatically supports these new payment methods for agentic transactions, and that when a customer authorizes an agent, Stripe provisions an agentic network token from Mastercard or Visa scoped to the customer's intent and shares it with the agent. That one primitive now spans Mastercard Agent Pay, Visa Intelligent Commerce network tokens, and BNPL through Affirm and Klarna. For a store already on Stripe this lowers the payment-eligibility bar to near zero by default: if the rails arrive switched on with the integration you already run, payment readiness stops being the thing that keeps you out of an agent's basket, and the deciding factors move back up to product and offer data. The payment service providers, meanwhile, have started to abstract these rails away from merchants entirely. Adyen announced Adyen Agentic on 16 June 2026, a three-layer suite (Agentic Feed, Agentic Cart, Agentic Payments) whose payments layer handles authentication, token portability, and merchant-of-record preservation across protocols, explicitly naming UCP, AP2, ACP, and Meta AI checkout among the rails it translates between; at launch it is in limited availability for U.S. enterprise merchants. If PSPs keep absorbing rail differences this way, a merchant's job shifts from betting on one protocol to keeping product and offer data clean enough for any rail to carry. ## Payment is not selection This is the positioning line that matters, and the specification draws the boundary itself. The AP2 specification defines only the payment-authorization layer and explicitly places the Commerce Protocol's catalog and discovery details "outside the scope of AP2," leaving how an agent finds and picks a merchant to that separate layer. The payment rail hands off *after* the agent has already chosen you; it makes the chosen purchase completable and accountable. Getting your store onto these rails removes a reason to be skipped (an agent will not select a merchant it cannot pay), but it adds nothing to why an agent would prefer you over an equally payable competitor. So treat payment-protocol support the way you treat SSL or a working checkout: table stakes, invisible when it works. The actual contest (the one this handbook exists for) happens one layer up, in the product signals an agent scores when it decides whom to pick. If you have not yet mapped that layer, start with [how AI shopping agents choose products](/how-ai-agents-choose-products/), and see the per-engine playbooks on the [AI shopping platforms hub](/platforms/). ## How this relates to UCP and ACP It is easy to blur the payment protocols together with the commerce protocols, because they are announced by the same companies and sometimes in the same breath. Keep them on two shelves. The commerce protocols, UCP (Google) and ACP (OpenAI and Stripe), cover discovery and checkout: how an agent finds a product and assembles an order. Even there, the payment side is wider than one provider: PayPal announced on 28 October 2025 that it would adopt ACP and support payments processing for merchants using Instant Checkout in ChatGPT. The payment protocols on this page cover the settlement and trust underneath that order. A merchant can be perfectly legible to a commerce protocol and still fail to convert if the payment and identity rails cannot authorize the agent's purchase, which is why the two layers are worth implementing and reasoning about separately. For the head-to-head on the commerce layer (scope, which engine each reaches, and why most catalogs should support both), see [UCP vs ACP: which gets you selected](/ucp-vs-acp/). For how the payment layer shows up on a specific engine, the ACP rail that powers ChatGPT's checkout is covered in [ChatGPT shopping optimization](/chatgpt-shopping-optimization/), and the Google side in [Gemini and Google AI Mode ranking](/gemini-shopping-ranking/). Two-sentence definitions of [AP2](/glossary/#ap2), [ACP](/glossary/#acp), and [UCP](/glossary/#ucp) live in the glossary. --- # Abdalsalaam Halawa https://agentmint.net/author/abdalsalaam-halawa/ I'm Abdalsalaam Halawa, a Palestinian Senior E-commerce Engineer with over 14 years of hands-on experience building the systems that run online stores. Most of that work has been in WordPress and WooCommerce: custom plugins, complex third-party integrations, payment gateways, the Store and REST API that stores use to move product data, and performance work. A lot of it lives close to the machinery that emits product data. I build shipping integrations that connect a store's carriers so rates and labels work automatically, and payment-gateway integrations that do the same for checkout. My route into this was not the usual one. I was born and raised in the Al-Shati refugee camp in Gaza, and that is where I taught myself to build for the web and became a WordPress and WooCommerce developer. I have a background in Computer Systems Engineering, and I now live and work in Bilbao, Spain. Across more than a decade of building and integrating commerce systems, my deepest work has been in WooCommerce and in carrier and payment integrations, and that is the same ground agent selection is now being fought on. AgentMint.net is where I work out, in the open, how AI shopping agents read those systems and decide what to put in front of a shopper. All my other links and contact details live at [halawa.io](https://halawa.io). ## What I write here AgentMint.net is deliberately narrow. Official protocol documentation tells a merchant how to become eligible for agentic commerce: the fields to emit, the endpoints to expose, the specs to conform to. This site covers the layer above that. Given that a store is eligible, how does it actually get selected when an AI agent compares it against everyone else? Every factual claim here is labeled with where it came from, and I never dress up a guess as data. The full sourcing policy, and more on why I built this, is on the [About page](/about/). --- # Agentic Commerce Glossary https://agentmint.net/glossary/ Agentic commerce has produced a thicket of overlapping terms: some are open protocol names with fixed, checkable meanings, some are vendor coinages, and some (including a few of ours) are framings for things no official spec has named yet. This page keeps them straight and honest: every entry carries its evidence type inline, links its primary source where one exists, and points to the chapter of this handbook that goes deep. Definitions marked *our analysis* are inferences we are accountable for, not established fact, so you can weigh them accordingly. ## Terms (A-Z) **ACP: Agentic Commerce Protocol** An open standard for agent-driven checkout and product feeds, from OpenAI and Stripe. OpenAI and Stripe announced ACP on 29 September 2025 as the rail behind ChatGPT's in-chat Instant Checkout; OpenAI has since moved away from a standalone Instant Checkout experience, so ACP feeds now power discovery in ChatGPT while purchases complete on merchant sites, and ACP also carries Microsoft's Copilot Checkout, launched January 2026 with Stripe. It governs *eligibility to transact*, not who gets recommended. The selection layer is where this handbook lives. We link the spec rather than re-document it: [UCP vs ACP](/ucp-vs-acp/). **Agent selection** The choice an AI shopping agent makes when it picks one store, product, or offer over the alternatives it could have returned, the outcome this entire handbook is about influencing. No official protocol defines or governs it; the protocols handle checkout and payment, while each AI platform runs its own, undocumented selection process. That gap is why we treat selection as its own discipline. The mechanics: [how AI agents choose products](/how-ai-agents-choose-products/). **Agent selection maturity model** Our five-level editorial framework for sorting how ready a store is to be chosen by AI shopping agents, ascending from level 1 (unreachable: blocked crawlers, no feed) through eligible, legible, and preferable to level 5 (measured: running the win-rate protocol and iterating). It is a way to prioritize work, not a measured or validated scale, and it carries no outcome numbers. Each level maps to specific Agent Selection Checklist categories and selection signals, so a level reading becomes a concrete next task. The full model: [the agent selection maturity model](/handbook/agent-selection-maturity-model/). **[Agent win rate](/glossary/agent-win-rate/)** Our proposed metric for agentic commerce: the share of relevant agent queries in which your product or store is the one selected, the agentic-era analogue of an ecommerce conversion rate. Because agents weight signals differently and reshuffle on model updates, we argue it is best tracked engine by engine rather than as one blended number. Full definition and how to measure it: [Agent win rate](/glossary/agent-win-rate/). **Agentic commerce optimization (ACO / AEO)** The practice of structuring a catalog, feed, and product pages so AI agents can find, parse, and prefer your products, the agentic-commerce counterpart to SEO; "answer engine optimization (AEO)" and "agentic commerce optimization (ACO)" are used near-interchangeably as industry coinages, several of them vendor-defined, with no standards body behind them. The specific term "agentic commerce optimization (ACO)" was introduced in Scot Wingo / ReFiBuy's Retailgentic series over September-October 2025, but attribution is not settled: a Search Engine Journal column floats "ACO" independently with no credit to any originator, and vendor glossaries define it with no named originator. The bare acronym is also ambiguous: "ACO" is dominantly the US-healthcare term "Accountable Care Organization", a concept from 2006 that the Affordable Care Act enacted in 2010. We prefer a sharper, non-colliding pair: agent selection for the winning question, and machine-readability, or legibility, for the substrate underneath it. Both have their own entries here: [agent selection](/glossary/#agent-selection) and [machine-readability score](/glossary/#machine-readability-score). We use ACO and AEO descriptively and stay skeptical of any vendor's specific weightings until they are evidenced. The handbook's take: [agentic commerce optimization](/agentic-commerce-optimization/). **AI crawler (GPTBot, PerplexityBot, etc.)** An automated bot that fetches web pages on behalf of an AI system: to train a model, to build a search or answer index, or to fetch a page live in response to a user's query. OpenAI documents distinct agents for these jobs: GPTBot (crawls content to train models), OAI-SearchBot (surfaces and links sites inside ChatGPT), and ChatGPT-User (the fetch triggered by a user's own request). The distinction matters for stores, because blocking the wrong token can hide you from the agents that decide whether a shopper sees you. Which to allow, and why: [AI crawlers, robots.txt & llms.txt](/ai-crawlers-robots-llms-txt/). **AP2: Agent Payments Protocol** An open protocol for authorizing and proving agent-initiated payments, so a purchase an agent makes carries a verifiable, accountable trail. Google announced AP2 on 16 September 2025; it is payment-method-agnostic and carried signed Intent, Cart, and Payment mandates at launch, since consolidated to Checkout and Payment mandates in the current spec. Like the other rails, it settles *how a purchase clears*, not who gets chosen. Compared with the other protocols: [agentic payment protocols](/agentic-payment-protocols/). **Choice homogeneity (modal product)** The tendency of AI shopping agents to concentrate their picks on a small set of "modal" products in each category while ignoring other options, and some brands, entirely. In the ACES simulation, agents can exhibit choice homogeneity, often concentrating demand on a few "modal" products while ignoring others entirely. This is a controlled simulation across a fixed model set, not live sales, so read it as a pattern to watch rather than a measured market share. What it means for whether your product becomes the modal pick: [how AI agents choose products](/how-ai-agents-choose-products/). **delegated payment token** In the Agentic Commerce Protocol, a single-use, allowance-constrained payment credential an agent hands to a merchant's payment provider to charge a specific cart, without the agent ever touching raw card data. The delegated payment payload is sent to the merchant's PSP or vault directly, is single-use and set with allowances, and the PSP or vault returns a payment token scoped to that delegated payment, keeping it outside PCI scope. This is the spec-level concept; [Shared Payment Token](/glossary/#shared-payment-token) is Stripe's named implementation of it. Where it fits among the rails: [agentic payment protocols](/agentic-payment-protocols/). **GEO: Generative Engine Optimization** The practice of structuring content so it surfaces inside an AI or generative engine's answer rather than a ranked list of links; the generative-answer counterpart to SEO, coined by the 2023 research paper of the same name. The 2023 paper introduced "Generative Engine Optimization (GEO)" as a framework for improving content visibility inside generative-engine responses, and reports it can lift visibility by up to 40% on the authors' own benchmark. That 40% is a result on the paper's own benchmark, not a measured effect on any live shopping engine. GEO answers the same substrate question our [agentic commerce optimization](/glossary/#aco-aeo) framing does; we keep it distinct from the winning question of [agent selection](/glossary/#agent-selection). The handbook's take: [agentic commerce optimization](/agentic-commerce-optimization/). **Google Merchant Center** Google's free tool where a merchant uploads and manages product data so those products become eligible to appear across Google's surfaces (Search, Shopping, Maps, YouTube) and, through UCP, agentic checkout. Merchant Center is a free tool for uploading and managing product data so products appear across Google Search, Maps, YouTube, and more. It is an eligibility substrate: it feeds your catalog into Google's [Shopping Graph](/glossary/#shopping-graph) and, through [UCP](/glossary/#ucp), its agentic checkout, but it does not decide which product an agent recommends. Getting the feed itself chosen is the work: [make your product feed AI-readable](/make-product-feed-ai-readable/). **llms.txt** A public spec, published at llmstxt.org and revised to v2 in August 2026, for a root-level /llms.txt Markdown file that hands a large language model a curated, easy-to-parse map of a site's most important content. There is no confirmed public evidence yet that ChatGPT, Gemini, or Perplexity read it when choosing products, so treat it as low-cost insurance rather than a selection lever. What to ship, and the honest caveats: [AI crawlers, robots.txt & llms.txt](/ai-crawlers-robots-llms-txt/). **Machine-readability score** A per-page grade for how much of a page an AI agent can read as structured data instead of inferring from layout. Retail product pages score an average of 66 out of 100 on Adobe's machine-readability index (meaning roughly a third of a typical product page is not cleanly machine-readable), versus 74 for category pages and 75 for homepages. Read it as a page-completeness score, not a share of pages. Closing the gap: [make your product feed AI-readable](/make-product-feed-ai-readable/). **Platform-endorsement signal** A store- or platform-issued mark that a product is endorsed (an "Overall Pick" badge, a "Choice" label, or similar), which agents tend to reward. In the ACES simulation, an "Overall Pick" endorsement lifted a baseline 10% selection probability to 24.3% for a Claude agent, 19.9% for GPT-4.1, and 42.6% for Gemini. This is a controlled simulation across a fixed model set, not live sales. The winning move is to *earn* legitimate endorsements, not fake the badge; the mechanics are in [how AI agents choose products](/how-ai-agents-choose-products/). **Position bias** An agent's tendency to favor a product because of where it appears in the layout the agent sees, independent of the product's merits. In the ACES simulation, moving a product from the bottom-right corner to the top row raised a Claude Sonnet 4 agent's selection rate roughly fivefold; the effect varied by provider and persisted even in text-only interfaces. This is a simulation, not live sales, and evidence that there is no universal "top" rank to chase. How it plays out per engine: [how AI agents choose products](/how-ai-agents-choose-products/). **Product feed** A structured data file (one row per product, each carrying attributes such as title, price, availability, GTIN, image, and description) that a merchant supplies so shopping surfaces read the catalog as data rather than scraping the page. A machine-readable product feed is part of the ACP open standard, which enumerates the core attributes an agent reads, including identifiers such as GTIN, price, and availability. Getting a feed *seen* is eligibility; getting it *chosen* is the work: [make your product feed AI-readable](/make-product-feed-ai-readable/). **Shared Payment Token** Stripe's single-use, merchant-and-amount-scoped payment credential for agent-initiated purchases; the first shipping implementation of the Agentic Commerce Protocol's Delegated Payment Spec. Stripe's Shared Payment Token is the first Delegated Payment Spec-compatible implementation, with more payment providers stated as coming. It is the vendor implementation, not the standard: the protocol-level mechanism it implements is the [delegated payment token](/glossary/#delegated-payment-token). How it compares with the other rails: [agentic payment protocols](/agentic-payment-protocols/). **Shopping Graph** Google's machine-learning-powered, real-time dataset of the world's products and sellers, the index that powers product results across Google Search, Shopping, and its AI and agentic surfaces. Google's Shopping Graph holds over 50 billion product listings, including inventory, prices, and reviews, with more than 2 billion refreshed every hour. Being listed there is eligibility to appear on Google surfaces, not a promise of being picked. How Google's agents rank what the graph holds: [Gemini and Google AI Mode ranking](/gemini-shopping-ranking/), and where it sits among the [AI shopping platforms](/platforms/). **Sponsored-tag penalty** The observed pattern where an agent selects a product *less* often when it is labeled "Sponsored." In the ACES simulation, a "Sponsored" tag pushed a baseline 10% selection probability down to 8.9% for a Claude agent, 8.0% for GPT-4.1, and 7.9% for Gemini; agents consistently penalized sponsored tags. This is a controlled simulation, not live sales. It is the counterintuitive inverse of paid search, and it argues against buying visibility with a badge agents discount; see [how AI agents choose products](/how-ai-agents-choose-products/). **UCP: Universal Commerce Protocol** Google's open standard for agents to complete the full commerce journey (discovery, checkout, and post-purchase) without leaving the AI surface. Google announced UCP at NRF 2026 on 11 January 2026 as a vendor-agnostic standard compatible with A2A, AP2, and MCP. It is "Universal *Commerce* Protocol," not "Universal Cart" (Google's consumer cart product), and it governs the transaction rail, not product-presentation logic. Side by side with ACP: [UCP vs ACP](/ucp-vs-acp/). --- # Agent Win Rate: Definition & How to Measure https://agentmint.net/glossary/agent-win-rate/ ## Key takeaways - Agent win rate is a selection metric: the fraction of an AI agent's shopping sessions, over a fixed query set, that end with your product chosen rather than a competitor's. - It is not click-through, impressions, or share of voice: those measure exposure, while win rate measures the agent's final decision. - There is no industry-standard definition yet, so the framing on this page is ours, labeled as such rather than presented as established fact. - To measure it, fix a query set, run repeated sessions per engine, and count the share your product wins. The full protocol lives in the methodology. - There is no single win rate: it varies by engine and shifts when models update, so report it per engine, with error bars, and a measurement date. ## Definition (our framing) There is no settled, vendor-neutral definition of *agent win rate* in circulation. A scan of the practitioner and vendor literature turned up no credible, non-marketing source that defines the term, so the framing below is ours, offered as a working definition, not an established standard. We define **agent win rate** as the share of an AI shopping agent's sessions, for a given shopping task or query, that end with your product being the one the agent recommends or buys, rather than a competitor's. The unit of analysis is a completed agent session; the outcome in each session is binary (your product was selected, or it was not); the win rate is the fraction of sessions you won across a defined set of queries. It is the outcome that [agent selection](/glossary/#agent-selection) (why an agent picks one store or offer over another) resolves into for a specific catalog. Because it is a decision metric, agent win rate is meant to be read alongside a denominator and a scope: *win rate on which queries, on which engine, over how many sessions.* A number without that scope is not a measurement. ## Not click-through or impressions Agent win rate answers "how often does the agent *choose* me?", not "how often am I *seen* or *clicked*?" Keeping it separate from web-analytics metrics matters, because agents collapse the funnel that those metrics were built to describe: - **Impressions or share of voice** count how often you appear in an agent's consideration set or its answer. That is exposure, not outcome: necessary to win, but not the same as winning. - **Click-through rate** is a human-funnel metric. An agent may compare, decide, and even transact without a human ever clicking a result, so CTR can miss the event that actually matters. - **Agent win rate** is the terminal decision: of the sessions where a choice was made, in how many was your product the pick. > **High visibility is not a win** > > A large impression share with a low win rate is a specific, diagnosable failure: the agent sees you and still selects someone else. That gap points at the selection signals (data completeness, price, ratings, description text) rather than at reach. ## How to measure Agent win rate is measured, not estimated from intuition. The high-level recipe (this is our method, not a standard): 1. **Define a representative query set** for your category: the shopping tasks a real buyer would hand an agent. 2. **Run repeated, independent sessions** on each engine you care about (for example ChatGPT, Gemini, Perplexity). 3. **Record the outcome per session**: whether your product is the recommendation or the purchase. 4. **Compute win rate = wins ÷ sessions, per engine**, and attach the sample size and a date. The reproducible protocol (prompt sampling, how many sessions, and how to control for position and presentation order so the number reflects your product and not its slot) is written up in [the methodology](/handbook/how-to-test-agent-selection/). We publish no win-rate figures here: the point of the metric is that you measure it on your own catalog. ## Honest error bars A win rate is an estimate from a finite sample of sessions, so it carries sampling uncertainty like any survey. Report it as a range with a confidence interval rather than a single decimal: "38% from 20 sessions" and "38% from 2,000 sessions" are not the same claim, and the first has error bars wide enough to be nearly uninformative. Small samples produce wide intervals; that is a fact about the measurement, not a detail to hide. There is a second source of drift beyond sampling: the thing being measured moves. Because agent behavior changes when the underlying model is updated, any win rate is a snapshot tied to a date and a model version, not a permanent property of your product. Stating the interval and the date is the difference between an honest metric and a vanity number. It is why this site refuses point estimates presented without error bars. ## Per-engine win rate varies There is no single agent win rate to report, because the engines do not agree. In the ACES study (a controlled simulation of frontier shopping agents, not a record of live sales), selection behavior was model-specific, and a model update could drastically reshuffle which products an agent picks. In practice, the same product can win often on one engine and rarely on another, and a comfortable win rate can decay after a model release you did not control. So a win rate is only meaningful per engine and per date: measure each engine separately, and re-measure after major model updates rather than trusting a figure indefinitely. The [platform playbooks](/platforms/) track where ChatGPT, Gemini, and Perplexity currently diverge, and [how AI agents choose products](/how-ai-agents-choose-products/) covers the signals that move the number in the first place. For the rest of the agentic-commerce vocabulary, return to the [glossary](/glossary/). --- # AI Shopping Platforms: How to Get Selected Across Engines https://agentmint.net/platforms/ ## Key takeaways - One catalog serves every agent: the same structured signals (grid position, price, rating, endorsement, and description text) drive selection across ChatGPT, Gemini, and Perplexity. - The weights are provider-specific. The strongest public evidence, the academic ACES simulation, shows the same signal moving each model by a different amount. - Protocol rails carry you to the engines: ACP feeds carry ChatGPT shopping (the in-chat checkout was scaled back in March 2026, so purchases now complete on merchant sites), and Google's own developer documentation confirms UCP is the rail enabling agentic actions on Gemini and AI Mode. - The rails no longer map one-to-one onto engines: Microsoft Copilot consumes both, running Copilot Checkout on ACP through Stripe while reading UCP-ready Merchant Center feeds. - There is no universal 'top rank' to chase. Optimize the shared inputs first, then break ties engine by engine. - Agent behavior is a moving target (a model update can reshuffle which products win), so every claim on this page is dated. ## The shared signal set (one catalog, many agents) You do not maintain a separate product catalog for each AI shopping engine, and you should not optimize for one as if the others do not exist. The [selection chapter](/how-ai-agents-choose-products/) of this handbook lays out the signals agents actually read (where a product sits in the results grid, its price, its star rating, whether it carries a platform endorsement, and how its description is written), and those same categories of signal recur across ChatGPT, Gemini, and Perplexity. That is what lets a single well-structured catalog compete everywhere at once, and it is the practical core of [agent selection](/glossary/#agent-selection): the inputs are shared even when the scoring is not. The evidence that the *categories* are shared but the *weights* are not comes from one controlled study. In the ACES simulation (vision-language-model agents choosing from a mock storefront in randomized trials), every selection signal (price, rating, endorsement, and description text) carried a different weight on each model tested, so no single "winning" configuration held across Claude, GPT-4.1, and Gemini. Read that as evidence of *how* engines diverge, not as conversion math for a live store: it is a simulation across a fixed model set, not a record of real purchases. This hub is the platform overview inside the broader [agentic commerce optimization](/agentic-commerce-optimization/) guide; the per-engine playbooks below carry the specifics. ## Where engines differ (the weights) If the signals are shared, the divergence lives in how hard each engine leans on them, and that is where per-engine work earns its keep. The [selection chapter](/how-ai-agents-choose-products/) reports the full ACES breakdown model by model; the short version is that the gaps are large enough to matter. One clear example: platform endorsement is a lever on every model, but not equally. A platform endorsement such as an "Overall Pick" badge lifted a baseline 10% selection probability to 24.3% for a Claude agent, 19.9% for GPT-4.1, and 42.6% for Gemini, with Gemini rewarding endorsement most strongly. The takeaway is directional, not a dial you set: the same honest signal buys more selection lift on some engines than others, which is exactly why there is no universal "top rank" to aim for and why a per-engine [agent win rate](/glossary/#agent-win-rate) is the number to watch rather than a single blended one. Get the shared inputs right first (feed completeness, product schema, titles, crawler access), then use the playbooks to break ties on the engine that matters most to your catalog. ## Which rail reaches which engine Signals decide *whether* an agent prefers you; a protocol rail decides *how* that agent reaches your catalog and completes a purchase. The two rails to know launched behind different engines, and both original mappings are confirmed. The Agentic Commerce Protocol (ACP), announced by OpenAI and Stripe on 29 September 2025, launched as the rail powering ChatGPT's Instant Checkout. The shape of that rail changed within six months: OpenAI scaled the in-chat checkout back by March 2026, routing purchases through merchant sites and apps instead, and OpenAI's merchant documentation now describes ChatGPT shopping as discovery-first: ACP product feeds decide how products appear in results, and customers complete their purchase on the merchant's own site or app, with no fees on purchases that start in ChatGPT. So for ChatGPT, ACP remains the confirmed rail, now carrying discovery and product feeds rather than an in-chat purchase. Google has put its side on the record too. Google announced the Universal Commerce Protocol (UCP) at NRF 2026 on 11 January 2026 as an open standard for agents to complete discovery, checkout, and post-purchase without leaving the AI surface, and Google's own UCP developer guide states that adopting UCP enables agentic actions on AI Mode in Google Search and Gemini, starting with direct buying, naming Gemini and AI Mode as UCP's consuming surfaces directly. The one-rail-per-engine picture then stopped holding in 2026, because Microsoft Copilot consumes both rails. Microsoft launched Copilot Checkout on 8 January 2026, letting shoppers complete a purchase inside Copilot, with merchants onboarding through PayPal or Stripe and launch brands including Urban Outfitters, Anthropologie, Ashley Furniture, and Etsy sellers, and Stripe states that Copilot Checkout runs on the Agentic Commerce Protocol, with a Shared Payment Token issued to the merchant, who remains the seller of record. On the discovery side, Microsoft announced on 21 April 2026 that UCP-ready feeds in Microsoft Merchant Center were generally available to everyone in the US, and that Copilot Checkout had expanded to more than 500,000 merchants and to mobile. That same post carries a detail worth acting on if you run WooCommerce: Copilot Brand Agents expanded to WooCommerce merchants, along with support for brand and policy materials, so a Woo store can run a branded Copilot agent rather than relying on feed inclusion alone. Microsoft's agentic commerce documentation describes UCP as a complementary layer over Merchant Center feeds, says Copilot surfaces products from both the open web and a merchant's Merchant Center feed, and limits Copilot Checkout to English-language merchants shipping within the US as of that documentation. That same documentation, re-checked in September 2026, spells out the gate's currency and commerce-model terms: eligibility is limited to English-language merchants selling to US buyers in USD, the merchant stays merchant of record ("Copilot does not become merchant of record"), and a return policy plus customer support information are required Merchant Center store settings for Copilot Checkout. For a merchant, the same two rails now cover three engines, so protocol work you do for one ecosystem increasingly pays out in another. The full protocol comparison (what each rail covers, and which one to implement) lives in [UCP vs ACP: which gets you selected](/ucp-vs-acp/). ## Per-engine playbooks Once the shared inputs are in place, these four pages cover what each engine does differently. - **[ChatGPT Shopping Optimization](/chatgpt-shopping-optimization/)**. The product-data signals ChatGPT reads over the ACP rails, and why there is no "enroll" button to flip. - **[Why you're not in ChatGPT Shopping](/store-not-in-chatgpt-shopping/)**. The diagnostic order when your products are missing: crawler blocks, feed gaps, title mismatches. - **[Gemini & Google AI Mode shopping ranking](/gemini-shopping-ranking/)**. How AI Mode ranks through your Merchant Center feed and the UCP rail, where feed quality is the lever. - **[Perplexity Shopping Optimization](/perplexity-shopping-optimization/)**. The signals and sources Perplexity leans on, and how it differs from the other two. Of the five surfaces here, Perplexity documents the least about how it selects: its Merchant Program terms set out the product data a merchant supplies, and almost nothing else is stated, so that playbook leans on crawler documentation and the program terms rather than a selection guide. ## Two surfaces the playbooks don't yet cover Amazon and Anthropic both moved in 2026, and neither has a per-engine playbook here yet. Both belong on the record now, because one states plainly what its agent weighs and the other sets a pattern for how a Claude agent shops. ### Amazon's Alexa for Shopping On 13 May 2026, Amazon renamed its Rufus shopping assistant to Alexa for Shopping and added agentic buying. Amazon rarely says what its shopping model weighs, so the launch account is worth quoting rather than paraphrasing. Amazon says the assistant runs on "a custom-built model leveraging knowledge from Amazon's extensive product catalog, customer reviews, community Q&As, and information from across the web", and gives "personalized product suggestions based on conversational context" plus each customer's "individual Amazon shopping activity". Two buying paths ship with the rename. Auto-Buy will "check prices frequently on your behalf and complete the purchase agentively", and for products Amazon does not sell it shows a "Buy for Me" button, where Amazon "agentically purchase[s] the item on your behalf", or a "Shop Direct" option. Because that model draws on Amazon's own catalog, reviews, community Q&A, and each shopper's Amazon history, we expect the levers that move it to sit largely inside Amazon's ecosystem rather than in the cross-engine feed and schema work the rest of this hub covers. ### Claude as a commerce surface On 2 September 2026, Anthropic published an Apache-2.0 reference implementation of a customer-facing shopping agent that searches, compares, plans, fills a cart, and answers policy and order questions, alongside a staff-facing merchant agent; it hands off to the merchant's own checkout and deliberately leaves out payment processing. The README documents what the agent does but gives no ranking or selection algorithm, so it shows how a Claude shopping agent is built, not how it picks between products. ## Behavior changes on updates Optimizing to a single engine is fragile because the engine itself moves. ACES documented that a model update can drastically reshuffle market shares, as it did between Gemini 2.5 Flash Preview and Gemini 2.5 Flash. What an agent rewards this quarter it may weight differently after the next release, which is why AgentMint.net types and dates every model-behavior claim rather than presenting it as a fixed rule. **Agent behavior changes with every model update. Last verified: 2026-09-18.** Treat the per-engine playbooks as snapshots, re-check them against your own measured [agent win rate](/glossary/#agent-win-rate) on a cadence, and weight the shared inputs (which are stable across updates) over any single engine's current quirks. --- # Privacy Policy https://agentmint.net/privacy/ ## Analytics We do not run any analytics on AgentMint.net. We do not measure your visits, we do not send page views to any analytics service, and we set no analytics or tracking cookies. Nothing on this site builds a profile of you or follows you across other websites. If we ever add analytics, it will be a privacy-friendly, cookieless tool, and we will describe here exactly what it collects before we turn it on. ## Newsletter If you subscribe to the AgentMint.net newsletter, you share your email address so we can send you new research and updates. We store and send through [Buttondown](https://buttondown.com), an email newsletter service based in the United States, which processes your email address on our behalf. New subscriptions are confirmed by email (double opt-in): Buttondown sends you a confirmation link, and you only start receiving the newsletter after you click it. We use your address only to send AgentMint.net emails, never for advertising, and we do not sell or rent it. Every email includes an unsubscribe link, so you can opt out at any time. See Buttondown's [privacy policy](https://buttondown.com/legal/privacy) for how they handle the data they process. ## Cookies AgentMint.net is a static site with no advertising, no analytics, and no cross-site tracking, so it sets no ad, analytics, or tracking cookies. The newsletter form on this site is plain HTML that posts directly to Buttondown, so it sets none of our own cookies; submitting it may cause Buttondown to set cookies on its own domain, governed by Buttondown's privacy policy. The site is hosted on Hostinger; any remaining cookies would be strictly functional ones that Hostinger may set to serve the site. We do not use cookies to profile you or to target ads. ## Contact You can ask to access or delete the personal data we hold (realistically, only your newsletter email address). Privacy laws such as the GDPR and CCPA give you rights over that data, including access, correction, deletion, and opting out. To exercise them, or for any question about this policy, reach Abdalsalaam Halawa through [halawa.io](https://halawa.io), which is the contact point for any data request. --- # AI Shopping Crawler Reference: Every User-Agent Token https://agentmint.net/reference/ai-shopping-crawlers/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It checks whether the documented AI shopping crawlers can reach your store and proposes safe changes. Review anything it changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Verify my store crawler access The agent checks robots, bot rules, and rendering against the reference table. ```text Fetch and read the full document at https://agentmint.net/reference/ai-shopping-crawlers.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are checking whether AI shopping crawlers can reach this repository's e-commerce store, using the reference table in that document. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first and change nothing yet. Check the store robots.txt, any WAF, bot-protection, or rate-limit rules, and how key pages render (server-rendered versus client-only), against the documented crawler tokens. For each relevant token in the reference, report: allowed, blocked, or unknown, with the evidence (the robots.txt line, the rule, or the render result). Then propose safe changes to unblock the legitimate crawlers you want, but do not apply them until I approve. Never propose serving crawlers different content than people see at the same URL. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: which crawlers can reach the store today, which cannot, and what you recommend I change. ``` ## Key takeaways - This page is a dated reference, not analysis: every token below is named in an operator's own documentation, with the exact purpose and robots.txt behavior each operator states. Most entries were re-verified on 2026-08-20; each claim carries its own verification date, and a handful (the Apple and Bing entries among them) still date from 2026-07-08. - Four platforms get full detail because this site already covers them elsewhere: OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot), Google (Googlebot, Storebot-Google, Google-Extended, Google-Agent), Anthropic (ClaudeBot, Claude-User, Claude-SearchBot), and Perplexity (PerplexityBot, Perplexity-User). - Storebot-Google is the actual Google Shopping crawler and the single most on-topic entry here; Google-Extended only controls training and grounding use of crawled content for Gemini models, not AI Mode inclusion, a distinction Google's own docs draw explicitly. - No Microsoft-owned source documents a distinct Copilot crawler: Copilot's shopping-relevant answers run on Bing's existing index through bingbot, and the 'CopilotBot' token some third-party lists cite has no primary source. - Several widely assumed tokens do not exist in any operator's documentation: no distinct crawler for Rakuten, Walmart, or TikTok Shop, and no token literally named for Amazon's Rufus. Treat any source claiming otherwise as unverified. This page is the exhaustive, dated reference: the exact user-agent tokens named in each operator's own documentation, what each one does, and whether it honors robots.txt. For the concepts behind these tokens (what robots.txt and llms.txt are, why blocking a crawler is a selection decision) see [AI crawlers, robots.txt and llms.txt for stores](/ai-crawlers-robots-llms-txt/). For the strategy of which agent engines to prioritize, see the [AI shopping platforms hub](/platforms/). Most entries below were re-fetched and verified on 2026-08-20; each claim carries its own verification date, and a handful of entries (Apple and Bing among them) still carry their 2026-07-08 dates. A few items carry 2026-09-18 dates: OpenAI's ad-safety token (OAI-AdsBot) now has its own row, a short section below the table covers how Cloudflare classifies crawler behavior, and the Perplexity section now spells out what a robots.txt block does and does not stop. Check the "Last verified" logic on [platform pages](/platforms/) for how often these are expected to move. ## The reference table Fifteen to eighteen rows can't hold every token every operator has ever shipped, so this table prioritizes shopping relevance: the crawlers that decide whether a store's pages get read, cited, or trained on by an agent a shopper might use. A few less central tokens (two of Meta's five) are covered in prose below the table instead of as rows. _AI shopping-relevant crawler tokens, verified against each operator's own documentation on 2026-08-20._ | Token | Operator | Purpose | Robots.txt-controllable | | --- | --- | --- | --- | | GPTBot | OpenAI | Trains OpenAI's generative foundation models | Yes | | OAI-SearchBot | OpenAI | Indexes pages for ChatGPT search citations | Yes | | ChatGPT-User | OpenAI | Live fetch when a ChatGPT user's request reaches a page | May not apply (user-triggered) | | OAI-AdsBot | OpenAI | Validates the safety of pages submitted as ads on ChatGPT; not used for AI training | Not stated by source | | Googlebot | Google | Standard Search, Images, Video, News, and Discover indexing | Yes | | Storebot-Google | Google | The dedicated Google Shopping crawler, across all Shopping surfaces | Yes | | Google-Extended | Google | Opt-out control for Gemini model training and grounding only | Yes (control token, no separate crawl) | | Google-Agent | Google | Powers agents on Google's own infrastructure acting on a user's request (for example, Project Mariner) | Generally no (user-triggered) | | ClaudeBot | Anthropic | Collects web content that can contribute to training | Yes | | Claude-User | Anthropic | Live fetch when someone asks Claude a question | Yes | | Claude-SearchBot | Anthropic | Improves Claude's search results; decides if Claude cites a page | Yes | | PerplexityBot | Perplexity | Surfaces and links sites in Perplexity search results | Yes | | Perplexity-User | Perplexity | Live fetch when a user asks Perplexity a question | Generally no (user-triggered) | | Amazonbot | Amazon | Improves Amazon products and services; may train Amazon AI models | Yes (site's robots.txt file cached up to 30 days) | | Amzn-SearchBot | Amazon | Improves search experiences in Amazon products; not used for AI training | Yes (falls back to other search-bot rules if unnamed) | | Amzn-User | Amazon | Supports user actions, such as Alexa queries needing live data | May not follow all directives (user-triggered) | | Meta-WebIndexer | Meta | Improves Meta AI search result quality | Not stated by source | | Meta-ExternalAgent | Meta | Trains foundation AI models and indexes content for products | Yes (up to 24-hour propagation) | | Meta-ExternalFetcher | Meta | User-requested fetch supporting agentic AI capabilities | May bypass (user-triggered) | ## OpenAI's shopping-relevant crawlers OpenAI documents GPTBot as the crawler used to train its generative foundation models, and its own guidance is explicit that disallowing GPTBot means a site's content should not be used in that training, not that the site is opting out of search visibility. That distinction matters because OpenAI splits training from surfacing across separate tokens. OAI-SearchBot is the one that indexes pages for citation, and OpenAI states plainly that a site opted out of OAI-SearchBot "will not be shown in ChatGPT search answers", which makes it the token to protect if being cited in ChatGPT search matters more than the training question. ChatGPT-User is a different kind of token entirely. ChatGPT-User is the fetch OpenAI triggers the moment an actual ChatGPT user's own request reaches a page, and because a person, not a schedule, initiated it, OpenAI notes that "robots.txt rules may not apply". A fourth, narrower token rounds out the set: OAI-AdsBot is used to validate the safety of web pages submitted as ads on ChatGPT, OpenAI states it is not used for AI training, and its IP ranges are published at openai.com/adsbot.json. The consequence is narrow but real: a merchant running ChatGPT ads has to let OAI-AdsBot reach the ad landing pages, or that safety validation fails. All four are verifiable by IP through OpenAI's published JSON files (searchbot.json, gptbot.json, chatgpt-user.json, and adsbot.json at openai.com), and OpenAI states that robots.txt changes take about 24 hours to propagate across its crawlers. ## Google's shopping-relevant crawlers Google's set is the widest of the four, and it includes the single most on-topic entry on this whole page. Googlebot is Google's standard crawler, used to build Google's search indexes across Search, Images, Video, News, and Discover, and it honors robots.txt; Shopping surfaces have their own dedicated crawler. Storebot-Google is that crawler: Google's own documentation states crawling preferences addressed to it "affect all surfaces of Google Shopping," and it honors robots.txt. If a merchant reads only one row in this reference, this is the one worth reading twice. Google-Extended gets confused with a general AI opt-out more often than any other token here, and Google's own wording draws the boundary precisely. Google-Extended does not have a separate HTTP request user agent string of its own; it is a robots.txt-only control token for managing whether content Google crawls may be used for training future generations of the Gemini models that power Gemini Apps and the Vertex AI API for Gemini, and for grounding, and Google states it "does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search". What Google's text does not say is equally important: it scopes Google-Extended to Gemini-model training and grounding specifically, not to AI Mode inclusion, so a merchant should not treat toggling it as a lever over AI Mode results. Google has also added a separate agent-building token: Google now documents a distinct Google-CloudVertexBot token "for building Vertex AI Agents," alongside GoogleOther, a generic crawler its product teams may use for fetching publicly accessible content; neither carries direct shopping weight, but both belong in a complete robots.txt audit. Google-Agent is the newest addition, introduced by Google's own account around March 2026. Google-Agent is used by agents hosted on Google's own infrastructure to navigate the web and perform actions on a user's request, and Google names Project Mariner as an example. Google groups Google-Agent among its user-triggered fetchers, the category of crawlers that generally does not honor robots.txt because a specific user request triggered the fetch. Verifying that a request claiming this identity is genuine now has documented paths: Google publishes IP ranges for these fetchers in JSON files (user-triggered-fetchers.json, user-triggered-fetchers-google.json, and user-triggered-agents.json), documents reverse-DNS masks of the form *.gae.googleusercontent.com and google-proxy-*.google.com, and states it is experimenting with the Web Bot Auth protocol using the https://agent.bot.goog identity, an early move toward cryptographic agent verification rather than spoofable user-agent strings. Project Mariner has been described elsewhere as capable of multi-step shopping and product-comparison tasks, and it is reasonable to expect Google-Agent traffic to include that kind of browsing, but this is our inference: Google's own token description does not use the word "shopping," so do not treat that specific link as confirmed by the primary source. ## Anthropic's (Claude) shopping-relevant crawlers Anthropic documents three bots on a single support page, and the split maps directly onto the training-versus-surfacing pattern seen at OpenAI. ClaudeBot collects web content that can contribute to model training, and it honors robots.txt. Claude-User is the live fetch behind an actual conversation: Anthropic states that "when individuals ask questions to Claude, it may access websites using a Claude-User agent," and this token also honors robots.txt. Claude-SearchBot is the one that decides whether Claude cites a page at all. Anthropic describes Claude-SearchBot as a crawler that "navigates the web to improve search result quality for users," and it warns that blocking it "prevents our system from indexing your content for search optimization". Two smaller notes worth carrying into a robots.txt audit: Anthropic's current documentation makes no mention of the older `anthropic-ai` token some third-party lists still carry, and Anthropic supports the non-standard `Crawl-delay` directive alongside IP verification at claude.com/crawling/bots.json. ## Perplexity's shopping-relevant crawlers PerplexityBot is described as "designed to surface and link websites in search results on Perplexity," is not used to crawl content for AI foundation models, and honors robots.txt; Perplexity's own guidance recommends allowing it. Perplexity-User "supports user actions within Perplexity," visiting a page when a user's own question requires it, and Perplexity states that this fetcher "generally ignores robots.txt rules" because the fetch follows a specific user request. Both are IP-verifiable through published JSON files at perplexity.com (perplexitybot.json and perplexity-user.json), and their user-agent strings carry version suffixes, currently PerplexityBot/1.0 and Perplexity-User/1.0. Because robots.txt controls PerplexityBot but Perplexity-User "generally ignores" it, a robots.txt block stops Perplexity from indexing a store without stopping it from fetching that store's pages when a shopper's question points there. Robots.txt governs crawling, not user-triggered retrieval, so on this engine it is the wrong tool for the second job. Perplexity's help center also states that a prior feature letting users prompt it to summarize robots.txt-blocked URLs anyway "has been disabled to prevent misuse," a dated clarification of how strictly Perplexity now enforces the block. ## Amazon's crawlers Amazon documents three bots, not one, each with a distinct job, all covered by one general robots.txt policy. Amazon's crawlers honor the Robots Exclusion Protocol, and Amazon may rely on a cached copy of a site's robots.txt file up to 30 days old if a fresh fetch fails; the non-standard crawl-delay directive is listed as unsupported. Amazonbot is used to improve Amazon's products and services and may be used to train Amazon AI models. Amzn-SearchBot is used to improve search experiences in Amazon's products and services, making crawled content eligible to appear in search experiences such as Alexa, and Amazon states it "does not crawl content for generative AI model training"; it carries one additional fallback rule beyond the general policy, that if a robots.txt file does not name it explicitly, it follows whatever rules apply to Amazon's other search bots. Amzn-User supports user actions, such as responding to Alexa queries that require up-to-date information, does not crawl for AI training, and, because its requests are user-initiated, Amazon states it may not follow all robots.txt directives. Third-party analysis (for example, dejan.ai) has linked Amzn-SearchBot to Rufus, Amazon's shopping assistant, but the word "Rufus" does not appear anywhere on Amazon's own documentation page. Treat that specific link as third-party speculation, not a fact confirmed by the primary source. Amazon's crawlers also honor page-level `noarchive` (exclude from AI training), `noindex`/`none`, and `rel=nofollow` directives. ## Meta's crawlers Meta documents five bots, and only three carry enough shopping relevance for the table above. Meta-WebIndexer "navigates the web to improve Meta AI search result quality for users". Meta-ExternalAgent "crawls the web for use cases such as training foundation AI models or improving products," and it respects robots.txt with up to 24-hour propagation. Meta-ExternalFetcher "fetches individual links at a user's request and supports product functions such as evaluating and improving agentic AI capabilities," and Meta states it "may bypass robots.txt because it performs fetches that were requested by the user". The other two are good to know about, if not full-row material. facebookexternalhit generates link previews when content is shared inside Meta's apps, and Meta-ExternalAds "crawls the web for use cases such as improving advertising and other business-related products". Meta's documentation names no shopping-specific crawler token: Facebook and Instagram Shops and Meta AI's shopping features are not tied to a distinct token in this source, a confirmed null result rather than a gap in our research. ## Apple and DuckDuckGo, briefly Two more operators publish a documented crawler relevant to AI answers, though neither carries enough shopping-specific weight for a full table row. Applebot powers Siri, Spotlight, and Safari search, honors robots.txt, and Apple states that "if robots instructions don't mention Applebot but mention Googlebot, the Apple robot will follow Googlebot instructions". Applebot-Extended is a training-opt-out-only token with no separate HTTP user agent of its own; Apple states it does not crawl webpages, and is only used to determine how to use the data Applebot already crawled, so pages that disallow it can still appear in Spotlight, Siri, and Safari search. DuckAssistBot "crawls pages in real-time for our AI-assisted answers, which prominently cite their sources," is not used for AI training, and an opt-out via robots.txt takes about 72 hours to apply. > **There is no Copilot-specific crawler** > > Microsoft is named in this site's own mission, and the honest answer here is a null result, best stated outright. Bing's own webmaster documentation lists only bingbot, adidxbot, BingPreview, MicrosoftPreview, and BingVideoPreview among its crawlers. Microsoft's Copilot Studio guidance for generative AI on public websites likewise names no distinct Copilot crawler. Copilot's shopping-relevant answers run on Bing's existing index through bingbot; there is no separate token to allow or block specifically for Copilot. Some third-party lists cite a "CopilotBot," but no Microsoft-owned source names one, so treat that token as unconfirmed rather than real. ## How Cloudflare classifies crawler behavior Plenty of stores never edit a raw robots.txt; their CDN decides what a bot may do. Cloudflare sorts bots by behavior rather than by operator, into eleven classes, and one of them names this reference's subject directly. Cloudflare classifies bot behavior into Search, Agent, Training, Transact, Data Collection, Security Testing, SEO, Ads Verification, Social / Link Preview, Feed Fetching, and Monitoring & Operations, and it defines the Transact class as "Checkout actions on behalf of users." Transact is agentic commerce in one word: a bot completing a purchase for a shopper. If your CDN can isolate that behavior, it can also block the precise step an agentic checkout depends on, so find out where your platform files it before a rule you did not write turns buyers away. Verification shifted at the same time, which matters on a page that documents how to verify each engine's bots. Cloudflare stated that "non-verified bots are still default blocked, but we are no longer viewing Verified as 'default allowed.' Now, the Verified label makes a bot allowable with its relevant category." A Verified label no longer means allowed outright; it means allowable within whatever category you have permitted, so an allow-list built on the older assumption needs a fresh look. One term is worth striking from your notes. There is no distinct "Verified AI Agent" category at Cloudflare. Bots are classified by behavior, not by a standalone verified-agent label, so any secondary source that uses that phrase is describing something Cloudflare does not publish. ## Confirmed absent: tokens that do not exist A negative finding, stated plainly, is worth more than a guess: it stops someone else from fabricating a token. Four are worth recording here. - **Rakuten.** No documented, distinct AI-shopping crawler token exists anywhere in Rakuten's own materials. - **Walmart.** No documented, distinct crawler token for Walmart's AI shopping features exists anywhere in Walmart's own materials. - **TikTok Shop.** No official ByteDance or TikTok developer documentation for any crawler exists. The widely reported `Bytespider` token is sourced only to third parties (for example, Cloudflare Radar and DataDome), never to a ByteDance-owned page, so treat any `Bytespider`-to-training-data claim as unconfirmed. TikTok's own robots.txt currently blocks a long list of AI bots by name, which is itself the one verifiable, on-the-record fact in this space. - **Amazon's "Rufus" as a distinct token.** As covered above, no crawler named for Rufus exists; Amazon's own documentation never uses the name. ## Two robots.txt snippets Standard `User-agent` / `Allow` / `Disallow` syntax, no vendor-specific extensions beyond Anthropic's optional `Crawl-delay`. Adjust to your own catalog and legal posture before shipping either. **A permissive allow-list**, letting every documented, shopping-relevant bot in this reference read the site: ``` User-agent: * Allow: / User-agent: GPTBot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: OAI-AdsBot Allow: / User-agent: Googlebot Allow: / User-agent: Storebot-Google Allow: / User-agent: Google-Extended Allow: / User-agent: Google-Agent Allow: / User-agent: ClaudeBot Allow: / User-agent: Claude-User Allow: / User-agent: Claude-SearchBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / User-agent: Amazonbot Allow: / User-agent: Amzn-SearchBot Allow: / User-agent: Amzn-User Allow: / User-agent: Meta-WebIndexer Allow: / User-agent: Meta-ExternalAgent Allow: / User-agent: Meta-ExternalFetcher Allow: / User-agent: Applebot Allow: / User-agent: Applebot-Extended Allow: / User-agent: DuckAssistBot Allow: / ``` **A training-data-only block**, keeping every search, citation, and user-fetch bot open while closing only the tokens each operator documents as training crawlers: ``` User-agent: * Allow: / # Training crawlers: closed User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Amazonbot Disallow: / User-agent: Meta-ExternalAgent Disallow: / User-agent: Google-Extended Disallow: / User-agent: Applebot-Extended Disallow: / # Search, citation, and live user-fetch bots: left open User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: Googlebot Allow: / User-agent: Storebot-Google Allow: / User-agent: Claude-User Allow: / User-agent: Claude-SearchBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / User-agent: Amzn-SearchBot Allow: / User-agent: Amzn-User Allow: / User-agent: Meta-WebIndexer Allow: / User-agent: Meta-ExternalFetcher Allow: / User-agent: Applebot Allow: / User-agent: DuckAssistBot Allow: / ``` ## Key takeaways - Storebot-Google, OAI-SearchBot, Claude-SearchBot, and PerplexityBot are the four tokens that most directly decide whether a store gets surfaced or cited; treat them as the ones to protect first. - GPTBot, ClaudeBot, Amazonbot, Meta-ExternalAgent, Google-Extended, and Applebot-Extended are training-scoped opt-outs a merchant can close without losing surfacing or citation. - User-triggered fetchers (ChatGPT-User, Perplexity-User, Google-Agent, Meta-ExternalFetcher) generally are not bound by robots.txt because a real person's request triggered the fetch, so blocking them rarely works as intended. - No primary source documents a Copilot-specific crawler, a Rakuten or Walmart AI-shopping crawler, or a token literally named for Amazon's Rufus. Treat any claim to the contrary as unverified until an operator publishes one. - This is a reference snapshot: most entries were re-verified on 2026-08-20, and each claim carries its own verification date (a few, the Apple and Bing entries among them, date from 2026-07-08). Crawler rosters change: recheck the primary sources linked throughout before copying a robots.txt block verbatim into production. --- # Open Questions in Agent Selection https://agentmint.net/reference/open-questions/ This is a register of the questions about agent selection we have not yet answered. Each entry states why the question matters, the evidence we already have, the evidence we are still missing, and a status: open, being investigated, or answered. A question lands here before anyone tries to answer it, so the gap is on the record rather than quietly filled in later. Where a question is already answered, we link the page that answers it. --- # Start Here: The 30-Minute Agent Selection Triage https://agentmint.net/start/ ## Key takeaways - Agent selection is not SEO: agents score structured product data, not brand recall, so the fix looks different from ranking a page. - Two checklists answer two different questions. Readiness asks whether an agent can find and transact with your store at all. Selection asks whether you win once you are eligible. - Have not shipped a protocol yet? Start with the readiness checklist. Shipped one and still not chosen? Skip straight to the selection checklist. - Three reading paths below take you through 4 to 5 pages in order, matched to your situation, in under 30 minutes. - The glossary and the open-questions register are there for depth once you know what to look up next. ## What "agent selection" means here (and why it is not SEO) An AI shopping agent, whether it is ChatGPT, Google's AI Mode and Gemini, Perplexity, Copilot, or Claude, does not scan a results page the way a person does. It reads your product data and returns one pick or a short list, and the choice it makes is what this site calls [agent selection](/glossary/#agent-selection). That is a different job from ranking a page for a human to click, and the full argument for why lives in [How AI Shopping Agents Choose Products](/how-ai-agents-choose-products/) and the flagship [Agentic Commerce Optimization](/agentic-commerce-optimization/) guide. This page skips that argument and gets you to the right next page for where you actually are. ## Which checklist do you need first? Two checklists on this site answer two different questions, and starting with the wrong one wastes the 30 minutes you have. - **You have not implemented ACP, UCP, or any agentic protocol yet.** Start with the [Agentic Shopping Readiness Checklist](/tools/agentic-readiness-checklist/). It checks whether an agent can find, parse, and transact with your store at all: the eligibility layer. - **You have shipped a protocol and agents still are not choosing you.** Go straight to the [Agent Selection Checklist](/tools/agent-selection-checklist/). Eligibility is not your problem, so this checks the signals that decide who actually wins. - **You are not sure which bucket you are in.** Read [How AI Shopping Agents Choose Products](/how-ai-agents-choose-products/) first. It draws the eligibility-versus-selection line in about five minutes, and you will know which checklist to run by the end. Prefer to have a coding agent run the audit for you? Each checklist ships a copyable prompt that points your agent at the checklist and has it audit your store item by item. See [running AgentMint with your coding agent](/tools/coding-agent-workflow/). ## Route by role The reading paths below cover situations; if you route better by job, start from your role instead. Each role pairs the checklist to run first with the pages that match the work you own. - **Store owner or e-commerce manager.** Run the [readiness checklist](/tools/agentic-readiness-checklist/) first, then follow the "I have not touched any agentic protocol yet" path below. You own the decisions an agent ends up reading (protocol choice, returns policy, delivery promises), so skim [how agents choose](/how-ai-agents-choose-products/) before delegating the technical items. - **Developer.** Go straight to the [blueprints](/blueprints/) (llms.txt, product JSON-LD, markdown mirrors, edge config) and the two implementation chapters: [serving agent traffic](/handbook/serving-agent-traffic/) and [information density](/handbook/information-density/). Or skip the reading and [hand the audit to your coding agent](/tools/coding-agent-workflow/). - **SEO or feed lead.** Your surface is the catalog: [make your product feed AI-readable](/make-product-feed-ai-readable/), [product schema for AI shopping](/product-schema-for-ai-shopping/), and [product titles agents match](/product-titles-for-ai-agents/), then the [selection checklist](/tools/agent-selection-checklist/) to score the gaps. - **Agency.** The [platform playbooks](/platforms/) show where ChatGPT, Gemini, and Perplexity diverge; the two checklists double as a client-audit instrument (each ships an audit-only coding-agent prompt), and the [Signals Database](/signals/) is the evidence layer behind every recommendation you hand a client. One rule of thumb holds across roles: readiness before selection. Nothing in the selection layer pays off while an agent cannot fetch, parse, or transact with the store in the first place. ## Three reading paths for your first 30 minutes Pick the path that matches your situation. Each one is 4 to 5 pages, in the order we would read them. ### I have not touched any agentic protocol yet 1. [Agentic Commerce Optimization: The Complete Guide](/agentic-commerce-optimization/), for the full landscape before you touch anything. 2. [How AI Shopping Agents Choose Products](/how-ai-agents-choose-products/), for what an agent actually scores once it can see you. 3. [AI Crawlers, robots.txt & llms.txt for Stores](/ai-crawlers-robots-llms-txt/), to confirm agents can reach your pages at all. 4. [Agentic Shopping Readiness Checklist](/tools/agentic-readiness-checklist/), the self-audit for where you stand today. 5. [UCP vs ACP: Which Gets You Selected](/ucp-vs-acp/), once you pass the readiness checklist, for which protocol to ship next. ### I have shipped ACP or UCP but agents still are not picking me 1. [How AI Shopping Agents Choose Products](/how-ai-agents-choose-products/), for why shipping a protocol gets you eligible, not chosen. 2. The three content levers that measurably moved selection in the strongest evidence available: [Make Your Product Feed AI-Readable](/make-product-feed-ai-readable/), [Product Schema (JSON-LD) for AI Shopping](/product-schema-for-ai-shopping/), and [Product Titles That AI Agents Match](/product-titles-for-ai-agents/). 3. [AI Shopping Platforms: How to Get Selected Across Engines](/platforms/), to see where ChatGPT, Gemini, and Perplexity actually diverge before you optimize further. 4. [Agent Selection Checklist](/tools/agent-selection-checklist/), the flagship self-audit for the signals no validator checks. 5. [Why You're Not in ChatGPT Shopping](/store-not-in-chatgpt-shopping/), if ChatGPT specifically is the gap. ### I just want to understand the landscape first 1. [Agentic Commerce Optimization: The Complete Guide](/agentic-commerce-optimization/), the flagship pillar, start to finish. 2. [UCP vs ACP: Which Gets You Selected](/ucp-vs-acp/), the protocol landscape: what each open standard actually governs. 3. [Agentic Payment Protocols, Explained](/agentic-payment-protocols/), the payment rails sitting under the protocols. 4. [AI Shopping Platforms: How to Get Selected Across Engines](/platforms/), engine by engine, where ChatGPT, Gemini, and Perplexity currently diverge. 5. [Agentic Commerce Glossary](/glossary/), the terms, defined and sourced, as you go. ## Where to go deeper later Once you have run a checklist and read your path, two places hold the rest of the site. - **[Agentic Commerce Glossary](/glossary/)**: every term on this site defined once, sourced, and evidence-typed, including [agent selection](/glossary/#agent-selection) and [agent win rate](/glossary/agent-win-rate/), the metric we propose for tracking whether the work above is paying off. - **[How to test agent selection](/handbook/how-to-test-agent-selection/)**: the protocol for measuring your own agent win rate, with the sampling and error bars that keep the answer honest. > **Agent behavior moves** > > Every page on this site types and dates its claims about how agents behave, because a model update can change what an agent rewards. Treat the reading paths above as a map of where to look, not a fixed formula, and expect to check back after a major model release. You do not need the whole site today. Run the right checklist, follow one path, and come back for the rest when you need it. --- # Agentic Commerce Timeline https://agentmint.net/timeline/ This is a sourced chronology of the agentic-commerce events that shape how AI shopping agents select stores, products, and offers: protocol launches, market shifts, and the research we cite across this handbook. Each entry is typed by evidence, sits under the year it happened, and links its primary source. The list runs newest first; it is not exhaustive, and it grows as verified events land. For the running log of smaller changes to this site and to how agents choose, see the [updates log](/updates/). --- # Run AgentMint With Your Coding Agent https://agentmint.net/tools/coding-agent-workflow/ Most of this site is written to be read. This page is about the other way to use it: hand a page to your coding agent and let it do the work. Applicable pages carry a "Run this with your coding agent" block with a ready-to-paste prompt. The prompt points your agent at the page's Markdown mirror and tells it to audit your store, or to implement against a blueprint, item by item. ## Key takeaways - Every checklist, blueprint, and implementation chapter ships a copyable prompt that works with any coding agent that can fetch a URL. - Run the audit-only prompt first. It reports against every item and changes nothing, so you see the picture before you decide. - The agent audits and implements, but it never invents your product data, and the judgment calls stay yours. Review everything before you ship. ## What the Markdown mirrors are Every page here has a plain-text twin at the same path with a `.md` on the end. The Agent Selection Checklist lives at `/tools/agent-selection-checklist/`, and its mirror lives at `/tools/agent-selection-checklist.md`. The mirror carries the same facts as the page, laid out for a machine to read: each item's statement, its stable ID, its evidence type and source, and the prompt itself. A coding agent reads the mirror instead of scraping the rendered page. That is why the prompt starts by telling your agent to fetch the mirror: it gets the full, structured checklist in one request, IDs and all, with none of the page furniture in the way. ## The three steps 1. **Open the page** for the checklist, blueprint, or chapter you want to act on. 2. **Copy the prompt** from its "Run this with your coding agent" block. On the checklists there are two prompts side by side; start with the audit-only one. 3. **Paste it into your coding agent** in the repository for your store, and let it work. The prompt handles the rest: it fetches the mirror, detects your platform, works through the items, and reports back. Any coding agent that can fetch a URL works, whether that is Cursor or a terminal-based agent. If yours cannot fetch URLs, the prompt says so and asks you to paste the document in. ## What a good audit report looks like The audit-only prompt produces a report keyed to the checklist's item IDs, with each item marked pass, fail, needs human decision, or not applicable. A good report quotes its evidence and stops rather than guessing. > **Illustrative example, not measured data** > > The report below is the shape you should expect for a hypothetical store. The verdicts are invented to show the format; they are not findings about any real store. ```text Platform detected: WooCommerce. a-bot-access-01: pass. Your robots.txt allows OAI-SearchBot, Claude-SearchBot, and PerplexityBot, with no blanket AI-crawler block. a-structured-data-01: fail. Your Product JSON-LD carries no price; the price is only written into the page after client-side JavaScript runs, so an agent reading the markup sees no offer. Fix: emit price and priceCurrency (ISO 4217) in the server-rendered JSON-LD. a-checkout-ops-02: needs human decision. I cannot tell from the code how fresh your inventory really is; that depends on your fulfillment process, not the code. Tell me your real restock and sync cadence and I will judge it against what agents expect. I did not guess a number. Summary: of the items that apply to your store, 1 passed, 1 failed (price is JavaScript-only), and 1 needs a decision only you can make. Several items that assume an agentic-checkout protocol were marked not applicable, because you have not installed one yet. Nothing was changed; this was an audit-only run. ``` Notice what the report does not do. It does not invent a GTIN, a price, or an inventory cadence to make an item pass. Where the data is missing or the call is yours, it says so and stops. That restraint is written into every prompt on the site, and it is the difference between a report you can trust and a report that quietly makes things up. ## What the agent will and will not do The agent reads your code and configuration, checks them against the document, and (in the audit-and-fix and implement prompts) makes small, reviewable changes once you approve them. It stops and asks before anything destructive or anything that touches customer-facing copy, prices, or checkout. What it will not do is decide your business. It will not fabricate ratings or review counts, invent GTINs or other identifiers, or guess delivery windows, prices, or return terms. Where a piece of data is missing, it lists exactly what you need to supply. The audit and the implementation are the agent's job; the judgment calls and the real business data stay yours. Review everything it changes before you ship it, because it is your store. ## Where to start Pick the surface that matches what you want to do: - [The Agentic Shopping Readiness Checklist](/tools/agentic-readiness-checklist/) if you want to know whether agents can find, read, and buy from your store at all. - [The Agent Selection Checklist](/tools/agent-selection-checklist/) if you are already eligible and want to know why agents are not choosing you. - [The blueprints](/blueprints/) if you want the agent to implement a specific machine surface, such as a token-efficient product feed or an edge-cache config. - [The AI shopping crawler reference](/reference/ai-shopping-crawlers/) if you want to check which crawlers can reach your store. New to the whole topic? [Start Here](/start/) is the 30-minute triage that points you at the right checklist first. --- # UCP vs ACP: Which Gets You Selected https://agentmint.net/ucp-vs-acp/ ## Key takeaways - UCP and ACP are not two options you pick between: they are the commerce rails for two different agent ecosystems, so the real question is coverage, not which protocol 'wins'. - ACP (OpenAI + Stripe, September 2025) is checkout-focused and carries ChatGPT shopping, though OpenAI scaled the in-chat Instant Checkout experience back in March 2026 in favor of merchant-site checkout; UCP (Google, NRF, January 2026) spans discovery, checkout, and post-purchase. - UCP is confirmed as the rail reaching Gemini and Google AI Mode: Google's own developer documentation states that adopting UCP enables agentic actions on both surfaces, starting with direct buying. - UCP is no longer just Google's: the specification is governed by a multi-stakeholder consortium whose technical committee includes Amazon, Meta, and Microsoft, and it now ships breaking, dated-tag releases (current: v2026-08-25). Google still runs the Gemini and AI Mode implementation you optimize for, so treat the spec as shared but the surface as Google's. - Neither rail is single-engine anymore: Microsoft Copilot runs Copilot Checkout on ACP through Stripe and reads UCP-ready Merchant Center feeds, and PayPal announced in October 2025 that it would join Stripe as an ACP payment provider. - Both already model fulfillment: ACP has carried shipping options since launch and now exposes pickup, delivery windows, and return-policy fields (though returns processing stays with the merchant of record); UCP's post-purchase order tracking and returns support is on Google's roadmap, not yet shipped. - Neither protocol decides which product an agent picks. Passing either is eligibility, not selection, so implementing both only makes you transactable to more agents. Winning the pick is the separate work this handbook covers. ## The one-line difference Read the two protocols by the ecosystem each serves, not as rivals competing for your integration budget. The Agentic Commerce Protocol (ACP), an open standard from OpenAI and Stripe announced on 29 September 2025, is a checkout standard (agent-ready checkout plus a product feed and delegated payment) and it launched as the rail behind ChatGPT's Instant Checkout. The payment side of ACP widened beyond Stripe: PayPal announced on 28 October 2025 that it would adopt ACP and support payments processing for merchants using Instant Checkout in ChatGPT. The in-chat purchase itself did not last in that form: by March 2026, reporting described OpenAI scaling back the in-chat checkout experience and routing transactions through merchant sites and apps instead, and OpenAI's own merchant page now states the shift plainly: OpenAI says it is moving away from a standalone Instant Checkout experience in ChatGPT and prioritizing shopping discovery and merchant-owned checkout, so users discover and evaluate products in ChatGPT while purchases complete on the merchant's own website or app. The Universal Commerce Protocol (UCP), Google's open standard announced at NRF 2026 on 11 January 2026, is scoped more broadly: Google describes it as "open, agnostic", built to keep the customer relationship front and center "from the moments of discovery to decision and beyond", and says it is starting with native checkout. Neither protocol claims to decide which product an agent presents. Both standardize how a transaction is carried out, which leaves selection as the merchant's problem on either rail. Two name traps worth clearing first. It is the Universal *Commerce* Protocol, and "Universal Cart" is a separate term that now points at two different things: Shopify ships a Universal Cart API for agents, and Google uses "Universal cart" for its own consumer cart product, so the name alone does not tell you which system someone means. Second, it is the Agent *Payments* Protocol (AP2), plural, in the payment layer below both. See [ACP](/glossary/#acp) and [UCP](/glossary/#ucp) in the glossary for the two-sentence anchors. The rest of this page is the practitioner's version of the difference: what each covers, which engine each reaches, and why the answer for most catalogs is "both." ## UCP is a consortium now, not only Google The mental model that pairs UCP with Google the way ACP pairs with OpenAI has gone stale, and that changes how you should weigh the bet. UCP is governed through a formal multi-stakeholder structure, a Governing Council plus a Technical Committee plus per-vertical Technical Councils; Stripe joined the Governing Council on 28 April 2026 alongside Google and Shopify, the Technical Committee expanded to 16 seats on 24 April 2026 to add Amazon, Meta, Microsoft, Stripe, and Salesforce, and vertical councils have formed for Payments on 2 September 2026 (Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, Stripe), Lodging on 11 August 2026 (Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, Trip.com), and Food on 16 July 2026 (Block/Square, DoorDash, Google, Toast, Uber Eats). Hold two facts at once. A technical committee that includes Amazon, Meta, and Microsoft is not one company's roadmap, so UCP is less exposed to a single vendor's priorities than the "Google's rail" shorthand implies. It is not vendor-neutral in practice either: Google runs the AI Mode and Gemini implementation of UCP, the surface where adopting the protocol enables agentic actions starting with direct buying. The specification is shared; the surface you actually get selected on is still Google's. For a merchant that means you can adopt UCP without betting your catalog on one company's product direction, while still treating Google's Merchant Center requirements as the gate that decides whether the integration does anything. ## The two protocols at a glance Every date, scope, and reach line in this table is sourced in the dimension-by-dimension detail below: the table is the scannable summary, the prose carries the citations. _ACP vs UCP: a decision-level summary. Each cell is sourced in the sections that follow._ | Dimension | ACP: Agentic Commerce Protocol | UCP: Universal Commerce Protocol | | --- | --- | --- | | Backed by | OpenAI + Stripe (PayPal adoption announced October 2025) | Google runs the Gemini / AI Mode implementation; spec governed by a multi-stakeholder consortium (Governing Council + Technical Committee incl. Amazon, Meta, Microsoft, Stripe, Salesforce) | | Announced | 29 September 2025 | 11 January 2026 (NRF 2026) | | Scope | Checkout: agent-ready checkout + product feed + delegated payment | Discovery → checkout → post-purchase (post-purchase is roadmap, not yet shipped) | | Fulfillment options | Modeled since launch; pickup, local delivery, delivery windows and return-policy fields added since | Cart (multi-item), Catalog (real-time variants/inventory/pricing), and Identity Linking announced March 2026 as rolling out; pickup and delivery-window field depth not independently confirmed | | Returns processing | Return-policy fields shipped since launch; RMA processing stays with the merchant of record | Roadmap only: order tracking and returns are planned, not yet shipped | | Agent engine reached | ChatGPT: discovery via ACP product feeds, checkout on merchant sites since March 2026; Microsoft Copilot: Copilot Checkout (confirmed) | Gemini / Google AI Mode (confirmed); Microsoft Merchant Center UCP feeds, US (confirmed) | ## Current spec versions, and what not to build against Both specs move, and they move differently, so "which version" is a real question before "which fields." UCP's 25 August 2026 release adds grocery capabilities (location search and lookup, standardized operating hours, fulfillment location context, and fractional quantities with sale-basis pricing steps), vendor-agnostic 3DS2 authentication via Actions, and reorganizes the spec into shopping, payment, and common verticals. Some of those changes break an existing integration rather than extend it. The fulfillment schema was restructured (the `allows_` prefixes were dropped, `fulfillment_option.description` became a structured object, and `multi_destination` changed from a map to an array), buyer consent moved from fixed booleans to a dynamic reverse-DNS-keyed map, `signing_keys[]` was replaced by a single `keys[]` JWK Set, and payment namespaces migrated from `dev.ucp.shopping.*` to `dev.ucp.common.payment.*`. If you integrated against an earlier build, each of those is a migration line item, not a free upgrade. Version references have to be specific because of how UCP numbers releases. UCP tags releases by date rather than semver, with recent tags running v2026-08-25, v2026-04-08, v2026-01-23, and v2026-01-11. Pin your integration to a dated tag, and treat the appearance of a newer tag as a review task rather than something to auto-adopt. One scope caution: this release reshaped how fulfillment is described, but it did not confirm post-purchase returns as a shipped capability, so the roadmap caveat in the sections below still holds. ACP is on the opposite rhythm. ACP's latest dated released version is still 2026-04-17, unchanged since then. Its repository does stage direction, and staged work is easy to mistake for the spec. The ACP repository stages unreleased work including a suggested-pricing feature, a feed-update-id, an upsert-products response schema, a product-url field on checkout items, and intent-traces examples. None of that is current spec. Do not build against it or present it to your team as a requirement; the released 2026-04-17 version is what an agent transacts on today. ## Scope compared: discovery, checkout, post-purchase The cleanest way to hold the two apart is by how much of the shopping journey each one standardizes. ACP concentrates on the transaction. ACP's job is programmatic checkout (turning an agent's intent into a completed purchase through an agent-ready checkout, a product feed, and a delegated payment token), not organizing the discovery step that precedes it. The spec still says that; what has shifted is which half of it ChatGPT deploys in production. OpenAI's merchant documentation states that ACP today supports product discovery and personalized recommendations through shared product data, and that over time it will expand to support the full shopping journey with deeper integrations and APIs. UCP draws a wider box, though not all of it is live yet. Google frames UCP as spanning the customer relationship "from the moments of discovery to decision and beyond" as a single abstraction, starting with native checkout, but Google's own UCP developer guide lists post-purchase order tracking and returns as an upcoming feature on its roadmap, not a capability shipped today. On that specific piece, ACP is currently ahead: it already ships return-policy fields, while UCP's order-management and returns scope remains a stated direction rather than a working capability. The rest of the UCP roadmap has started to move, in announced stages. In March 2026 Google announced a Cart option letting agents save or add multiple items to a cart from a single store, a Catalog capability for agents to retrieve real-time product details such as variants, inventory, and pricing, Identity Linking so shoppers keep loyalty and member benefits, and a simplified UCP onboarding flow in Merchant Center, rolling out over the coming months. Geography is widening on the same announced-not-assumed basis: at Google Marketing Live in May 2026, Google said UCP-powered checkout would roll out across Canada and Australia in the coming months and later to the UK, with Google Pay checkout available at retailers including Nike, Sephora, Target, and Walmart. Treat both as rollout plans dated to their announcements, not availability you can bank on today; post-purchase tracking and returns stay on the roadmap either way. This is a comparison of *where you get selected*, not an implementation guide: the field-by-field mechanics are the official docs' turf, and we link out to them below rather than reproduce them. For a practitioner, the scope difference boils down to what each rail takes for granted: a checkout-only rail assumes an agent has already decided to buy from you and just needs to complete the purchase; a discovery-through-post-purchase rail is trying to own more of the loop. Neither, crucially, ranks your products for you. Both are silent on which product an agent should choose, and that silence is the layer this handbook exists to help you win. ## Which engine each protocol reaches For a merchant, scope matters less than reach: a protocol is only worth your time if it carries you to an agent your buyers actually use. Both mappings are confirmed by primary sources. ACP is confirmed on the OpenAI side, though what riding it buys you has changed shape. ACP launched on 29 September 2025 as the rail behind ChatGPT's Instant Checkout, OpenAI scaled that in-chat checkout back by March 2026, routing transactions through merchant sites and apps instead, and OpenAI's merchant documentation now frames ChatGPT shopping as discovery-first: merchants share ACP product feeds so their products appear and stay accurate in results, and customers complete purchases on the merchant's own website or app. ACP-readiness is still how ChatGPT reads your catalog; the purchase itself now lands on your site. UCP is confirmed on the Google side. Google states that adopting UCP enables agentic actions on AI Mode in Google Search and Gemini, starting with direct buying. A third engine now sits on both rails at once. Stripe states that Microsoft's Copilot Checkout, launched 8 January 2026, runs on the Agentic Commerce Protocol, with a Shared Payment Token issued to the merchant, who remains the seller of record. On the feed side, Microsoft announced on 21 April 2026 that UCP-ready feeds in Microsoft Merchant Center were generally available to everyone in the US, with Copilot Checkout expanded to more than 500,000 merchants. And on the discovery side, Shopify lists Microsoft Copilot among the channels its UCP-backed Catalog reaches. Read together, these point to discovery and payment traveling different rails: the most consistent reading is that Copilot is reached for discovery through UCP-backed feeds while its checkout completes over ACP, so one engine sits on both rails and a single integration effort can count on each rather than committing you to one camp. The per-engine playbooks live at [ChatGPT shopping optimization](/chatgpt-shopping-optimization/) and [Gemini and Google AI Mode ranking](/gemini-shopping-ranking/), and the shared cross-engine view (including the Copilot rail detail) is on the [AI shopping platforms hub](/platforms/). ## Fulfillment and returns: what is actually in scope A common but wrong belief is that these protocols stop at "add to cart and pay" and ignore delivery and returns. That was never true of ACP, and it is worth correcting because it changes what you can promise an agent. ACP's checkout schema has modeled shipping and fulfillment options since its launch spec, and by the 2026-01-30 spec version also exposes pickup, local delivery, delivery windows, and return-policy fields. There is a real limit, though, and it sits at returns. Under ACP, end-to-end returns and RMA processing remain the merchant of record's responsibility: the protocol exposes return-*policy* fields, not a returns pipeline you can hand off. UCP looks structural at first glance, but the returns piece specifically is not live yet. Google's UCP developer guide places post-purchase order tracking and returns under its roadmap of upcoming features, not among what UCP ships today. On this specific dimension, ACP is currently ahead of UCP: its return-policy fields are already shipped, while UCP's returns and order-management scope remains a stated future direction rather than a working capability. > **Why this nuance matters for selection** > > If an agent can see a clear return policy and delivery window, it has more of the structured signal it scores when it decides which offer to surface. That is why fulfillment completeness is a selection lever, not just an operations detail. The more of your terms are legible in-protocol, the fewer reasons an agent has to skip you. ## Why most merchants implement both The two rails grew up serving *different* engines, so the protocols never competed for one audience the way rival standards usually do, and Copilot consuming both only sharpens that. The practical implication is that ACP and UCP reach additive agent audiences (ChatGPT on one side, the Google surfaces on the other, with Microsoft Copilot drawing on both rails), so for most catalogs the return-maximizing move is to be legible to both rather than to bet a single integration on one ecosystem. This is our reasoning from the reach mapping above, not a measured result; the magnitude of the gain depends on where your buyers actually shop, which is a thing to measure rather than assume. The load-bearing caveat is the one from the takeaways: implementing either protocol is an *eligibility* step. It makes you transactable inside that ecosystem. It does not make an agent choose you over a competitor who is equally transactable. Doing both simply widens the set of agents that *can* pick you; the [ACO guide](/agentic-commerce-optimization/) and the platform pages are about making them actually *do* it. ## What a small store should do first Most stores should do both, as the section above argues. But a small team rarely has the capacity to stand up two integrations at once, so the honest question becomes not "which protocol" but "which one first." An early practitioner-facing framing from No Hacks argues that for a small merchant the choice is largely upstream of the spec: it comes down to which commerce platform you run (your platform carries the protocol coverage) and how clean your product data is, more than an ACP-vs-UCP spec decision. That reframing helps because it shifts the first decision off the protocol and onto things you already control. Even on a platform that carries a rail, access can be gated above your data quality. Shopify operates a trust-tier model in which higher trust tiers unlock broader access, including direct checkout completion. So on Shopify the question is not only whether your feed is clean but whether your store has earned the tier that lets an agent complete checkout, a merchant-standing gate that sits on top of catalog quality rather than replacing it. So the practical starting point is to check whether your commerce platform already carries one of these rails, then get your product data in order. When you genuinely can influence the order, we would start with the rail that reaches the engine your buyers already use: ACP is the rail into ChatGPT shopping, UCP the rail into Gemini and Google AI Mode, as mapped in "Which engine each protocol reaches" above. This is sequencing, not a permanent one-or-the-other. Both stays the goal. The deeper leverage sits upstream of either protocol: get your [product feed AI-readable](/make-product-feed-ai-readable/), then win the pick over an equally transactable competitor, which is the work the [platforms hub](/platforms/) is for. ## The payment layer beneath both Sitting under UCP and ACP is a separate question (can an agent be trusted to *pay* on a shopper's behalf), handled by payment protocols like AP2, Visa's Trusted Agent Protocol, and Mastercard Agent Pay. They are worth knowing because they are table stakes for being a selectable merchant, but they are deliberately agnostic about which merchant gets chosen, so they sit outside the selection contest this page is about. We cover them separately in [agentic payment protocols, explained](/agentic-payment-protocols/), and [AP2](/glossary/#ap2) has a short glossary anchor. ## Where to implement each (link out) This page owns the *which*; the official sources own the *how*, and we send you to them rather than reproduce a spec that will drift. For ACP, start at the [Agentic Commerce Protocol repository](https://github.com/agentic-commerce-protocol) (open standard, schema, and reference material). For UCP, start at [Google's UCP developer guide](https://developers.google.com/merchant/ucp), the canonical implementation reference; the [NRF 2026 announcement](https://blog.google/company-news/inside-google/message-ceo/nrf-2026-remarks) remains the original primary source for the launch itself. When you are ready to translate either integration into actual selection wins, come back to the [platforms hub](/platforms/) and the per-engine pages. --- # Agent Selection Updates https://agentmint.net/updates/ This page is a dated log of the changes that matter for agent selection: shifts in how AI shopping agents choose products and stores, updates to the protocols merchants need to track, and corrections we make to our own research pages when a primary source changes. Each entry is dated by when the change became true or was caught here, not by when the underlying source itself was published. Subscribe to the [RSS feed](/updates/rss.xml) to get each entry as it lands.

Ads arrive in ChatGPT shopping, OpenAI publishes its ranking factors, and the research lab closes

Protocol change · September 18, 2026

Two things landed on the ChatGPT shopping surface at once, and they pull in opposite directions. OpenAI began testing Sponsored Agents on September 16, a limited alpha with selected US advertisers that lets a shopper open a labelled conversation with a business after clicking an ad. At the same time, OpenAI's shopping help article states plainly that product results are selected independently, are not ads, and are not influenced by any OpenAI partnership. The [ChatGPT playbook](/chatgpt-shopping-optimization/) now carries both, scoped as the alpha it is rather than a rollout anyone can buy into. The same help article turned out to be the most valuable source of this refresh. It publishes what ChatGPT weighs when choosing products, and separately what it weighs when ranking merchants: availability, price, quality, and whether you are the maker or primary seller of the item. That last factor is one a reseller cannot edit its way out of, and it is now a [signal](/signals/) in its own right. The article also settles something the [titles guidance](/product-titles-for-ai-agents/) had to assume: ChatGPT rewrites merchant titles and descriptions into simplified versions, so on that surface your title is an input to a rewrite rather than the string a shopper reads. There is a new page on [sponsored placement and agent selection](/sponsored-placement-and-agent-selection/), because the research and the product change deserve to be read together. A 2026 choice experiment finds that agents penalise sponsored listings, and that the penalty shrinks when the agent is told it works for the platform rather than the shopper. Disclosure labels written for human consumers now reach a model instead, and how that model weighs them depends on whose interest it thinks it serves. The infrastructure change is the one most likely to be silently costing someone traffic today. On September 15 Cloudflare set new defaults: for domains newly onboarding, its Agent and Training classes are blocked by default on pages that display ads, and multi-purpose crawlers are judged by every behaviour they carry, so blocking training can take Googlebot, Applebot and Bingbot with it. Verified status no longer means allowed by default. The [serving agent traffic chapter](/handbook/serving-agent-traffic/) now walks through checking what your own CDN blocks, and the [crawler reference](/reference/ai-shopping-crawlers/) carries Cloudflare's behaviour classes, including a Transact class for checkout actions taken on a shopper's behalf, plus a full row for OpenAI's ad-safety crawler. On the protocol side, the tidy picture of one rail per engine has finished collapsing. UCP shipped a dated release on August 25 with breaking schema changes to fulfillment, consent and signing keys, and it now runs under a consortium whose technical committee includes Amazon, Meta and Microsoft. Google still runs the AI Mode and Gemini implementation, so both things are true at once, and [the comparison](/ucp-vs-acp/) says so. Google also made its Merchant Center AI performance insights generally available, which gives merchants a share-of-voice number against named competitors. It measures being shown rather than being chosen, and the [Gemini playbook](/gemini-shopping-ranking/) draws that line explicitly. Two more surfaces joined the map. Shopify turned on WebMCP by default across Liquid storefronts, so an in-browser agent can call a store's tools instead of parsing its pages, which is the subject of a new chapter on [storefronts that answer tool calls](/handbook/storefronts-that-answer-tool-calls/). Anthropic published an open reference implementation of a shopping agent that hands off to the merchant's own checkout. And for anyone running a WooCommerce store, there is now an honest status page on [what actually ships today](/integrations/woocommerce/agentic-commerce/), including the distinction between WooCommerce's store-management MCP integration and a shopper-facing rail, which are not the same thing. Finally, a subtraction. The research lab is gone. It published a methodology for a quarterly benchmark and never published a number, and a results page that waits indefinitely is a promise, not a publication. The measurement protocol survives as a chapter you can run yourself, [how to test agent selection](/handbook/how-to-test-agent-selection/), and the register of what remains unknown moved to [open questions](/reference/open-questions/). Every old address still works. This site now runs no experiments of its own and publishes no measured claims, which is what was already true.

Copilot's dual rails, llms.txt v2, new payment rails, and fresh selection research

Protocol change · August 20, 2026

The agentic-commerce map moved over the summer, and the site's coverage moved with it. The [timeline](/timeline/) now records the biggest shift: Microsoft Copilot became the second major surface on both rails, launching Copilot Checkout on the Agentic Commerce Protocol with Stripe in January and taking UCP-ready Merchant Center feeds to US general availability in April. UCP itself grew Cart, Catalog, and Identity Linking capabilities, and Google announced Universal Cart plus checkout expansion beyond the US. The clean one-rail-per-engine picture in the [UCP vs ACP comparison](/ucp-vs-acp/) no longer holds, and the coverage now says so. The single biggest correction is on the ChatGPT side. OpenAI moved away from its standalone in-chat Instant Checkout around March 2026, and its merchant documentation now describes shopping in ChatGPT as discovery, with checkout completed on the merchant's own site or app. The [ChatGPT playbook](/chatgpt-shopping-optimization/) and its [troubleshooting sibling](/store-not-in-chatgpt-shopping/) now carry that dated status, which makes the product feed, not an in-chat buy button, the surface to win. The payment layer thickened too: American Express debuted Agentic Commerce Experiences with a consumer protection commitment for registered-agent purchases, and Adyen announced an API suite, in limited availability at launch, that spans UCP, AP2, and ACP in one integration, both now dated on the timeline alongside Visa's pilot progress. Two machine-surface updates matter for anyone who followed our implementation guidance. The llms.txt specification moved to v2, which removes the old Optional-section semantics and blesses Markdown link relations for discovery. And the [AI shopping crawler reference](/reference/ai-shopping-crawlers/) picked up Google changes: Google-Extended's scope is now stated as Gemini model training, Vertex AI agent work moved to the new Google-CloudVertexBot token, and Google is experimenting with cryptographic agent verification through Web Bot Auth. The evidence base also grew beyond ACES: a peer-reviewed Marketing Science study of ChatGPT referral traffic to e-commerce sites, a Microsoft Research marketplace simulation that found large first-proposal and response-speed advantages, and the ABxLab testbed, from a team including MIT Media Lab researchers, showing agent choices shift predictably under price, rating, and nudge manipulation.

Site update · July 9, 2026

Most of this site is written to be read. Now the parts meant to be acted on can be handed to a coding agent instead. Both [merchant checklists](/tools/), every [blueprint](/blueprints/), the [AI shopping crawler reference](/reference/ai-shopping-crawlers/), and the implementation-oriented handbook chapters carry a "Run this with your coding agent" block: a short, copyable prompt you paste into any coding agent that can fetch a URL. The prompt does the setup for you. It tells the agent to fetch the page's Markdown mirror first, detect whether your store is Shopify, WooCommerce, Magento, BigCommerce, or custom, and work through the page item by item. The checklists give you two prompts: an audit-only one that reports against every item and changes nothing (run this first), and an audit-and-fix one that implements the fixes you approve. Every prompt carries the same hard rule: the agent never invents your product data, no made-up GTINs, prices, or delivery windows, and it lists exactly what you need to supply where something is missing. There is a short [walkthrough of the whole workflow](/tools/coding-agent-workflow/), including what a good audit report looks like. It works with any coding agent that can fetch a URL; review everything your agent changes before you ship it.

Article table of contents on every long-form page, and a redesigned footer

Site update · July 9, 2026

Long-form pages (the handbook, platform playbooks, research pages, reference, blueprints, comparisons, and both merchant checklists) now carry an "On this page" table of contents generated from each page's headings. On wide screens it sits beside the article and highlights the section you are reading as you scroll; on phones it is a collapsed block above the content; with JavaScript off it is a plain list of anchor links. The two [merchant checklists](/tools/) use their category sections as entries, so the long self-assessments gained section navigation too. The footer is redesigned around the newsletter signup (new research and model-update notes; no spam; unsubscribe anytime), keeps every section link, and now also links [signals.json](/signals.json), the machine-readable export of the [Signals Database](/signals/), alongside [llms.txt](/llms.txt) and the RSS feeds.

Navigation rebuilt: section dropdowns, three new hubs, and an all-pages index

Site update · July 9, 2026

The header menu now carries dropdown panels for each section, so the newer surfaces (the handbook chapters, the [blueprints](/blueprints/), the [Agent Legibility Analyzer](/tools/agent-legibility-analyzer/), and this updates log) are reachable directly from any page. Four new pages ship with it: - **[The Agent Selection Handbook](/handbook/)**: the handbook's table of contents in reading order. - **[Merchant Tools](/tools/)**: both checklists and the analyzer in one place. - **[Reference](/reference/)**: the glossary, the AI shopping crawler reference, protocol comparisons, and the blueprints. - **[All Pages](/sitemap/)**: every published page, grouped by section. The menu works without JavaScript, and every published page stays within two clicks of the home header or footer.

v1.1: two handbook chapters, the Agent Legibility Analyzer, blueprints, and the Agent Selection Index methodology

Site update · July 8, 2026

This release ships the v1.1 surfaces. Each item below links the live page: - **Two handbook chapters:** [serving agent traffic](/handbook/serving-agent-traffic/), on how to afford being open to AI crawlers through caching and edge config rather than blocking them, and [information density for agents](/handbook/information-density/), on the token economy of machine surfaces plus an anti-cloaking doctrine: the same facts everywhere, machine surfaces at their own linked URLs, never content that varies by user agent at one URL. - **The Agent Legibility Analyzer:** a [client-side tool](/tools/agent-legibility-analyzer/) that reads a pasted product payload the way a language-model agent would, showing token cost, which decision fields are present, marketing-noise dilution, and a lean view that only removes and reorders. Nothing you paste is transmitted or stored. - **Blueprints:** a versioned [blueprints collection](/blueprints/) of copy-paste templates for machine surfaces, an llms.txt for catalogs, a product markdown-mirror, token-efficient product JSON-LD, and an edge-worker config, mirrored in a standalone MIT-licensed examples repo. - **The Agent Selection Index methodology:** the full methodology for a planned quarterly benchmark of how AI shopping agents choose under controlled conditions. It ships methodology-complete and numbers-empty on purpose: measured values appear only after a run is generated and author-verified.

ACES description-rewrite figures revised upward in v3

Research · July 8, 2026

The ACES paper's current version (v3, December 2025) reports that a seller-side description rewrite raised average market share by +3.66 percentage points for Claude Sonnet 4, +8.37pp for GPT-4.1, and +14.79pp for Gemini 2.5 Flash, substantially larger than the +2.69pp, +5.64pp, and +4.83pp the same experiment reported in the superseded v2 (October 2025). About 33% of category-model pairs now show a large, statistically significant gain, up from roughly 25% in v2. v3 also tests three newer model generations not covered in v2 (Claude Opus 4.5, GPT-5.1, and Gemini 3.0 Pro Preview). "Office lamp" is the only product category where every one of the six models tested showed a positive, statistically significant gain, ranging from +7.1pp to +80.4pp. A live re-verification caught that three AgentMint.net pages, the description-rewrite experiment, [how AI agents choose products](/how-ai-agents-choose-products/), and [product titles for AI agents](/product-titles-for-ai-agents/), were still citing the superseded v2 figures. All three were corrected today to the current v3 numbers. --- # Edge worker for machine surfaces https://agentmint.net/blueprints/edge-worker-machine-surfaces/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It reads this blueprint, checks your store against it, then implements what you approve. Review everything your agent changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Implement this blueprint The agent checks your store against the blueprint, then builds what fits. ```text Fetch and read the full document at https://agentmint.net/blueprints/edge-worker-machine-surfaces.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are implementing this blueprint in this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first. Read the blueprint sections, check what this store already has against each one, and tell me the plan before you change anything. Then, only after I approve, implement the blueprint adapted to the detected platform, in small, reviewable steps. Stop and ask before anything destructive or anything that changes customer-facing behavior. Report completion against the blueprint sections: done, partial with what remains, or not applicable with a reason. Name the section each change maps to. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: what you added, what is partial, and the exact data or decisions you need from me. ``` This blueprint gives you two ready-to-deploy Cloudflare Worker configurations for caching your machine surfaces (llms.txt, .md mirrors, RSS or Atom feeds) at the edge, and the choice between them turns on one fact: the Workers Cache API does not honor `stale-while-revalidate`, so only the CDN path gives you true directive-driven stale serving. ## Key takeaways - Variant A (CDN path) calls fetch with cf.cacheEverything so Cloudflare honors the origin's stale-while-revalidate directive: it serves stale immediately and revalidates in the background. Prefer it for llms.txt and .md mirrors. - Variant B (Cache API) is self-contained, but the Cache API does not honor stale-while-revalidate, so it has to orchestrate the background refresh by hand with ctx.waitUntil. - The reverse-proxy equivalent is nginx proxy_cache_use_stale updating, which serves a stale entry while one request refreshes it upstream. - Every TTL here is illustrative, not a spec requirement. Keep price and availability on a short TTL so an agent never quotes a stale offer. ## Why there are two variants A Worker is a small piece of code that runs at Cloudflare's edge in front of your origin, so it is the natural place to cache low-churn machine surfaces and keep agent refetches off your origin. The question is how you get stale-while-revalidate behavior: the edge returns the cached copy instantly and refreshes it out of band. That pattern is what protects an origin from crawler bursts without ever making an agent wait. A Workers module exports a default object with an `async fetch(request, env, ctx)` handler, and `ctx.waitUntil(promise)` extends the Worker's lifetime so it can finish background work after the response has already been returned to the client. The load-bearing constraint is what these two Worker APIs do with the `stale-while-revalidate` directive. The Workers Cache API (`caches.default`) does not honor the `stale-while-revalidate` or `stale-if-error` directives. A Worker that caches through that API therefore cannot get automatic stale serving from a header; once its own freshness window lapses, the next `cache.match` is simply a miss. To get real directive-driven stale serving you have to go through Cloudflare's CDN cache instead. Cloudflare's CDN serves stale content during revalidation only when the origin's `Cache-Control` includes `stale-while-revalidate`; the first request after the fresh window triggers an asynchronous background revalidation and immediately returns the stale response with an `UPDATING` cache status. So the split is clean: Variant A rides the CDN path and lets the origin's header drive real SWR; Variant B stays inside the Cache API and rebuilds the stale-then-refresh behavior by hand. ## Variant A: CDN path (preferred for llms.txt and .md mirrors) ```js export default { async fetch(request, env, ctx) { // Origin sends: Cache-Control: max-age=3600, stale-while-revalidate=86400 // cacheEverything makes Cloudflare's CDN cache honor those directives: // serve stale + async-revalidate (UPDATING) after the fresh window. // The TTLs live in the ORIGIN headers (illustrative: 1h fresh / 24h stale). return fetch(request, { cf: { cacheEverything: true } }); } }; ``` The whole mechanism lives in one line and one origin header. `cf: { cacheEverything: true }` tells Cloudflare to run this response through the CDN cache, and the CDN cache is the layer that reads `stale-while-revalidate` and produces the `UPDATING` flow described above. Because the TTLs live in the origin's `Cache-Control` and not in the Worker, you tune freshness per surface by changing a header, not by redeploying code. We prefer this variant for llms.txt and .md mirrors because stale serving there is nearly free: those files change rarely, and an agent that reads a link index or a Markdown mirror one revalidation behind loses nothing. Variant A is also the smaller surface to maintain, since the freshness policy is data (a header) rather than logic. Note the header shape. Variant A pairs `max-age` with `stale-while-revalidate` rather than using `s-maxage`. Cloudflare's cache-control guidance notes that `s-maxage` implies `proxy-revalidate`, so a shared cache must not serve stale without revalidating, and it advises against combining `s-maxage` with `stale-while-revalidate`. That is why the SWR path in Variant A is expressed with `max-age`, while the manual path in Variant B (which has no SWR to combine with) uses `s-maxage` on its own. ## Variant B: Cache API, manual refresh (self-contained) ```js export default { async fetch(request, env, ctx) { if (request.method !== "GET") return fetch(request); const cache = caches.default; const cacheKey = new Request(request.url, request); const cached = await cache.match(cacheKey); if (cached) { // HIT: serve now, revalidate in the background. NOTE: the Cache API does // NOT honor stale-while-revalidate, so we orchestrate the refresh manually. ctx.waitUntil(refresh(cache, cacheKey, request)); return cached; } const response = await fetch(request); const toStore = new Response(response.body, response); toStore.headers.set("Cache-Control", "s-maxage=3600"); // illustrative TTL ctx.waitUntil(cache.put(cacheKey, toStore.clone())); return toStore; } }; async function refresh(cache, cacheKey, request) { const response = await fetch(request); const toStore = new Response(response.body, response); toStore.headers.set("Cache-Control", "s-maxage=3600"); // illustrative TTL await cache.put(cacheKey, toStore); } ``` This variant reconstructs the stale-then-refresh pattern that the Cache API will not give you for free. On a hit it returns the cached copy right away and schedules `refresh()` with `ctx.waitUntil`, so the fetch to your origin happens after the agent already has its response. The `waitUntil` handle is what keeps that background fetch from being cut off when the response returns. Two documented Cache API behaviors shape the code. `cache.match` and `cache.put` respect `Cache-Control` including `s-maxage`, and `cache.put` refuses to store responses to non-GET requests, `206` partial responses, responses with `Vary: *`, or responses carrying a `Set-Cookie` header. The `if (request.method !== "GET")` guard exists because non-GET requests cannot be cached, so there is no reason to route them through the cache lookup. And because the Cache API ignores `stale-while-revalidate` entirely, the code never sets it; `s-maxage` alone defines the freshness window, and the manual `refresh` replaces the SWR the API will not honor. > **Variant B is an approximation, not native SWR** > > Once the `s-maxage` window passes, `cache.match` returns a miss, and that request pays the full origin round trip while the fresh copy is stored. Variant B therefore approximates stale-while-revalidate rather than reproducing it: it revalidates in the background on hits, but it does not serve stale past expiry the way Cloudflare's CDN `UPDATING` flow does. If a warm-refresh-on-every-request guarantee matters, prefer Variant A. ## The reverse-proxy equivalent (nginx) If you cache on your own reverse proxy instead of a Worker, the same shape of behavior has a documented switch. ```nginx # Reverse-proxy equivalent of Variant A's stale-while-revalidate behavior: # serve the stale entry while one request refreshes it upstream, instead of # stampeding the origin. proxy_cache_valid sets the fresh window (illustrative). proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=machine:10m inactive=24h; server { location ~ \.(txt|md)$ { proxy_pass http://origin; proxy_cache machine; proxy_cache_valid 200 1h; # illustrative fresh window proxy_cache_use_stale updating; # serve stale while it refreshes } } ``` In nginx, `proxy_cache_use_stale` with the `updating` parameter serves a stale cached response while that entry is being refreshed, which minimizes upstream requests (the default is `off`); since version 1.11.10 nginx can also serve stale directly from an upstream's `stale-while-revalidate` or `stale-if-error` extensions, at lower priority than the `proxy_cache_use_stale` parameters. This produces the same practical outcome as Variant A, serve the cached copy now and refresh it out of band, but it is a distinct mechanism from Cloudflare's asynchronous `UPDATING` status rather than an identical one, so treat them as analogous rather than interchangeable. ## Freshness: what you must not serve stale > Illustrative example, not measured data. A store puts llms.txt and every .md mirror behind Variant A with a 1 hour fresh window and a 24 hour stale window, and puts the product-detail pages that carry live price and availability on a 60 second TTL with no stale serving. The link index and Markdown copies are cheap to serve slightly behind; the offer facts an agent quotes are not. This is an illustration of the tradeoff, not a measured configuration. Every TTL in this blueprint (1 hour fresh, 24 hours stale, `s-maxage=3600`, `proxy_cache_valid 200 1h`) is an illustrative editorial choice, not a spec requirement. The directives and their behavior are documented; the specific seconds are yours to set per surface. Stale serving is safe for low-churn surfaces like llms.txt and Markdown mirrors, but price and availability are the opposite: keep them on a short TTL or bypass the cache entirely, because an agent that reads a long-stale offer may quote a price or a stock state you have already changed. ## Which to use, and where this sits Reach for Variant A on llms.txt, .md mirrors, and feeds, where directive-driven SWR is free and the config is one line plus one origin header. Reach for Variant B when you need caching logic to live inside the Worker, for example when the freshness window depends on request shape rather than a static header, and accept that it approximates SWR rather than reproducing it. On a non-Cloudflare stack, the nginx block above is the equivalent lever. This is the serving half of making machine surfaces fast for agents. The chapter [serving agent traffic](/handbook/serving-agent-traffic/) covers the surrounding judgment, which crawlers to expect and how caching protects an origin from refetch bursts, and [AI crawlers, robots.txt and llms.txt for stores](/ai-crawlers-robots-llms-txt/) covers the access-policy side. For what these Workers should be caching, see the companion blueprints: [llms.txt for e-commerce catalogs](/blueprints/llms-txt-for-ecommerce-catalogs/), the [product Markdown mirror](/blueprints/product-markdown-mirror/), and [token-efficient product JSON-LD](/blueprints/token-efficient-product-json-ld/). For the format itself, see the [llms.txt](/glossary/#llms-txt) glossary entry. --- # llms.txt for e-commerce catalogs https://agentmint.net/blueprints/llms-txt-for-ecommerce-catalogs/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It reads this blueprint, checks your store against it, then implements what you approve. Review everything your agent changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Implement this blueprint The agent checks your store against the blueprint, then builds what fits. ```text Fetch and read the full document at https://agentmint.net/blueprints/llms-txt-for-ecommerce-catalogs.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are implementing this blueprint in this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first. Read the blueprint sections, check what this store already has against each one, and tell me the plan before you change anything. Then, only after I approve, implement the blueprint adapted to the detected platform, in small, reviewable steps. Stop and ask before anything destructive or anything that changes customer-facing behavior. Report completion against the blueprint sections: done, partial with what remains, or not applicable with a reason. Name the section each change maps to. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: what you added, what is partial, and the exact data or decisions you need from me. ``` An llms.txt for a store is a root Markdown file that hands an agent your catalog's machine surfaces in decision-weight order: the product feed and offer data first, brand pages last. The format is fixed by a public spec; the only real authoring choice for a catalog is which of your URLs earn the top of the file. Here is a production-shaped template and the ordering rule that makes it work. ## Key takeaways - The spec fixes the file's structure; since its August 2026 v2 revision, 'Optional' is a plain convention for secondary links rather than a skip directive, so decision-weight ordering is your editorial lever, not a spec mechanism. - For a catalog, order your H2 link lists by decision weight: the product feed, per-product structured data, and shipping and return policies first; brand, blog, and press pages under 'Optional'. - Point the top links at surfaces an agent can act on directly, the feed and the .md mirrors of your policy and category pages, not at HTML landing pages. - The spec sets no size cap, so density is your discipline: link the category indexes that map the catalog, not every product URL. > **What this blueprint adds** > > The llms.txt format itself is owned by the proposal at llmstxt.org, and we link out to it rather than restate the grammar. What this blueprint adds is the part the spec leaves open for a store: which of your URLs carry buying-relevant facts, and therefore which links belong above the "Optional" line. That ordering is our pattern, not a spec requirement. ## The format, in one paragraph The llms.txt spec, revised to v2 in August 2026, puts the file at the site root in Markdown and fixes its order: an H1 with the site or project name is the only required element, followed by an optional blockquote one-line summary, then zero or more non-heading Markdown blocks, then zero or more H2 sections, each an unordered list of links written as `[name](url): optional notes`. v2 also clarifies that a file covers the pages under its path, with the most specific file applying. That grammar is the whole spec. Everything below is about what a store puts in the H2 sections and in what order, which the spec deliberately leaves to you. ## The template Swap the store name, the domain, and every URL for your own. The domain here is a placeholder; the shape is what matters. ```markdown # Northwind Coffee Co. > Direct-to-consumer specialty coffee: single-origin beans, espresso > blends, brewing gear, and subscriptions. Ships to US and Canada. Northwind Coffee Co. roasts and ships specialty coffee. The links below expose the machine-readable catalog and the offer and policy data an agent needs to compare us. Product-level facts (price, availability, GTIN, shipping, returns) live in the feed and in per-product structured data; these URLs point an agent at them in decision-weight order. ## Product data - [Product feed (RSS 2.0 / Merchant)](https://www.example.com/feeds/products.xml): full catalog, one entry per sellable variant, with GTIN, price, currency, availability, and shipping. - [Product schema reference](https://www.example.com/catalog/product-schema.md): the Product and Offer fields on every product page, including gtin13, priceValidUntil, shippingDetails, and hasMerchantReturnPolicy. - [Variant model](https://www.example.com/catalog/variants.md): how size, grind, and roast variants map to ProductGroup and hasVariant, with the productGroupID scheme. ## Policies - [Shipping policy](https://www.example.com/policies/shipping.md): destinations, handling time, transit time, and rates by region. - [Returns policy](https://www.example.com/policies/returns.md): 30-day window, return method, and who pays return shipping. - [Freshness guarantee](https://www.example.com/policies/freshness.md): roast-date guarantee and replacement terms. ## Catalog indexes - [Single-origin coffee](https://www.example.com/collections/single-origin.md): all single-origin lots, by region and process. - [Espresso blends](https://www.example.com/collections/espresso.md): blends with roast level and tasting notes. - [Brewing equipment](https://www.example.com/collections/equipment.md): grinders, kettles, and filters with specs. - [Subscriptions](https://www.example.com/collections/subscriptions.md): plan tiers, cadence, and pricing. ## Optional - [About Northwind](https://www.example.com/about.md): company background and sourcing story. - [Brewing guides](https://www.example.com/guides/): recipe and technique articles. - [Press](https://www.example.com/press.md): media coverage and assets. ``` ## Why this order Ordering is the lever you have, and since the spec's v2 revision it is yours alone. Under the 2024 v1 spec, an H2 section titled "Optional" marked links whose URLs could be skipped when a shorter context was needed; the August 2026 v2 revision removes that skip mechanism, keeps "Optional" only as a plain convention for secondary links, and instead expects an agent to view or search the file and follow the links relevant to its task. The sequence of your H2 sections still reads as a ranking to anything scanning the file top to bottom, so we treat ordering as the file's real prioritization signal even though the spec no longer defines one. For a catalog, we order the H2 sections by decision weight rather than by navigation: product data first, then policies, then category indexes, with brand and editorial pages under "Optional." An agent comparing stores acts on price, availability, GTIN, shipping, and returns, so the surfaces that carry those facts earn the top of the file, and the pages a shopper enjoys but an agent cannot act on go under "Optional." The [llms.txt](/glossary/#llms-txt) file is a router, not a brochure, so it should route toward the facts that decide selection. We point the highest-weight links at surfaces an agent can parse directly, the product feed and the .md mirrors of your policy and category pages, rather than at HTML landing pages, because the file's job is to get an agent to the facts in the fewest hops. A link that lands on a marketing page forces the agent to spend tokens digging for the price and the return window; a link that lands on the feed or a Markdown mirror hands them over. This is the same facts-per-token discipline covered in [facts per token on machine surfaces](/handbook/information-density/), applied to the routing layer. ## What each list is for The four sections in the template map to four jobs. Product data is the section an agent uses to actually compare you, so it goes first and it points at the two structured channels an engine reads before it reads prose. The feed carries the whole catalog as data; the schema reference documents the per-product fields. We also add one link that documents the variant model, how size, grind, or color map to a product group and its variants, so an agent resolving a specific SKU knows where the variant hierarchy is defined instead of inferring it from product titles. Both of those destinations are their own blueprints: [token-efficient product JSON-LD](/blueprints/token-efficient-product-json-ld/) for the schema, and the variant model it describes. Policies come second because return window, shipping cost, and delivery time are selection inputs, not fine print, for an agent optimizing a purchase. Catalog indexes come third: they map the range so an agent can find the right subset without you listing every product. Because the spec caps nothing, we treat brevity as the discipline: link the category indexes that map the catalog, not every product URL, and keep each note after the colon to the facts an agent will find at that link. A file that lists ten thousand product URLs spends an agent's context without adding decision weight. The spec sets no explicit maximum file size, token, or byte cap, so that restraint is yours to impose, not a limit the spec enforces. "Optional" is where the about page, the blog, and the press kit go. They are real pages, but an agent under a tight context budget loses nothing decision-relevant by skipping them. The v2 spec keeps the section as exactly that, a convention for secondary links, and that is how this template uses it. ## Ship it and cross-check The llms.txt file only earns its place by pointing at destinations that are themselves dense and fast, so build those next: [Markdown mirrors](/blueprints/product-markdown-mirror/) for the policy and category pages this file links, [token-efficient product JSON-LD](/blueprints/token-efficient-product-json-ld/) for the schema reference, and the [edge-worker config](/blueprints/edge-worker-machine-surfaces/) to serve and cache all of them from one place. For the doctrine behind the ordering, read [facts per token on machine surfaces](/handbook/information-density/); for how llms.txt sits alongside robots.txt and your crawler policy, read [AI crawlers, robots.txt and llms.txt for stores](/ai-crawlers-robots-llms-txt/). --- # Product markdown-mirror template https://agentmint.net/blueprints/product-markdown-mirror/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It reads this blueprint, checks your store against it, then implements what you approve. Review everything your agent changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Implement this blueprint The agent checks your store against the blueprint, then builds what fits. ```text Fetch and read the full document at https://agentmint.net/blueprints/product-markdown-mirror.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are implementing this blueprint in this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first. Read the blueprint sections, check what this store already has against each one, and tell me the plan before you change anything. Then, only after I approve, implement the blueprint adapted to the detected platform, in small, reviewable steps. Stop and ask before anything destructive or anything that changes customer-facing behavior. Report completion against the blueprint sections: done, partial with what remains, or not applicable with a reason. Name the section each change maps to. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: what you added, what is partial, and the exact data or decisions you need from me. ``` A product markdown mirror is a distinct `.md` URL that serves a plain-Markdown copy of a product page, ordered so the facts an agent selects on (identifiers, specs, price, availability, shipping, returns) come first and marketing prose comes last or not at all. This blueprint is the template plus the judgment about what goes where and why. ## Key takeaways - A product markdown mirror is a distinct .md URL serving a plain-Markdown copy of a product page. It is a valid, conservative machine surface: no Accept-header branching, it caches and links like any other URL, and it stays discoverable through a rel=alternate reference. - Order the mirror by decision weight: identifiers, specs, price, availability, shipping, and returns first; marketing prose last or omitted. That ordering is our inference from the facts-per-token principle, not a rule any vendor publishes. - Same-URL content negotiation and distinct .md mirrors are complementary, not rivals. AgentMint ships distinct mirrors as a conservative choice, not a safer one. - The mirror is only safe if its facts equal the HTML a shopper sees. Different content by format is legitimate; different content by audience is cloaking. And no verified source shows a shopping agent fetches product Markdown yet, so ship it cheaply but do not attribute a selection outcome to it. ## The template Copy this per product. Replace every `{placeholder}`, keep the section order, and delete any section you cannot fill honestly rather than padding it. Serve it at a stable `.md` URL alongside the HTML page (for example `/product/weighted-sleep-mask.md`). ```markdown # {Product name} > {One factual sentence: what it is, the headline spec, price, and availability.} ## Identifiers - GTIN: {gtin13} - MPN: {manufacturer part number} - SKU: {your internal sku} - Brand: {brand name} - Condition: {New | Refurbished | Used} ## Specifications - {Spec name}: {value with unit} - {Spec name}: {value with unit} - Material: {material} - Dimensions: {L x W x H with unit} - Weight: {value with unit} ## Price - Price: {24.99} {USD} - Price valid until: {2026-12-31} ## Availability - Availability: {In stock | Out of stock | Preorder | Backorder} - Sold by: {seller name} - Ships from: {country} ## Shipping - Shipping cost: {0.00} {USD} - Ships to: {US, CA, GB} - Handling time: {1-2 business days} - Transit time: {2-3 business days} ## Returns - Return window: {30 days | not accepted} - Return method: {by mail | in store} - Return fees: {free | customer pays} ## Description {Optional. One short factual paragraph only. Omit brand-voice copy.} --- Canonical: https://example.com/product/{slug} Last updated: {2026-07-08} ``` ## Why this order The ordering is the decision that matters most in this template, and it is ours, not a vendor's. We order the mirror by decision weight, leading with identifiers, then specifications, price, availability, and shipping and returns, and pushing any description to the end or out entirely, because structured verifiable facts plausibly carry more decision weight per token than qualitative marketing prose. Those are the fields an agent can match against a shopper's query and compare across stores; a sentence of adjectives is expensive to read and hard to act on. The same discipline drives our [information density](/handbook/information-density/) chapter, which argues the case in full. The mechanical reason to strip weight is not ours. Vendors publishing guidance on serving Markdown to agents through 2026, including Cloudflare, Mintlify, and Vercel, each state that agents operate under context-window and token budgets, and that converting HTML to Markdown reduces token consumption and cost while preserving the decision-relevant content. A mirror that opens with a GTIN and a price spends the agent's budget on facts; one that opens with a paragraph of brand copy spends it on nothing the agent can use. The identifiers block leads for a reason beyond density: it is what lets an agent resolve your listing to a specific product across catalogs. Put the same identifiers, specs, price, availability, and policies into your structured channels too, since a mirror is not a substitute for them. Pair this template with the [token-efficient product JSON-LD](/blueprints/token-efficient-product-json-ld/) blueprint for the machine-parseable version of the same facts, and with [make your product feed AI-readable](/make-product-feed-ai-readable/) for the merchant-controlled data an engine ingests directly. ## Why a distinct .md URL There are two documented ways to hand an agent a Markdown copy, and they are complementary. Pronovix, writing in March 2026, frames same-URL Accept-header negotiation and distinct .md URLs as complementary rather than competing, and recommends pairing the Markdown alternate with a canonical link so search engines still consolidate on the HTML page. The alternative to a distinct URL is same-URL negotiation, where one URL returns HTML by default and Markdown when the request sends `Accept: text/markdown`. MDN defines content negotiation as "the mechanism that is used for serving different representations of a resource to the same URI," selected by the client's Accept header. This blueprint ships the distinct-URL variant. AgentMint itself serves distinct .md mirror URLs rather than same-URL negotiation, and we treat that as a valid, conservative choice, not a safer one: it needs no Accept-header branching at the edge, it caches and links like any other URL, and it stays discoverable through a rel=alternate reference. Same-URL negotiation is equally legitimate; the two are implementation options, not a safety ranking, and no source we verified ranks one above the other. Whichever you pick, advertise the alternate so agents that cannot negotiate can still find it. Vercel recommends advertising the Markdown alternate with a `` element so an agent that cannot negotiate can still find it. Add these two lines to the HTML product page head and keep the canonical pointing at the HTML page so ranking signals stay consolidated there: ```html ``` > **Equivalence guard: keep the mirror's facts equal to the HTML** > > A markdown mirror is safe because it is a different format of the same content, not different content for a different audience. Google defines cloaking as "the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users." We read a Markdown mirror whose facts equal the HTML as format negotiation rather than cloaking, because cloaking turns on serving different content with intent to deceive, whereas the mirror delivers the same facts in a machine-preferred representation. It becomes a cloaking risk the moment a price, claim, or spec appears in the mirror but not in the HTML a shopper sees. The full argument lives in the [information density](/handbook/information-density/) chapter; here the rule is short: any fact present in one and absent from the other is a defect, fix it so the two are equivalent. ## The honest boundary Ship the mirror because it is cheap and standards-compliant, not because it is proven to win selection. We have found no verified public source showing that a shopping agent (ChatGPT Shopping, Perplexity, or Gemini) fetches a Markdown representation of a product page. Treat content negotiation and .md mirrors as proven for documentation and coding agents and unverified for shopping agents, and do not attribute a selection outcome to the mirror. Re-verified 2026-07-08: no named shopping agent (ChatGPT Shopping, Perplexity, or Google's Gemini and AI Mode) documents fetching product Markdown or negotiating a Markdown representation of a product page; the crawler documentation OpenAI, Perplexity, and Anthropic publish describes robots.txt as the control mechanism and never mentions Markdown negotiation, and OpenAI's Agentic Commerce product feed spec describes a structured feed file, not page-format negotiation. Google's AI-features optimization guide, updated in June 2026, states that sites do not need to create new machine-readable files, AI text files, markup, or Markdown to appear in Google Search, and that Google Search ignores such files. All of that is absence of documentation as of that date, not proof that no agent ever fetches Markdown. If your products are missing from an engine's results, the format of an alternate representation is far down the list of likely causes. ## Verify before you ship - First-screen facts. Read the first 200 words of the rendered mirror and count the verifiable facts (identifier, spec, price, availability, policy). If the count is low because a description leads, reorder so the identifiers and specs come first. - Equivalence diff. Compare every fact in the mirror against the HTML product page. Any price, claim, or spec present in one and absent from the other is a cloaking risk, not a shortcut. - Discoverability. Confirm the HTML page exposes a `` to the `.md` mirror and a `` to itself, so agents can find the format and search engines still consolidate on the page. - Freshness. Confirm the mirror regenerates when the product's price, availability, or policy changes, so a stale mirror never contradicts the live page. For the machine-parseable version of these same facts, continue with the [token-efficient product JSON-LD](/blueprints/token-efficient-product-json-ld/) blueprint; for the site-level index that points agents at your catalog, see [llms.txt for e-commerce catalogs](/blueprints/llms-txt-for-ecommerce-catalogs/); and for serving these surfaces fast at the edge, see [edge-worker config for machine surfaces](/blueprints/edge-worker-machine-surfaces/). The reasoning behind the ordering sits in [information density](/handbook/information-density/). --- # Token-efficient product JSON-LD patterns https://agentmint.net/blueprints/token-efficient-product-json-ld/ ## Run this with your coding agent This prompt works with any coding agent that can fetch a URL. It reads this blueprint, checks your store against it, then implements what you approve. Review everything your agent changes before you ship it. It is your store. How this works: https://agentmint.net/tools/coding-agent-workflow/ ### Implement this blueprint The agent checks your store against the blueprint, then builds what fits. ```text Fetch and read the full document at https://agentmint.net/blueprints/token-efficient-product-json-ld.md before doing anything else. If you cannot fetch URLs, tell me and I will paste the content. You are implementing this blueprint in this repository's e-commerce store. State which platform you detect (Shopify, WooCommerce, Magento or Adobe Commerce, BigCommerce, or custom/headless) and apply that platform's notes from the document. Work audit-first. Read the blueprint sections, check what this store already has against each one, and tell me the plan before you change anything. Then, only after I approve, implement the blueprint adapted to the detected platform, in small, reviewable steps. Stop and ask before anything destructive or anything that changes customer-facing behavior. Report completion against the blueprint sections: done, partial with what remains, or not applicable with a reason. Name the section each change maps to. Never invent factual product data to satisfy a check. Do not fabricate ratings or review counts, GTINs or other identifiers, delivery windows, prices, or return terms. Where required data is missing, list exactly what I need to supply and stop, rather than guessing. End with a plain-language summary: what you added, what is partial, and the exact data or decisions you need from me. ``` This blueprint ships two verified Product JSON-LD skeletons you can copy (a single product with shipping and returns, and a multi-variant ProductGroup) and explains which fields an AI shopping agent actually reads to select you. ## Key takeaways - The fields an agent can match and compare carry the selection weight: identifiers (gtin, sku, mpn), price, availability, shipping, and returns. Lead with those; brand prose can wait. - Two skeletons ship here verbatim, a single product with shipping and returns and a multi-variant ProductGroup. Copy one, swap in your data, then validate before shipping. - For products that vary by color, size, or material, Google documents ProductGroup with hasVariant as the compact representation, so shared fields are stated once instead of repeated on every variant. - The GTIN in the single-product skeleton is a checksum-valid placeholder, and neither skeleton has been run through a validator yet, so validate both and replace the GTIN before you ship. ## Which fields carry decision weight An agent does not read Product JSON-LD to admire your copy. It reads it to answer a shopper's query and to line you up against competing offers, so the fields worth optimizing are the ones it can match and compare. Google's merchant listing documentation defines the Product and Offer core an agent reads: name, image, description, sku, mpn, a GTIN property (gtin13 for a 13-digit code, or the generic gtin), and brand, alongside an offers object carrying url, priceCurrency, price, priceValidUntil, availability, and itemCondition. The availability value is written as a canonical full schema.org URL, for example https://schema.org/InStock, drawn from the ItemAvailability enumeration that also includes OutOfStock, BackOrder, PreOrder, PreSale, SoldOut, LimitedAvailability, and Discontinued. For itemCondition, Google lists NewCondition, RefurbishedCondition, and UsedCondition, again as full schema.org URLs. Those are the field definitions. The ordering judgment is ours. Among these fields, the ones that plausibly carry the most selection weight are the ones an agent can match against a query and compare across stores: the identifiers that resolve the product to a single global identity, the price and its currency, the availability that says whether it can transact now, and the shipping and return terms that break ties between otherwise equal offers. Free-text description and brand voice are the least comparable, so they earn the least token budget. This is the same facts-per-token discipline the handbook argues for on the page itself, applied to the structured layer. See [information density on machine surfaces](/handbook/information-density/) for the underlying case. ## Skeleton A: single product with shipping and returns Copy this block, swap in your real values, and keep the shape. It carries the identifiers, the offer, an offer-level shipping model, and a return policy in one object. ```json { "@context": "https://schema.org/", "@type": "Product", "name": "Example Widget", "image": ["https://example.com/photos/widget-1x1.jpg"], "description": "One-line factual product description.", "sku": "SKU-12345", "mpn": "MPN-98765", "gtin13": "9780201379624", "brand": { "@type": "Brand", "name": "ExampleBrand" }, "offers": { "@type": "Offer", "url": "https://example.com/products/example-widget", "priceCurrency": "USD", "price": 29.99, "priceValidUntil": "2026-12-31", "availability": "https://schema.org/InStock", "itemCondition": "https://schema.org/NewCondition", "shippingDetails": { "@type": "OfferShippingDetails", "shippingRate": { "@type": "MonetaryAmount", "value": 3.49, "currency": "USD" }, "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" }, "deliveryTime": { "@type": "ShippingDeliveryTime", "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" }, "transitTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 5, "unitCode": "DAY" } } }, "hasMerchantReturnPolicy": { "@type": "MerchantReturnPolicy", "applicableCountry": "US", "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow", "merchantReturnDays": 30, "returnMethod": "https://schema.org/ReturnByMail", "returnFees": "https://schema.org/FreeReturn" } } } ``` The two nested blocks are where most catalogs are thin, and they are the tie-breakers. Google's merchant listing documentation defines the offer-level shipping shape as offers.shippingDetails of type OfferShippingDetails, carrying a shippingRate (a MonetaryAmount with value and currency), a shippingDestination (a DefinedRegion whose addressCountry is an ISO 3166-1 alpha-2 code), and a deliveryTime (ShippingDeliveryTime) that splits into handlingTime and transitTime, each a QuantitativeValue with minValue, maxValue, and unitCode DAY. Google's return policy documentation (last updated 2025-12-10) defines offers.hasMerchantReturnPolicy of type MerchantReturnPolicy, with applicableCountry, a returnPolicyCategory enum (MerchantReturnFiniteReturnWindow, MerchantReturnNotPermitted, or MerchantReturnUnlimitedWindow), returnMethod such as ReturnByMail, and returnFees such as FreeReturn; merchantReturnDays is an integer and is required when the category is a finite window. We lead this skeleton with the identifiers and the offer, then shipping, then returns, because an agent resolves what the product is before it weighs how the product ships and how returns work. JSON-LD key order means nothing to a parser, so this sequence is for the humans who maintain the file; the load-bearing decision is which fields you populate, not their order. > **Replace the placeholder GTIN** > > The GTIN 9780201379624 in this skeleton is a checksum-valid placeholder (an ISBN used only so the block validates syntactically). Replace it with your product's real, checksum-valid GTIN before shipping. Google validates the GTIN check digit, so an incorrect digit will not pass validation. ## Skeleton B: multi-variant products (ProductGroup) When a product varies by color, size, or material, do not emit one bloated Product per variant with every shared field repeated. Group them. ```json { "@context": "https://schema.org/", "@type": "ProductGroup", "name": "Example T-Shirt", "description": "Cotton t-shirt.", "url": "https://example.com/products/example-tshirt", "brand": { "@type": "Brand", "name": "ExampleBrand" }, "productGroupID": "TSHIRT-001", "variesBy": ["https://schema.org/color", "https://schema.org/size"], "hasVariant": [ { "@type": "Product", "sku": "TSHIRT-001-RED-M", "name": "Example T-Shirt, Red, M", "color": "Red", "size": "M", "inProductGroupWithID": "TSHIRT-001", "offers": { "@type": "Offer", "url": "https://example.com/products/example-tshirt?variant=red-m", "priceCurrency": "USD", "price": 19.99, "availability": "https://schema.org/InStock", "itemCondition": "https://schema.org/NewCondition" } } ] } ``` The `hasVariant` array holds one Product per real variant; add more objects to it for each color and size permutation you sell. Google's product variant documentation (last updated 2026-05-20) documents ProductGroup with a productGroupID, a variesBy array naming the varying attributes (for example schema.org/color and schema.org/size), and a hasVariant array of Product objects, each carrying its varying attribute values, an inProductGroupWithID back-reference, and its own Offer; Google describes nesting variants under hasVariant as the most compact and natural representation. The pattern stays token-efficient because the shared attributes (name, description, brand, url, productGroupID) are stated once on the group, and each entry in hasVariant restates only what actually varies plus its own offer. A catalog with many size and color permutations therefore avoids repeating identical fields on every variant, which is both smaller to parse and easier to keep consistent. > **Validate both skeletons before shipping** > > These skeletons were built from live-confirmed schema.org and Google properties, but neither has been run through Google's Rich Results Test or validator.schema.org yet: treat them as verified in structure and unvalidated until you check them. Before either block ships to a real store, paste it into both validators, resolve every error and warning, and replace the placeholder GTIN with your product's real code. ## Before you ship - Paste each skeleton into Google's Rich Results Test and into validator.schema.org, and resolve every error and warning before it goes near a product template. - Replace `9780201379624` with the product's real GTIN, and confirm the check digit is correct so validation passes. - Confirm `availability` and `itemCondition` use full schema.org URLs, not bare strings like `InStock`. - For variant products, check that every entry in `hasVariant` carries its own `offers`, its varying attributes, and an `inProductGroupWithID` that matches the group's `productGroupID`. - Diff the facts in the JSON-LD against the visible page. Any price, availability, or policy that appears in one and not the other is an equivalence problem, and the fix is to make them match. ## Related blueprints and chapters These skeletons are the structured layer of a bigger picture. Pair this with [Product schema for AI shopping](/product-schema-for-ai-shopping/) for the full field walkthrough and the eligibility rules, and read [information density on machine surfaces](/handbook/information-density/) for why the fields an agent can match earn the token budget. When you also serve a Markdown copy of the page, keep the same facts in both by following the [product Markdown mirror](/blueprints/product-markdown-mirror/) blueprint, and see the [machine-readability score](/glossary/#machine-readability-score) for how all of this rolls up into one measure of how usable your data is to an agent. ---