Can AI read my pricing page? 17 of 93 SaaS pricing pages put a price in the markup

How the pricing page was found, and what that alone revealed

A pricing page has no well-known location. There is no specification that puts it at a fixed path the way the robots exclusion standard puts a file at /robots.txt, so finding one means doing what a crawler does: fetch the home page and follow a link. Each of the 130 hostnames received one request for its home page over HTTPS from one network location, with redirects followed and a twenty five second timeout. 119 answered with a 2xx status and an HTML content type. The other 11 did not, and the reasons matter for reading every figure below: seven answered HTTP 403 to this crawler, two answered 429, one answered 503 and one answered 404. Among the seven refusals were openai.com, oracle.com, akamai.com and servicenow.com, so the surviving set leans toward sites that admit an unknown crawler, exactly as it does whenever this blog counts what a scan was refused.

From each of the 119 home pages every anchor element was read and a link was taken as the pricing link when its href path segment or its anchor text named pricing, plans or prices, in English or in one of four other spellings the corpus contains. 90 of the 119 home pages carried such a link and 29 did not. For those 29 the conventional path /pricing was requested instead, and that guess is worth its own sentence because it failed so comprehensively: of the 29, five returned a usable page, two returned 403, and 22 returned HTTP 404. A convention that holds on five sites in twenty nine is not a convention. The result is that the pages measured here were almost all reached the way a crawler would reach them, by following a link the site chose to publish, which is the same dependency this blog measured when it counted how many home pages offered a crawler no internal path at all. Two of the 90 discovered links answered 403 and the remaining 88 answered with HTML, giving 93 pricing pages in total. Four of the 93 sat on a different hostname from the home page that linked them.

Can AI read my pricing page?

On these 93 pages, a crawler that runs no JavaScript could read a price in the prose of 77 of them. That is the encouraging half and it is genuinely encouraging: the majority of these pricing pages are server rendered well enough that the numbers arrive in the bytes, which is not something this blog can say about every page type it has measured. When it counted the effect of client side rendering across a different frame, JavaScript supplied a measurable share of the prose. Here the prices mostly survive the fetch.

The second half is where the finding sits. 58 of the 93 pages carried at least one JSON-LD block. Only 17 carried a price, lowPrice or highPrice value anywhere inside it, and only 13 of those 17 carried a value above zero. So 41 pages published machine-readable markup on their pricing page and put no price in it, and 61 pages showed a reader a price while marking none of it up. The markup those 41 pages do carry is usually an Organization or a WebPage node, the same identity layer this blog found named no organization on 103 of 385 pages elsewhere in the corpus. It says who the company is. It does not say what the company charges.

That distinction is the whole reason the second number matters more than it looks. schema.org defines the price property of an Offer as "the offer price of a product, or of a price component when attached to PriceSpecification and its subtypes", which is an unambiguous assertion by the publisher about a specific thing. A figure in a paragraph is not. An engine that lifts "$19" from a sentence has to decide which plan it belongs to, whether it is monthly or annual, per seat or per account, and whether the adjacent "from" changes its meaning. That inference is exactly where a wrong answer comes from, and it is the same class of problem as the one behind a ChatGPT product feed requiring twelve fields rather than trusting a page to speak for itself. Marking the price up does not guarantee a citation, and this post does not claim it does. It removes the guess.

Four pages declared a price of zero while selling paid plans

Of the 17 pages that declared a price, four declared nothing but zero: auth0.com, dropbox.com, netlify.com and zapier.com. All four of those pages listed paid tiers in their visible text on the same day, and all four used the SoftwareApplication type. The mechanism is visible in the markup itself. Zapier's pricing page declares a SoftwareApplication with four Offer nodes named Free, Professional, Team and Enterprise. The Free node carries "price": "0" and "priceCurrency": "USD". The other three carry a name and a description and no price at all, and the Enterprise description ends "Contact for pricing". The visible text of the same page, read in the same request, contained $19.99, $69, $33.33 and $400 among others. Netlify's page does the same thing more briefly: a single Offer with "price": "0" and a description reading "Free tier available; paid plans for teams and enterprises", on a page whose text showed $9, $20 and $40.

