Before You Optimize for AI, Check What Your Store Actually Sends

Imagine a fictional Shopify team discussing AI shopping. Someone reads that shoppers are starting to ask AI assistants for product recommendations. They panic a little. They open a new tab and start searching for the file, the plugin, the schema, the trick that will get their products "into AI."

Today I want to suggest the opposite. Some of those things may matter later. But before you optimize anything for AI, check what your store actually sends. You can't improve a signal you've never looked at.

Welcome to this educational series from Verity Score, about GEO and AI commerce for Shopify merchants. Verity Score makes a Shopify app focused on GEO, generative engine optimization. AI commerce is the wider subject of this series. So we have a point of view, and we keep the product promotion brief. The platform facts come from public documentation by Shopify, Google and OpenAI. The exercises are our editorial recommendations, and the store example is fictional. The links, and the date they were reviewed, are in the show notes. The platform details were checked on October twenty-first, twenty twenty-six. If the documentation changes, use the current version.

And nothing here is a promise. No one can promise that your products will be recommended, cited or sold through an AI assistant. What you can control is whether what you send is accurate, complete and consistent.

One task today: make a dated record for one product in one market. We will map the routes it could take, preview the data checks, and decide what needs verifying before any changes.

To keep it concrete, let's follow that imaginary team. It is a small luggage brand selling carry-ons, weekenders and a couple of backpacks. It's based outside the United States, and it sells to customers in the US. Its products and policies are invented for this example.

First, the routes. The most useful idea I can give you today: there isn't one door into AI shopping. There are at least two, and they work differently.

The first door is data you transmit. Shopify's help center describes Catalog: your product data can be made available to eligible channels through it. For Google, Shopify points to the Google and YouTube app and Google Merchant Center.

The second door is the open web. Search engines and other systems can crawl your public pages, and that's a separate process. Here's a useful distinction from Shopify's documentation: robots.txt, the file that gives web crawlers instructions, does not block Catalog transmission. So if our example store blocked a folder in robots.txt to keep some products out of AI channels, that doesn't hold for Catalog. Two doors, two sets of rules. For our example store, that means two questions: is the Catalog route active for the channels it cares about, and are its product pages public and indexable?

Now, ChatGPT. Shopify has a help page for selling through it. As we read it, it applies to stores selling to US customers, with Catalog eligibility requirements, terms to accept, and complete store policies. And on checkout: the shopper is sent to your store's checkout, not a Shopify checkout inside the chat. You may have read about instant checkout with other merchants on OpenAI's side. Don't assume that applies to the Shopify channel. Read the page for your channel.

A store can be based outside the US and still qualify if it sells to US customers and meets the requirements. That does not establish our example store’s eligibility. If you sell only in other markets, check the routes available there.

Google's AI features? Google says you don't need a special file or a special schema. It points to access and indexing, and even then, there's no guarantee of appearing. Shopify also describes native agents.md and llms URLs. Good to know they exist. Just don't treat them, or an llms.txt file, as a key that unlocks AI visibility. Nothing in the documentation we're using says that. If someone sells you one as a shortcut, ask them which documentation says so.

Last point. OpenAI says product results in ChatGPT are selected based on context, using metadata, and may not include every product. A position observed in one answer should therefore not be treated as a universal ranking. Record the question and the conversation context you can actually observe.

So, block one in a sentence: data you transmit and pages that get crawled are different routes, with different rules, and neither comes with a guarantee.

If selection depends on your data, the next question is whether your data tells the truth. Four checks preview the rest of the series. Today, record the product page and the source your team trusts. Do not change anything during this first pass.

First, identity and offer. Can the shopper and your team unambiguously identify the same product and variant? Does the offer specify price, currency and availability for the intended market? Google's merchant listing documentation requires the machine-readable information to meet its conditions and match the visible offer. We will inspect that layer later. If you cannot inspect it reliably, record it as not checked and assign it to the person responsible for the theme or feed.

Next, policies and answers. Shopify's ChatGPT documentation requires complete policies. Check which shipping and returns information applies to your target market. Shopify also offers a Knowledge Base app whose FAQs are separate from your storefront FAQ page. If you use both, an answer can differ between them. In our example, imagine one says a backpack fits a fifteen-inch laptop and the other says thirteen. Consistency alone cannot tell you which is right. You need a verified specification or measurement, and someone responsible for it. Save the discrepancy before changing either answer.

Identity, offer, policies, answers. Start with one product and one market. Once the method is clear, expand to a small sample that includes a product with known inconsistencies.

Block three. Before you fix anything, write down what you see today. This creates a record you can use to compare later observations.

Open a spreadsheet, one row for the product and market you chose. Record the date, product and variant, public page address, target market and currency, and the source your team uses to verify the product facts. Then list the routes you actually use. A channel listed in a help article is a possibility to investigate, not proof that your store is connected.

For Catalog and connected channels, record what your own admin shows and the current documentation you used. If you cannot establish the transmission status, write “not verified.” Do not turn an unanswered question into “active” or “blocked.” For the public web route, record whether you can open the page as a shopper. That is a useful first observation; it does not prove that a crawler can access it or that a search engine has indexed it. We will investigate those questions separately.

For our luggage team, the first row might concern one carry-on sold to US customers. The team records which variant it means, the displayed US price and currency, the policy pages that apply to that market, and the documented eligibility requirements for the channel. Any status they have not checked stays unknown. Their location outside the US is one detail in the assessment, not a verdict on its own.

Then assign the unanswered questions. Who can confirm the dimensions? Who owns shipping information? Who can check the connected channel settings? Give each question an owner and keep the evidence with the row. This is the record another colleague should be able to inspect without asking what you meant. If the data conflicts, save the original statements before approving a correction. After this first recording pass, make any approved corrections and log their dates.

What about asking an AI assistant to recommend your product? We will build that observation protocol next time. A mention, a source citation, a recommendation, a visit and an order need different evidence. They do not form a compulsory sequence. A source can be cited without its merchant being recommended. An order can happen later without an attributable visit from an assistant.

One run is a snapshot. A repeatable protocol improves comparability without holding the model or all context constant; we will detail that protocol next time. A changed answer after a product edit does not establish that your edit caused the change. Customer questions can help shape your research when their use is authorized. Remove identifying details and never paste a raw customer conversation into an AI tool without appropriate authorization. Otherwise label questions as hypotheses instead of calling them customer demand.

So, your action for this week is deliberately small. One product, one market, one dated record. Identify the public page, your verified source of product truth, the channels you actually use and the eligibility questions you still need to answer. Save discrepancies before changing them. You do not have to complete four technical audits or prove AI visibility to finish this first exercise. Episodes four and five will take the data and policy checks further.

You can find Verity Score and the episode resources in the show notes. And if this was useful, send it to the person on your team who keeps getting asked, "Are we in AI yet?" This episode gives them a way to start that record.

Thanks for listening. Next time, we will separate a product mention from a source citation, a recommendation, an attributable visit and an observed order. Those are different observations, and they need different evidence.