Make your pricing machine-readable for shopping agents

Quick summary

An agent that has to read "starting at $12/month, billed annually" out of a paragraph is guessing at three separate facts: the number, the currency, and the billing period. Structured pricing turns that guess into a field lookup.

Why a shopping agent can't just read your price off the page

Think of a pricing page the way a human reads it: a headline number, a strikethrough for the discount, a footnote about annual billing, maybe an asterisk pointing at a currency note lower down. A person's eyes assemble that into one fact in about a second. A language model reading the same HTML has to do the same assembly from prose, and prose is where prices go wrong: a "starting at" that isn't the actual price, a currency symbol that's ambiguous between USD and CAD, a "monthly" that's actually billed yearly. None of that is a rendering failure. The page looks correct. It's a structured-data failure, because there's no field anywhere on the page that says, unambiguously, price: 12.00, priceCurrency: USD, billingDuration: 1 month.

Schema.org's Offer and AggregateOffer types exist to close exactly that gap. They put the price, the currency, the availability and the billing period into a machine-parseable block sitting next to the human-readable page, so an agent can read the field instead of parsing the sentence. AIScan's own check for this is M4, under the commerce dimension, and its own fix guide states the reasoning in one line: a JSON-LD Offer block on a pricing page lets an agent answer "what does this cost" without reading prose. Fetched from AIScan's get_check_guidance tool on 22 September 2026, so this is the platform's own current wording, not a paraphrase.

What the schema actually needs to say

Two schema.org types cover almost every pricing page. Reach for Offer when you're pricing one specific thing at one specific price. Reach for AggregateOffer when a single product or plan comes in a range, several tiers, several currencies, several variants, and you want one block that spans the range rather than one block per price.

AIScan's own fix guide for M4 gives this as the base example, fetched from get_check_guidance on 22 September 2026:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Pro",
  "offers": {
    "@type": "Offer",
    "price": "12.00",
    "priceCurrency": "USD",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "price": "12.00",
      "priceCurrency": "USD",
      "billingDuration": 1,
      "billingIncrement": 1,
      "unitCode": "MON"
    },
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/pricing"
  }
}
</script>

That's a number-plus-unit-code form of billingDuration: 1 unit, where the unit is MON (UN/CEFACT code for month). Schema.org also accepts an ISO 8601 duration string for the same property, and it's worth knowing both forms exist because real sites use each. Squarespace's own pricing page, re-verified live on 22 September 2026 at squarespace.com/pricing, ships an OfferCatalog JSON-LD node where every plan carries monthly and annual Offer objects using priceSpecification.billingDuration written as "P1M" and "P1Y", the ISO form, alongside an eligibleRegion field the AIScan example doesn't include. Both forms validate. Pick one and stay consistent across every Offer block on your own site, because a parser that assumes one form for a whole page will misread the other.

One rule matters more than either format choice: the structured price has to match the price a human sees on the same page. AIScan's own guidance is explicit about this, and it's the one line worth keeping in view while you write the block, because an agent quoting a stale or wrong structured price to a shopper is worse than shipping no schema at all.

Path 1: any platform, hand-authored JSON-LD

This works on anything that lets you drop a <script> tag into a page: a WordPress Custom HTML block, a static site's template, a Framer Custom Code panel, a Webflow embed, or a raw HTML file.

1. Decide Offer or AggregateOffer. One fixed price for one thing gets Offer. Several plans or variants get either AggregateOffer with lowPrice/highPrice, or one Offer object per plan nested under an array, whichever reads more naturally for your catalogue.
2. Fill in price and priceCurrency using the exact number and ISO 4217 code shown on the page. Copy them, don't retype them, so a page edit can't quietly leave the schema stale.
3. Add priceSpecification for recurring billing. Nest a UnitPriceSpecification with billingDuration, billingIncrement and unitCode (or the ISO duration string), matching the AIScan example above.
4. Set availability. https://schema.org/InStock for anything currently purchasable, https://schema.org/PreOrder for something not yet on sale, https://schema.org/Discontinued for a retired plan.
5. Wrap it in <script type="application/ld+json"> and paste that whole block into a Custom HTML block, a template partial, or a <head> include, wherever your platform lets you inject raw markup on the pricing page.
6. Validate before you publish. Paste the block into any JSON-LD linter, or run the verification steps below, before the page goes live. A malformed block fails silently: the page still renders, the schema just isn't read.

