Skip to content
Arab SEO
E-commerce SEO

How to Optimize Product Pages for AI Shopping Assistants

Arab SEO Team14 min read0 views
How to Optimize Product Pages for AI Shopping Assistants

For twenty years, e-commerce optimisation meant persuading a human. Better photography, a tighter headline, a trust badge near the buy button. An AI shopping assistant looks at none of that. It reads your data, filters it against what the shopper asked for, and names two or three products. Your homepage, your lifestyle imagery and your brand story never enter the conversation — and if one attribute is missing from your catalogue, you are not ranked lower, you are excluded from the comparison entirely.

Quick answer: make your product facts machine-readable in three places. Put complete Product and Offer schema on the page — including availability, shipping and returns, not just name and price. Publish a merchant feed so you enter the consideration set at all. Then decide whether to support an agentic checkout protocol so an assistant can complete the purchase. Completeness beats cleverness: the attributes most catalogues leave blank are exactly the ones conversational queries filter on.

This is the work our e-commerce team now does alongside traditional SEO, and it is less speculative than it sounds — the specifications are published, the fields are documented, and the gap between a catalogue that wins and one that is invisible is mostly clerical.

What an AI shopping assistant actually reads

The three layers an AI shopping assistant reads Layer one, the foundation, is the product page HTML with Product and Offer schema, which decides whether your facts are readable. Layer two is the merchant product feed, which decides whether you are considered at all. Layer three is the agentic checkout protocol, which decides whether the agent can complete a purchase. What the assistant reads, and what each layer decides Layer 3 · TransactionAgentic checkout protocolWhether the agent can buyLayer 2 · DistributionMerchant product feedWhether you are consideredLayer 1 · FoundationProduct page HTML + Product/Offer schemaWhether your facts are readable Build upward: a feed cannot fix a page that states nothing.
Three surfaces, three different jobs. Most stores work on layer one and assume it covers the rest. It does not: the page makes your facts legible, the feed decides whether you enter the shortlist, and the protocol decides whether a purchase can complete without a human. Each layer is a different file, owned by a different team in most companies.

The mistake we see most is treating this as one job. A beautifully marked-up product page will not get you into ChatGPT's shortlist if you publish no feed, and a perfect feed will not survive a shopper clicking through to a page that contradicts it. Build upward, in order, and keep the three layers telling the same story.

Layer 1: a product page whose facts validate

Structured data is the difference between a page an assistant can parse and a page it has to guess at. Google's merchant listing documentation sets the baseline, and it is worth being precise about what is required versus what actually wins comparisons.

PropertyStatusWhy an assistant needs it
nameRequiredIdentifies the product unambiguously
imageRequiredHigh resolution, multiple aspect ratios
offers · priceRequiredEvery "under X" query filters on it
offers · priceCurrencyRequiredAED, not an unlabelled number
★ availabilityRecommendedOut-of-stock products get dropped from shortlists
★ shippingDetailsRecommended"Delivered by Thursday" is a decisive comparison
★ hasMerchantReturnPolicyRecommendedFrequently the tiebreaker between two products
brand · sku · mpnRecommendedLets the assistant match you to a known product
aggregateRatingRecommendedRanking signal and a quoted reason to choose you
itemConditionRecommendedSeparates new from refurbished in comparisons

Note that offers must be an Offer, not an AggregateOffer, for a merchant listing — you are the seller, not a price comparison. And validate the rendered page rather than the template: theme updates and review apps routinely inject a second, conflicting Product block, and two contradictory prices in one page is worse than none.

Layer 2: the feed is how you enter the shortlist

A crawl tells an assistant what your page said the last time it visited. A feed tells it what is true now, at the price and stock level you are currently trading at, which is why every shopping surface prefers one. Google reads Merchant Center. OpenAI accepts a merchant product feed containing, in its own description, identifiers, descriptions, pricing, inventory, media and fulfillment options, refreshed on a schedule.

