AI Assistants Read Your Product Pages Worst — And That's the Page That Sells

You have probably already done a round of AI visibility work. Rewrote the homepage copy. Added FAQ schema. Published the buying guides. Checked that ChatGPT and Perplexity mention the brand when someone asks for a recommendation in your category.

Then you looked at where the AI-referred traffic actually lands. Not the homepage. Not the guides. It lands on product pages, and it converts better than almost anything else in your mix.

So here is the question worth sitting with: can an AI assistant actually read those product pages? Most brands have not checked. Adobe has, across the whole US retail sector, and the answer is uncomfortable.

The number nobody expected

Adobe's Q2 2026 AI Traffic Report, published 16 April 2026, is built on more than a trillion visits to US retail sites plus a survey of over 5,000 US consumers. Alongside the traffic data, Adobe ran its AI Content Visibility Checker across the sector — a diagnostic that scores a page from 0 to 100% on how much of its content a large language model can actually read. A score of 66% means a third of the page is invisible to the machine.

Here is the sector benchmark:

• Returns and exchanges pages: 82%
• Contact us: 81%
• FAQ: 80%
• Customer service / help center: 79%
• Loyalty and membership: 78%
• Homepages: 75%
• Category pages: 74%
• Store locator: 73%
• Product pages: 66%

Product pages came last. The pages that describe what you sell are the pages machines read least well on the average US retail site. Your returns policy is more legible to an AI shopping assistant than your product is.

Adobe's own framing is blunt: retailers have thousands of SKUs, and much of that content is currently invisible to LLMs.

Why this is expensive right now, not later

The same report puts a price on it.

In March 2026, AI-sourced traffic to US retail sites converted 42% better than non-AI traffic — a record high in Adobe's data. Twelve months earlier, in March 2025, the same channel converted 38% worse. That is roughly an eighty-point swing in one year. Traffic from AI sources to US retail grew 393% year over year across Q1 2026.

And once an AI-referred shopper arrives, they behave like someone who has already made up their mind: 12% higher engagement rate, 48% longer on the page, 13% more pages per visit than other channels.

Read those two findings together and the problem states itself. The highest-intent traffic in your mix is arriving because an assistant read a page about your product — and on the average US retail site, a third of that page is not readable by the thing doing the reading. Every product where the assistant could not confirm the material, the fit, the compatibility or the return window is a product it recommended less confidently, described more vaguely, or skipped.

Why are product pages the least readable page type for AI?

Product pages score lowest because their decisive facts — specs, materials, sizing, compatibility, availability — live in images, JavaScript tabs and filter facets rather than in server-rendered text and complete Product schema. Adobe's 2026 benchmark puts US retail product pages at 66% machine-readable, against 75% for homepages. The fix is the data layer, not the copy.

Three engineering reasons product pages score lowest

We build and run commerce platforms, so this pattern is familiar. It is almost never a content problem.

1. The facts live in pixels and scripts

Spec tables exported as images. Size charts inside a modal that only loads on click. Materials and care instructions in a tabbed accordion that populates via JavaScript after interaction. A human sees all of it. A retrieval agent that does not execute scripts, or does not wait for them, sees a heading and an empty container.

2. Attributes exist as facets, not as statements

This one is subtle and extremely common. Your catalog knows the jacket is waterproof — waterproof: true sits in the search index and powers a filter checkbox. But the page itself never says "waterproof" in readable text, and your Product schema never declares it. The attribute exists in your database and not on your page. Filters made the fact machine-queryable for your own site search while leaving it machine-invisible to everyone else.

3. Variant sprawl with thin, templated copy

Color and size variants generating dozens of near-identical URLs, templated descriptions that differ by one word, and canonicals that were configured once and never revisited. The differentiating attribute — the thing a shopper actually asked the assistant about — is the one thing the variant page does not clearly state.

What to fix, in order

Order matters here. Most teams start at step three and wonder why nothing moved.

1. Score your own PDP template first. Fetch it the way a retrieval bot does: no JavaScript execution, no cookies, no session. Whatever survives is what the assistant sees. Do this before you write a word of new copy — it usually reframes the whole project.
2. Complete the Product schema, not just the required fields. Most product markup stops at name, price and availability. Complete markup declares GTIN, brand, material, color, size, audience, shipping details and return policy. Incomplete Product markup is the norm; complete Product markup is a genuine differentiator, because it hands the assistant facts it does not have to infer.
3. State attributes in prose, not only in facets. One honest paragraph per product that says the specs in sentences. Not marketing adjectives — the actual claims a shopper filters on.
4. Server-render anything behind a click. If a fact lives inside a tab, an accordion or a modal, it belongs in the initial HTML too. Keep the interaction for humans; stop making it a precondition for the content existing.
5. Then look at on-site search. Deliberately last, and here is why.

The on-site half of the same problem

Shoppers who arrive from an AI assistant have already compared, filtered and narrowed. They land on your site still speaking the way they spoke to the assistant — "waterproof but breathable, under $150, ships this week."

Keyword search returns nothing for that. Vendor benchmarks put null-search rates across ecommerce catalogs in the 10–30% range with best-in-class under 5%; treat those as directional and measure your own. The point is structural rather than statistical: a rising share of your visitors now search in full sentences, hitting a search layer built for two-word queries.

Semantic search fixes this — but only if the attributes it needs are actually modeled. Bolting a vector index onto a catalog whose facts live in JPEGs and JavaScript produces confident, wrong answers. The structured attribute layer that makes your product page legible to an outside assistant is the same layer your own AI search and recommendations run on. Build it once and both problems resolve.

Where we stand on this

We are not going to claim a benchmark we have not measured on your store. What we will say is that we build this layer for a living and run it on our own commerce platform — MnT Commerce has semantic search, a shopping assistant and an ops agent in production, which is how we know where these builds break.

If you want to know how your product pages score before spending anything, we run a free agent-readiness audit: we fetch your PDP template the way a retrieval agent does, show you what survives, and tell you what to fix in order. If the honest answer is that your data layer is already in decent shape, we will tell you that instead.

Figures cited from Adobe's Q2 2026 AI Traffic Report, published 16 April 2026.