Product schema for SaaS: the fields AI actually reads

Name, description, brand, and offers — a practical Product block for software companies without fake ratings.

SaaS teams often copy ecommerce Product schema — complete with fake aggregateRating and a price of 0 — then wonder why the block feels wrong. Software is a product, but the useful fields for AI and parsers are the boring ones: name, description, brand, and offers stated without theater.

This guide is a practical Product block for SaaS, not a path to star-rich-results glory.

What "Product" means for software

For Northstar Analytics, the "product" might be the application itself or a specific plan. Pick one primary entity per URL. Do not mark the homepage as five products and a blog.

Machines reading Product markup are trying to answer: What is this called? Who offers it? What is the offer? What is it, in one plain description?

That overlaps SEO, but the AEO bar is honesty and consistency with on-page pricing — assistants will invent plan details when you are vague. Clear Product/Offer data reduces the need to guess.

Fields AI (and humans) actually need

Example: honest SaaS Product JSON-LD

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Northstar Analytics",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "description": "Northstar Analytics is B2B product analytics software for funnel and retention reporting.",
  "brand": {
    "@type": "Organization",
    "name": "Northstar Analytics"
  },
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "USD",
    "url": "https://www.northstar.example/pricing",
    "availability": "https://schema.org/InStock",
    "description": "Agency plan billed monthly"
  }
}

SoftwareApplication is often a better @type than generic Product for apps. If you use Product, still include brand and offers. Align the company entity with your Organization schema so brand and org do not disagree.

Pricing pages without lying

Ambiguous pricing ("starts at", "custom", three unnamed tiers) is catnip for hallucinations. You do not need to dump every enterprise exception into JSON-LD. You do need:

1. Plan names that match the page.
2. At least one concrete offer machine-readable if you publish a number.
3. A url on the Offer pointing at the canonical pricing page.
4. No aggregateRating scraped from a spreadsheet someone invented.

BrandKnown's Agency plan is $49/mo — when we discuss product pricing in this blog, we state it the same way on-page and in examples. Your schema should show the same discipline.

If price is truly sales-led only, prefer a clear HTML statement ("Contact for pricing") and a soft Offer without a fake price of 0, or omit Offer details you cannot defend. A wrong zero is worse than omission.

Decision table: Product vs Organization vs both

How to implement

1. Choose the canonical product URL (often / or /product).
2. Write a one-sentence description a stranger could reuse.
3. Add JSON-LD with name, description, brand, offers (as applicable).
4. Match strings to visible copy and to Organization name.
5. Validate; deploy; fetch without JS.
6. Re-check after pricing changes the same day — stale Offer prices are a trust cut.

Mistakes that void the block

• Fake stars and review counts
• Marking every blog URL as the product
• name that is a campaign slogan ("The Future of Insights™") while the app is called Northstar Analytics
• Currency mismatches ($ in HTML, EUR in schema)
• Blocking AI crawlers while obsessing over Product JSON-LD (ChatGPT-User vs GPTBot)

Pew Research (March 2025) observed AI Overviews on about 18% of Google searches in their study window, with lower click-through to traditional results when a summary was present. That does not make Product schema mandatory — it makes accurate on-page product facts more valuable when a summary or assistant answer is assembled from multiple sources (88% of summaries cited three or more sources in that study).

How to verify

1. Schema validator: type, required fields, no errors.
2. Diff offers.price against the pricing page.
3. Confirm brand/org naming matches Across title, H1, and Organization markup.
4. Include Product/SoftwareApplication checks in your AEO audit.

Honest ceiling

Product schema will not make ChatGPT prefer your SaaS over a competitor with stronger third-party reviews. It will reduce stupid mismatches — wrong price, wrong name, missing brand — that make you easy to skip or misstate.

State the product plainly. Offer what you actually sell. Leave the fake ratings in 2014.

Multi-plan SaaS without schema soup

If you sell Free, Pro, and Agency, you have two honest options:

1. One SoftwareApplication on the main product URL, with a single representative Offer (or an AggregateOffer with lowPrice/highPrice that matches the public page).
2. Separate Offer objects only where each plan has its own stable URL and on-page copy.

What fails is marking three conflicting prices on the homepage while the pricing page shows a fourth "from" number. Pick the canonical story and make JSON-LD agree.

For BrandKnown-style packaging, stating Agency at $49/mo with 10 saved brands and 100 scans/month is the kind of concrete offer detail that should match marketing pages exactly — including limits — so an assistant summarizing plans does not invent "unlimited scans."

Relating Product markup to crawler access

None of this matters if answer crawlers receive a blank app shell or a 403. Before you debate applicationCategory enums, confirm AI crawler access and that pricing HTML is present without client-only rendering. Schema is structured commentary on content the fetcher already retrieved.