How to Make Your Pricing Page Readable by AI Agents

AI agents are starting to compare SaaS pricing for their users. Buffer's new machine-readable /pricing.md file shows where the web is heading.

Pricing table on a clean grid representing structured SaaS pricing pages
Updated How we review →
Rob
By Rob14 June 2026 · 4 min read

There's a quiet shift happening in how people compare software pricing. Instead of opening four browser tabs to compare four tools, more users now ask an AI agent to do the comparison and summarise the differences. The agent goes off, reads each pricing page, and comes back with a short answer.

The problem with this workflow today is that pricing pages aren't designed to be read by software. They're designed to convert humans - lots of visual hierarchy, conditional pricing modal pop-ups, feature comparison tables that only render after a JavaScript hydration step. An AI agent often gets a confusing or outdated answer. Buffer noticed this and shipped something interesting in response.

What did Buffer actually do?

Buffer added a new file at the path /pricing.md to its marketing site. The file is structured markdown that lists the plans, the monthly and annual prices, the feature limits per plan, and the policy notes (refunds, billing terms, included channels). No CSS, no JavaScript, no marketing copy - just clean readable structured data.

The clever bit is that the path is conventional rather than buried behind a custom API. Any agent (or developer, or competitor) looking at buffer.com/pricing.md can pull a usable pricing snapshot in under a second. It builds on the same idea as the llms.txt convention some sites have adopted to expose their content structure to language models without requiring scraping.

Why is this likely to spread?

Three reasons.

  • AI agents are getting pricing wrong. If you've ever asked a chatbot to compare two SaaS tools' pricing, you've probably seen at least one number that turned out to be old or wrong. SaaS companies don't enjoy being misquoted on their own prices. A canonical machine-readable file gives them a way to control what gets repeated.
  • The signal-to-noise ratio of pricing pages is bad. Modern pricing pages are full of upsell modals, trust badges, customer logos, and feature tables that only render after the user interacts. The page is great for conversion but terrible for comparison. A separate machine-readable file solves the conversion-vs-comparison tension cleanly.
  • The cost of building one is tiny. Buffer's file is a few dozen lines of markdown. Updating it when pricing changes is trivial. Most SaaS teams will look at this and ask 'why don't we just do that'.

What does this mean if you run a website?

The general pattern is broader than pricing. The web is starting to grow a parallel surface designed for machines: /llms.txt for content structure, /pricing.md for pricing, robots.txt for crawl directives, and more emerging. If you operate a site where prices or product specs are part of the value, it's worth thinking about what an AI agent would see if it tried to compare you against your competitors today.

A few practical questions to ask yourself:

  • If someone asks an AI to compare your tool to two alternatives, what numbers does the agent come back with? Are they correct?
  • Do the prices on your marketing site need JavaScript to render? An agent without a real browser will see nothing.
  • Could a small machine-readable file like /pricing.md or /llms.txt give you a more reliable surface to be quoted from?

This isn't a 'rush to do it today' situation. AI-driven discovery is still a minority of traffic for most sites. But the curve is going up sharply, and the early adopters are starting to put structure in place.

What are the limits of this approach?

Two honest caveats.

First, a machine-readable file only helps agents that know to look for it. Buffer's file works today because a small number of agents have started checking conventional paths like /llms.txt and /pricing.md. There's no widespread standard yet. Until there is, you'd want the file in place and also keep your visible pricing page well-structured for agents that fall back to standard crawling.

Second, exposing structured pricing publicly makes it easy for competitors to track changes automatically. If your pricing strategy depends on stealth - test prices, regional differences, limited-time offers shown only to certain visitors - a public /pricing.md isn't the right move. For most SaaS tools with transparent pricing this isn't a real cost, but it's worth thinking about.

The bottom line

The web has historically been a wall of pages designed for humans to read. AI agents are slowly building a parallel surface for the same content optimised for machines to parse. /pricing.md is one small example of where this is heading. If you run a site where being correctly quoted matters - SaaS pricing, product specs, opening hours, policy details - it's worth checking what an AI agent sees today and thinking about whether a dedicated machine-readable file would give you more control.

The infrastructure is being built quietly while most of the conversation is about the chatbot side. The teams who set up canonical machine-readable surfaces early will probably look quite far-sighted in a year or two.