A benchmark study published on June 18, 2026, found that AI agents researching software pricing on 100 leading B2B products encountered access errors in nearly a third of all runs, forcing many of those sessions to pull pricing and feature data from third-party blogs rather than the vendor's own website. The analysis, conducted by Siteline founder David Kaufman, ran a simulated Claude agent against the pricing and marketing pages of companies spanning five categories: productivity and collaboration, developer tools, marketing and sales, customer support, and analytics and data. The gap between the best and worst performing sites, according to the report, was wide enough that the top 10 percent of products let an agent finish its research twice as fast and at under a quarter of the cost of the bottom 10 percent.

What the benchmark measured

Kaufman's team gave a Claude Sonnet 4.6 agent a single, repeatable instruction for each of the 100 products: find the monthly pricing for all publicly listed plans and list the top features of each plan. The methodology, described in the June 18 report on Siteline's site, ran this prompt across N=534 total simulated sessions, tracking accessibility, how cleanly pricing and feature information could be extracted, and the resulting token usage, dollar cost, and time spent for each run.

The median session, according to the findings, took about 32 seconds, made three search or fetch tool calls, and cost 0.24 dollars. That median obscured a much wider spread once individual products were compared. Full percentile data published alongside the report showed the fastest 10 percent of sessions (p10) completing in 22.9 seconds at a cost of 0.142 dollars, while the slowest 10 percent (p90) took 50.4 seconds and cost 0.589 dollars, a 4.2-times difference in price and a 2.2-times difference in time between the two ends of the distribution.

Kaufman's report noted that controlling for the number of product offerings, comparing only similarly simple products against each other, narrowed that variance by just 3 percent. In other words, the cost gap was not primarily explained by some vendors having more complex catalogs than others. It reflected something closer to how those catalogs were published on the web.

The Linear and Zendesk comparison

Two named case studies anchored the report's discussion of best and worst outcomes. Linear, described in the analysis as a modern engineering project management tool, completed its session in 16.9 seconds, using 33,000 tokens at a cost of 0.109 dollars across two tool calls: one search to locate the pricing page and one fetch to read it. According to the report, the agent parsed four separate plans with pricing and top features in a single pass, without consulting any source beyond Linear's own website.

Zendesk, a customer support platform the report characterizes as older and offering a more complex product line, took considerably longer. Its session ran 53.1 seconds, consumed 159,000 tokens, and cost 0.510 dollars across six tool calls, a roughly five-times cost difference and more than three-times time difference compared with Linear. The report's session trace shows what happened in detail: the agent's initial fetch of Zendesk's pricing page loaded, but the pricing table itself was rendered client-side in JavaScript, leaving no plan data visible to the agent. A follow-up attempt at a compare-plans page also failed. At that point, according to the trace, the agent pivoted entirely to third-party sources, pulling information from two blog posts, one hosted at hiverhq.com and another at featurebase.app, that discuss Zendesk's pricing externally. The report frames this outcome plainly: after two failed attempts at first-party data, the session fell back entirely to third-party blogs, which carry the risk of being outdated or inaccurate.

Zendesk was not evaluated in isolation. The full performance table published with the report places it among several products with above-median costs and elevated reliance on outside sources: a 55.5 cents average cost per run, 175,000 tokens, 48.4 seconds, 5.8 tool calls on average, and 60 percent of content in those sessions pulled from third parties, despite the vendor reporting no formal access errors in its own row of the dataset. Databricks appeared as the single most expensive product measured, at 0.95 dollars per run on 308,000 tokens, with 41 percent of content drawn from third-party sources despite what the report describes as accessible first-party pricing pages; the sticking point there was a pay-as-you-go cost calculator the agent could not read directly.

Access errors and the third-party fallback problem

The report's most consequential finding concerns what happens once an agent cannot load a page cleanly. Nearly one in three sessions, 30 percent according to the published data, hit at least one access error. A quarter of those errors, the report states, involved the agent being denied access outright, described in the underlying data as "URL not accessible" or "URL not allowed" responses consistent with bot blocking, broken links, or non-HTML content.

The consequence of those errors compounds rather than simply delaying the session. Sessions that encountered at least one access error pulled 58 percent of their eventual content from third-party sources, compared with just 12 percent for sessions where the agent reached the vendor's site without friction, according to the analysis. In 5 percent of all runs, the report notes, the agent abandoned the vendor's own website entirely and sourced 100 percent of its answer from outside pages.

Why does that matter beyond the raw efficiency numbers? Kaufman's report argues that third-party blogs and comparison articles frequently carry stale or inaccurate pricing, since they are not maintained on the same update cycle as a vendor's own site. An agent that defaults to those sources risks recommending a competitor whose pricing happens to be published more reliably, regardless of which vendor actually offers better value. The report states this concern directly in its framing of the Zendesk example, and repeats a version of the same warning in its discussion of Braze, a marketing and sales platform where the agent was reportedly unable to access pricing pages across all runs and instead fell back to a Braze resources article that itself pulls figures from third-party sites G2 and Vendr.

