The perfect product page for shopping AI

What do shopping AIs actually read?

Three sources, and they aren't equal. First, the structured data placed in the page: a standardised block declaring "this is a product, it's called X, it costs Y, it's available". That's the common language of the commercial web, and it's what engines read first because it needs no interpretation.

Then product feeds — a file listing a whole catalogue at once, with one field per piece of information. That's what shopping engines and, increasingly, buying agents consume: a clean list beats a thousand pages to crawl.

Last, the visible text, which stays useful for what no field encodes: the material, the use, what makes your piece different. But it comes last, and it never compensates for the absence of the first two. A beautifully written page with no declared price is, to a machine, a product with no price.

Remember the hierarchy: what is declared gets read, what would have to be guessed gets ignored. A price written only inside an image or a sentence doesn't exist.

• The page's structured data: the foundation, read first.
• Product feeds: the whole catalogue, in one file.
• Visible text: what differentiates, once the rest is readable.
• Images: they must be publicly reachable, not just attractive.

Which fields make the difference?

Seven, and the order matters. The exact title first: what someone would type, not a play on words. "Blue glazed stoneware bowl 12 cm" gets found; "Azure Reverie" doesn't. Then the price, with its currency, as a number — not a range, not "from" as the only information.

Availability, which often decides on its own whether a product is offered: an assistant avoids recommending something out of stock. Brand and identifiers — the product's barcode, the manufacturer reference — which let your offer be matched against others. They're optional for a one-off handmade piece, and there a field declares exactly that: "no identifier", which is information rather than a hole.

The item's condition, new or used, which completely changes how it matches a request. The category, which files your product into the taxonomy shopping engines use. And the images, several of them, reachable at a public address.

The rest — material, dimensions, dispatch time, returns terms — lives in the description. That's what answer engines quote when comparing two similar products, and it's also what saves a buyer from having to write and ask.

What does Mopsee publish automatically?

Every product page emits a block of structured data describing the product and its offer: name, description, images, brand, barcode, manufacturer reference, price in the shop's currency, availability derived from stock, condition, and the seller. When an offer has no publishable price — a quote, for instance — no offer block is emitted at all, rather than an empty one: declaring an offer without a price is worth less than declaring nothing.

Every shop also publishes its business description, the ordered list of its products and a breadcrumb, so the catalogue's structure is readable without exploration.

Two product feeds are generated and kept up to date on their own. One follows an open format aimed at buying agents, the other the format shopping engines expect. Both use the same data: what you correct in your product page reaches both on the next pass.

Finally, every shop exposes its catalogue as plain text, for assistants that would rather read a clean page than interpret a layout. None of this needs enabling: it's produced on publication.

• Product page: product and offer declared, with price, currency, availability, condition, brand and identifiers.
• Shop: business, ordered product list, breadcrumb.
• Two product feeds, one for buying agents, one for shopping engines.
• Catalogue as plain text for assistants.
• Sitemap covering shops, product pages and guides.

What's left for you to do?

The substance, meaning everything no system can guess. The price, first: with no amount, your offer is published as a quote, and a quote doesn't enter a product comparison. It's the leading cause of absence from recommendations, and it's fixed in thirty seconds.

Then the measurable data: dimensions, material, weight, capacity, duration. They're what lets an assistant answer "yes, this one is indeed 12 centimetres" instead of dropping your product out of caution.

Stock, kept up to date. False availability is worse than no availability: the first disappointed buyer doesn't come back, and out-of-stock signals propagate.

Finally the images: several per product, sharp, showing the object from several angles and at scale. And if you resell identified articles, fill in the barcode and the manufacturer's brand — that's what lets your offer appear alongside the others instead of alone in its corner.

How do you check your page is machine-readable?

Three checks, all doable in minutes and with no paid tool.

First: open your product page's source and look for the structured data block. It must contain the name, price, currency and availability. Paste it into the schema.org validator: zero errors expected.

Second: open your shop's product feed and check your item is in it, at the right price. A product missing from the feed is a product invisible to buying agents — the cause is almost always a missing price, an unpublished offer, or an excluded sales format such as an auction.

Third: ask an assistant to describe your product from its address. Whatever it gets wrong is exactly what's missing from your page. It's the test closest to real use, and the most instructive.

• The structured data block is present and valid.
• Price and currency are in it in plain form, with availability.
• The product appears in the shop's product feed.
• An assistant can restate what your product is from its address.