One Product, Conflicting Offers

How many versions of your product exist right now? Not variants. Versions. There's the product in your admin. There's the page a shopper sees. There's the structured data hidden in that page's code. And there's whatever your store sends to the channels you've activated. If you sell in more than one market, multiply that by each market. So today's question is simple to ask and slow to answer: where can your product information drift, and how would you know?

You're listening to Verity Score. This educational series is for Shopify merchants. Last time, we built a product truth card: one internal place where a product's job, its verified attributes and its unknowns are written down with evidence. Today, we take one product's facts out of that card and follow them everywhere they travel, to see whether they still agree when they arrive.

We're staying with the fictional luggage team. This time, the product is their weekender duffel. The store, the bag, the markets, the prices and every mismatch I describe are invented for the example. No real store, buyer or channel result is involved.

The team sells to customers in the US and in the UK. In their admin, the weekender is one product with two colors. Each market has its own currency and its own price. Shipping to each market is set up separately.

One morning, someone on the team opens the product page twice, side by side. One window is set to the US market, the other to the UK market. They're not testing an AI assistant. They're simply reading what a shopper in each market would see.

The first difference is expected. The US page shows a dollar price, the UK page shows a pound price. That's how the markets were set up, and it's fine.

The second difference isn't expected. The description on both pages gives the bag's capacity and size in metric units, because that's how the supplier's sheet was written. But the US page also has a specification table, added months ago by a freelancer, that gives the size in inches. And when the team converts the inches back, the numbers don't quite match the metric ones. The difference could come from an error, rounding or a different measurement method. The team must check before deciding.

The third difference is in shipping. The UK page has a banner saying delivery is available across the UK. But the shipping settings the team checks in the admin don't cover every part of the UK. In our fictional case, the banner was written before a change in carrier, and nobody updated it.

The fourth difference only shows up when someone opens the page's source code. The structured data, the block of code that describes the product for search engines, lists the price and availability. On the UK page, in our fictional case, that block shows availability as "in stock" for both colors. But the person responsible confirms that the camel colour is unavailable for sale in the offer being checked. This example does not assume that Shopify has a separate native stock counter for every market.

Four differences. One is intended. Three are drift. And none of them would have shown up if the team had only looked at the admin, which is only one place to check.

Let's take the versions one at a time.

The admin record is one place your team publishes product information. It is not automatically the final authority on a physical measurement or a commercial promise. Compare it with verified specifications, measurements and the people responsible for the offer. Other surfaces may copy or render some fields while adding information from elsewhere.

The page is what a shopper reads. It's also what any service that reads web pages can see, if it's allowed to. And here, text that someone added by hand, like that specification table or that shipping banner, can contradict the admin without anyone noticing.

The structured data matters for Google in particular. Google's documentation on merchant listing structured data, which we reviewed on October twenty-second, twenty twenty-six, describes the Product and Offer types. It asks you to look at the product or variant, its price, currency and availability, within the scope of the surface you're targeting. It also says that validating your markup doesn't promise that it will be displayed. Passing a markup check establishes only what that particular check covers. It doesn't tell you the code agrees with the page, or with your stock.

And then there's the feed. On Shopify, the documentation for Catalog describes it as sharing product data with eligible channels you've activated, including the title, description, options, images, price and availability. It describes mapping for custom data and for grouping variants. And for Google, that same documentation says the route goes through the Google and YouTube app. Description and per-colour availability are fields Catalog can share. Whether that US-only specification table travels depends on where it is stored; the team must check instead of assuming the page rendering and transmitted data are identical.

What can't the team see? In this example, the team cannot establish exactly how a given channel stores or displays what it received, or when it last refreshed it. That's an unknown, and it belongs in the reconciliation as an unknown, not as an assumption.

Now, a word about markets. The team sells in the UK. That's a commercial fact about their store. It doesn't tell us whether any particular AI shopping channel is available to UK buyers, or how it would work there. This episode doesn't answer that question, and you shouldn't infer it from what I've said. If you want to know about a channel in a specific country, check that channel's current documentation for that country, and date what you find. Our comparison stays with what the team can see: its own pages, its own markup and its own settings, market by market.

Also, this episode isn't legal advice. If you're unsure about how prices, units or delivery claims must be presented in a given market, that's a question for a qualified advisor in that market, not for a podcast.

The team doesn't fix everything at once. They reconcile one product first, carefully, and they write down what they found. That's your action this week: reconcile one product across your admin, your page, your structured data and any feed you've activated.

Here's how. Pick one product that sells in more than one market, or one product with several variants if you sell in only one. Make a table. The rows are the fields that matter to a buyer: title, variant, price, currency, availability per variant, shipping scope, units and any size or capacity claim. The columns are the places those fields live: the admin, the page for each market, the structured data on each page, and the channel view, where your admin gives you one.

Fill in each cell with what you actually see, and the date and time. If you can't see a field in a place, write "not visible," not "probably the same." Then mark each row as matching or not matching, and for each mismatch, decide which version is the truth, using your product truth card. That's the version every other copy should follow.

For our team, the outcome looks like this. The metric measurements on the supplier sheet get checked against the actual bag, and the specification table gets corrected or removed. The UK shipping banner is rewritten to match the configured shipping options. And the structured data for the unavailable colour gets investigated: does the markup describe one offer for every colour, or is something cached? They don't know yet. That row stays open, with an owner and a date.

Notice what the team didn't do. They didn't add more text to the page to compensate. They didn't change the feed by hand to paper over a page problem. And they didn't assume that fixing the page would instantly change what any channel shows. They fixed the source, checked each copy, and wrote down the time of the check, so they can look again later and compare.

One more thing. After you make a correction, do the side-by-side check again. A fix in one place can reveal a second copy you didn't know existed. That's normal. It's also why the table has a column for the date.

So, to recap the idea, not the steps. Your product exists in several versions at once. The admin is one publishing record, the page is what shoppers read, the structured data is a description for machines, and the feed carries fields to channels. Validation is not agreement. And each market can drift in its own way. Next time, we'll leave the product page and look at the questions buyers ask before they buy: care, delivery and returns. We'll ask who owns each answer, and what happens when two answers disagree.

Sources and review dates are in the show notes. This episode is read by a synthetic voice.