What an agentic knowledge base actually is

It is not a help centre. A help centre is a place customers go when something has gone wrong. An agentic knowledge base is the complete, structured, machine readable body of truth about your store, assembled so that any system asking a question about your brand gets a correct and current answer.

It has five layers. Most brands have built one of them.

Layer one: product truth. What the item is, made of, sized as, cared for, compatible with, and shipped as. Attributes, not adjectives.

Layer two: commercial truth. Price, currency, availability, variant logic, bundles, promotions, delivery estimates by region, payment methods accepted.

Layer three: policy truth. Shipping, returns, exchange, warranty, cancellation, COD terms. The boring documents that decide whether an agent is willing to recommend you at all.

Layer four: brand truth. Who you are, where you manufacture, what the materials are, what the provenance claims are, where the stores are, how to reach a human.

Layer five: question truth. The forty questions your support team answers every week, written down in the words customers actually use.

An agent recommending a product to a stranger is making a small bet on your behalf. It will favour the merchant whose answers are complete and unambiguous, because incomplete answers are risk. This is the whole game.

Where each layer lives in Shopify

Shopify gives you good tools for this. Most merchants use perhaps a third of them.

Metafields are the workhorse

Anything that is a fact about a product belongs in a metafield, not buried in the description paragraph. Materials, fabric composition, weight, dimensions, water resistance rating, movement type, strap width, country of origin, warranty period, care instructions, certifications.

The discipline that matters is consistency. One definition, one data type, one unit, applied across the entire catalogue. A field that is populated on sixty percent of products is worse than useless, because it teaches any system reading it that absence means nothing rather than no.

Use the proper types. A number field for weight, not a text field containing “approx 340 grams”. A dimension type with units. A boolean for yes or no attributes. Typed data can be filtered and compared. Free text cannot.

Metaobjects for the things that repeat

Size charts, care guides, material profiles, warranty terms, designer or artisan profiles, FAQ entries. These are reusable structured records that attach to many products at once.

The advantage over pasting a size chart image onto forty product pages is that you update it once, it is text rather than pixels, and it can be rendered anywhere including into schema markup. The advantage over a PDF is that a PDF is a black box to most systems reading your site.

If your sizing information currently exists as an image, that is likely the single highest value fix on this list.

The Shopify product taxonomy

Shopify maintains a standard product taxonomy with category specific attributes. Mapping your catalogue to it properly does real work: it standardises your category and attribute names against a vocabulary that other systems already understand, and it improves how your products behave in Shopping feeds and marketplace integrations at the same time.

It is tedious. It is also the closest thing to a free win in this entire exercise.

Product descriptions, rewritten for two readers

The instinct is to choose between poetry for humans and specifications for machines. You do not have to.

Structure the description so the top carries the brand voice and the body carries the facts in plain declarative sentences. Answer the questions rather than gesturing at them. “Cut for a relaxed fit through the shoulder. Model is 6 feet tall and wears size M. Chest measures 42 inches on size M.” reads fine to a person and is fully legible to a machine. “Effortless ease, reimagined.” is legible to neither.

Avoid putting critical facts only inside bullet images, comparison graphics or embedded video.

Policy pages that state numbers

Most returns pages are written by a lawyer trying to preserve optionality. That is exactly wrong for this purpose.

State the window in days. State who pays return shipping. State the refund timeline. State the exclusions explicitly. State whether exchanges are available and how. Do the same for shipping: dispatch time, delivery estimate by region, the cutoff for same day dispatch, what happens on delays.

An agent asked “can I return this if it does not fit” needs a number. Give it one.

Reviews as structured data

Review content is one of the strongest trust signals available to a recommendation system, but only if it is exposed as structured ratings rather than rendered inside a widget that loads after the page does. Check what your review app actually outputs in the page source. Several popular ones do this well. Some do not.

Schema markup on every template

Product schema with offers, price, currency, availability, brand, GTIN or MPN where they exist, aggregate rating, and shipping and returns details. Organisation schema on the site. FAQ schema on the pages that carry questions. Breadcrumb schema on collections.

Validate it. Broken or partial schema markup is extremely common and almost never noticed, because nothing on the page looks wrong.

The exposure layer

This is where you decide what can read you.

Your robots.txt in Shopify is editable through robots.txt.liquid. Check what it currently says about AI crawlers, because most merchants have never looked. GPTBot, OAI SearchBot, ClaudeBot, PerplexityBot and Google Extended each control a different thing, and blocking them is a strategic choice, not a hygiene default. Blocking a crawler that feeds an assistant’s shopping recommendations removes you from that surface entirely.

