What Makes a Product “Discoverable” to AI Shopping Assistants?

AI shopping assistants are changing how people discover products online. But being visible to an AI isn’t as simple as having a product listed in your catalog. A product needs to be understood, matched to the shopper’s intent, available to buy, and supported by enough information for an AI system to confidently surface it.

So what actually makes a product discoverable in AI-powered ecommerce?

A product is conditionally discoverable to an AI shopping assistant when the intended item or variant is distinguishable; its relevant meaning and hard constraints are represented without material conflict; a current eligible offer exists; the chosen shopping surface is intentionally accessible; the assistant says no more than its evidence supports; and representative queries behave as expected.

If one link fails, narrow the claim and fix or route that failure. Even when every tested link passes, the defensible conclusion is observed readiness for that product, surface, market, context, and time not guaranteed indexing, inclusion, ranking, comparison, recommendation, checkout eligibility, or commercial results.

The six-link chain, its order, its non-numeric status model, and the weakest-link rule are original editorial analysis informed by current OpenAI, Shopify, Google, and evaluation documentation. No reviewed source validates this complete model across assistants, and the model is not a standard, certification, ranking funnel, implementation architecture, or description of a Wizzy product.

Product discoverability is a chain, not a single field

For this evaluation, a surface is the named route through which an assistant can access product information: for example, a direct feed, a platform catalog or channel, or permitted open-web search. An offer is the current seller-, variant-, market-, and channel-specific opportunity to buy. Eligible means the named path permits consideration under its documented conditions. Shown, compared, and recommended are later and different states.

That separation matters. OpenAI’s current product-feed specification distinguishes stable item or variant identity, factual product content, product URLs, images, price, availability, product attributes, search eligibility, and checkout eligibility. It also states that search eligibility does not guarantee display (OpenAI product feed specification). Google similarly says product structured data can make pages eligible for richer search experiences while the appearance of those enhancements remains discretionary (Google Product structured data). These are named platform examples, not a universal assistant model.

The following scorecard is therefore non-numeric. Record each link as Pass, Fail, Unknown, or Not applicable with a reason. A pass needs a reference to inspected evidence. A material fail or unknown cannot be offset by stronger results elsewhere.

Link	Condition to establish	Evidence to inspect	Representative check	Failure meaning and safe action
1. Product identity	The exact product or purchasable variant is distinguishable from its parent, siblings, other seller offers, and unrelated items.	Stable item and variant identifiers, grouping, seller and brand, option values, destination, and variant-specific media.	Exact identifier, sibling variant, same product from another seller, and offer change without identity change.	Do not use exact-item or exact-variant language. Correct grouping, clarify, or retain an ambiguous or unknown state.
2. Meaning and constraints	The record supports the tested need and hard constraints without a material conflict.	Factual title, description, category, options, attributes, units, relationships, images, structured fields, and destination content.	Synonym, several hard constraints, missing value, unit variation, unsupported compatibility, and conflicting evidence.	Clarify, narrow, exclude, expose uncertainty, correct the source, or stop. Never silently treat an absent constraint as satisfied.
3. Current offer	A current eligible offer exists for the exact variant, seller, market, and channel.	Price and currency, availability, seller, destination, publication or channel state, market, and timestamp.	Unavailable sibling, changed price, expired sale, unknown stock, market restriction, or destination mismatch.	Preserve product identity but remove or condition purchasability language. Refresh or route the offer evidence.
4. Approved access	The product is intentionally reachable through the named authorized path.	Feed validation, product eligibility, catalog or channel settings, mapping, URL reachability, and intended crawler controls.	Rejected feed row, removed channel, blocked crawler, inaccessible URL, or different results across paths.	Record a surface-specific access failure. Fix that route without declaring the whole catalog undiscoverable.
5. Evidence limits	The response says no more than current evidence supports.	Exact query and context, observed response, retrieved facts, provenance where available, unresolved constraints, and generated or inferred wording.	Wrong variant, stale price, unsupported fit, generated “best” label, omitted eligible item, or included ineligible item.	Correct, narrow, clarify, verify, expose uncertainty, exclude, or stop. Plausible wording is not a pass.
6. Representative queries	Purpose-specific tests cover relevant positive and failure cases, with human-reviewed results.	Versioned cases, expected states, snapshots, captured outputs, reviewer rationale, failed link, and retest trigger.	Known item, hard constraints, excluded item, ambiguity, unavailable variant, stale facts, no qualifying product, and path variation.	Localize the earliest failed link, correct or narrow it, and rerun affected cases. Do not average away a material false inclusion.

