If you want a chatbot or an AI shopping surface to put your product in front of a buyer, the part that matters is not your product description. It's your fields. Brand, GTIN, material, size in actual units, colour as a real value rather than "Shade 3", stock status that updates within minutes, a returns window stated as a number. A Shopify store with good copy and empty attributes loses to a dull competitor whose catalogue is filled in properly. That's the whole post. The rest is how to fix it.
What machines actually read on a Shopify product page
Three things, roughly, and only one of them is the page a human sees.
First, the JSON-LD block your theme emits. Most modern Shopify themes output a Product schema with name, image, price and availability. Many stop there. No brand, no gtin13, no per-variant offers, no shipping or return details. An assistant parsing that page learns your product exists and costs ₹2,499. It learns nothing that would help it decide your product answers the question.
Second, the product feed. When you connect the Google or Meta sales channels, Shopify maps your product fields into a feed. That mapping is mechanical. If your barcode field is blank, the feed has no GTIN. If your product type is "Apparel" for all 900 items, the feed has no useful taxonomy. Feeds are also what most third-party commerce datasets are built from, so a weak feed propagates everywhere at once.
Third, the raw HTML, because crawlers that build shopping indexes still read pages. Which means anything you rendered inside an image, or loaded through an app that injects after the fact, may as well not exist.
The fields almost every Shopify catalogue is missing
We audit catalogues often enough to have a mental list of what comes back empty. Barcode, nearly always, on Indian D2C brands that never sold through retail. Vendor, often set to the store's own name on every product, which makes it useless as a brand signal. Product type left at whatever the importer wrote. Country of origin. Material or fabric composition. Net weight, as opposed to shipping weight. Care instructions. Shelf life. Compatible models, for anything in auto parts or electronics accessories.
None of that is exotic. It's the stuff on the back of the box. The reason it's missing is that nobody needed it to launch, and the catalogue was built in a hurry by someone pasting rows into a CSV at 11pm before a festive drop.
Variants are where Shopify data quietly breaks
Open your products export and look at Option1 Name. If a chunk of your catalogue says "Title" with the value "Default Title", those are single-variant products, fine. But look at the rest. We regularly find stores where size is stored as "S / M / L" on one collection, "Small, Medium, Large" on another, and "38, 40, 42" on a third, all under an option called "Size". A human shopper copes. A machine trying to match "women's size M cotton kurta" against your catalogue does not.
Same with colour. "Midnight", "Ink", "Deep Navy" and "Blue 02" might all be navy. If you sell them as distinct products rather than variants, each one competes with the others and none of them carries a parent grouping. Google's feed spec has an item group ID for exactly this reason, and Shopify populates it from the product, so splitting colourways into separate products throws that away.
The fix is boring and it works: pick one vocabulary per option, write it down, enforce it. Shopify's standard product taxonomy and category metafields help, because they give you prefilled option values instead of free text. Migrating an existing catalogue onto them takes a weekend of bulk edits and saves you from this conversation permanently.
Specifications trapped in images are invisible
This one is common in electronics, appliances, supplements and anything with a nutrition panel. The brand designs a beautiful spec sheet in Illustrator, exports a PNG, drops it in the gallery, and considers the job done. Nothing in that image reaches a feed, a schema block or an on-site search index.
Keep the image. Also put the spec in metafields: twelve rows of key-value data per product, rendered in a table on the page and exposed in your structured data. For supplements and packaged food sold in India, this is where the FSSAI licence number, net quantity under Legal Metrology rules, veg/non-veg mark and shelf life should live. You are legally required to display most of it anyway. Putting it in structured fields rather than a graphic means it also does commercial work.
The Indian attributes that nobody maps
Rupee pricing carries assumptions that AI surfaces get wrong when you leave them implicit. Is the listed price inclusive of GST? Almost always yes in D2C, almost never stated. Is there an MRP that differs from your selling price? If you show a struck-through number, say which one it is. Shopify's compare-at-price field is the right home for MRP, and if you're putting a fictional inflated number there to manufacture a discount, that's a separate problem and it will eventually cost you.
Then there's COD. For a large share of Indian shoppers, cash on delivery availability is a purchase condition, not a nice-to-have. It lives nowhere in your product data. Neither does serviceable pincode coverage. We've started storing both as product-level or collection-level metafields on stores where COD is restricted by category, so the information is at least in the HTML and in on-site search, even though no feed spec has a slot for it yet.
What cleaning a catalogue actually costs
Here's the arithmetic, because this is the part that gets hand-waved.
Take an apparel store with 900 SKUs. Say six fields are missing per product: barcode, material, country of origin, care, fit and a proper product category. That's 900 × 6 = 5,400 cells. Careful manual entry with a source document open, including the time spent finding the source document, runs around 40 cells an hour. So 5,400 ÷ 40 = 135 hours. At a mid-level Indian catalogue associate's loaded cost of roughly ₹400 an hour, that's about ₹54,000 and three and a half working weeks for one person.
You can cut it. If your supplier tech packs exist as spreadsheets, a VLOOKUP against the SKU gets material, care and origin for maybe 70% of the catalogue in an afternoon, leaving 1,620 cells to key by hand, which is roughly 40 hours. Barcodes you either have from your vendor or you don't, and if you manufacture your own goods you don't, so you set the identifier-exists flag false and move on rather than inventing numbers. Inventing GTINs gets your feed suspended.
The honest summary: this is data entry. No app does it for you reliably, and the ones that offer to generate attributes with AI will confidently tell Google your cotton shirt is 60% polyester. Use generation for first drafts of descriptions, not for facts.
How to do the work inside Shopify without creating a mess
Define metafields before you fill anything. Use Shopify's category metafields where they exist, because they come with validation and the right data types, and a number field that only accepts numbers will save you from "approx 250g" appearing in a feed.
Then work in this order:
- Set standard product categories on everything. This unlocks the prefilled attributes and improves feed classification immediately.
- Normalise option names and values across the catalogue. One vocabulary, no exceptions.
- Fill the six to ten attributes that matter for your category, highest-revenue collections first. Your top 100 SKUs probably carry most of your sales, so do those before the long tail.
- Render the metafields on the product page and extend your theme's JSON-LD to include brand, GTIN or MPN, item condition, per-variant offers, and shipping and return details.
- Re-sync the sales channels and read the diagnostics. Merchant Center will tell you exactly which attributes it wanted.
Step 4 is theme work and it's the one that needs a developer. If you don't have one in-house, it's a small, well-defined brief: a Shopify developer can extend the schema output and build the spec table in a few days, assuming the metafields are already defined.
Your own site search is the same problem
Clean attributes pay off twice. The second payoff is on your own storefront, because the filters and search on a Shopify collection page read from exactly the same fields. A store with 900 products and three filters is leaking money on every collection page, and the reason there are only three filters is usually that there's no data to build more. Once material, fit and colour family are populated, you can filter on them, and an on-site AI search can answer "linen shirt under 3000" instead of returning everything with the word "shirt". We build this with FilterPro on stores where the catalogue is large enough to need it, but the app only works as well as the data underneath it. Fix the fields first.
What's overrated right now
Dropping an llms.txt file at your root and declaring the AI problem solved. It costs nothing, so put one up if you like, but no major shopping surface treats it as a ranking input today and it will not compensate for a feed with no GTINs.
Blocking AI crawlers in robots.txt out of caution is the other half of the same mistake, in reverse. If you block the crawlers, you cannot be cited. That might be the right call for a publisher protecting original editorial. For a store that wants its products recommended, it's self-harm. Decide deliberately rather than by inheriting a robots.txt from a template.
And generating 900 product descriptions in one batch. They'll read identically, they'll repeat your competitors' phrasing because they were trained on it, and they'll dilute the pages that were actually doing well. If you're rewriting descriptions at scale, do it in tiers with real input per category: how we approach product content starts from the attributes, not the adjectives.
Start with twenty products
Export your top twenty SKUs by revenue. In a spreadsheet, add columns for every attribute a buyer asks about in your customer service inbox. Fill them. Count the blanks, then multiply by your catalogue size to get the real scope of the job before you commit a quarter to it.
If you'd rather someone else count, our free store audit covers feed coverage, schema output and variant consistency alongside the usual speed and conversion checks. You'll get the list of missing fields whether or not you do anything else with us.