There is also a newer convention, llms.txt, which proposes a plain text file summarising a site’s key content for language models. Adoption is not yet proven and no major assistant has committed to it as a ranking input. It costs an hour to publish and may do nothing. We treat it as a cheap option rather than a priority.

Separately, Shopify has been building endpoints that let agents query a storefront’s catalogue and cart directly rather than reading the page. Ask your platform contact where that stands for your plan and what it requires of you, because that path bypasses the crawling question entirely.

The build sequence

In order, because doing this out of sequence wastes weeks.

1. Audit before you build. Export the catalogue and measure completeness field by field. What percentage of products have materials, dimensions, care, country of origin? Where are the gaps concentrated? You are looking for the twenty fields that matter across the eighty percent of SKUs that drive revenue, not perfection everywhere.

2. Define the schema. Decide the metafield and metaobject definitions before anyone populates anything. Naming convention, data types, units, permitted values. Write it down. This document is the thing that stops the whole effort decaying in six months.

3. Map to the standard taxonomy. Category and category attributes across the catalogue.

4. Populate, highest revenue first. Do not attempt the full catalogue in one pass. Take the SKUs that generate most of your revenue and finish them completely, then work outward. A catalogue that is fully correct on two hundred products beats one that is half correct on two thousand.

5. Rewrite the templates to render it. Structured data is worthless if it sits in the admin and never reaches the page. Product templates need to output the metafields as visible text and as schema markup.

6. Fix the policy and FAQ content. Rewrite for specificity. Add FAQ schema.

7. Decide the crawler policy. Explicitly, as a business decision, documented.

8. Validate everything. Schema validators, and then the practical test below.

9. Set a maintenance cadence. New products cannot ship without the required fields populated. This is a process rule, not a nice intention.

How to test whether it worked

The useful test is not a validator. It is asking the questions a customer would ask, of the systems your customers use, and seeing what comes back.

Take twenty real presale questions from your support inbox. Ask them of the major assistants, phrased naturally, with and without your brand name. Note three things: whether your brand appears at all, whether the answer given about your product is correct, and where the answer came from.

The failures are usually informative. A wrong price means a caching or markup issue. A wrong returns window means the policy page is ambiguous. Total absence on unbranded queries means your product data is too thin to be selected. A confident answer sourced from a marketplace listing rather than your own site means someone else is speaking for your brand.

Repeat monthly. This is your agentic rank tracking, crude as it is.

The India specifics

Several things matter more here than in the guides written for US merchants.

Delivery by pincode. “Ships across India” is not an answer. Serviceability and delivery estimates vary enormously by pincode and courier. If your delivery promise is dynamic, make sure the underlying logic is reachable and that your shipping page states realistic ranges by zone rather than a single optimistic number.

COD terms, written down. Whether COD is available, on which order values, in which pincodes, with what fee. This is a top three question for Indian shoppers and it is frequently undocumented.

Sizing conventions. Indian apparel sizing is inconsistent across brands, and shoppers know it. A size chart in centimetres and inches, as text, with body measurements rather than garment labels, removes a real purchase barrier for humans and gives an agent something to reason with.

GST and invoicing. Whether a GST invoice is provided, and how a business buyer requests one. Small detail, meaningful for a segment of your customers.

Checkout reality. If you run GoKwik, Shiprocket Checkout or a similar layer, your cart to payment path is not the standard Shopify one. That has implications for any future agentic checkout integration. Ask the vendor directly what their roadmap is rather than assuming it is handled.

Common mistakes

Treating it as a content project. It is a data project with a content component. Handing it to a copywriter alone produces beautiful pages with the same structural gaps.

Populating fields nobody defined. Three people entering fabric composition three different ways is worse than an empty field.

Facts locked in images. Size charts, specification tables, ingredient lists and comparison grids delivered as JPEGs are invisible. This is the most common and most costly error we see.

PDFs as documentation. Manuals, care guides and warranty terms in PDF are far less reliably read than an HTML page.

Blocking crawlers by accident. Someone added a rule two years ago for a good reason that no longer applies.

Building once. A knowledge base that is not maintained is a knowledge base that is wrong, and confidently wrong data is worse than missing data.

Our view

There is a version of this work that sounds like preparing for a speculative future, and we would be sceptical of that framing too.

But look at what is actually on the list. Complete product attributes. A standard taxonomy mapping. Text based size charts. Specific policy pages. Valid schema markup. Reviews exposed properly. Every one of those improves classic organic search, improves your Shopping and Performance Max feed quality, reduces presale support volume, and lifts conversion rate on the product page. The agentic benefit is a fourth return on the same investment, not the justification for it.

That is the honest case. Do it because it pays for itself three ways today, and because when discovery does shift further into conversational surfaces, the brands that can be read will be the brands that get recommended.