Evaluate links 1–4 before accepting the content of a response. Evaluate link 5 against the response actually produced. Then use link 6 to test typical and failure conditions. Later fluency cannot repair ambiguous identity, unsupported constraints, an ineligible offer, or an inaccessible route.

Teams also need a compact snapshot record. For each evaluation, capture the product and variant identity; seller, market, and channel; named surface and access path; source timestamps; exact query and relevant context; required and prohibited claims; expected eligible and ineligible state; observed output; status at each link; earliest failure; safe response; next owner or action; and retest trigger. This record is original practical guidance, not a prescribed schema or universal operating model.

Link 1: Distinguish the exact product and purchasable variant

Trace identity without using offer facts as a shortcut

Start with the entity the assistant could safely name. Inspect stable item and variant IDs, parent or group relationships, brand and seller, and assigned identifiers such as GTIN or MPN where applicable. Ask whether identifiers remain stable when price or stock changes and whether retired identifiers are reused.

OpenAI’s current feed specification requires a stable ID for each item or variant and documents variant grouping. Its related guidance recommends variant-specific titles, URLs, descriptions, media, availability, and price when those facts differ (OpenAI feed best practices). Google Merchant Center separately documents stable IDs, variant grouping, landing URLs, price, availability, and identifiers (Google Merchant Center product data specification). Those are platform-specific examples; they do not show that every assistant uses the same identifiers or that a populated field guarantees retrieval.

Try to falsify identity. Check an exact identifier, a sibling size or color, the same product sold by another seller, and a price or stock change that should not create a new product identity. Confirm that the variant URL, image, option values, price, and availability resolve to the tested variant rather than only to its parent.

If the parent is known but the exact variant is not, retain that partial knowledge. Do not promote a family-level match into an exact-variant claim. An identity failure limits the response to a candidate, ambiguous family, or unknown until grouping is corrected or clarification resolves the branch.

Link 2: Represent meaning, attributes, and hard constraints without conflict

Point each material requirement to current evidence

Identity tells you which entity is under review. It does not establish what that entity means for a specific decision. Inspect the factual title and description, category, selected variant options, relevant measurable attributes and units, and explicit condition or compatibility relationships only where they are sourced.

There is no evidence-backed universal minimum attribute set for AI shopping assistants. The necessary facts depend on the product category and the tested request. For each hard constraint, point to exact current evidence or mark it missing, unsupported, or conflicting. A populated field is not a pass when it disagrees with the selected variant, image, destination page, or another authoritative source.

Current OpenAI feed documentation provides one product-specific example of factual descriptions, attributes, and variant information. Shopify’s agentic-storefront guidance says Shopify Catalog can syndicate structured product information and that custom product data may require Catalog Mapping (Shopify product discovery for agentic storefronts). Shopify’s current Global Catalog extension also warns that inferred descriptions, options, or attributes may be absent or vary in accuracy and are not merchant-authored source text (Shopify Global Catalog extension). Mapping or field presence does not guarantee correct interpretation, selection, or display.

Use representative challenges: a natural-language synonym, several simultaneous hard constraints, a missing attribute, unit variation, a conflict among title, image, and variant data, and a compatibility request with no explicit relationship evidence. When a hard constraint cannot be established, ask a discriminating question if an answer can resolve it. Otherwise narrow or exclude the match, expose uncertainty, defer to a current authoritative source, or stop. Do not broaden the request merely to return a product.

Link 3: Verify a current offer for the tested market and channel

Keep durable identity separate from dynamic purchasability

A correctly identified product may still lack a current eligible offer. Resolve price and currency, availability, seller, destination, exact variant, market, and channel at the same level of detail. Where a platform separates search eligibility from checkout eligibility, preserve that distinction rather than treating one as evidence of the other.

OpenAI’s current feed specification requires price and availability and separately represents search and checkout eligibility. Shopify’s current agentic-storefront guidance documents channel controls and says identified B2B-only products are excluded from agentic storefronts. Google Merchant Center warns that inaccurate, missing, or conflicting product data can cause disapproval, limited eligibility, or incorrect display within its own ecosystem. None of these statements guarantees that an eligible offer will be shown or sold.