Three rules decide whether a feed earns its keep. Completeness beats brevity — every blank optional attribute is a query you cannot be matched to. Freshness is a ranking input, because an assistant that recommends an out-of-stock product looks broken and will learn to avoid you. And the feed must agree with the page: a feed price of AED 349 against a page price of AED 399 is a trust failure that can cost you the surface entirely.

Specifications differ by destination, so read the one you are publishing to instead of assuming a universal field list. That work is unglamorous, and it is the highest-leverage thing most Gulf catalogues could do this quarter — more so than another round of e-commerce SEO on the top twenty pages.

Layer 3: letting an agent actually buy

The newest layer is transactional. The Agentic Commerce Protocol, published by OpenAI with Stripe as an open standard, lets ChatGPT act as the shopper's purchasing agent: it collects buyer, fulfilment and payment details and passes them to your systems to complete the order.

The detail worth understanding before anyone panics about disintermediation: OpenAI is not the merchant of record. You keep payment processing, tax calculation, fraud analysis and final acceptance of the order, and the agent presents a one-time delegated payment request with a spending limit and an expiry. It is an integration you choose to build, not something that happens to your store. For most Gulf retailers it is a 2027 question — but layers one and two are prerequisites for it, so the work is not wasted either way.

Conversational queries are filters, not keywords

How one conversational shopping query breaks into six product data fields The query "waterproof running shoes under AED 400, size 43, in stock in Dubai" requires six fields: material or additionalProperty, category or productType, price and priceCurrency, size or variant offer, availability, and shippingDetails or areaServed. A product missing any one of them cannot be matched to the query. THE SHOPPER ASKS "waterproof running shoes under AED 400, size 43, in stock in Dubai" "waterproof"material · additionalProperty"running shoes"category · productType"under AED 400"price · priceCurrency"size 43"size · variant offer"in stock"availability"in Dubai"shippingDetails · areaServed
Every clause is a filter against your data. A shopper typing this into Google would scan a results page and forgive gaps. An assistant cannot: it matches clause by clause against fields, and a product with no material attribute is simply not waterproof as far as the machine is concerned. Six clauses, six fields, and most catalogues populate three of them.

This is the mental shift that makes the rest of the checklist obvious. Nobody types "running shoes Dubai" to an assistant; they describe the thing they want, with constraints. Each constraint is matched against a field. A product page that says "engineered for all conditions" in marketing prose, with no material or waterproofing attribute in the data, loses to a duller competitor that recorded the fact properly.

The practical exercise: take the ten questions your sales team answers most, write them as a shopper would say them to an assistant, and underline every constraint. That list is your missing-attribute backlog, in priority order.

Variants: how an assistant matches "size 43"

Size and colour are where most catalogues quietly fail, because the information exists on the page but only inside a dropdown that populates after a click. If the variant's price, stock and identifier are not in the markup, an assistant cannot confirm that size 43 is available at AED 380 — and a product it cannot confirm is a product it will not recommend.

Google documents the structure for this. A ProductGroup wraps the family, declares what the variants differ by through variesBy — colour, size, material — and carries a productGroupID, the parent SKU. Each variant is a nested Product with its own unique identifier, its own distinguishing properties, its own offer with price, availability and URL, and a link back to the parent through inProductGroupWithID or isVariantOf.

Two practical consequences. First, a variant with no distinct URL and no distinct offer effectively does not exist to an assistant, however visible it is to a shopper using the dropdown. Second, stock has to be per variant: a page marked in-stock because one colour remains will get recommended for the colour that sold out, which produces exactly the disappointed shopper an assistant is built to avoid — and the surface learns from that.

The attributes each category forgets

Which fields matter is category-specific, and the gaps are remarkably consistent within each one. These are the omissions we find most often in Gulf catalogues.

