Quick answer
AI buyer agents fail on pricing pages more often than most teams expect. A Claude agent tested against 100 B2B products returned a readable price on only 65, hit access errors on roughly 30% of runs, and in 5% of runs gave up on the brand site and quoted a third-party source instead (Siteline via Search Engine Journal). The number one cause was JavaScript-rendered pricing tables, which agents cannot see because they read HTML and do not run your scripts. Fix it by server-rendering your prices in raw HTML, keeping the pricing URL reachable to AI bots, and adding pricing context to your llms.txt. If an agent cannot read your price, it recommends a competitor who published theirs.
A team ran a simple experiment. They pointed a Claude agent at 100 B2B software companies and asked it the one question every buyer asks: what does this cost? The agent came back with a readable price on 65 of them. On the other 35, it failed.
That result, from a Siteline study written up in Search Engine Journal, is the clearest picture yet of a problem most companies do not know they have. This is late-funnel failure, which is the expensive kind. The buyer already knows your brand. They trust you enough to ask. They send an assistant to pull your pricing, your site returns nothing the agent can use, and you never see the deal you just lost.
The study: a Claude agent failed on more than a third of pricing pages
Siteline ran a Claude agent against the pricing pages of 100 B2B software products and measured what came back. The headline numbers are worth sitting with.
| What the agent found | Share of the 100 products |
|---|---|
| Plans with a readable price returned | 65% |
| No readable price returned | 35% |
| Runs that hit an access error | ~30% |
| Runs that abandoned the brand site for a third-party source | 5% |
Two of these matter more than the rest. First, 35% of these companies have a pricing page that an AI buyer agent could not use. Not a slow page, not an ugly page, an unreadable page. Second, in 5% of runs the agent did not just fail quietly. It went and found your price somewhere else, on G2, on Vendr, or in a stale blog post that may be two versions and one price increase out of date. Those numbers come from the Siteline study; the interpretation is ours.
Access errors were the other big bucket, roughly 30% of runs. An access error means the agent asked for the page and got something it could not read: a block, a challenge, a redirect loop, or a shell of a page with no content in it. To a human in a browser the same URL looks perfectly normal. That gap between what a browser sees and what an agent receives is the whole story.
Why JavaScript pricing tables are invisible to agents
The single biggest culprit in the study was pricing tables rendered by JavaScript. To understand why that breaks agents, you have to know how they fetch a page, which is nothing like how a person does.
A browser downloads your HTML, then runs every script on the page. If your pricing tiers get injected by a React component, pulled from an API after load, or built by a pricing widget, the browser executes all of that and paints the final table. The person sees prices.
Most AI fetchers do not run scripts. They request the raw HTML at the URL and read what comes back in that first response. If the price is not in that HTML, it does not exist as far as the agent is concerned. A client-side pricing table is, to a bot, an empty container waiting for JavaScript that never runs. The buyer's assistant sees a pricing page with no prices on it.
This is the same failure that trips up ChatGPT-User, Claude's fetcher, Perplexity, and any tool-calling agent sent to check a number. It is not a rendering quirk you can style around. The content has to be in the HTML the server sends, or it is gone. We cover the broader version of this problem in why ChatGPT agents can't access some sites.
The "Contact Sales" dead end hands the deal to a competitor
Not every pricing page fails because of JavaScript. Some fail on purpose. The classic move in B2B is to publish a starter price, then gate everything serious behind a "Contact Sales" button with no number attached.
A human tolerates that. They sigh, they fill out the form, they wait for the sales email. An agent does not fill out your form. It hits the wall, registers that there is no price to read, and does exactly what the study caught it doing in 5% of runs: it leaves and finds the number somewhere else. G2 has a range. Vendr has a benchmark. An old comparison blog has a figure from 2024. The agent takes whichever it can read and moves on.
Worse, a pure "Contact Sales" dead end with no public anchor can push the agent to recommend a competitor who did list a price. When the assistant is helping a buyer compare three vendors and yours is the only one it cannot price, you are the easy one to drop from the shortlist. You did not lose on product. You lost because the machine reading the shortlist could not find your number.
You can gate. Just leave an anchor. A "starting at" price, a published range, or a single readable tier gives the agent enough to place you in the comparison instead of dropping you from it. This is the late-funnel version of the silent funnel, where agents make and break shortlists without ever showing up in your analytics.
Don't accidentally block the bots you want to reach
The 30% access-error rate points at a second self-inflicted wound: blocking. Plenty of sites have added AI-crawler blocks over the past year, sometimes deliberately to keep training bots out, sometimes as a default that shipped with a security tool or a WAF rule nobody reviewed.
The problem is that a blanket block does not distinguish a training crawler from the user-triggered fetcher that fires when a real buyer asks an assistant to check your price. Block one and you often block the other. The result is an access error on the exact page you most want a buyer's agent to read. Deciding what to keep out is a real question, and we walk through it in our llms.txt resource, but the pricing page is almost never the page to gate.
The catch is that you usually cannot tell this is happening. The block is invisible in a browser. The only way to know whether GPTBot, ClaudeBot, or ChatGPT-User is reaching your pricing page, or bouncing off a rule, is to look at what the bots actually did.
What to fix on your pricing page
Five concrete changes, in the order that pays off fastest:
- Server-render your prices in raw HTML. Plan names, prices, and feature lists must be in the first HTML response, not injected by a client-side script. If you are on a framework that supports it, move the pricing table to server-side rendering or static generation. The quick test: view the page source (not the inspector) and confirm the numbers are in the markup.
- Keep the pricing URL reachable to AI bots. Audit your robots.txt, WAF, and CDN rules for anything that returns a block or challenge to AI user agents on the pricing path. The user-triggered fetchers are the ones a buyer sends. Let them through.
- Leave a readable anchor on gated tiers. If a plan is "Contact Sales," still publish a starting price or a range so an agent can place you in a comparison instead of dropping you from it.
- Add pricing context to your
llms.txt. Link the pricing page and summarize, in one line, what each tier costs and who it is for. This gives an agent a clean, machine-readable pointer even if it never renders the full table. - Verify that agents actually reach the page. Do not assume the fix worked. Watch real bot hits on the pricing URL and confirm the fetchers you care about are getting a real response.
See whether agents are reaching your pricing at all
The first four fixes are engineering. The fifth is measurement, and it is the one most teams skip. You can server-render a perfect pricing table and still lose the deal if a stray WAF rule is bouncing ChatGPT-User before it reads the page. Configuration is not the same as visibility.
This is where Crawlytics fits. The DETECT layer shows which AI bots hit which pages, when, so you can watch your pricing URL specifically and confirm that GPTBot, ClaudeBot, PerplexityBot, and the user-triggered fetchers are getting through. If an accidental block is turning them away, it shows up as the absence of hits or a pattern of errors on that path, which is the signal you cannot see in a browser or in Google Analytics.
From there, the same tool generates an llms.txt that gives agents a clean pointer to your pricing, and the per-page audit scores whether each page is agent-readable in the first place. If you want the fast version, the free Agent-Ready Grader runs the readability checks on your pricing page right now. For teams selling to agent buyers, agentic commerce for SaaS covers the next layer, letting an agent select and start a purchase without scraping your DOM.
The bottom line
A buyer who already trusts you sends an agent to check your price. That is a warm, late-funnel signal, and 35% of B2B software companies fail it because their prices live in JavaScript or behind a wall the agent cannot open. The fix is not exotic. Put the numbers in the HTML, keep the page reachable, leave an anchor on gated tiers, describe your pricing in llms.txt, and then look at the bot logs to prove it worked.
Do that and the next time an assistant builds a shortlist, your price is on it. Skip it and the agent quotes whoever made theirs easy to read.
Frequently asked questions
Can AI agents read my pricing page?
Often not. In a Siteline study covered by Search Engine Journal, a Claude agent checked pricing on 100 B2B software products and returned a readable price on only 65 of them. About 30% of runs hit access errors, and 35% ended with no usable price. The most common reason was pricing tables rendered by JavaScript, which agents do not execute. If your prices only appear after a script runs, a buyer agent sees an empty page.
Why can't AI agents see JavaScript-rendered pricing?
Most AI fetchers request the raw HTML of a page and do not run JavaScript the way a browser does. When your pricing tiers are injected by a client-side script or loaded from an API after the page loads, that content is not in the HTML the agent receives. The human in a browser sees the full table because the browser executes the script. The agent sees the version before the script ran, which usually means no prices at all.
Should I block AI bots from my pricing page?
No, not the pricing page. Blocking training crawlers site-wide is a defensible choice, but the same rule can accidentally block the user-triggered fetchers that fire when a buyer asks an assistant to check your price. A blocked pricing page returns an access error, and the agent moves on to a source it can read, often a competitor or a third-party aggregator. Keep the pricing URL reachable to AI user agents even if you keep training bots out elsewhere.
How do I make my pricing agent-readable?
Render plan names, prices, and feature lists in server-side HTML so they exist in the first response. Keep the pricing URL alive and reachable even when a specific plan says "Contact Sales." Add a line to your llms.txt that points to the pricing page and summarizes what each tier costs and who it is for. Then confirm that real AI bots are reaching the page instead of assuming they are.
What happens when my pricing page has a "Contact Sales" wall?
The agent hits a dead end and looks elsewhere. In the Siteline study, 5% of runs abandoned the brand site and pulled numbers from third-party sources like G2, Vendr, or old blog posts. A "Contact Sales" gate with no public number can push the agent to recommend a competitor whose price is listed. If you gate high tiers, keep at least a starting price or a range readable so the agent can still place you.
Related
Written by Crawlytics Team. Crawlytics tracks AI bots, generates llms.txt, and powers WebMCP commerce, all from one snippet on any stack. See how it works →