We checked 24 Polish stores: can an AI agent buy from them?

An AI shopping agent never looks at your page, it reads a product record. So we checked what that record holds across twenty-four Polish stores: nine fields a purchase cannot close without, from identifier to return terms. Seven stores could be read. In none of them was the selling unit, the delivery date or the return terms present as data. Price and currency were everywhere. Below are the raw numbers, the method, and what these figures must not be used to claim.

Three fields appeared nowhere at all

Aggregate result across the seven stores we could read, ordered from present to entirely absent.

Our own measurement on 25 August 2026, four product pages per store. The run was repeated three times with an identical result.

The table splits cleanly in half. The top rows are fields Google has asked for over several years so that a product can appear in shopping results. The bottom rows are fields a search engine never needed, because displaying an offer does not require them. An agent needs both halves at once to buy.

Stores did exactly what they were asked to do, and not one step further.

Seventeen stores could not be read at all

This finding matters more than the missing fields, because it covers most of the sample. The reasons break down like this: seven stores serve product pages with no structured data whatsoever, four reject traffic that identifies itself as a bot, four have no sitemap listing product addresses, and in two we could not fetch a single page within the time budget.

The second group is worth a pause. One large chain carries a rule in its robots.txt explicitly forbidding access to product page addresses, while also rejecting bot-identified requests with a 403. We do not know the reasoning and it may well be sound, such as guarding prices against competitor scraping. The side effect is that the store also closes the door to the crawlers that feed language model answers.

While we were there we checked access for ten AI crawlers, from GPTBot to ClaudeBot. None of the seven readable stores blocks any of them in robots.txt. That is good news, and also a hint that blocks tend to come from firewall configuration rather than a deliberate line in a file.

Variants buried in the product name, an error nobody sees

In four stores out of seven the colour or finish lives inside the product name rather than a separate field. A name like „Self-adhesive quad hook, matte black” reads perfectly well to a person. To an agent it is one product with a long name, not a colour version of something that also comes in other versions. When a customer says „matte black, size forty”, the agent has nothing to narrow by and moves to a store where the variant is a field.

In one store selling made-to-measure goods the structured data reported a price of zero. That is typical of configurators that price only after dimensions are entered, but an agent reads such a record as a free product or drops it from comparison. We took similar cases apart field by field in our piece on what an AI agent sees in your store.

How we measured it

The method is simple and deliberately repeatable. For each store we fetch robots.txt, find the sitemap, sample product pages from it and read schema.org structured data from each one. We test for the presence of nine fields and nothing else. The whole measurement is deterministic, with no language model involved, so the same store always yields the same result and every gap can be pointed at in the page source.

• Sample: 24 stores, mostly large chains and brands you would see advertised, plus a few smaller ones.
• Scope: up to four product pages per store, spread across the whole sitemap rather than taken from one section.
• Date: 25 August 2026. The measurement was repeated three times with the same result each time.
• Manners: we respect robots.txt, identify ourselves in the User-Agent header, space out requests and store none of the fetched content.

We did not work around any blocks. A store that refused our request is counted here as unreadable, and that is all.

Limits worth knowing before anyone quotes these figures

The sample is small and not random, so this is not a representative picture of Polish eCommerce. It is skewed towards large chains with in-house technical teams, and those usually hold better data than the market average. So if these numbers are wrong in any direction, it is most likely that they are too optimistic.

• Four product pages per store reveal a template, not a catalogue. A store running several templates may score differently across categories.
• We test whether a field is present, not whether its value is correct. A field filled in wrongly counts here as present.
• We do not compare structured data against the product feed, because feeds are not public. That gap hides some of the most damaging errors.
• Unreadable stores may hold perfectly good data they simply do not expose to automated clients. From an agent’s point of view the outcome is the same, but it is not the same problem.

Our own tool lied three times before it told the truth

This section is here because without it the numbers above would be worth less. While it was being built, the engine we measured with accused a store of something it had not done on three separate occasions, each time for a different reason.

• A store did publish its price, but the currency symbol was written as HTML entities, so the amount „was not” on the page. The tool reported a mismatch that did not exist.
• A price written „1.299,00 zł” was read as 299, because the dot there is a thousands separator. Another mismatch out of nothing.
• An address taken for a product page turned out to be a category listing, so we compared one item’s data against another item’s price.

After the third attempt we removed that feature rather than patching it again. Measuring a price mismatch credibly requires rendering the page, not pulling amounts out of source code. Two further bugs ran deeper: one store scored too low because it publishes tax status inside an array rather than an object, another because its product page carried extra records from a „bought together” section. Both fixed, and both raised somebody else’s score once fixed.

Check your own store and start with three fields

You can run the same measurement on your own store for free in our agent readiness check. Enter an address and you get the list of gaps with a fix for each one, plus a ready record to paste. If your result shows the same three zeroes the studied stores had, start there: selling unit, delivery and returns are the only fields where an agent does not guess, it gives up.

And if you are weighing whether any of this is worth doing before something larger, we set out that order in our piece on what an AI assistant in a store can realistically do. Briefly: product data is fixed once and then works for search, sales channels and model answers at the same time.