A pricing.md example built from confirmed prices

By Ding Xiang · Published 2026-11-13 · Updated 2026-11-13

A pricing.md file is your pricing page rewritten as a plain Markdown table an agent can parse without guessing: product, price, billing basis, what is included, how it is delivered. It is a convention we use on our own products, not a universal standard — no registry certifies it and no agent is obliged to read it. Its value is narrower and real: when a tool does fetch it, your price comes back as a number in a labelled cell instead of a figure scraped from a styled page. This guide annotates a live example — ours.

1. Start from the visible page, not from a template

The Markdown file is a representation of a pricing page that already exists. If your human page says one thing and the file says another, the file is wrong by definition, however clean its formatting is. So the workflow starts at the source of truth: the prices a buyer sees at checkout. Write those down first — price, currency, and whether it is one-time or recurring — and only then open a text editor. Every figure in the example below traces back to the pricing table on this site's home page in exactly this way.

2. Record price, currency, billing basis and scope

These are the first lines of our live pricing.md:

Agent-Ready Audit is a one-time, human-run check of whether AI agents can read your product correctly: your pricing, your scope, and your contact facts. It covers 1 domain and up to 5 public pages. All prices are in USD.

Three facts an agent must never have to infer are stated before any table appears: the billing shape (one-time), the scope limit (1 domain, up to 5 pages), and the currency (USD). The plans table that follows then gives each plan the same five columns — product, price, billing, what you get, delivery — so “$19” is never a bare number. It is a one-time PayPal payment for a named deliverable with a stated delivery window.

3. Include exclusions, delivery and refund terms

Agents get asked the awkward questions too: what is not included, when does it arrive, what if it goes wrong. Our file answers them in a Details section rather than leaving the model to improvise. It states that the 48-hour window starts after payment is confirmed and the public URL is received; that the refund is full before delivery and, after delivery, a free fix or 50% back if our file cannot be published for a technical fault in the file itself; and that the service does not guarantee recommendations, rankings, citations or traffic. Exclusions written down are what keep a confident wrong answer from being assembled out of silence.

4. Two more live examples: PicForge and PatioBoQ

The same format runs on two other products of ours. PicForge's pricing.md lists its browser tools at $0 and one paid service, a Share Card Pack at $9 one-time via PayPal, with its 24-hour first-draft window and the one included revision spelled out. PatioBoQ's pricing.md lists a free calculator, an Instant Quote Score at $9.90 and a human-reviewed quote check at $19.90 — and just as importantly, it states its limits in the file: US ground-level concrete paver patios only, no walls, pools or driveways. Different products, same discipline: confirmed prices, named scope, exclusions in writing.

5. Check parity against the visible pricing page

Before publishing, and after every price change, diff the two representations by eye: every figure in the Markdown must appear identically on the human page, including the awkward ones — the scope limit, the delivery condition, the refund terms. When we deploy this site we compare the served /pricing.md byte for byte with the file in the build, so what an agent downloads is provably what we wrote. Parity is the entire point of the exercise: a second, machine-readable copy of the truth, kept true on purpose.