Make Your SaaS Price Machine-Readable (So AI Assistants Can Actually Quote It)

A developer argues that SaaS pricing must be machine-readable in plain HTML for AI assistants to quote it, providing a self-audit command and a JSON-LD template. The post identifies common failures like missing currency codes or client-side rendering that hides prices from crawlers, and offers a server-rendering fix for Next.js.

When someone asks an AI assistant "what is a cheap tool for X under $20 a month," the assistant can only put your product in that answer if it can read your price as plain, parseable text. Not as a number painted into a hero image. Not as a value that only exists after three React renders and an API call. Not behind a "Contact us" button. This is a narrower problem than it sounds, and it is very fixable. Below is the version I wish someone had handed me: the exact failure modes, a self-audit you can run in one line, and a complete, valid JSON-LD block you can paste and adapt. An extractor a crawler, an LLM fetching your page, an AI search bot sees roughly what curl sees, plus a best-effort attempt at running your JavaScript. If your price is not in the HTML it receives, and not in your structured data, then as far as that extractor is concerned, your price does not exist. It will reach for a competitor whose price it can read. So the whole job is: get a real, qualified price into text the machine receives on first load. Here is the difference that matters, side by side. First, an Offer an extractor can use: { "@type": "Offer", "price": "12.00", "priceCurrency": "USD" } And here are three Offer shapes that look fine to a human but break machine reading: // 1. Missing priceCurrency: "12" of what? Unusable. { "@type": "Offer", "price": "12.00" } // 2. priceRange on an Offer: invalid here, it belongs on LocalBusiness. { "@type": "Offer", "priceRange": "$12-$49", "priceCurrency": "USD" } // 3. No numeric price at all, just prose. { "@type": "Offer", "description": "Contact sales for pricing" } The valid one has two things every parser needs: a numeric price and an ISO priceCurrency . Everything else in this post is in service of producing that. Before changing anything, look at your page the way a crawler does. The fastest check is one line: curl -s https://yourdomain.com/pricing | grep -iE '\$ 0-9 |per month|priceCurrency' This fetches the raw HTML no JavaScript executed, which is the worst-case an extractor might face and greps for the three signals that matter: a dollar amount, a billing period phrase, and the structured-data currency field. What the output tells you: $ match but no priceCurrency :Run it against a couple of competitors too. It is a quick way to see who is legible to AI and who is not. If you want to be stricter, fetch with a bot-like user agent and inspect the body: curl -s -A 'Mozilla/5.0 compatible; ExtractorBot/1.0 ' \ https://yourdomain.com/pricing | grep -ic 'priceCurrency' A count of 0 means no machine-readable currency anywhere in the served HTML. The single highest-leverage fix. If your pricing page is a client component that fetches plans from an API and renders them after hydration, the first HTML payload contains no prices. Extractors that do not run your JS many do not, and even those that do may time out see an empty shell. You do not have to server-render the entire interactive pricing table with its toggles and tooltips. You need at least one real, representative price in the initial HTML. A common, pragmatic pattern: render a static default tier server-side, then let the client enhance it. In a Next.js App Router server component, this is the default behavior as long as you do not push the data fetch into a 'use client' boundary: js // app/pricing/page.tsx Server Component, no "use client" import { getPlans } from '@/lib/plans'; export default async function PricingPage { const plans = await getPlans ; const starter = plans.find p = p.id === 'starter' ; return <main <h1 Pricing</h1 <section <h2 {starter.name}</h2 {/ amount and period live in ONE text node, see Step 3 /} <p className="price" { $${starter.price} per month }</p </section {/ client-enhanced interactive table can hydrate below /} </main ; } The key is that getPlans runs on the server, so $12 per month is in the HTML curl receives. Re-run the Step 1 audit after this change and you should see the line appear. If you are on a fully static site, the same rule holds: the price must be in the built HTML, not injected by a script tag after load. This one is sneaky because it looks correct in the browser. Designers love to stack the number and the cadence: < -- Reads as "$12" then, somewhere else visually, "/month". A parser that strips layout sees "12" and "month" as unrelated tokens. -- <div class="price" <span class="amount" $12</span <span class="period" /month</span </div Visually that is $12/month . But CSS is what places those spans next to each other. An extractor that flattens the DOM to text, or a screen reader, may read $12 and month as two disconnected pieces, or drop the relationship entirely. The same failure happens with flex gaps and absolute positioning doing the spacing. Bake the relationship into a single text node: <div class="price" $12 per month</div If you must style the number differently from the period, keep them in the same node and style with a wrapping span that does not break the text flow, or accept that the whole string $12 per month is what gets read. The rule: a parser stripping all CSS should still read "twelve dollars per month" as one continuous phrase. "per month" and "/month" both work; what fails is having the amount in one element and the period in a visually-separated sibling with no textual glue. Visible text gets you most of the way. Structured data makes the price unambiguous and removes any guesswork about currency, billing, and what the price even refers to. For a software product, the correct top-level type is SoftwareApplication . Here is a complete, minimal block you can adapt. Drop it in a <script type="application/ld+json" tag in your page head or body: { "@context": "https://schema.org", "@type": "SoftwareApplication", "name": "Acme Analytics", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "offers": { "@type": "Offer", "price": "12.00", "priceCurrency": "USD" } } That is the whole contract for a single price: SoftwareApplication with an offers object that carries price and priceCurrency . If you have multiple tiers, use an array of Offer objects: { "@context": "https://schema.org", "@type": "SoftwareApplication", "name": "Acme Analytics", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "offers": { "@type": "Offer", "name": "Starter", "price": "12.00", "priceCurrency": "USD" }, { "@type": "Offer", "name": "Pro", "price": "49.00", "priceCurrency": "USD" } } Notes that save you debugging time later: price is a string, and a plain number with no currency symbol inside it. "12.00" , not "$12" . priceCurrency is an ISO 4217 code: USD , EUR , GBP . applicationCategory and operatingSystem are not strictly required for the price to read, but they help classifiers understand what the product is.If your structured data and your visible price ever disagree, fix the data. Extractors and search engines penalize structured data that contradicts the page, and an AI assistant quoting a stale JSON-LD number is worse than quoting none. After auditing a lot of pricing pages, the same three mistakes account for most of the unreadable ones. All three are in the JSON-LD, and all three are quick fixes. Product instead of SoftwareApplication Product in schema.org is modeled for physical goods. Software is not a physical good, and using Product muddies how a parser classifies you. Use SoftwareApplication or a subtype like WebApplication for SaaS. // Wrong for SaaS: { "@type": "Product", "name": "Acme Analytics", "offers": { ... } } // Right: { "@type": "SoftwareApplication", "name": "Acme Analytics", "offers": { ... } } priceCurrency A price with no currency is meaningless. "12.00" could be dollars, euros, rupees, anything. Parsers that require a currency most do will discard the offer entirely, so you end up with the same outcome as having no price at all. // Discarded: no currency. { "@type": "Offer", "price": "12.00" } // Usable. { "@type": "Offer", "price": "12.00", "priceCurrency": "USD" } priceRange on an Offer This is the one that trips up people who know schema.org exists but grab the wrong property. priceRange is a property of LocalBusiness think the $$ symbols on a restaurant listing . It is not valid on Offer , and putting it there gives you a string like "$12-$49" that no parser will read as a number. // Invalid: priceRange does not belong on Offer. { "@type": "Offer", "priceRange": "$12-$49", "priceCurrency": "USD" } // Express a range as multiple offers, each with a numeric price. "offers": { "@type": "Offer", "name": "Starter", "price": "12.00", "priceCurrency": "USD" }, { "@type": "Offer", "name": "Pro", "price": "49.00", "priceCurrency": "USD" } If you genuinely have variable pricing, model the low end as a concrete Offer so there is at least one real number an assistant can anchor on. Sometimes there is no public price by design. That is a business decision and this post will not argue you out of it. But understand the tradeoff: a "Contact us" wall is, to an extractor, identical to having no price. When an AI assistant assembles a price-qualified shortlist, you are not in the candidate set, because there is no number to qualify. If even one entry-level tier has a public price, you become quotable. That single number is the price of admission to those answers. Two quick checks close the loop: curl | grep audit. You should now see your amount, your period, and priceCurrency in the raw HTML. Offer .If both pass, an extractor fetching your page gets a numeric price, a currency, and a billing period it can attach to your product name. That is the entire requirement. Making your price machine-readable is one slice of a broader shift: software products are increasingly described in structured, queryable ways so that AI systems can recommend them reliably. The same discipline applies to how you describe use cases, platforms, and audiences. Structured product directories such as PeerPush https://peerpush.com/ lean on exactly this kind of normalized data, and there are other ways to get the signal out too, including clean JSON-LD on your own domain and accurate listings wherever your product appears. But you do not need any of that to start. Run the one-line audit today. If it comes back empty, you have found real money leaking out of every AI-mediated buying conversation, and you now have the four fixes to plug it.