Path 2: platform-native, no plugin needed

WooCommerce is the clean case, because it does this automatically. WooCommerce core's own structured-data class, class-wc-structured-data.php, confirmed live on raw.githubusercontent.com/woocommerce/woocommerce on 22 September 2026, builds a Product schema block with a nested Offer carrying priceCurrency and availability for every product, with no plugin installed and nothing to configure.

1. Confirm it's already running. View source on any WooCommerce product page and search for application/ld+json. If WooCommerce is active and untouched, the block is there.
2. Check the values match your store settings. priceCurrency follows WooCommerce → Settings → General → Currency, and availability follows the product's stock status field, so a currency change or a restock updates the schema automatically the next time the page renders.
3. Watch for minification stripping the tag. A caching or HTML-minification plugin configured aggressively can strip <script> tags it doesn't recognise as critical. If the schema disappears from a live page but is present with caching disabled, exclude JSON-LD scripts from your minifier's rules.
4. Recurring billing on a WooCommerce Subscriptions product needs the priceSpecification/billingDuration block added by hand, in a Custom HTML block or a small theme filter on the product template, following Path 1's steps 3 to 5. Core WooCommerce covers one-time pricing; the recurring-billing detail is not automatic.

Shopify does the equivalent through its own theme filter rather than a core class, and that mechanism is already documented in full, with the exact file and line number, in The complete AI readiness setup for Shopify. If you're on Shopify, read that post's M4 section rather than re-deriving it here; the short version is that Dawn's {{ product | structured_data }} filter emits the same price/priceCurrency/availability fields for you.

If your WordPress site isn't running WooCommerce, don't assume your SEO plugin covers this. ThinkRank, the plugin we recommend first on WordPress for agent-facing SEO, handles Organization, Person and WebSite schema types out of the box; checked first-party against a live install's get-schema-settings on 22 September 2026, its enabled schema list does not include Product or Offer. A non-WooCommerce WordPress pricing page still needs Path 1's manual JSON-LD block, in a Custom HTML block or the page template, full stop.

Two platforms worth knowing the limits of

Not every builder treats structured data the same way, and two are worth a callout rather than a full path.

Both facts are still-live as recorded in the queue notes for this item; if either becomes the main path for a specific reader rather than background color, re-verify it against the platform's current documentation before publishing.

How to verify it worked

Lead with AIScan, because it checks the same field the schema is meant to satisfy in one pass.

1. Run npx aiscan-cli yoursite.com/pricing, or paste the URL at aiscan.site. No account needed.
2. Read check M4 directly in the result. A pass means an Offer or AggregateOffer block was found with price, priceCurrency and availability all present.
3. If M4 still fails after you've added the block, re-fetch the live page yourself; a script tag that renders in your editor but not in the deployed HTML (a caching layer, a build step that strips inline scripts) is the single most common cause.

If you'd rather check by hand, two methods work without any tool:

• Google's Rich Results Test. Paste your pricing URL in and look for the Offer or Product type in the parsed results. It flags malformed JSON before search engines or agents ever see it.
• curl plus a JSON-LD parse. curl -s https://yoursite.com/pricing | grep -o '<script type="application/ld+json">.*</script>' pulls the raw block out of the page; paste the extracted JSON into any online JSON validator to confirm it parses, then check the price, priceCurrency and availability fields by eye against what the page actually shows.

Where AIScan fits, and where it doesn't

A scan confirms the block exists and carries the required fields. It can't confirm the number inside it is current, because that's a business fact, not a markup fact: a JSON-LD price of 12.00 next to a page that now charges 15.00 still passes M4, because the check reads structure, not truth. Keeping the structured price and the displayed price in sync is on you, on whatever process already updates the visible price.

Fix this, then check the rest

If your pricing page has no Offer or AggregateOffer block at all, Path 1's six steps are a same-day fix on any platform, and Path 2 means you may have nothing to do if you're already on WooCommerce. Run the scan afterward and read check M4 by name rather than trusting the page looks right. The rest of the commerce dimension, and every other check this series has covered, is indexed at /docs/checks/commerce and /guides.