Key takeaways
Measure ChatGPT visibility with a stable prompt set, then repair the SKU-level catalog inputs that AI engines can read. Reconcile product pages, structured data, and merchant feeds around one governed record. Validate identifiers, variants, taxonomy, price, stock, and publication status before repeating the visibility test.
- Visibility monitoring measures mentions and citations, while SKU-level catalog repair changes the merchant-controlled inputs that AI engines can read.
- One governed product record should keep price, stock, identity, variants, taxonomy, pages, markup, and applicable feeds consistent.
- Valid manufacturer identifiers and distinct variant records make products easier for compatible systems to match across sources.
- AI engines control retrieval and presentation, so cleaner catalog data improves readability while rankings, recommendations, citations, and sales remain outside Veliu’s control.
A $79 product page paired with an $89 structured price gives ChatGPT two conflicting facts before a marketing team measures one mention. This guide explains how to improve ChatGPT brand visibility by repairing the SKU-level catalog data that ChatGPT can read, including product identity, price, stock, variants, taxonomy, and machine-readable markup.
It is for ecommerce marketing and growth teams that track traffic, conversion, and share of voice but do not manage data engineering. Gemini, Perplexity, Copilot, and Google AI Overviews may also use product pages, feeds, or structured data, which is labeled information machines can parse. Cleaner inputs make a catalog easier to read and match. Each engine still decides what it retrieves, cites, or presents.
The commercial boundary is clear.
Veliu can improve catalog readability, taxonomy alignment, and endpoint availability. Merchants control prices, inventory, traffic, and reviews, while AI engines control selection and presentation.
Verdict: Measurement finds the gap; catalog repair changes it
A visibility baseline shows where mentions, citations, and product facts differ across prompts. The repair workflow changes merchant-controlled inputs at the level of a stock keeping unit, or SKU, meaning one sellable product or variant.
Start with a fixed prompt set covering actual categories, products, markets, and buyer constraints. A running-shoe merchant could test “waterproof trail shoes under $150 in the US” and “women’s road shoes for wide feet in the UK,” then record the engine, market, date, cited URL, mentioned brand, product, price, and stock claim.
Track four outputs:
- Mention presence: whether the response names the merchant or brand.
- Citation presence: whether it links or attributes a claim to the merchant domain.
- Fact accuracy: whether cited price, stock, and specifications match the current catalog.
- Prompt-set share of voice: the share of a defined prompt set in which the brand appears during one dated run.
Keep the prompts and scoring rules stable. If the team changes “trail shoes under $150” to “best trail shoes,” it has changed the measurement instrument, so the next result cannot be compared cleanly with the earlier run.
The appeal is obvious: more monitoring should reveal the path to more visibility. The evidence does not support that leap. Monitoring can identify an incorrect $89 citation, but only a source-level repair can align that value with the current $79 offer.
Tools in this review of GEO measurement platforms can help diagnose mentions and citations. GEO, or generative engine optimization, means improving the information that generative search and answer engines can understand and potentially cite.
How should you crawl a catalog into one SKU matrix?
Answer first: Create one row for every sellable SKU, including each color and size variant. Extract the visible product facts, machine-readable values, identifiers, category, and update times. This exposes missing fields and conflicts that page-level averages hide.
A product detail page, or PDP, is the storefront page for one product or variant. A jacket shown on one PDP in navy and green across five sizes still represents 10 sellable combinations, each with its own stock and variant attributes.
For every row, collect:
- internal SKU and stable product ID
- title, description, brand, and canonical URL, meaning the preferred permanent page address
- price, ISO 4217 currency code, and availability
- image URL and updated timestamp
- GTIN, the Global Trade Item Number allocated under the GS1 system by a licensed company or through an individual GS1 number
- MPN, the manufacturer part number assigned by the maker
- variant group, color, size, material, and condition where relevant
- merchant category and proposed standard taxonomy category
- visible shipping and return information
Presence and validity need separate columns. The value available is present, yet schema.org expects a defined availability value such as https://schema.org/InStock; a GTIN can have the expected length and still fail its check digit.
Use sellable SKUs as the denominator.
Page counts can miss orphaned variants, products loaded only after a script runs, or combinations hidden behind one selector.
| Catalog segment | Price and currency | Availability | Identity | Variants | Taxonomy |
|---|---|---|---|---|---|
| Priority SKUs | Complete | Complete | Review | Complete | Review |
| Long-tail SKUs | Partial | Invalid | Missing | Partial | Unresolved |
This is an illustrative status matrix. Replace every cell with crawl evidence from the merchant’s catalog.
Reconcile every publication layer around one record
A canonical record is the governed version of a SKU used to generate downstream outputs. Compare that record with the visible PDP, schema.org markup, and each enrolled merchant feed, then repair the system that generated any mismatch.
Check price with currency, canonical URL, availability, variant identity, primary image, and update time. Calculate a source-divergence rate as mismatched checked fields ÷ all checked fields, and segment it by source pair so the team can locate the failing handoff.
| Source | SKU | Price | Currency | Updated |
|---|---|---|---|---|
| Visible PDP | RUN-42-BLK | $79 | USD | 2025-02-14 09:04 UTC |
| JSON-LD | RUN-42-BLK | $89 | USD | 2025-02-12 02:10 UTC |
| Merchant feed | RUN-42-BLK | $84 | USD | 2025-02-13 23:30 UTC |
These values are illustrative product prices. JSON-LD, or JavaScript Object Notation for Linked Data, is a page-level format that labels facts such as product price and availability.
Only one price can describe the current offer.
If $79 is authoritative, correct the pricing source or export rule, regenerate the page markup and feeds, and inspect the rendered outputs after their normal processing delay. Editing only the JSON-LD leaves the feed stale and allows the conflict to return during the next export.
Google’s landing-page requirements state plainly: “The price on your landing page needs to match the price in your product data.” The operational lesson extends beyond one program because a growth report is unreliable when its underlying product facts disagree.
Validate identity before rewriting product copy
Identifiers help systems match records for the same manufactured item. Validate an assigned GTIN against its permitted format and check digit; never fabricate, truncate, or pad a number merely to make it appear valid.
Some databases represent shorter GTIN formats within a 14-digit field using leading zeroes, so formatting rules must be checked in context. When no GTIN was assigned, use the genuine MPN with the accurate brand, and retain the merchant SKU as a separate internal identifier.
Each sellable variant commonly needs its own applicable identifier. A black size 9 shoe and a black size 10 shoe may share a model and variant group, yet they remain separate offers with different stock and potentially distinct GTINs.
Title similarity is weak evidence.
“Acme Trail Pro Men’s Waterproof Shoe” and “Acme Trail Pro Women’s Waterproof Shoe” differ in fit and variant structure even though most title words match; merging them can attach the wrong availability to a product.
Normalize attributes and taxonomy with reviewable rules
Standardize brand casing, model, product type, units, colors, materials, condition, and variant groups while preserving buyer-visible facts. For example, raw.color = "blk" can map to canonical.color = "Black", with the source retained so an editor can reverse an incorrect transformation.
- Visible $79 price
- Usable product image
- Brand stored as ACME®
- Category is Shoes
- Color is blk
- brand: Acme
- color: Black
- priceCurrency: USD
- availability: InStock
- Requires source review
Taxonomy alignment maps a merchant category to a standard product hierarchy. “Weekend Ready” may work for onsite merchandising, but an external system cannot tell whether it contains a backpack, dress, or coffee maker.
For teams using Google Product Taxonomy internally, recommended fields can include googleCategoryId, googleCategoryPath, category tiers, and a review status. These are implementation choices, and they are not universal platform requirements.
Veliu may use an internal field named gpcResolution to record mapping quality with labels such as exact_path, fuzzy, or unresolved. A yoga mat should reach a narrow category only when its type, dimensions, material, and description support that decision; an ambiguous record belongs in a human review queue.

