Intelligence

AI Product Intelligence checks whether AI shopping assistants can understand your products. Use it to find products that are missing the plain facts a machine needs, such as sizes or materials.

It doesn't have its own admin page. You'll find it in Insights → SEO, as a group of stats and four checklist rows.

Despite the name, Litestore doesn't call an AI model here. A set of rules reads your catalog and reports what it finds.

Litestore scores each published product on three questions:

1. Does it list structured attributes, such as Size = M?
2. Does it have intent tags?
3. Is it linked to related or add-on products?

The same step that answers the first question also publishes those facts. Litestore adds them to the product page's JSON-LD and to the product feed.

This matters because an AI shopping assistant can't work out from a paragraph of marketing copy that a shirt comes in medium. It can read a declared attribute pair.

The four audit rows

The report flags products in four cases:

1. No structured specs at all
2. Fewer specs than your minimum
3. No intent tags
4. No related or add-on products linked

The minimum number of specs is a setting. It defaults to:

3

If a published product has fewer structured specs than that, Litestore flags it as thin.

Each row appears in Insights → SEO with the prefix AI ·, next to the ordinary SEO findings.

The peer norm

The most useful check needs no setup from you. Litestore compares each product with the other products in its category.

An attribute counts as expected in a category once at least half of the category's products declare it:

≥ 50% of a category's products must declare a key
only in categories holding ≥ 3 products

Both parts of that rule matter.

The 50% threshold means the norm comes from what you actually sell, not from a fixed list someone wrote. Say most of your jackets declare a shell material. A jacket without one is clearly incomplete, and the report says so. Nobody had to set up a "jackets need shell material" rule.

The three-product minimum stops a tiny category from inventing a norm. In a category of two, one product declaring a key would already be 50%. That would be noise, not a real pattern.

When a product is missing an expected key, Litestore lists it with the exact labels its peers use. To fix it, you copy a label that already exists in your catalog instead of guessing what to call it.

The comparison ignores capital letters and spaces around the text, so Material and material count as the same attribute. Otherwise one inconsistent capital letter could split a category's norm in two and hide the gap.

One pair per value

Litestore builds each product's attributes from two sources and merges them. It uses the product's curated specifications and its variant options. If both have the same key, the specification wins.

What matters most is how Litestore writes the values. Each value becomes its own pair:

Size = S
Size = M
Size = L

It doesn't write one joined string like Size = S, M, L.

A machine reading separate pairs can answer "do you have this in medium?". A machine reading the joined string has to parse it, and it will sometimes get it wrong.

Litestore has no built-in list of attribute names. Whatever name you give an attribute is published as it is, so you never have to wait for a name to be supported.

Litestore publishes at most:

60 pairs per product

One source for two places

Litestore uses the same code to publish attributes, keywords and related products in two places.

On the product page, it produces these JSON-LD fields:

• additionalProperty
• keywords
• isRelatedTo

In the product feed at /api/products/feed, it produces the same JSON-LD.

Because one piece of code serves both, the product page and the feed always agree about a product's attributes. When you fix something once, the fix shows up in both.

The feed adds one thing the product page doesn't. It also lists attributes for each SKU, taken from the option values each variant uses.

What is shared and what isn't

Litestore builds the return policy from your return window setting. It publishes it as MerchantReturnPolicy in both the product page schema and the feed.

If you don't offer a return window with a fixed length, Litestore leaves the return policy out completely rather than guessing. A wrong returns promise in structured data is worse than none, because a shopper's assistant will repeat it to them.

Two things don't use this shared code yet:

• Litestore doesn't publish shipping details through it.
• Litestore still calculates price and availability separately for the product page and the feed.

Keep the second point in mind. Price and availability have two separate code paths, so unlike attributes, they aren't guaranteed to agree.

Where the rules are in the code

If you're a developer and want to read the rules themselves, look in these files:

lib/aio/attributes.ts
lib/aio/audit.ts
lib/aio/commerce.ts
server/admin/aio/queries.ts

None of this code calls a model, and none of it writes a stored score.

Working through the rows

1. Fill in specifications and options first. Both count as attributes. An option you already added for variants does double duty here.
2. Open Insights → SEO and work through the four AI · rows. They cover missing specs, thin specs, missing intent tags and products with no related or add-on links. Then work through the peer gaps.
3. Publish. The product page and the feed both update from the same data.

Take the peer gaps seriously, even when a product looks finished. They are the only findings based on what your own catalog already treats as normal, and they give you the exact label to use.

For every product, the feature asks one question:

Could a machine answer a shopper's question about this product without reading the marketing copy?

Related