You carry the right inventory. The sizes are in stock. The price is competitive. And when someone asks ChatGPT or Perplexity for a recommendation in your category, your store does not come up.
In our experience, the problem is usually not what you sell. It is how the data about what you sell is structured on the page.
AI shopping tools do not read product descriptions the way a customer does. They extract structured signals: specific attributes that match what the user asked. If those attributes do not exist as discrete, parseable fields on your product pages, the AI has nothing to match against. Your store is invisible not because the product is wrong, but because the attributes do not exist as fields.
This is the gap we see across category after category. A shoe store that never declared foot type or width as fields. An apparel brand with beautiful lifestyle copy that never stated fabric weight. A trailer parts supplier whose compatibility data never existed as a structured field.
This checklist gives you the specific fields each product category needs to be readable by AI recommendation engines. It is the hands-on companion to our pillar on getting found in ChatGPT, Gemini, and Perplexity shopping (https://www.qadigitalpartners.com/blog/get-found-chatgpt-shopping-gemini-perplexity). Read that one first if you want the full picture of how AI discovery works. Come back here when you are ready to act by category.
How AI Recommends Products
When a user asks an AI shopping tool for a product recommendation, the model does pattern-matching against structured data. It is not summarizing your brand story. It is checking whether your product's declared attributes match the attributes in the query.
Take a query like "running shoes for flat feet under $160." The AI is looking for three signals: a price field that confirms the number, a foot type field that maps to flat feet, and a use-case field that confirms running. If any of those signals are missing or buried in unstructured prose, the match becomes unreliable.
This is the AI readiness checklist problem in its simplest form. The signals are knowable in advance by category. The work is declaring them as fields.
Footwear Checklist
The footwear category has one of the richest attribute structures in ecommerce. It is also one of the most commonly botched for AI visibility. The attributes exist in the buyer's head and in the manufacturer's spec sheet. They rarely make it to the product page as discrete, machine-readable fields.
A discussion in the Shopify Community makes this gap concrete (community.shopify.com/t/sizefinder-for-shoes-product-filter-based-on-actual-insole-lengths/335856). A store owner wanted something that sounds simple: let the customer enter their actual foot measurements and see every shoe in stock that fits. She had thousands of variants, each with its own measurements, living in a CSV that no discovery channel could read. She needed a third-party plugin just to make length and width exist as filterable fields.
The lesson is not about the plugin. It is that the matching data existed all along and was invisible, because it was never structured as fields.
Here is what AI needs to recommend footwear:
Declared price (numeric): List the exact price as a machine-readable number. "Starting from" values do not match against budget queries. The number needs to be in a field, not a sentence.
Foot type (normal, flat, high arch): This should be a structured field, not a sentence in a product description. "Works great for most feet" does not match "flat feet." "Recommended for: flat feet, neutral arch" does.
Toe box width (standard, wide, extra wide): Width fitting is a top purchase qualifier in footwear. It belongs in a dedicated field, separate from the general size declaration.
Last / fit shape: Whether the shoe runs narrow, true to size, or wide relative to labeled size is distinct from listed width. Both matter and both need to be declared as separate fields.
Use context (running, walking, standing all day, plantar fasciitis support): "Comfortable and supportive" does not match any query. "Designed for all-day standing and plantar fasciitis relief" matches dozens of them. Declare use context as a field or as a clearly labeled attribute block.
Return policy window: First-time online footwear buyers ask about returns immediately after price. A declared return window (30 days, free returns) is an attribute that appears in AI recommendation rationale, not just in footer policy pages.
Insole compatibility and removability: Customers searching for shoes compatible with custom orthotics need a declared insole depth and a removability flag. This is a narrow but high-intent audience that converts when the attribute is there and disappears when it is not.
Apparel Checklist
Apparel product pages have the opposite problem from footwear. They tend to be rich with copy and images and thin on structured data. The lifestyle description is there. The feel-good language is there. The field that says "8 oz fabric weight" is not.
Two community discussions make the gap concrete. In one, a seasonal apparel seller asked how descriptions should look because he was worried about searchability (community.shopify.com/t/apparel-product-descriptions/645049). His fabric content and weight, real data like a 50/50 cotton-poly fleece at 8 oz, was buried inside prose paragraphs, so Google Merchant Center scraped a blurry summary instead of clean attributes. In another, an apparel store owner had real traffic and zero sales, and did not know why (community.shopify.com/t/many-visits-but-0-sales-apparel-accessories-ecom-store-need-your-expert-feedback/396569). The replies pointed at missing basics: material, fit, care instructions, and a size guide positioned too far down. The product was fine. The fields were not.
The comparison that clarifies this most directly is two ways of stating the same product fact:
"Comfy cotton blend with a soft, breathable feel" versus "50% cotton, 50% polyester, 8 oz per square yard, pre-shrunk."
The second version matches against "heavyweight cotton tee" or "pre-shrunk blend under 250 GSM." The first version matches nothing because it has no extractable data point.
Here is what AI needs to recommend apparel:
Fabric composition (percentages, not descriptions): "Cotton blend" is prose. "52% cotton, 48% polyester" is a field. Only the field is matchable against composition-specific queries.
Fabric weight (in oz per square yard or GSM): Weight determines whether a garment is appropriate for layering, warm weather, or structured wear. It is a frequent filter in AI queries and it needs to be a declared number, not a feel descriptor.
Fit type (relaxed, slim, regular, oversized): AI queries use standard fit labels. "Relaxed fit" and "loose fit" are not synonymous in matching terms. Use the standard labels, not proprietary naming.
Intended use or occasion: Gym, work, casual, outdoor, layering. Declared as a field or labeled attribute, not embedded in the product story.
Size range and inclusivity flags: If you carry extended sizes, that needs to be a structured field. Queries like "extended size athletic wear" or "plus size workwear under $50" match only if the size range is declared data, not copy.
Care and durability indicators: Machine washable, wrinkle-resistant, pilling-resistant. These are decision points for buyers and match terms for AI. State them as attributes, not marketing language.
Electronics and Parts Checklist
In electronics and specialty parts, the critical attribute is compatibility. Every other category has attributes that improve recommendations. In this category, compatibility is the recommendation. If a product does not declare what it works with, the AI cannot surface it for someone who names a specific device, vehicle, or system.
A trailer parts supplier described this exact wall in the Shopify Community (community.shopify.com/t/how-to-verify-product-compatibility-for-trailer-parts-on-my-website/317729). When someone suggested listing compatible models inside each product description, his answer was that he had too many products for that approach to work. The suggested workaround was an external form. That is a patch, not a fix. The compatibility data needs to live in the catalog as structured fields, or no tool, AI or otherwise, can match the right part to the right buyer.
Here is what AI needs to recommend electronics and parts:
Compatibility matrix (make, model, year, version): This should be a structured list, not a paragraph. "Compatible with: Ford F-150 2015 to 2023, Ram 1500 2013 to 2024" written as machine-readable data. Prose compatibility statements do not match against specific model queries.
Technical specifications as discrete fields: Voltage, amperage, connector type, frequency, storage capacity. Each spec is a separate field with a unit. "High-performance specs" is not a field and matches nothing.
What is included versus what is required separately: Buyers in electronics and parts routinely need to know if they need additional components. "Requires [item X], sold separately" as a declared field prevents mismatches and reduces returns from incompatibility.
Certifications and standards compliance: UL listed, FCC certified, OEM spec, OSHA rated. These are qualification filters in queries from buyers with safety or compliance requirements. They should be declared attributes, not mentioned once in a product description paragraph.
Return window and compatibility guarantee: In parts and electronics, a compatibility guarantee or a clear return window for compatibility issues is a decision signal. Declare it as a field, not as policy text three clicks away from the product page.
The Core Principle
The thread connecting these three categories is direct. AI tools do not read product pages the way a human browser does. They do not extract meaning from well-written prose. They match structured signals: fields with specific values against query terms with specific requirements.
Every product category has 3 to 5 attributes that are the primary match points for AI recommendation in that space. For footwear, foot type and fit are in the top three. For apparel, fabric weight and composition. For parts and electronics, compatibility. The AI does not reward you for having more content. It rewards you for having the right fields.
The practical consequence: a product page that declares fabric composition as 52% cotton, 48% polyester and fabric weight as 8 oz will outperform a competitor with 400 words of lifestyle copy and no structured fabric data in AI shopping results.
This is not about optimizing for a ranking signal. It is about making your product data parseable. The AI recommends the product that best matches what the user asked for. Your job is to make sure your product declares the attributes that let that match happen.
Frequently Asked Questions
My product pages already rank on Google. Why do I need to change anything for AI?
Google ranking and AI recommendation run on different signals. Google rewards content depth, backlinks, and engagement. AI shopping tools reward structured attribute matching. A page can rank on Google because it has thorough written content and still be invisible in AI results because that content has no machine-readable attribute fields. Strong SEO does not transfer to AEO automatically.
How many attributes do I actually need per product to appear in AI results?
There is no universal threshold, but the pattern we see is that 3 to 5 correctly structured, category-specific attributes outperform pages with 20 generic ones. Quantity is not the goal. Precision is. Get the attributes that match the top query patterns in your specific category right first, then expand from there.
Do I need to restructure my entire product catalog at once?
No. Start with your top 20 to 30 SKUs by traffic or revenue. Map the attributes from the checklists above to those products first. Measure whether AI referral traffic changes over 60 to 90 days. Then expand to the rest of the catalog based on what you learn from the initial set.
Does this apply to products I sell on Amazon or other marketplaces, or only my own site?
It applies everywhere you have control over product data. Marketplace listings that let you declare structured attributes benefit from this approach directly. Where marketplace attribute control is limited, prioritize structured data investment on your own site and use the marketplace listing as a secondary channel.
