An AI purchasing agent scanning your pricing page for a shortlist doesn't read your copy. It parses the Schema.org JSON-LD on that page, specifically the Product and Offer types, to pull the price, the currency, the tier name, and whether that tier is available right now. If that markup is missing, outdated, or absent, the agent either skips your page entirely or reports a price it can't verify, and either way you're out of the comparison before a human ever sees your name. Below is the exact JSON-LD block to add to your pricing page, the three mistakes that get schema ignored even when it's present, and how to check whether any of the agents actually doing this right now have even visited your page.
What an AI agent is actually looking for on your pricing page
An agent parsing your page for a shortlist is running a five-field checklist: product name, brand, each tier's price, the currency, and current availability. Gartner has projected AI shopping agents will mediate roughly a quarter of online retail transactions in 2026, and McKinsey puts the total agentic commerce opportunity at three to five trillion dollars by 2030. Neither number means anything if your pricing page has nothing structured for the agent to read.
Most B2B SaaS pricing pages are built as styled divs and JavaScript-rendered tier cards, which a human reads instantly and a crawler has to guess at. GPTBot, ClaudeBot, and PerplexityBot, the crawlers actually doing the fetching behind an AI agent's research step, need something explicit: which number is the price, what currency it's in, and whether the tier is buyable today. That's what Product and Offer schema exist to do.
The exact JSON-LD block to add
Paste this inside a script tag with type="application/ld+json" in the head of your pricing page. Use one Offer per tier, or an AggregateOffer if you want to cover the full price range in a single block:
{ "@context": "https://schema.org", "@type": "Product", "name": "[Your product] Growth plan", "brand": { "@type": "Brand", "name": "[Your company]" }, "description": "[One sentence describing what this plan includes]", "offers": { "@type": "AggregateOffer", "priceCurrency": "USD", "lowPrice": "49", "highPrice": "499", "offerCount": "3", "availability": "https://schema.org/InStock", "priceValidUntil": "2026-12-31" } }
Five fields carry almost all of the weight here. Name and brand tell the agent what it's looking at and who sells it. PriceCurrency and the low or high price tell it what it costs. Availability tells it whether you're actually selling right now, and priceValidUntil tells it the number is current rather than a stale cache. Skip any one of these and the agent either can't use the listing or has to guess, and guessing is what gets you excluded from a shortlist instead of included in one.
The three mistakes that make agents distrust your schema
- Stale price. If the JSON-LD price doesn't match what's actually on the page, agents treat that mismatch as a trust signal and downgrade or drop the listing rather than giving you the benefit of the doubt.
- A flat Offer on a tiered product. One static price on a plan that actually has three tiers tells the agent you have a single price point, which misrepresents you against competitors whose AggregateOffer clearly shows a range.
- No availability field. Without it, an agent can't tell if you're actively selling to new customers or sitting in some legacy or waitlist state, and it defaults to skipping the page rather than assuming you're open for business.
Where to check it's actually being read
Run your pricing URL through Google's Rich Results Test to confirm the Product and Offer types parse without warnings. Then check your server logs or a bot analytics tool for hits from GPTBot, ClaudeBot, PerplexityBot, and OAI-SearchBot specifically on the pricing URL, not just your homepage. If none of those four have touched that page in the last 30 days, the schema isn't the bottleneck yet, because nothing is fetching the page to read it.
This is also where llms.txt gets confused with schema markup, and they're not the same fix. The crawlers doing AI search and shopping comparisons overwhelmingly skip llms.txt and fetch your HTML directly, which means the JSON-LD on your actual page is doing the real work for a purchasing agent right now, not a text file most of those bots never open.
What this doesn't fix
This block gets your price and tiers parsed correctly. It doesn't fix a pricing page whose tiers are confusing, whose plan names don't map to a real buyer question, or whose structure penalizes a customer for growing, that's a separate readiness problem. An agent will parse a badly structured pricing page perfectly and still shortlist you out. Schema is the parsing layer, not the pricing strategy, and it's a different question from whether AI search is citing you at all.
The one thing to do this week
Add the block above to your live pricing page, run it through the Rich Results Test, and check your bot analytics for GPTBot, ClaudeBot, and PerplexityBot hits over the next two weeks. If they show up and your listing still doesn't get picked, the problem has moved from parsing to positioning. If they never show up at all, the fix isn't more schema, it's getting mentioned and linked on the sites those crawlers already trust enough to cite.
Frequently asked questions
Does JSON-LD schema on my pricing page actually help with ChatGPT or Perplexity results?
It helps in the moment those tools' crawlers fetch your page directly during a live comparison query. It doesn't influence whether you show up in a general answer, that's driven by being cited and linked elsewhere, not by on-page schema alone.
Do I need different schema for SaaS versus a physical product?
No. Product and Offer are the pair built to carry pricing tiers for software the same way they carry a retail SKU. Some sites layer SoftwareApplication schema alongside it, but Product and Offer are what a purchasing agent parses first.
What happens if my JSON-LD price goes out of date?
The agent treats the mismatch between your schema price and your visible page price as a trust problem, not a rounding error. It downgrades or skips the listing rather than assuming your live page is right, so this has to stay in sync every time pricing changes.
Should I use llms.txt instead of this schema?
No, they solve different problems. llms.txt is read reliably by IDE agents like Cursor and Claude Code, not by the AI search and shopping crawlers running purchase comparisons, which is why schema markup is the one actually reaching purchasing agents today.
How do I know if any AI agents are even visiting my pricing page?
Check server logs or a bot analytics tool for the GPTBot, ClaudeBot, PerplexityBot, and OAI-SearchBot user agents hitting your pricing URL specifically, not just your homepage or blog.
None of this needs an engineering sprint. It's one script tag, five fields, and a validator check. The founders who get shortlisted by an agent they never see aren't the ones with the best pricing, they're the ones whose pricing was actually readable when the agent looked.