Our pricing is per-seat and usage-based. What do we publish?

Publish the model and a representative starting point as text: from $12 per seat per month, plus $0.10 per 1,000 requests. Agents relay the shape of the pricing accurately when you state it; they invent nothing when you do not, they just omit you.

Does hiding prices behind contact sales really cost agent traffic?

For any query that compares cost, yes. An agent shortlists vendors it can put numbers on. Contact for pricing is unrankable in a cost comparison, so the shortlist is built from competitors who publish.

What about currency toggles and regional prices?

Server-render a sensible default currency as text, and put per-currency values in Offer schema (one Offer per currency if needed). The failure mode to avoid is a page whose every price appears only after client-side JavaScript runs.

Prices agents can read: text and schema, not pixels

Updated 2026-07-13 · 3 min read · comprehension pillar

An agent finds your price two ways: a currency pattern in the page text ($49, 49 USD, EUR 49) or a price field in Offer structured data. If your prices exist only inside images, only after JavaScript renders a calculator, or only behind a contact form, then as far as agents are concerned you do not have prices.

This is a purely mechanical problem. The agent is not judging your pricing model; it just cannot extract a number from a PNG or from markup that does not exist at fetch time.

Why unreadable prices remove you from the answer

A large share of buying questions are price questions: what does X cost, cheapest tool that does Y, is A worth it over B. Assistants answer them with concrete numbers pulled from pages where numbers are extractable. If yours are not, you are either absent from the comparison or, worse, represented by whatever stale figure a review site or forum thread recorded last year.

Being in the comparison with your real, current price is the whole game. The agent does not negotiate; it shortlists what it can verify and presents that to the human. Every mechanism below exists to get your true number into that shortlist.

Publish prices as text, in sane markup

Keep each price and its currency symbol in one text node next to the plan or product name, server-rendered. If you offer a monthly and annual toggle, render one of them as real HTML by default instead of mounting both via JavaScript after load. Avoid assembling digits with CSS or splitting a price across elements for styling.

html

<section aria-labelledby="pricing-h">
  <h2 id="pricing-h">Pricing</h2>
  <div>
    <h3>Starter</h3>
    <p><strong>$19/month</strong>, billed monthly. 1 project, email support.</p>
  </div>
  <div>
    <h3>Pro</h3>
    <p><strong>$49/month</strong>, billed monthly. 5 projects, priority support.</p>
  </div>
  <div>
    <h3>Agency</h3>
    <p><strong>$99/month</strong>, billed monthly. 20 projects, SLA.</p>
  </div>
</section>

Plain text prices adjacent to plan names: the pattern both currency-regex extraction and humans skim correctly.

Back the text with Offer schema

Structured data makes the price authoritative instead of inferred. For SaaS plans, offers on a SoftwareApplication (or Service) work; for physical products use Product with Offer as covered in the product schema guide. Keep the schema numbers generated from the same source as the visible ones.

If your top tier is genuinely custom-priced, publish the floor: from $499/month gets you into shortlists that contact sales never will. State what is public honestly; agents relay qualifiers like starting price fine.

The two mechanisms back each other up. Text prices are what an agent quotes when it reads the page like a human would; schema prices are what it trusts when it wants a machine answer. Sites that publish both give every extraction path the same number, which is exactly what being quoted correctly requires.

html

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme CRM",
  "applicationCategory": "BusinessApplication",
  "offers": [
    { "@type": "Offer", "name": "Starter", "price": "19.00",
      "priceCurrency": "USD", "url": "https://acme.example/pricing" },
    { "@type": "Offer", "name": "Pro", "price": "49.00",
      "priceCurrency": "USD", "url": "https://acme.example/pricing" },
    { "@type": "Offer", "name": "Agency", "price": "99.00",
      "priceCurrency": "USD", "url": "https://acme.example/pricing" }
  ]
}
</script>

How AgentReady checks it

The scanner asks: are prices readable as text or structured data? On commerce sites it looks for currency patterns in the key page's text or a price inside Offer schema. Non-commerce sites with a pricing page get the same test there; sites with no pricing surface are marked not applicable rather than punished. The check is worth 2 points in the Comprehension pillar.

The methodology's reasoning: agents that cannot find a price in text or schema cannot compare or buy. Prices locked in images or JavaScript are invisible to them.

Frequently asked questions

Our pricing is per-seat and usage-based. What do we publish?: Publish the model and a representative starting point as text: from $12 per seat per month, plus $0.10 per 1,000 requests. Agents relay the shape of the pricing accurately when you state it; they invent nothing when you do not, they just omit you.
Does hiding prices behind contact sales really cost agent traffic?: For any query that compares cost, yes. An agent shortlists vendors it can put numbers on. Contact for pricing is unrankable in a cost comparison, so the shortlist is built from competitors who publish.
What about currency toggles and regional prices?: Server-render a sensible default currency as text, and put per-currency values in Offer schema (one Offer per currency if needed). The failure mode to avoid is a page whose every price appears only after client-side JavaScript runs.