What should each catalog destination receive?
Answer first: Publish accurate visible facts and supported schema.org Product and Offer markup on crawlable product pages. Send program-specific feeds only through the enrollment and transport process described in each program’s current primary documentation, then confirm item-level acceptance.
A merchant feed is a structured product file or transfer submitted to a commerce program. Its required fields, eligibility rules, and delivery mechanism can change, so implementation teams should verify current vendor documentation during deployment instead of relying on a dated secondary checklist.
For the open web, keep the visible PDP aligned with supported schema.org `Product` and `Offer` fields. Structured markup can make product facts easier for compatible systems to parse, although support and retrieval decisions vary by engine.
For an enrolled merchant program, generate its documented artifact from the same canonical record. Confirm transfer status, rejected items, warnings, and freshness through the program’s available controls. Crawler access, feed enrollment, and checkout capabilities should be tested as separate surfaces whenever a vendor documents them separately.
This approach deliberately avoids freezing time-sensitive OpenAI commerce fields or eligibility semantics into the workflow. Before launch, the implementation owner must compare the generated artifact with the current primary specification and save the reviewed version or access date in the deployment ticket.
Verdict: Cleaner catalog data makes AI matching easier
ChatGPT can read product information from accessible web pages and supported structured sources. Gemini, Perplexity, Copilot, and AI Overviews may also use accessible pages or structured product information, depending on each vendor’s systems and current program support.
Consistent identity, offer, taxonomy, and availability fields provide cleaner inputs for reading and matching. Selection, ranking, citations, transactions, traffic, and sales remain under the control of each engine, merchant, and market involved.

