How to structure product pages for AI shopping engines

Ask an assistant to find a 12-inch cast iron skillet under 60 dollars that ships this week, and watch what it has to work with. It needs a product name, a number it is confident is the price, a stock state, and enough spec detail to know the thing is 12 inches.

Your product page has all four. It just may not have them in a form a machine can read. The price is a styled span next to a struck-through span. The stock state is a green pill. The size is in the fourth bullet of a marketing paragraph, or worse, in the image of the spec sheet.

A shopper decodes all of that instantly. A machine gets a grid of styled elements and starts inferring, and inference is where your product gets described wrong or skipped.

The four things an engine needs from a product page

Name, price, availability, and enough attributes to match a specific request. That is close to the whole job. Everything below is about handing over those four without ambiguity.

The broader case for why this matters to stores specifically is in AI search for ecommerce stores. This guide is the mechanics.

Do the task

1. Get the facts into real text

Before any markup, check the served HTML. View the page source and search for the price as a string. If it is not there, an engine that does not execute your script will not find it either.

Same for the stock state. A colored pill that reads "In stock" to a person is a styled element with a background color to a parser unless the words are actually in the text. And the same for size, weight, and capacity: if the only place the reader can learn the skillet is 12 inches is the product photo, the machine cannot learn it at all.

2. Write a complete offer, not a partial one

Product schema is the label that says which string is the name and which number is the price. The mechanics for WordPress and WooCommerce are in add Product schema in WordPress.

The failure mode in practice is not missing schema, it is thin schema. A Product object with a name and nothing else technically validates and tells an engine almost nothing.

A complete offer carries:

• price and priceCurrency as separate values, not a formatted string with a symbol baked in
• availability set to the real current state, not a default left over from the template
• itemCondition where new and refurbished both exist in your catalogue
• priceValidUntil when a sale has an end date, so a machine knows the number expires
• shipping and return details where you have them, because those are frequently the deciding attribute in a shopping question

Fill in what is true. Leave out what you cannot back with the visible page.

3. Treat freshness as the actual problem

This is the part that breaks after launch, and it breaks silently.

You run a flash sale. The storefront shows 39 dollars. The JSON-LD block, generated once and cached, still says 59. Nothing errors. The page looks perfect. An engine now has a confidently labeled wrong price, and it is your label, so it wins over anything it could have inferred.

A stale labeled price is worse than no label. Wire the markup to the same source of truth as the storefront so a price change cannot update one without the other, and treat sale start and end dates as events that touch both. If your setup cannot do that automatically, then sale days need a manual check, and you should know that about your own stack before an engine tells a customer the wrong number.

The same drift logic applies to plan pricing on a service site, covered in make your pricing page machine-readable.

4. Publish specs as a table a machine can parse

Specifications are where shopping questions get resolved: the diameter, the wattage, the thread count, the compatible models. Put them in a real HTML table with header cells, one attribute per row, and units written out in text rather than implied by a column heading image.

Three things to avoid. Spec sheets as downloadable PDFs, which most engines will not open on your behalf. Specs baked into a comparison graphic. And specs written only as prose, where "roomy enough for a weekend trip" is doing the work that "42 liters" should be doing.

Keep the prose. Add the numbers.

5. Be honest in the review markup

Review and rating markup is genuinely useful, and it is also the most tempting place on the page to overstate.

The rule is the same one that governs all structured data: the markup describes what the page actually shows. An aggregate rating in the markup should match the aggregate rating a visitor can see, drawn from reviews that exist. Brand-level reviews are not this product's reviews. A rating averaged across a category is not this product's rating.

Beyond the validator risk, there is a plainer reason. Rating markup is a claim about other people's opinions, made in your own voice, in a format designed to be trusted without checking. Getting caught inflating that is a different kind of problem than a stale price.

Old way versus new way

The old way built the product page for conversion: hero image, social proof, urgency badge, everything else compressed into an accordion the shopper opens only if they care.

The new way keeps the conversion layout and adds a machine-readable layer under it. The buyer still gets the photograph and the badge. The engine gets a name, a labeled price, a real stock state, and a spec table it can match against a specific question. You are not choosing between the two readers, you are stopping the second one from being locked out.

The damaging admission

Complete Product schema does not make an engine recommend your skillet. It makes your skillet legible to something that is comparing it with other skillets. That is a prerequisite, not a result, and we will not sell it as more.

It also cannot fix a page with nothing to say. If your specs are thin, labeling them precisely just tells a machine precisely how little you published.

And this work is never finished, which is the honest version of the freshness section. Prices move, stock moves, and the markup has to move with them. Being readable is a state you maintain, not a task you complete.

Where Citedon fits

Citedon's free scan reads your product pages the way ChatGPT, Perplexity, Gemini, and Claude do, and reports what parses, what is missing from the offer, and where the labeled values and the visible page disagree.

Automated apply, with a preview and per-fix approval, runs only through the connected plugin on WordPress and WooCommerce, and it works alongside Yoast and Rank Math. Most stores are not on WordPress, and on Shopify, Wix, or a headless storefront the scan still diagnoses every page and you or your developer make the change.

Run a free scan on your best-selling product page and see which of the four facts an engine can actually read.