An AI shopping audit should do more than check whether a store has product schema or whether an AI crawler is allowed in robots.txt. It should identify what a channel can access, what product information it can interpret, how clearly the brand and product are represented, and what happens when real shopping questions are tested.
A useful working model is a four-layer funnel:
- Discoverability: Can the relevant channel access the product data or page?
- Comprehensibility: Is the product represented clearly enough to evaluate?
- Trust and entity clarity: Are the brand and product facts consistent and attributable?
- Observed recommendation performance: Does the product appear in a defined sample of relevant AI shopping answers?
The layers build on one another, but there is an important technical distinction: a commerce catalog/feed path and a public web-crawling path are not the same. A crawler restriction may block a web-search path without disabling a Shopify Catalog feed. An audit should record the path being tested rather than collapse all access into one score.
Shopify says eligible products can be discovered by supported AI channels through Shopify Catalog and other routes such as web crawling, indexing, or merchant product feeds. Start with Shopify's product discovery documentation before evaluating crawler settings.
Before the audit: define the scope
Record these items before checking the first product:
- Store domain and storefront architecture: standard Shopify, headless, or a custom storefront.
- Target country, language, currency, and customer market.
- Target channels: for example, ChatGPT through Shopify Catalog, ChatGPT web search, Google AI Mode/Gemini, Microsoft Copilot, or Perplexity.
- Product sample: category, SKU count, variant structure, and selection method.
- Test date and the version of each relevant tool or channel, where available.
- Whether the audit covers catalog distribution, public crawlability, recommendation tests, or all three.
This scope matters because a store can be available through one route and not another. Do not use a robots.txt result as a proxy for Shopify Catalog eligibility, and do not infer recommendation quality from structured-data validity alone.
Layer 1: Discoverability and access
Layer 1 asks whether the relevant product information can reach the intended system. Divide the audit into two independent paths.
Path A: catalog or product-feed distribution
For Shopify-connected AI shopping channels, inspect the merchant-side distribution path first.
| Check | Evidence to collect | What a failure may mean |
|---|---|---|
| Channel eligibility | Shopify Admin status and any eligibility warnings | The store or product may not qualify for that channel |
| Channel access | Current settings in Sales channels > Agentic | Catalog sharing may be disabled or configured differently than expected |
| Product eligibility | Eligible product count and the affected product records | Some products may be excluded even if the store is eligible |
| Product-data mapping | Actual mapping for title, description, options, images, price, and availability | The channel may receive a different field than the merchant expects |
| Store policies | Current Terms, Privacy, Returns/Refunds and any channel-specific policy requirements | Missing required policies may prevent participation in a channel |
| Update state | Change timestamp and later re-check | Product feeds and channel reports may not reflect a change immediately |
Shopify currently documents that ChatGPT sales through its channel require eligible products and specific store/policy conditions. Its current help page says that eligible Shopify products are discovered through Shopify Catalog without extra manual submission, but it does not guarantee placement in a particular answer. Verify requirements in the current ChatGPT channel guide because channel eligibility and features can change.
Path B: public web crawling and indexing
This path matters when the product page itself needs to be discovered from the public web or cited by an AI search experience. It should not be confused with a merchant product-feed path.
robots.txt and crawler controls
Review whether robots.txt rules accidentally disallow the canonical product URLs, relevant assets, or resources needed to render the page. Look for overly broad rules affecting product paths or query strings. A filter rule can be useful for reducing crawl waste, but it should not unintentionally block important product pages.
Do not paste a generic list of AI user agents into robots.txt without deciding what you want to allow. The user agents have different roles. OpenAI currently distinguishes:
OAI-SearchBot: automatic crawling for ChatGPT search discovery.GPTBot: crawling that may be used for training OpenAI foundation models.ChatGPT-User: a fetch triggered by a user request, not the automatic search crawler.
Those rules are independent. See OpenAI's crawler reference. Other names you may encounter include ClaudeBot, Claude-SearchBot, PerplexityBot, CCBot, Bytespider, and Meta-ExternalAgent, but do not assume they all serve the same purpose or influence the same product. Verify each operator's current documentation before creating rules.
Google states that Google-Extended is a robots.txt product token rather than a separate HTTP request User-Agent string; it controls certain uses of content by Gemini-related systems and does not control inclusion in Google Search. Google's crawler documentation explains this distinction. Apple similarly documents Applebot-Extended as a control over use of data crawled by Applebot, not a crawler that fetches webpages itself. Applebot documentation.
Build your check around actual provider behavior and current documentation. For example, don't search server logs for Google-Extended or Applebot-Extended as if either were a unique HTTP request UA. Don't block Googlebot or Applebot just because you want to control Google-Extended or Applebot-Extended data use. Those tokens are used in robots.txt to signal data-use preferences; they are not interchangeable with the corresponding search crawlers.
HTTP responses, WAF, and rendering
If you operate a CDN, reverse proxy, custom storefront, or headless environment, inspect server and edge logs for:
- 403, 429, 5xx, or challenge responses affecting legitimate crawlers
- Redirect chains and unexpected final URLs
- Canonical product pages returning different content from the expected variant URL
- Product details that exist only after client-side JavaScript execution
- Missing or incomplete HTML where title, availability, price, or core specifications should appear
A manual request with a spoofed User-Agent is only a diagnostic, not proof that a verified crawler can access the page. When possible, use provider-published crawler IP ranges or your CDN's verified-bot features, and corroborate with server logs. If the merchant uses standard Shopify hosting, they may not control all hosting-edge rules directly. Don't claim a WAF setting is wrong when the site owner has no access to that layer.
Cloudflare's AI Crawl Control documentation can show AI crawler requests and their outcomes for sites using Cloudflare. Those are crawler requests, not human shopping sessions.
Sitemap and canonical strategy
Check that the sitemap contains the canonical product URLs that should be discoverable. Do not mechanically require every variant to have a separate sitemap URL. Some Shopify variants share one product URL and use query parameters; others may use distinct URLs. The sitemap, canonical tags, and variant structured data should reflect the actual page architecture and indexing strategy.
For Google, the rules are explicit: single-page variant setups generally use a canonical URL for the overall ProductGroup, while multi-page variant setups can have independently important pages with self-contained markup. See Google's product variant guide.
Layer 1 report fields
For every finding, record:
| Field | Example |
|---|---|
| Route under test | Shopify Catalog, direct product feed, public crawl, AI search crawler |
| URL or product ID | Canonical product URL or SKU |
| Check | Eligibility, robots rule, HTTP status, render, canonical, sitemap |
| Evidence | Admin status, response code, log, HTML snapshot, sitemap entry |
| Status | Pass, fail, warning, not applicable, unknown |
| Next action | Specific correction, responsible owner, verification date |
If a required access route fails, downstream tests that rely on that route cannot establish anything meaningful. However, a failure in the public crawl route does not automatically mean the Shopify Catalog route is unavailable. Keep them separate.
Layer 2: Comprehensibility
Layer 2 asks whether the information that reaches a channel is useful for identifying and evaluating the product.
Audit visible content and structured data together
For a representative product sample, compare the product page, Shopify record, catalog mapping, and structured data. Investigate at least:
- Accurate product name
- Primary images with useful alt text
- A specific and factual description
- Correct price and currency
- Current availability
- Product URL and variant URLs where relevant
- SKU and GTIN/MPN where applicable and available
- Brand and manufacturer details where applicable
- Material, size, dimensions, capacity, compatibility, ingredients, or other category-specific specifications
- Clear product options and variant distinctions
These are practical data-quality checks, not a universal list of mandatory properties for every AI system. Requirements differ by channel, schema type, and product category.
Product structured data
Google supports Product structured data and has separate requirements for product snippets and merchant listings. Some properties that are optional in one feature may be required in another. For merchant listings, offer data such as price, currency, and availability matters. Read the relevant Google Product structured-data documentation and test the actual page with Google's Rich Results Test.
JSON-LD is Google's recommended structured-data format in general because it is easier to implement and maintain at scale, but valid Microdata and RDFa are also supported. A JSON-LD block is not a universal AI recommendation signal, and a valid schema does not guarantee a result. See Google's structured-data overview.
For products with meaningful variants, use variant structures where the underlying page architecture supports them. Google's documented ProductGroup, hasVariant, variesBy, and product-group identifiers can help express how variants relate to one another. Do not add variant markup that disagrees with the visible page or the actual purchasable options.
Test for information density and scenario fit
A complete field is not always a useful field. A product can have a long description that repeats generic marketing language but omits the facts a buyer needs to compare alternatives.
Ask whether a shopper can find answers to relevant questions without guessing:
- Who is this product designed for?
- What job or situation is it suitable for?
- Which constraints does it meet or not meet?
- What makes it different from the closest alternative?
- Which size, configuration, compatibility, or setup details affect the choice?
- What limitations or exclusions should the buyer know?
A collection page may also need a clear explanation of how items differ and how a shopper should choose among them. Treat that as a content-quality recommendation, not as a confirmed platform ranking factor.
Layer 2 report fields
Record each issue at the product level and assign a practical severity:
- Critical: a core fact is missing or incorrect, such as price, availability, selected variant, or compatibility.
- High: important differentiating details are missing or inconsistent.
- Medium: the information exists but is hard to compare or interpret.
- Low: a minor clarity or formatting improvement.
Prioritize facts that affect correct product selection. Do not add made-up attributes merely to fill a schema field.
Layer 3: Trust and entity clarity
Layer 3 asks whether the product and the business are represented consistently enough for a system and a person to identify the source and evaluate the claims.
Brand and organization identity
Check whether the store clearly identifies the business or brand. Depending on the business, useful evidence may include:
- Consistent business and brand names
- An accurate Organization or Brand structured-data entity
- Correct logo and official website references
sameAslinks to genuine brand-controlled profiles where applicable- A clear About page and contact method
- Current shipping, returns, warranty, and policy information
- Genuine product reviews and substantiated customer examples
Do not add a Wikipedia or social profile to sameAs just to make the list look longer. Link only to real, authoritative profiles that represent the same entity. Reviews, awards, certifications, and case studies must be genuine and traceable.
Fact consistency
Compare the important facts across:
- Product page visible text
- Structured data
- Shopify Catalog mapping
- Collection or category pages
- Variant selectors and variant URLs
- Merchant policies and shipping information
- Price and availability feeds
A disagreement between a visible product page and its structured data is a concrete data-quality issue. An inconsistent brand name or unclear manufacturer relationship may also make the source less clear.
Product descriptions and originality
Do not assume that every duplicated sentence automatically triggers an AI-specific penalty. Public documentation does not provide a universal rule of that kind. Instead, inspect whether the content provides specific, accurate, differentiating facts or merely repeats language that could describe hundreds of other products.
A genuinely useful comparison, use case, or limitation can make a product easier for a shopper to evaluate. It does not guarantee that a model will cite it. Treat it as a controllable improvement to product information rather than a guaranteed ranking tactic.
Layer 3 report fields
Capture the observed issue, the pages that disagree, the supporting source, and a correction that can be verified. Separate:
- Identity problems, such as ambiguous brand or manufacturer details
- Factual inconsistencies, such as conflicting sizes or prices
- Unsupported or unsubstantiated claims
- Missing policies or business context
- Generic descriptions with little product-specific information
Layer 4: Observed recommendation performance
This is the only layer in this framework that directly tests AI answers. The first three layers assess access and information quality; the fourth measures what a defined set of model interactions actually returned.
It is not a complete view of all customer exposure. A probe is a sample, and different models or sessions can produce different answers.
Build a scenario-based prompt set
For an initial audit, begin with 30 to 100 prompts if the product category and resources justify that sample size. This range is a practical starting point, not a statistically validated universal standard.
Cover different forms of shopping intent:
| Prompt type | Example | What it tests |
|---|---|---|
| Category | "Recommend a compact travel backpack under $150." | Does the product enter the candidate set? |
| Comparison | "Compare Brand A and Brand B for frequent business travel." | Is the product compared accurately and fairly? |
| Problem or situation | "What lamp works on a small desk for video calls?" | Does the recommendation match constraints and context? |
| Brand-specific | "What should I know before buying Model X from Brand Y?" | Can the model identify the product and source correctly? |
Write prompts using real shopping language. Include constraints that meaningfully separate products in the category. Do not build every prompt around the target brand's exact name; brand-only prompts cannot show whether the product is discoverable in category-level shopping.
Record a consistent set of results
For each prompt and run, record:
- Provider and surface
- Model or visible version, if available
- Date, market, and language
- Whether web search or browsing was enabled, disabled, or unknown
- Whether the product or brand was included
- Whether it was the first recommendation
- Position in the returned list, if a list exists
- URL citations or product links shown
- Competing brands included
- Stance: recommended, neutrally mentioned, or discouraged
- Reason given by the answer, if any
Run the same prompts across at least two providers when possible. Repeat a subset on another day. Do not mix browsing-enabled and non-browsing runs without labelling them separately: a model answering from learned context and a model retrieving current product pages are different measurement conditions.
A citation is useful evidence that a source was surfaced in that answer. It is not proof that users clicked, bought, or preferred the product. Likewise, a first-place mention is not a stable ranking position across all shoppers.
Keep probes separate from actual sales
Probe results answer, "What did the model say under these test conditions?" Analytics answers, "Which visits and orders were observed?" Neither can substitute for the other.
Cross-reference cited URLs with landing pages and real referral data when available. If the sets do not overlap, do not immediately assume one system is broken. The user may click a different link, the answer may cite a collection page, or the measurement sample may be too small.
A four-layer audit score, if a score is useful
A score can help prioritize remediation across many products, but only if the report shows the underlying evidence. Avoid presenting one number as "the AI recommendation score."
A practical report can show four separate components:
- Discoverability: access, eligibility, response status, canonical and sitemap checks, and whether required information is available in the selected route.
- Comprehensibility: product facts, schema consistency, attributes, variants, and usefulness of visible information.
- Trust and entity clarity: business identity, fact consistency, policies, and evidence supporting claims.
- Observed recommendation performance: inclusion, position, citation, and competitive context across the defined prompt sample.
Keep each component visible. A store might have strong technical access but weak scenario-specific product information, or strong information quality but no observed recommendations in a small probe set. The score should reveal that difference, not hide it.
Final audit report template
For every finding, use a small number of consistent fields:
| Field | What to include |
|---|---|
| Layer | Discoverability, Comprehensibility, Trust, or Performance |
| Product or URL | The exact product/variant or page affected |
| Finding | What was observed, not what was guessed |
| Evidence | Admin state, data export, response, schema test, page capture, or probe log |
| Impact hypothesis | Why it may matter for product discovery |
| Priority | Critical, High, Medium, or Low |
| Recommendation | A specific correction or test |
| Validation method | How to confirm the fix worked |
| Limitation | What cannot be concluded from this evidence |
The final report should end with a short prioritized action list, not just a readiness score.
What the four layers do not prove
No public AI shopping platform exposes a complete and stable ranking formula. These checks cannot reveal a product's probability of being recommended, guarantee a particular placement, or prove a future sales increase. Some failures may be outside a merchant's control, and different distribution routes may use different data sources.
A good audit makes uncertainty actionable. It separates fixable data-quality problems from channel eligibility issues, unknown platform behavior, and results that need more testing.