The $79 conflict from the opening now has an operational resolution: one authoritative $79 offer, if that price is current, should propagate consistently across the visible page, markup, and every active feed.
Validate the repair before repeating the prompt test
Answer first: Treat publication as a quality-assurance gate. Check field validity, source consistency, program acceptance, and propagation for each affected SKU before rerunning the unchanged ChatGPT prompt set. Visibility movement is an outcome metric, while catalog validity is the controllable input.
| Check | Measurement | Release rule |
|---|---|---|
| Price and currency | Valid value and ISO 4217 code | Block absent or conflicting values |
| Availability | Supported structured value | Block unsupported free text |
| Product identity | Valid assigned GTIN, or applicable MPN plus brand | Quarantine fabricated identifiers |
| Variant integrity | Group plus distinguishing attributes | Review merged sizes or colors |
| Taxonomy status | Distribution by internal review label | Review fuzzy and unresolved mappings |
| Schema accuracy | Parsable fields matching visible facts | Block price or stock conflicts |
| Feed status | Accepted, rejected, and warning counts | Resolve item-level errors in scope |
| Propagation time | Source update to observed output | Investigate breaches of the merchant’s target |
Set thresholds according to catalog risk, update frequency, and the cost of a wrong fact. A sitewide percentage can conceal failures in a launch collection, so report priority products and long-tail inventory separately.
After propagation, repeat the original prompts with the same market, language, wording, and scoring rules. Keep mention presence, citation presence, and prompt-set share of voice in the outcome view; keep completeness, divergence, validation, and acceptance in the input-quality view.
That separation protects the budget conversation.
A changed answer cannot prove that one catalog edit caused the movement, while a passed SKU-level validation can prove that the merchant-controlled input was repaired.
Assign the next action by failure type
- Wrong cited price: trace PDP, markup, and feed values to the authoritative pricing system, repair the generator, and republish.
- Missing product identity: verify the manufacturer-assigned identifier or use the applicable MPN with brand.
- Merged variants: create distinct sellable records and preserve their shared variant group.
- Broad category mapping: enrich supported attributes and send ambiguous products to review.
- Valid page with rejected feed: inspect the program’s current item-level error and required-field documentation.
- Visibility changed with no catalog defect: review prompt stability, cited sources, competitive changes, and engine behavior before opening a data ticket.
OpenAI’s cited public documentation does not describe a general merchant brand-visibility optimization service. Veliu’s first-party product scope is catalog crawling, normalization, taxonomy alignment, validation, and publishing support, subject to the merchant’s implementation and connected systems.
Author and methodology note: Veliu Editorial Team. The method follows one sellable SKU across its visible product page, schema.org markup, and active merchant feeds; checks identity, variants, taxonomy, price, availability, and freshness; records item-level publication status; and repeats an unchanged prompt set after propagation. Illustrative prices and records contain no merchant performance data. Time-sensitive vendor requirements must be checked against live primary documentation during implementation.
Get the next piece when it ships
We send new notes on making your catalog readable and buyable by AI agents as they come out.
Subscribe to the newsletter