JavaScript rendering as the primary barrier

The report identifies a specific technical cause behind the majority of access failures: JavaScript-rendered pricing tables and product information. According to the analysis, with the exception of Google, agents built by Anthropic and OpenAI do not execute JavaScript, meaning any content that depends on client-side rendering is effectively invisible to them. The report states that 13 percent of runs contained references in the agent's internal processing to JavaScript or rendering issues, even though this was not formally counted as an error in the dataset.

This finding lines up with wider reporting PPC Land has tracked on the same structural problem. In a June 2026 analysis of comments from Google Search Advocate Gary Illyes, Illyes described the accumulated complexity of JavaScript rendering across the web as a significant obstacle for AI agents attempting to retrieve and process page content directly, a claim that mirrors the mechanism Siteline's benchmark isolates at the level of individual product pricing pages.

The report's recommended fix is comparatively simple in principle, if not always in execution: render content server-side, place the most important information near the top of the page since agents reliably process only the first 15,000 to 20,000 tokens, and publish actual prices rather than routing visitors to a sales conversation.

How much pricing goes undisclosed

A separate strand of the analysis examined how often vendors published real prices at all, as opposed to directing visitors toward a demo or a sales call. Across all 100 products, 65 percent of plans surfaced pricing directly, according to the findings, while 14 percent of the products evaluated did not disclose pricing on any plan whatsoever.

That figure varied considerably by category. The report's category breakdown lists price disclosure rates of 78 percent for productivity and collaboration tools and 75 percent for developer tools, both with 0 percent of products showing no pricing at all. Customer support fell to 61 percent price disclosure with 30 percent of products showing no prices anywhere, and marketing and sales landed at 56 percent disclosure with 29 percent showing none. Analytics and data tools sat at 54 percent disclosure with a comparatively lower 12 percent showing no prices at all.

Kaufman's report is careful to frame this as an open question rather than a settled causal claim. It states that further analysis would be needed to definitively link price disclosure to visibility in AI-generated answers, while adding that it is not a large leap to conclude that customers comparing prices in depth, or agents acting on their behalf, benefit when that information is actually accessible.

Category-level patterns

The report broke its full dataset into five categories, each covering 20 products, and offered specific observations within each. In developer tools, described as an overall strong-performing category with no access errors and fast run times, Supabase stood out for a single static, server-rendered pricing page that, at 24 kilobytes, returns complete pricing and feature information for every plan; Twilio and Stripe, though error-free, were comparatively slow and expensive because the agent had to navigate between three and six separate pricing pages for Twilio and as many as six for Stripe. In productivity and collaboration, Coda drew a specific critical mention: every attempt to fetch its pricing page reportedly failed, forcing the agent to assemble plan details entirely from third-party sources, which the category's full data places at a 96 percent third-party content share, the highest of any product in that group.

In customer support, beyond Zendesk, the report flags Gladly for repeated failures attempting to fetch pricing pages that do not appear to exist, with the agent falling back to a Shopify App Store listing and larger third-party articles, while Zoho Desk is described as accessible but thin, prompting supplementation from sources such as Capterra in some runs. In analytics and data, FullStory is highlighted for a pricing page that displays different plan tiers but no actual prices for any of them, while Omni presents an unusual case: despite averaging 0.80 dollars on 260,000 tokens, the agent stuck mostly to first-party content, with the high cost instead attributed to Omni being a generic-sounding name that led the agent through many unrelated search results before locating the correct product. In marketing and sales, beyond Braze, Iterable faced a distinct error: the agent attempted to visit iterable.com/pricing, a URL that does not exist and was not present in its search results, described in the report as the agent hallucinating the address, before turning again to third-party sources. The report suggests one lesson from this case is that vendors benefit from maintaining a pricing page at a predictable address even when they choose not to disclose exact figures there.

What businesses can do, according to the report

Kaufman's report closes with a set of concrete recommendations rather than general advice, framed as observations about what separated high- and low-friction sessions in the dataset itself. First, it recommends verifying that all text-bearing sections of a website render server-side, since the report describes this as by far the most significant obstacle preventing agents from retrieving content, and suggests site operators can check this themselves in Chrome's developer tools by disabling JavaScript rendering under Inspect, Settings, Preferences. It also recommends checking robots.txt files and bot-blocking configurations, singling out Cloudflare's default bot control settings as a common source of unintended blocking.

