Is my product data visible to AI?

Check which product facts a crawler can read, separate access from recommendations, and find missing fitment data before changing your catalog.

Your product page can expose a price while leaving vehicle compatibility unreadable. Is my product data visible to AI? The useful answer is specific to a product, a field, and an access route. Inspect what that route returns, compare the response with your catalog, and test recommendations separately. A readable page alone does not establish that an assistant will select your product.

We recounted the store table in remilink's Fitment Readability Index. Five of the six readable product pages had zero vehicle lines in the recorded HTML. The remaining page had one. Those observations are from September 3, 2026, recounted on September 14, not a fresh crawl.

What does visible product data actually mean?

Visible product data means the facts are available through the access route you are testing. Treat access, field completeness, and recommendation outcomes as separate checks.

Start with a named consumer and channel: a public product-page fetch, Google's indexed page, or an integration you operate. Record the product URL, variant, locale and time. Otherwise a price for one variant is read as evidence about another.

Google Search Central states: "Indexing and serving isn't guaranteed." Google's guidance for AI features requires a page to be indexed and eligible for a search snippet before appearing as a supporting link in AI Overviews or AI Mode. Google also recommends accessible text, crawl access, and structured data that agrees with visible content. Those are Google-specific requirements, not a universal test for every assistant.

Use the distinction in your own acceptance criteria. "The response contains the selected variant's availability" is inspectable. "The catalog is AI-ready" leaves the field, consumer, and evidence undefined.

How can I check what a product page exposes?

Compare a response obtained without a signed-in session or JavaScript execution with the product facts your catalog says should be present.

Choose examples from the templates your store uses: a simple product, a variant product, and one whose purchase depends on compatibility. Keep the URLs so the same pages can be rechecked after a fix.

Ask engineering to capture the response headers and the unrendered HTML. Check whether it carries product content, a challenge, a redirect, or a request to choose a vehicle. Then compare it with the browser view after the normal shopping interactions.

For each page, record the expected value from your catalog beside the value the response carries:

Mark a field as present, missing, conflicting, or untested. Never turn an untested field into a pass, and keep a failed request in the worksheet as a failure.

A generic request meeting a challenge does not establish what a verified crawler receives. Have the infrastructure owner compare crawler policy with access logs before changing any access rule. An empty HTML field likewise does not prove the fact is absent from every feed.

What did the fitment sample actually show?

The recount found five pages with no vehicle lines in HTML, but those pages did not all have the same recorded presentation. Keeping that distinction helps frame the next diagnostic.

Each row is one group of the six readable pages, labelled with how many pages fell into it. Blue marks the pages carrying no vehicle lines at all. Teal marks the single page that carried one. The smaller line under each row is what the observation does not settle.

The sample covers one product page per store. It does not establish store-wide behaviour, verified crawler access, or recommendation frequency.

For an empty widget, inspect whether the response that fills it carries approved compatibility data. For a page with no fitment section, check whether compatibility is held elsewhere. A single visible vehicle line still needs a completeness check. Presence is not coverage.

This is why a readability review should name missing fields instead of stopping at a product-schema pass.

Is Product structured data enough for fitment?

Product structured data can describe a product without establishing all the vehicle conditions needed for a correct fitment answer. Validate compatibility against your catalog records separately.

Google's Product structured-data documentation describes product snippets, merchant listings, variants, and product feeds through Google Merchant Center. They are ways to give Google product information, not a test of whether a part fits a vehicle.

Schema.org defines isAccessoryOrSparePartFor as a relationship from a product to another product for which the first is an accessory or spare part. Its existence does not establish that a downstream consumer supports your compatibility model.

For auto parts, start with the approved applicability record, including engine, production-date and other exclusions. Expose that record as readable text or through an integration with an explicit contract. Test a known fit, a known non-fit and an unknown case. Keep unknown distinct from compatible.

If identifiers or applicability records conflict, resolve the conflict in your data foundation before copying the values into more outputs. remilink's catalog and semantic-search case study is related work on product discovery, not evidence of external assistant visibility.

What should I fix and measure first?

Fix the earliest observed failure, then repeat the same request and field comparison. Give the fix an owner and retain before-and-after evidence.

If the response is blocked, investigate access policy. If approved facts appear only after interaction, work out how to put them in the initial response. If values conflict, trace the publishing paths back to the catalog. Avoid adding another copy of a value nobody owns.

For a proposed catalog integration, define the consumer, accepted identifiers, update behaviour and treatment of unknown compatibility before implementation. Judge it by the answers it returns for your test cases.

After access and data checks pass, record recommendation observations separately: the question, assistant, date, cited URL, selected product and factual errors. An observed mention does not establish a stable ranking or a sales effect.

A benchmarking brief holding the sampled URLs, expected facts, failed checks, fixes and retest criteria is what your delivery methodology hands to catalog and engineering owners.

FAQ

Does a readable product page guarantee an AI recommendation?

No. Readability establishes only that the tested response contains the facts. Recommendation testing records separately whether an assistant selected the product and represented them correctly.

Do I need an llms.txt file for Google AI features?

No. Google says additional AI text files and special structured data are not required for AI Overviews or AI Mode. Follow Google's documented indexing, snippet eligibility, and content requirements.

Does a successful fetch mean my fitment data is visible?

No. Inspect the compatibility fields in the returned content. A response can contain a product name and offer while omitting the applicability information needed for a fitment answer.

Should I build an MCP server for my ecommerce catalog first?

Start with a demonstrated consumer requirement. If the integration uses Model Context Protocol, define and test the product and compatibility operations it needs. An endpoint alone is not evidence that an assistant connected to it or recommended a product.

How do I tell missing data from data hidden by JavaScript?

Compare the initial HTML, the browser view after interaction, and the approved catalog record. Record where the expected value appears. If you have not inspected the underlying record or interaction response, leave the cause unresolved.

Can I use the six-page count as my store's visibility score?

No. The count describes a historical sample from other stores. Build your own field-level record and keep the sample boundaries attached to every result you report.