Check dynamic and conflicting conditions: in-stock and out-of-stock siblings, a changed price, an expired promotion, unknown stock, an unavailable market, a B2B-only item in a D2C route, a product removed from a channel, and a landing-page/feed mismatch. Record the source and timestamp for every dynamic fact.

If offer evidence fails, preserve supported identity and meaning findings while removing or conditioning phrases such as “available,” “buyable,” “in stock,” or “checkout-ready.” Refresh the authoritative offer source or route the issue to the relevant commerce or channel owner, then rerun the offer and downstream response checks.

Link 4: Confirm access through the approved shopping surface

Name and test the route rather than claiming universal visibility

A product can be intentionally accessible through one path and absent from another. Distinguish the actual tested route: a direct feed or API, a platform catalog or channel, or permitted open-web search. These categories are useful for this audit but are not an exhaustive architecture for every assistant.

For a feed or API, inspect onboarding and validation state, row acceptance or rejection, product-level eligibility, and current submission state. For a platform catalog or channel, inspect mapping, syndication, and product/channel settings. For an open-web route, inspect public HTTP(S) reachability, login or interstitial behavior, destination content, and crawler or robots controls for the intended bot.

OpenAI documents product feeds and open-web search as separate routes. It says a feed is not strictly required when a site can be crawled, while its OAI-SearchBot control is independent from GPTBot (OpenAI product discovery; OpenAI crawler documentation). Shopify likewise documents Shopify Catalog, web crawling and indexing, and merchant-owned feeds as distinct discovery methods. These controls and availability conditions can change. Feed acceptance, channel eligibility, crawler permission, an HTTP 200 response, or structured data may support a particular access path; none proves indexing, inclusion, ranking, comparison, or recommendation.

Test a rejected feed row, search-disabled product, removed channel, blocked crawler, unavailable URL, and a product reachable through one path but absent from another. Diagnose a failure against the named route. Do not infer that another route shares the same failure or pass.

Readers making a separate interface-level decision can review how conversational search works with filters and recommendations. That article is optional next reading, not evidence for this chain or for any Wizzy capability.

Link 5: Keep the assistant’s claim inside its evidence boundary

Review the answer, not only the data path

A response can sound plausible while overstating the item, variant, offer, fit, comparison, recommendation reason, or generated label. Record the exact query and relevant context, named surface, retrieved product and offer facts, source and timestamp, unresolved constraints, and whether material wording is merchant-authored, generated, or inferred where that distinction is available.

OpenAI’s current shopping help says ChatGPT can interpret product intent incorrectly, not all products are shown, generated labels are not guarantees, reviews are not verified by OpenAI, and price updates may lag (Shopping with ChatGPT Search). That source describes ChatGPT, not every assistant, and it does not disclose a complete retrieval or ranking formula.

Challenge the response with a wrong sibling variant, a stale price, an unavailable item, an unsupported compatibility or fit statement, and generated labels such as “best,” “budget,” or “popular.” Require the material statement to trace to current evidence. Visible provenance can make a basis inspectable, but it does not itself make the claim correct.

Track two failures separately. A false exclusion occurs when an eligible product expected under the defined test is omitted. A false inclusion occurs when a product appears despite violating an explicit hard constraint or eligibility condition, or when it is described with unsupported material facts. This classification is original analysis. Do not average away a material false inclusion because other cases succeeded.

When support is missing, correct the underlying data or response behavior, narrow the wording, ask for clarification, show uncertainty, direct a dynamic fact to the current authoritative destination where available, exclude the unsupported option, or stop. A relevant product name and polished prose are not enough.

Link 6: Evaluate representative queries without averaging away failures

Define the test contract before running queries

Record the product, variant, market, context, surface, path, and time snapshot. For every case, specify the exact query and relevant context, required facts, expected eligible and ineligible products or states, acceptable clarification or unknown behavior, prohibited implication, and human reviewer. Define material pass conditions for the intended use; do not invent a universal confidence threshold, pass percentage, query count, or review cadence.

General evaluation guidance recommends task-specific criteria and a mix of typical, edge, and adversarial cases with human judgment (OpenAI evaluation best practices). NIST’s AI Risk Management Framework resources likewise make measurement context-dependent and retain a role for human judgment (NIST AI RMF characteristics). Neither source supplies this commerce matrix or a readiness threshold.