CategoryAttributes usually missingThe query you lose
Apparel & footwearsize system, fit, material, care"true to size, machine washable, size 43"
Electronicscompatibility, port types, warranty length"works with my 2024 MacBook, 2-year warranty"
★ Beauty & fragranceconcentration, size in ml, notes, longevity"long-lasting oud EDP, 100ml, under AED 300"
Furnituredimensions, assembly, lead time, material"fits a 2.4m wall, delivered this month"
Jewellerymetal purity, stone weight, certification"18k gold, certified diamond, under AED 5,000"
Grocery & supplementsingredients, allergens, halal certification"halal certified, no added sugar"
Auto partsmake, model, year fitment"fits a 2019 Patrol"

Two of those rows deserve emphasis in this market. Halal certification is a hard filter for a large share of Gulf shoppers and is almost never a structured attribute — it sits in a paragraph, or on a badge image, where no assistant can read it. And fitment data in auto parts is the difference between being recommended and being a returns problem; an assistant asked for a part for a specific vehicle will simply not name products that cannot prove compatibility.

Writing copy an assistant can quote

Structured data states the facts; the prose is what gets quoted back to the shopper as a reason. Three habits make copy quotable.

  • Put specifications in text, never only in images. A spec sheet rendered as a JPEG is invisible. This is the single most common cause of a technically excellent product page being passed over.
  • Answer the comparison directly. A short "EDP versus EDT" or "which size fits a 2.4m wall" section gives the assistant the sentence it needs. The Shopify SEO checklist for perfume stores works the same principle through a single platform, if you want the store-level version.
  • State the limits honestly. "Not suitable for dishwasher" or "runs half a size small" reads as trustworthy to a human and gives a model a precise fact to match against a negative constraint. Brands are strangely reluctant to publish the one sentence that would win them a recommendation.

Gulf-specific data most catalogues get wrong

Three things break AI shopping visibility in this region specifically. Currency: prices must carry AED explicitly in the data, not just a dirham symbol in the theme — an unlabelled number is unusable in an "under AED 400" filter. Delivery reality: shipping timelines differ between Dubai, the northern emirates and cross-border to Saudi Arabia, and a single national promise either overstates or undersells. Arabic product data: an Arabic storefront whose product attributes exist only in English is invisible to an Arabic-language assistant query, which is a much larger gap than most brands assume — the same argument as our Arabic SEO work, applied to structured fields rather than prose.

Access and measurement

None of this matters if the crawler behind the assistant cannot reach the page. Check robots.txt for a blanket AI block added in a defensive moment — the crawler that powers an assistant's search is usually a different user agent from the one that collects training data, and blocking both removes you from the answers while protecting nothing you care about. Then confirm in server logs that those agents are actually fetching your product URLs.

Measurement follows the same pattern as the rest of AI visibility. Run a monthly prompt panel of real buying questions and record whether your products are named, and on what grounds — "cheapest", "best reviewed", "ships fastest" tells you which attribute earned the mention. Watch referral traffic from assistant domains, and accept that a large share arrives unattributed as direct. This is the measurement layer our answer engine optimization engagements run, and for catalogues it is more diagnostic than any ranking report.

Case study — Maison Layali, Gold & Diamond Park. A fine jewellery Shopify Plus catalogue, and the closest analogue in our own book: the engagement was built on product and category schema, a restructured catalogue and trilingual content in English, Arabic and Hindi, with Google Shopping support. Monthly organic revenue went from AED 218,000 to AED 828,000 over 42 months. The work predates AI shopping assistants — but the asset it produced, a complete and consistent product dataset, is precisely what these assistants now read. The detail is in the Maison Layali case study.

Worked example — a Dubai electronics retailer. Illustrative. 1,200 SKUs, strong Google rankings, never named by any assistant. The audit finds the cause in the data, not the site: no compatibility attributes, warranty stated only in a footer paragraph, shipping promised as "1–3 days" nationally with no emirate detail, and the Arabic storefront carrying English attributes. Three sprints — populate compatibility and warranty as structured fields, split shipping by emirate, translate attributes rather than just descriptions — and the same catalogue starts appearing in "works with" and "delivered by" comparisons it was previously invisible to.

The order to do this in

All of it matters eventually; almost none of it should be attempted at once. This is the sequence we run, ordered by return on effort rather than by how modern it sounds.