Neither site has done anything careless, which is what makes this the interesting case rather than an error list. Google's SoftwareApplication documentation, carrying Last updated 2026-09-08 UTC, lists offers.price under Required properties and instructs that "if the app is available without payment, set offers.price to 0". A publisher with a free tier and four paid tiers has one required price field and five prices. Setting it to zero satisfies the requirement literally. What comes out the other end is a machine-readable statement that the product costs nothing, published on the page that exists to say what it costs, and there is no signal in the markup that the zero is a floor rather than the answer. This is the same failure shape as markup whose values are not on the page it describes: the syntax validates and the claim is wrong. The honest alternative is already in the vocabulary. Five of the 17 pages used AggregateOffer, which carries lowPrice and highPrice, and sentry.io declared lowPrice 0 and highPrice 960.00 on one node, which states the range instead of collapsing it.

The 16 pages that showed a crawler no price at all

Sixteen of the 93 pricing pages carried no currency token in their visible text, and they divide into three causes that call for three different responses. The largest group is deliberate. Nine of the 16 carried contact-sales wording, among them snowflake.com, workday.com, databricks.com and outsystems.com, and on a page that genuinely refuses to publish a number there is nothing to mark up and nothing wrong. An answer engine asked what those products cost should say that the vendor does not publish it, and the page supports exactly that answer.

The second cause is a page that arrived empty. hubspot.com/pricing/marketing returned 74,787 bytes of HTML and 5 visible words, which were the words of its own title element. canva.com/pricing returned 58 visible words, and all of them were an unsupported browser notice telling the client to update to Chrome, Firefox, Safari or Edge. Neither page is refusing to state a price; both are stating it somewhere a non-rendering client never reaches, which is the condition the scanner grades as a prose parity failure and the reason the what GPTBot sees tool exists. A stack-specific version of the fix is on the React and Next.js pages.

The third cause is the one most likely to be mistaken for the second, and it is the most instructive. jetbrains.com/store returned 60,425 bytes containing 144 currency tokens, including $299.00, $239.00 and $24.92, and 8 visible words. The prices are in the delivered bytes. They are inside script elements, in the payload the page will hydrate from, so an extractor that drops script subtrees the way a browser's text layer does never counts them. This blog has measured that exact arrangement before and found that text in hydration JSON scored the same as no text at all, and the same pattern accounts for 1password.com/pricing/enterprise with 95 tokens in the bytes and none in the text, and webnames.ca with 60. Four of the 16 pages are in this state. A site in it is one template change away from parity, because the data has already been sent.

What this measurement does not say

It describes 93 pages on one day. It does not describe what any named crawler does with them, because no request in this run came from GPTBot, ClaudeBot or PerplexityBot and none of those vendors documents how its fetcher treats an Offer node. Nothing here should be read as a claim that marking a price up produces a citation in ChatGPT or in Google AI Overviews. The claim is narrower and it is about legibility: a price inside an Offer is a statement a parser can take without inference, and a price in a sentence is not.

Five limits are worth stating plainly. 37 of the 130 hostnames produced no readable pricing page, 11 at the home page and 26 at the pricing page, and they are not absent at random, since a site that refuses an unknown crawler is likelier to refuse other automation too. Only one page per site was read, so nothing here describes a site's product pages, its documentation or its other templates. No JavaScript was executed, which is the point of the measurement rather than a shortcoming, but it means every figure describes what the server sent rather than what a browser eventually drew. A price was defined as a currency symbol or ISO code adjacent to a digit, which will count a figure that is not a plan price and will miss a price written in words, so the visible-text counts are an upper bound on precision rather than an exact inventory. And the corpus is an editorial sampling frame assembled for the crawlability study, so every rate here supports a statement about these 130 hostnames and nothing wider.

One more thing this run did not do is check whether the declared prices are correct. The table above reports what each site says about itself, not what it charges, and a blog post is dated while a price is not: any of these values may have changed since 22 September 2026. That is also the argument for reading them from markup rather than from a model's memory of a page, and it is why our own pricing is a page rather than a claim in an article. Anyone who wants the same two tests run against their own pricing page can get them from a scan, and the definitions behind the schema sub-score are set out on the methodology page and in the note on what structured data reaches ten million domains.