The following cases are hypothetical test categories, not real products, queries, customer data, logs, evaluations, or observed results.

Case	Required evidence or expected state	Failure risk to inspect	Likely failed link	Safe next action
Exact known item or identifier	The exact entity and intended seller offer are distinguishable.	Parent, sibling, other seller, or unrelated item substituted.	Identity	Correct grouping, clarify, or withhold exact-item language.
Several hard constraints	Each material condition has current, non-conflicting evidence.	A missing constraint is silently dropped or softened.	Meaning and constraints	Narrow, exclude, clarify, expose uncertainty, or stop.
Sibling variants with different availability	The selected variant’s own offer facts govern the response.	Parent or sibling stock becomes a variant availability claim.	Identity or current offer	Resolve the exact variant and refresh offer evidence.
Ineligible or search-disabled item	The defined route excludes the product from consideration.	The product is shown or called buyable despite route conditions.	Offer or approved access	Exclude or condition the product and repair the named route if appropriate.
Missing attribute or unsupported compatibility	The response retains an unknown or requests useful clarification.	Absence is treated as satisfaction or fit.	Meaning or evidence limits	Ask, verify, narrow, defer, or stop.
Stale price or changed availability	The dynamic fact matches a timestamped authoritative source.	An older value is repeated without a freshness limit.	Current offer or evidence limits	Refresh the source, correct the response, and rerun affected cases.
No qualifying product	An honest empty, excluded, unknown, or clarification state is allowed.	A product is invented or constraints are relaxed to create an answer.	Meaning, offer, or evidence limits	Preserve the constraints and stop or ask for a shopper-directed change.
Same product across two access paths	Each route has its own product-level access evidence and observed output.	One route’s pass or failure is generalized to another.	Approved access	Keep findings surface-specific and investigate each route independently.
Generated comparison or recommendation label	Every material comparison and reason is supported at the stated granularity.	Generated wording is presented as verified fact or suitability.	Evidence limits	Narrow the label, show uncertainty, verify, exclude, or stop.

Add prompt variation, locale, market, context, and adjacent variants only where they can change the intended decision. Rerun affected cases after relevant catalog, feed, offer, policy, channel, assistant, or documentation changes. If the cause of an omission is unknown, record it as unknown rather than guessing a ranking reason.

Conclude with the narrowest claim the evidence supports

Use the chain as an operating record, not a score:Fix the snapshot. Name one product or variant, seller, market, channel, approved surface and path, context, timestamp, intended decision, and hard constraints.

1. Check identity first. If exact identity is ambiguous, stop exact-item language. Do not let later attributes or offer data compensate.

Check meaning and constraints. Trace every material requirement to current evidence; keep missing or conflicting facts visible.

Check the current offer. Resolve price, currency, availability, seller, destination, market, and channel at the exact offer or variant level.

Check the named access path. Verify product-level feed, catalog/channel, or open-web evidence for that route. Keep other routes separate unless tested.

Inspect the actual response. Trace material facts, labels, comparisons, and recommendation reasons to current evidence; narrow, clarify, verify, or stop when support is missing.

Run positive and failure cases. Include qualifying, excluded, ambiguous, stale or conflicting, sibling-variant, no-qualifying-product, and path-specific cases relevant to the intended use.

Classify without averaging. Record Pass, Fail, Unknown, or Not applicable with reason at every link. Track false inclusion and false exclusion separately.

Report only the observed state. Name the product, surface, market, context, and timestamp. Do not generalize to another assistant, route, user, locale, product, or date.

Repair and retest. Assign the earliest failed or unknown link, preserve the evidence record, and rerun the affected cases with accountable human review.

Record observed readiness only when every material gate for the intended use has evidence and the representative cases behave as expected. Otherwise state the narrower condition: identity unresolved, constraint unsupported, offer ineligible or unknown, path inaccessible, response unsupported, or evaluation incomplete.

The weakest failed or unknown link defines the narrowest defensible claim and the next action. AI shopping assistants can complement product-discovery operations, but they do not replace catalog and variant governance, authoritative offer data, category navigation, filters, site search, relevance operations, merchandising controls, or human review. Choose one representative product and one approved surface, complete the non-numeric record, run the positive and failure cases, and document only what that snapshot supports.