#WorkEffortWhy it comes here
1Unblock the assistant crawlersMinutesEverything else is wasted while you are excluded
2Validate schema on real pagesDaysFinds duplicate and invalid blocks before you scale anything
3Fill availability, shipping, returnsDaysThe recommended fields that decide comparisons
4Move specs out of images into textWeeksUnlocks the facts an assistant can quote
5Model variants properlyWeeksMakes size and colour queries matchable
6Publish and reconcile the feedWeeksGets you into the consideration set, at live prices
7Translate attributes, not just copyWeeksOpens Arabic-language assistant queries
8Evaluate an agentic checkout integrationQuarterOnly worth it once 1–7 hold

Steps one to three are usually a fortnight of unglamorous work that moves more than a quarter of content production. Step eight is the one that gets written about, and it is last for a reason: an agent that can check out of a catalogue with missing attributes will still not choose it.

The mistakes that keep catalogues invisible

  • Specs in images. Unreadable, and usually the whole reason a good product loses.
  • A feed that disagrees with the page on price or stock.
  • Leaving recommended fields blank because they are optional — optional to Google, mandatory to a filter.
  • Blocking every AI crawler, then asking why no assistant recommends you.
  • Marketing adjectives instead of attributes. "Premium" is not a filter; 18k is.
  • English-only attributes on an Arabic storefront.

Frequently asked questions

What is the difference between SEO and optimising for AI shopping assistants?

Classic SEO wins a ranked link that a human clicks and interprets. An AI assistant never shows your page — it reads your structured data and feed, filters products against the shopper's constraints, and names a shortlist. That makes completeness and accuracy of product attributes more important than page design, and it makes a missing field a disqualification rather than a missed opportunity.

Do I need a product feed if my product pages already have schema markup?

Yes, for most surfaces. Schema makes your page legible when an assistant fetches it; a feed is how you get into the consideration set in the first place, and it carries inventory and price at a refresh rate a crawl cannot match. Google reads Merchant Center, and OpenAI accepts a merchant product feed for ChatGPT shopping. Treat the page and the feed as one dataset published twice.

Which structured data properties actually matter for products?

Google requires name, image and an offers block with price and priceCurrency for merchant listings. The properties that decide whether you match a conversational query are the recommended ones most stores skip: availability, itemCondition, brand, sku or mpn, aggregateRating, shippingDetails and hasMerchantReturnPolicy. Shipping and returns are frequently the tiebreaker between two otherwise identical products.

Can AI assistants complete a purchase on my store?

That is what the Agentic Commerce Protocol, published by OpenAI with Stripe, is built for. Crucially the merchant stays the merchant of record: you keep payment processing, tax, fraud checks and final order acceptance, and the agent receives a delegated payment request with limits and an expiry. It is an integration decision, not something that happens to your store automatically.

Should I block AI crawlers from my product pages?

Not if you want to be recommended. Blocking the crawler that powers an assistant's search removes you from its answers entirely — you keep the content and lose the shelf space. If you are worried about training use specifically, block the training crawler and allow the search one; they are separate user agents with separate rules.

How do I know whether assistants are recommending my products?

Run a prompt panel: ten to twenty real buying questions for your category, put through ChatGPT, Gemini and Google AI Mode monthly, recording whether your products are named and on what grounds. Pair it with referral traffic from assistant domains and a "how did you hear about us" field, because much of this traffic arrives with no referrer at all.


The uncomfortable part of agentic commerce is that it rewards bookkeeping over creativity: the catalogue with complete, accurate, consistently published attributes wins, and the better-looking store loses quietly without ever knowing which comparisons it was left out of. If you want to know which queries your catalogue is already disqualified from — and what it would take to fix the data rather than the design — send us your product feed and we will run the gaps against the questions your buyers actually ask.

#ai shopping#agentic commerce#product schema#merchant feed#ecommerce seo#aeo

Ready to rank on Google — and inside ChatGPT?

Talk to the team behind this playbook. 8 years, 520+ brands ranked across the UAE & GCC.

Get your free audit

Keep reading