Everyone else will just be quiet.

FAQ: Shopify Knowledge Base for Agentic Commerce:

1. What is a Shopify knowledge base for agentic commerce?

It is the complete, structured, machine readable body of truth about your store: product attributes, pricing and availability logic, policies, brand facts and the answers to common customer questions, all held in a form that any system can query and get a correct answer from. It lives across Shopify metafields, metaobjects, product templates, policy pages and schema markup rather than in a single app. The purpose is simple. When an AI assistant evaluates your brand for a shopper, it should find complete answers rather than gaps.

2. How is this different from my existing FAQ or help centre?

A help centre is where customers go after something has gone wrong, and it is written for people who are already on your site. A knowledge base for agentic commerce is written for systems that have never seen your site, and it covers the whole decision, not just support issues. It includes fabric composition, dimensions, delivery estimates by region, COD terms, returns windows in days and sizing in actual measurements. Much of it never appears as a question on a help page at all, because it belongs on the product itself.

3. Does Shopify not handle this automatically?

Shopify gives you the infrastructure but not the content. Metafields, metaobjects, the standard product taxonomy and structured data support all exist on the platform, and Shopify has been building endpoints that let agents query catalogue and cart directly. None of that populates your fabric composition, writes your delivery estimates or converts your size chart from an image into text. The platform is capable. The completeness of what sits inside it is entirely on the merchant, and this is where almost every store falls short.

4. When should I use a metafield versus a metaobject?

Use a metafield for a value that belongs to one product, and a metaobject for a structured record shared across many. Fabric composition, water resistance rating, warranty period in months and country of origin are metafields. Size charts, care guides, material profiles, artisan or designer bios and reusable FAQ entries are metaobjects, because you want to write them once and attach them to fifty products. The practical test: if updating this information means editing more than one product, it should probably be a metaobject.

5. Why do my size charts and spec sheets not count?

Because they are images or PDFs, and the information inside them is invisible to most systems reading your store. A size chart delivered as a JPEG is unreadable to an agent asked whether size M fits a 40 inch chest, even though a human can see the answer clearly. The same applies to specification grids, ingredient lists, comparison tables and care instructions locked inside graphics or embedded video. Rebuilding these as text, ideally as metaobjects rendered into the page, is usually the single highest value fix available.

6. Should I block AI crawlers like GPTBot and ClaudeBot?

Treat it as a commercial decision rather than a security default, because blocking a crawler that feeds an assistant’s shopping recommendations removes you from that surface entirely. Different crawlers control different things, so review them individually rather than blanket blocking. Most merchants have never looked at their robots.txt and are unknowingly running whatever was set years ago. In Shopify you control this through robots.txt.liquid. For a brand that wants to be discoverable inside AI assistants, allowing the shopping and search focused crawlers is usually the right call.

7. Is llms.txt worth publishing?

It is a cheap option rather than a priority. The convention proposes a plain text file summarising your site’s key content for language models, and it takes about an hour to publish. Adoption is not yet proven and no major assistant has committed to it as a ranking input, so nobody should be selling it to you as essential. Publish it if the effort is trivial for your team, but do not let it displace the work that reliably matters: complete product attributes, valid schema markup and specific policy pages.

8. How much of my catalogue do I actually need to complete?

Start with the products that drive most of your revenue and finish them completely, then work outward. A catalogue that is fully correct on two hundred SKUs is far more useful than one that is half correct on two thousand, because partial data teaches every system reading it that a missing field means nothing rather than no. Identify the twenty fields that genuinely affect purchase decisions in your category, populate those consistently across your core range, and set a rule that no new product ships without them.

9. How do I test whether AI assistants can read my store correctly?

Take twenty real questions from your support inbox and ask them of the major assistants, phrased naturally, both with and without your brand name. Check three things: whether your brand appears at all, whether the answer about your product is correct, and where the answer came from. The failure modes are diagnostic. A wrong price points to markup or caching. A wrong returns window means an ambiguous policy page. Absence on unbranded queries means your product data is too thin to be selected. Repeat monthly.

10. Is this worth doing when agentic commerce is still small?

Yes, because almost none of the work is specific to agentic commerce. Complete product attributes, standard taxonomy mapping, text based size charts, specific policy pages, valid schema markup and properly exposed reviews each improve organic search, improve Shopping and Performance Max feed quality, reduce presale support volume and lift product page conversion. Those returns arrive now, on current traffic. The agentic benefit is a fourth return on the same investment rather than the reason to make it, which is what makes the business case defensible today.

NOIR & BLANCO builds and scales Shopify storefronts for premium D2C brands. If you want an audit of how complete your catalogue data actually is, [get in touch].