The best way to give AI shopping agents accurate pricing and policy answers: plain HTML pages, llms.txt, schema.org Offer markup, feeds, agent endpoints and testing.
Hannah Owen
·
Updated
The best way to give AI shopping agents accurate pricing and policy answers is to publish one source of truth in formats agents can read without guessing, then check what they actually say. In practice that means pricing and policy pages in plain HTML text, a short llms.txt index pointing at clean markdown versions, schema.org Offer and MerchantReturnPolicy markup on product pages, a product feed that matches the page, and, for anything account-specific, an agent-facing endpoint backed by a support concierge that answers from your knowledge base.
Lorikeet does this for its own site: it publishes a pricing.md file, an llms.txt index, an agents.md guide and public agent endpoints, and its AI concierge answers pricing and policy questions from the same content. Lorikeet publishes this guide and sells that concierge, including B2A for serving personal AI agents, so we will be clear about where a product helps and where a static file is enough. Most of this list costs nothing but discipline.
Key takeaways
Agents get prices wrong for boring reasons: prices rendered by JavaScript, policies in PDFs or images, and three pages that disagree.
Put the current price, currency, inclusions and key conditions in plain HTML text on the page, then mirror it in markdown.
Use schema.org Offer and MerchantReturnPolicy markup, following Google's documentation, so structured readers get the same facts.
Keep feeds, markup, pages and checkout in agreement. Google's Merchant Center spec already asks for this.
Give agents a way to ask, through an endpoint or WebMCP tools, for anything a static page cannot answer.
Test what assistants say about your prices on a schedule, and fix the source when they are wrong.
Why agents get your prices wrong
The usual assumption is that AI assistants hallucinate prices because the models are unreliable. Sometimes. More often the agent read something real and out of date: a cached comparison page, last year's pricing PDF, a reseller listing, or a promotion page nobody took down. Or it read your live page and found nothing, because the price loads from a script after the page renders and the agent's fetcher does not run it.
Shopping agents are also more literal than people. A person sees "From $29" next to a strikethrough and a banner and works it out. An agent may report $29 for the plan that actually costs $49 once you add the thing everyone needs. If the conditions live in a tooltip, a modal or a footnote image, the agent never sees them. The fix is less about AI and more about publishing your facts as text, once, in a structure that does not need interpreting.
The formats agents read, and what each is for
No single format covers every agent. Some fetch HTML. Some look for llms.txt. Some read structured data the way search engines do. Some call tools. The table below is how we think about the stack.
Format | Best for | Who reads it | Upkeep |
|---|---|---|---|
Plain HTML pricing and policy pages | Current prices, inclusions, conditions, returns and cancellation terms | Every agent that fetches a page, plus people | Low, if the page is the source of truth |
llms.txt and markdown copies | A short index of what matters and clean text versions of key pages | Agents and tools that look for it | Low; generate from the same source |
schema.org Offer and MerchantReturnPolicy markup | Machine-readable price, currency, availability and return rules per product | Search engines and structured-data readers | Medium; must change when prices change |
Product feed | Full catalogue pricing and availability for shopping surfaces | Shopping platforms such as Google Merchant Center | Medium; scheduled sync |
Agent endpoint, MCP server or WebMCP tools | Questions a page cannot answer, and account-specific queries | Agents that can call tools or HTTP endpoints | Depends on build or vendor |
Step 1: make pricing and policy pages plain text
Start with the pages you already have. For each plan or product, the page should state in visible HTML text: the price, the currency, the billing period, what is included, what costs extra, and the conditions that change the price, such as annual billing or minimum terms. Policy pages should state return windows, cancellation terms, refund conditions and who they apply to, in sentences, not in a PDF link.
Test it the way an agent would. Fetch the page without running JavaScript and read the raw text. If the price is missing, an agent may miss it too. Write the conditions next to the number, not in a hover state. And put a "last updated" date on pricing and policy pages, so an agent that finds two versions has a reason to prefer one. Our agent-ready website checklist covers the wider site.
Step 2: publish llms.txt and markdown copies
The llms.txt proposal suggests adding a /llms.txt markdown file at the site root that offers "brief background information, guidance, and links to detailed markdown files." It is a proposal, not a standard every assistant follows, but it is cheap and it gives any agent that does look a short path to your real facts. Link your pricing and policy pages from it, and publish markdown versions of those pages next to the HTML.
Lorikeet's own site is a working example: lorikeetcx.ai/llms.txt indexes the site, /pricing.md states plans, prices and rates in plain markdown, and /agents.md tells agents how to sign someone up, book a demo or ask the support agent. Generate these files from the same source as the pages so they cannot drift. For how llms.txt compares with endpoints and WebMCP, see WebMCP vs public endpoint vs llms.txt.
Step 3: add schema.org Offer and return policy markup
Structured data gives readers that parse markup the same facts without interpretation. On schema.org, an Offer is "an offer to transfer some rights to an item or to provide a service", with properties including price, priceCurrency, priceValidUntil, availability, priceSpecification and hasMerchantReturnPolicy. A MerchantReturnPolicy describes return policies associated with an Organization, Product or Offer, with properties such as returnPolicyCategory, merchantReturnDays and returnFees.
Follow Google's documentation rather than inventing your own pattern. Google's merchant listing structured data guide says the active price is required, may be nested inside priceSpecification, and must be greater than zero, and it lists hasMerchantReturnPolicy and shippingDetails as recommended Offer properties. Its return policy guide recommends a standard return policy nested under your Organization markup using hasMerchantReturnPolicy, with MerchantReturnPolicy under an Offer only to override it for a specific product. Validate the markup, and make sure it changes in the same release as the visible price.
Step 4: keep product feeds in step with the page
If you sell physical products, a product feed is how shopping surfaces get your catalogue. Google's Merchant Center product data specification marks price and availability as required, and asks merchants to match the price with the landing page, structured data and checkout, and to match availability with the landing page. That rule is good practice whoever is reading. When a feed, a page and markup disagree, an agent picks one, and you do not get a say in which.
Step 5: give agents something to ask
Pages answer the general questions. They cannot answer "does my plan include this", "what would I pay if I switched mid-cycle" or "am I still inside the return window for order 4471". Agents acting for a customer ask exactly those, and when nothing answers, they guess from the general page or go to your phone line.
Two patterns exist. The Model Context Protocol is an open protocol for connecting LLM applications to external data sources and tools, typically through a server you host. WebMCP is a proposed web standard that lets a site expose functionality as tools, JavaScript functions with natural language descriptions and structured schemas, defined in the page's own script. A plain HTTP endpoint that takes a question and returns an answer covers agents that support neither. Whichever you use, account-specific answers need identity: the agent should get no more than the customer could see after signing in.
This is the part a support concierge handles well, because it already answers the same questions for people. Lorikeet B2A lets agents that support WebMCP call tools on your website, while every other agent calls a public endpoint. Both answer from your knowledge, and the agent reaches the same concierge your customers do, with the same guardrails, identity verification and action policies. Lorikeet's own public ask endpoint, documented in its agents.md, is the same agent that answers on its website, so it reflects current product, pricing and policy content.
Step 6: test what agents actually say
Publishing is half the job. The other half is asking the assistants your customers use the questions your customers ask, on a schedule, and checking the answers against your source of truth. AI visibility monitoring tools now run fixed prompts across assistants daily and show what each one says and which pages it cites. You can also do it by hand for your top 20 pricing and policy questions each month.
When an answer is wrong, look at what was cited before you look at the model. Usually the agent found an old page, a third-party page or a page that hides the condition. Fix or redirect the stale page, add the missing sentence to the live one, and re-test. Blocking agents to stop wrong answers tends to make it worse, because they then answer from whatever else they can find. We cover that trade-off in blocking vs serving AI agents.
Platforms and approaches worth considering
Most businesses need a static layer and a conversational layer. These are the options we would look at, and they combine well.
1. Lorikeet B2A concierge
Lorikeet is an AI customer support platform for complex and regulated businesses. B2A deploys a concierge adapted to personal agent traffic with a copy-paste snippet, answers from your own knowledge through WebMCP tools or a public endpoint, and handles account-specific questions under the same identity verification and action policies as your customers. Always-on guardrails include response grounding, which keeps answers based on your knowledge base, data or instructions. Best when agents are asking questions a static page cannot answer.
2. Google Merchant Center feeds
For retailers, a Merchant Center product feed is the documented way to supply catalogue price and availability to Google's shopping surfaces, with the rule that feed, landing page, structured data and checkout match. It does not answer policy or account questions.
3. schema.org markup on your own pages
Offer, MerchantReturnPolicy and related types, implemented to Google's guidelines, give any structured-data reader the same price and return facts as the visible page. Free to adopt, and only as good as your release discipline.
4. llms.txt and markdown mirrors
A proposed convention, cheap to publish and easy to generate from your CMS. It helps agents that look for it and costs little if they do not.
5. Your own MCP server
If you have engineering capacity and structured pricing data, an MCP server can expose quote or lookup tools directly. You own the build, the auth model, rate limits and logging.
Checklist: accurate pricing and policy answers for agents
Pick one source of truth for prices and policies, and generate pages, markdown, markup and feeds from it.
Check every pricing and policy page renders its key facts as plain HTML text without JavaScript.
State currency, billing period, inclusions, extras and conditions next to each price.
Add a last-updated date to pricing and policy pages.
Publish /llms.txt linking to markdown versions of pricing and policy pages.
Add Offer and MerchantReturnPolicy markup per Google's guides, and validate it.
Reconcile feeds, markup, page and checkout prices on every release.
Remove or redirect old pricing pages, PDFs and promotion pages.
Offer an endpoint or WebMCP tools for questions pages cannot answer, with identity checks for account data.
Test your top pricing and policy questions across assistants monthly and fix the cited source when answers are wrong.
For the bigger picture on serving agents as a channel, read what is B2A.
Getting started
Do steps 1 and 2 this week; they are an afternoon of work for most teams. Add markup and reconcile feeds next. Then decide whether agents asking account-specific questions are frequent enough to need a concierge behind an endpoint.
If they are, you can get a demo or start a 30-day free trial, where Coach, Lorikeet's setup agent, helps you build a concierge, turn on the agent-facing endpoint and paste the snippet into your site.
Frequently asked questions
What is the best way to give AI shopping agents accurate prices?
Publish one source of truth and expose it in formats agents read: plain HTML pricing pages with conditions next to each price, an llms.txt index linking markdown copies, schema.org Offer markup, and a product feed that matches the page. Then test what assistants say and fix the cited source when they are wrong.
Does llms.txt make AI assistants use my pricing?
Not on its own. llms.txt is a proposal for a markdown file at the site root that gives brief background and links to detailed markdown files. Some agents and tools look for it and many do not, so treat it as a cheap addition to plain HTML pages and structured data, not a replacement.
Which schema.org types should I use for prices and return policies?
Use Offer for price, priceCurrency, availability and related properties, and MerchantReturnPolicy for return rules. Google recommends a standard return policy nested under Organization markup with hasMerchantReturnPolicy, and MerchantReturnPolicy under an Offer only to override it for a specific product.
Why do AI assistants quote old prices?
Usually because they found an old page, PDF, reseller listing or promotion page, or because the live price loads with JavaScript and the agent's fetcher does not run it. Remove or redirect stale pages, put prices in plain text and add a last-updated date to pricing pages.
How should agents get account-specific pricing or policy answers?
Through an endpoint or WebMCP tools backed by something that can verify the customer, such as a support concierge. The agent should get no more than the customer could see after signing in. Lorikeet B2A does this with the same identity verification and action policies your customers go through.
How does Lorikeet publish its own pricing for agents?
Lorikeet publishes pricing.md with plans, prices and rates in markdown, an llms.txt site index, an agents.md guide, and public endpoints for agent sign-up, demo booking and asking its support agent. The ask endpoint is the same agent that answers on the website, so it reflects current product, pricing and policy content.