Second, the report recommends writing pricing and feature descriptions concisely and placing the most important details early in the page, on the basis that agents in the dataset reliably read only the first 15,000 to 20,000 tokens of any given page. Third, it points to a set of emerging technical standards relevant to agent accessibility: Cloudflare's automatic HTML-to-markdown conversion, described as a way of stripping content that agents do not need; Chrome's introduction of WebMCP, a mechanism giving agents on-the-fly access to site-specific tools; and the llms.txt standard, which the report states is now referenced more frequently by agents and bots according to data from Siteline and which Chrome has recently added to its Lighthouse developer best practices audit.

That last point connects directly to reporting PPC Land has followed closely over the past year. PPC Land's coverage of Google's Lighthouse integration in late May 2026 placed the standard inside the same audit tooling that site operators and technical SEO practitioners already treat as a baseline quality benchmark, even as adoption of the underlying file itself has remained modest. A study published in April 2026 and covered by PPC Land found that just 7.4 percent of Fortune 500 companies, 37 out of 500, had implemented an llms.txt file, compared with 92.8 percent that had implemented the far older robots.txt standard. A more recent adoption study found that among the tens of thousands of llms.txt files now published across the web, 97 percent recorded zero requests from AI systems, with AI retrieval bots accounting for only 1.1 percent of the requests those files did receive.

The final recommendation in Kaufman's report addresses what happens once an agent has already turned to a third-party source. It advises monitoring which outside sources are most frequently cited when agents discuss a given brand or product, and ensuring the information found there stays accurate and current, since the report's own data shows this fallback path occurring in a meaningful share of sessions regardless of what a vendor does on its own site.

Context: an industry already tracking this shift

The Siteline findings arrive as marketing and web publishing organizations have spent much of 2026 documenting a parallel set of pressures from AI systems on the open web, even though those pressures concern search and discovery rather than direct product research by agents. Cloudflare's Attribution Business Insights dashboard, launched July 1, 2026 and analyzed by PPC Land, documented crawl-to-referral ratios for AI systems ranging from 118 crawls per human visitor at the low end to nearly 50,000 at the high end, a separate but related measure of how much AI traffic now touches commercial websites without necessarily sending business back in return.

That broader pattern of AI systems reshaping how content gets discovered and consumed has also shown up directly in click-through data. PPC Land's coverage of SISTRIX's March 2026 review found that the click-through rate for the first organic search result in Germany fell from 27 percent to 11 percent when an AI Overview appeared on the page, a compression the same coverage tied to a broader body of evidence assembled by Ahrefs and Seer Interactive across separate markets and methodologies. Kaufman's benchmark measures a distinct part of the same underlying shift: not whether a product gets discovered by an AI system in the first place, but whether an agent that already knows about a product can actually retrieve accurate pricing and feature information once it goes looking.

Server-side rendering, a recurring theme in the Siteline report, has also surfaced repeatedly in PPC Land's coverage of how large platforms treat automated content requests. Cloudflare's Markdown for Agents service, introduced in February 2026 and covered by PPC Land at the time, converts HTML into a stripped-down markdown format specifically to reduce the token cost of serving content to AI systems, cutting that cost by roughly 80 percent according to the company's own figures. The mechanism addresses a version of the same problem Siteline's benchmark quantifies from the requesting side: agents process fewer tokens, and therefore incur lower cost, when the content they retrieve is already structured for machine reading rather than formatted primarily for a human browser.

Timeline

  • June 18, 2026 - Siteline founder David Kaufman publishes the full benchmark analysis and an accompanying interactive dashboard, describing a simulated Claude Sonnet 4.6 agent's attempts to retrieve pricing and feature data across 100 B2B software products.
  • Approximately three weeks after publication - Kaufman shares a summary of the findings on LinkedIn, including the Linear and Zendesk session comparisons and the JavaScript rendering explanation, drawing more than 74 reactions and several comments from marketing professionals.

Summary

Who: Siteline founder David Kaufman conducted and published the benchmark analysis, evaluating 100 B2B software products across five categories using a simulated Claude Sonnet 4.6 agent.

What: The analysis measured how efficiently an AI agent could retrieve monthly pricing and top features for each product, finding that access errors affected nearly a third of sessions, that those errors pushed reliance on third-party sources up to 58 percent of content from a baseline of 12 percent, and that 14 percent of products disclosed no pricing information at all.

When: Siteline published the full report and dashboard on June 18, 2026, with a summary shared on LinkedIn roughly three weeks later.

Where: The findings apply to publicly accessible pricing and marketing pages across the open web, with specific case studies drawn from Linear, Zendesk, Databricks, Coda, Braze, Iterable, Gladly, Zoho Desk, FullStory, and Omni, among others.

Why: The report matters to the marketing and advertising technology community because it quantifies, for the first time at this scale, a distinct layer of AI-driven discovery that sits below search visibility: whether an agent that already knows a product exists can retrieve accurate information about it, and what happens to that information when it cannot.