DEV Community: IP

Make Your SaaS Product Page Quotable by an LLM: schema.org, llms.txt, and Stable URLs

IP — Tue, 09 Jun 2026 12:54:00 +0000

Here is a JSON-LD block that looks fine to a human and is useless to an LLM extractor:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme Analytics",
  "offers": {
    "@type": "Offer",
    "priceRange": "$"
  }
}

If you build product pages and you care whether an AI assistant ever names your product in a discovery answer ("what's the best tool for X?"), this matters more than another homepage redesign. The block above fails for two concrete reasons: priceRange is not a valid field on Offer (it belongs on LocalBusiness), and there is no price or priceCurrency. So an extractor asked "what does Acme cost?" has nothing to return, and the page gets dropped from the retrieval set for any pricing-shaped prompt.

Here is the same block, fixed:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme Analytics",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "description": "Acme Analytics is a web analytics tool for indie SaaS teams. It tracks product events and reports retention. Plans start at $19/month.",
  "offers": {
    "@type": "Offer",
    "price": "19.00",
    "priceCurrency": "USD"
  }
}

Four fields carry the weight: name, description, and an offers object with price and priceCurrency. That is the minimum machine-readable contract for a SaaS page that wants to be in an AI answer.

Why this decides whether you get recommended

An assistant answering "what is the best X for Y" runs three stages: retrieve pages, extract facts, synthesize a shortlist. Structured data is what makes the extract stage succeed. A page with no schema, or broken schema, can survive retrieval and still get dropped before synthesis, because the model could not pull clean facts from it. The products that show up in the shortlist are the ones whose facts were extractable, not necessarily the ones with the best marketing. (This is a pattern worth internalizing if you've ever wondered why a worse-funded competitor keeps showing up in AI answers and you don't.)

The three breaks worth auditing

These pass loose validators and fail in practice:

priceRange on Offer. Only valid on LocalBusiness. Use price + priceCurrency on Offer.
Missing offers entirely. A SoftwareApplication with no offer cannot answer cost questions. Add it even for free products ("price": "0").
Raw URL strings where an object is required. ListItem.item and InteractionCounter.interactionType should be a full Thing / IdReference, not a bare URL string. Google tolerates the loose form; strict parsers reject it. Also: ImageObject.width/height must be strings or QuantitativeValue, never raw numbers.

Validate with a strict, typed builder instead of eyeballing. In TypeScript, schema-dts makes the compiler reject hallucinated fields:

import type { WithContext, SoftwareApplication } from 'schema-dts';

const ld: WithContext<SoftwareApplication> = {
  '@context': 'https://schema.org',
  '@type': 'SoftwareApplication',
  name: 'Acme Analytics',
  applicationCategory: 'BusinessApplication',
  offers: { '@type': 'Offer', price: '19.00', priceCurrency: 'USD' },
};

If you put a field that does not belong on SoftwareApplication, this fails to compile. That is the point: it catches the made-up fields that loose JSON validators wave through. (This is the exact approach we landed on building product listings at PeerPush, after enough hand-written JSON-LD drifted out of spec.)

Test what actually ships, not what you think ships

Client-rendered JSON-LD can vanish from the served HTML, and CSS-driven spacing can mangle text nodes that an extractor reads. Check the raw response, not the browser:

curl -s https://yoursite.com/product/acme | grep -c 'application/ld+json'
curl -s https://yoursite.com/product/acme \
  | python3 -c "import sys,re,json; [json.loads(m) for m in re.findall(r'<script type=\"application/ld\+json\">(.*?)</script>', sys.stdin.read(), re.S)]; print('all JSON-LD blocks parse')"

If a block does not parse, it is invisible to extractors, which is worse than having none.

Ship llms.txt

llms.txt is an emerging convention: a plain-text file at your site root that describes your site and lists key pages for AI retrieval. It is not yet required by any assistant, but it is cheap to ship and a reasonable hedge:

# Acme Analytics
> Web analytics for indie SaaS teams. Plans from $19/mo.

## Key pages
- /product: what Acme does
- /pricing: plans and prices
- /alternatives: how Acme compares

Stable URLs are part of the contract

A slug that changes on a rebrand drops you out of the retrieval set until the new URL re-indexes. Assign slugs once, hold them forever, and 301 anything you must move, keeping the redirect alive indefinitely. Protect three URLs above all: your product page, /pricing, and any /alternatives or /vs page. Treat changes to those as migrations, not casual edits.

A first paragraph that extracts

Extractors weight the opening of a page heavily. Open each page with a complete factual claim: what the product is, who it's for, what it costs, in plain English. Replace "Discover the future of analytics" with "Acme Analytics is a web analytics tool for indie SaaS teams; plans start at $19/month." Concrete sentences get quoted; vague ones get dropped.

The checklist

[ ] SoftwareApplication JSON-LD with name, description, and offers (price + priceCurrency).
[ ] No priceRange on Offer; no raw URL strings where objects are required; image dims as strings.
[ ] Validate with schema-dts (or the Schema.org validator) in CI.
[ ] First paragraph of each page is a complete factual claim, not a tease.
[ ] llms.txt at the root.
[ ] Stable slugs; 301s held indefinitely for the product, pricing, and alternatives pages.
[ ] curl | grep the served HTML to confirm the JSON-LD actually ships.

None of this is a product change. It is the difference between a page an assistant can quote and one it silently skips, and it's almost entirely under your control as the person who owns the markup.

How to Structure a SaaS Product Page So AI Assistants Can Recommend It

IP — Thu, 21 May 2026 07:42:32 +0000

Most SaaS product pages in 2026 are structured for human eyes and Google's old keyword crawler. They render fine in a browser, they score well on Lighthouse, they have a /blog and a /pricing and a /about. And they are nearly invisible to ChatGPT, Claude, Perplexity, and Gemini when a user asks "what is the best tool for X." This post is the technical playbook for closing that gap.

PeerPush, the indie SaaS directory at https://peerpush.net, builds every product listing around the same primitives covered below. The advice applies whether a product gets listed on PeerPush or not. The structure is what matters.

The TL;DR: AI assistants synthesizing a "best X for Y" answer fetch pages, parse facts off them, and rank candidates by the volume and quality of extractable structured data. Make your facts extractable, on stable URLs, with the right schema.org annotations, and the assistant has what it needs to recommend you.

Why AI engines need structured data

A frontier AI assistant fielding a product recommendation question runs roughly this pipeline:

1. Retrieve:   fetch pages relevant to the user's query
2. Extract:    pull discrete facts (name, price, features, integrations, audience, tradeoffs)
3. Synthesize: build a ranked shortlist and a justification paragraph

The extraction step is where most product pages fail. A page that says "We help your team scale operations with our intuitive platform" is invisible. A page that says "Acme Tasks is a project management tool for engineering teams of 3-30. Free plan with 5 users. Paid plans start at $12/user/month. Integrates with GitHub, Linear, Slack" is the page the assistant cites.

Structured data formats give the model explicit hooks for the extraction step. The most important ones for SaaS are JSON-LD with schema.org's SoftwareApplication, Offer, FAQPage, and BreadcrumbList types.

Schema.org primitives every SaaS product page needs

SoftwareApplication with Offer

The minimum viable JSON-LD for a SaaS product page in 2026:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme Tasks",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web, iOS, Android",
  "description": "Project management for engineering teams of 3-30. Async-first, GitHub-integrated, opinionated about cycle time.",
  "url": "https://acmetasks.example/",
  "offers": [
    {
      "@type": "Offer",
      "name": "Free",
      "price": "0",
      "priceCurrency": "USD",
      "description": "Up to 5 users, unlimited tasks, no SSO"
    },
    {
      "@type": "Offer",
      "name": "Pro",
      "price": "12",
      "priceCurrency": "USD",
      "description": "Per user / month, unlimited users, SSO, audit log"
    }
  ]
}

Two things matter here that most product pages get wrong:

offers must contain price and priceCurrency as primitive values, not as priceRange: "$12-$48". AI extractors and Google's rich result parsers both reject priceRange on Offer (it's only valid on LocalBusiness). Multiple price points = multiple Offer entries in an array.
description does double duty. It is what the assistant pulls when summarizing your product. Write it as a single noun-phrase sentence that names who the product is for, not as marketing copy.

A common mistake: putting the @type as Product instead of SoftwareApplication. Product is for physical goods. SaaS is software. Google and the major AI extractors weight SoftwareApplication correctly; Product confuses the classification.

BreadcrumbList for category context

If your product page lives at /products/acme-tasks under a category tree like /categories/project-management, give the assistant the path:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@id": "https://acmetasks.example/categories/project-management",
        "name": "Project Management"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@id": "https://acmetasks.example/products/acme-tasks",
        "name": "Acme Tasks"
      }
    }
  ]
}

Note: item must be a full Thing object with @id and name, not a raw URL string. Google's documentation shows both shapes; some AI extractors only accept the strong-typed form. Use the strong-typed form.

FAQPage for "common questions" extraction

When a user asks "does Acme Tasks support SSO," the assistant wants a Q&A pair it can pull verbatim. The FAQPage schema gives it one:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does Acme Tasks support SSO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. SAML SSO and SCIM provisioning are available on the Pro plan and above. Free plan users authenticate with email + password or Google OAuth."
      }
    },
    {
      "@type": "Question",
      "name": "What is Acme Tasks priced at?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Free for up to 5 users. Pro is $12 per user per month, billed annually. Enterprise is custom."
      }
    }
  ]
}

Five to ten Q&A pairs per product page is the sweet spot. Cover pricing, integrations, the most common "does it support X" questions, and at least one objection ("how does this compare to [competitor]").

The llms.txt file pattern

llms.txt is the AI-era equivalent of robots.txt. It is a plain Markdown file at the root of your domain (https://yourdomain.example/llms.txt) that gives AI crawlers and assistants a curated index of your most important public URLs.

A minimum useful llms.txt for a SaaS product:

# Acme Tasks

> Project management for engineering teams of 3-30. Async-first, GitHub-integrated, opinionated about cycle time.

## Core pages

- [Pricing](https://acmetasks.example/pricing): full plan breakdown with real prices
- [Integrations](https://acmetasks.example/integrations): supported and not-supported integrations
- [Documentation](https://acmetasks.example/docs): how the product works
- [Changelog](https://acmetasks.example/changelog): what's shipped recently

## Comparisons

- [Acme Tasks vs Linear](https://acmetasks.example/alternatives/linear): when each is the better choice
- [Acme Tasks vs Jira](https://acmetasks.example/alternatives/jira): tradeoffs and migration notes

## Posts AI assistants might find useful

- [How we think about cycle time](https://acmetasks.example/blog/cycle-time): opinion piece, 2026-01-15

This file is not a standard yet (the proposal is at llmstxt.org). It works in practice because AI crawlers and grounded retrieval systems are increasingly opportunistic about consuming Markdown indexes when they find them. Cost to ship: 30 minutes once, then keep current. Upside: a small structured nudge that tells AI infrastructure which URLs matter most.

URL stability: redirects, canonicals, sitemap discipline

The compounding effect of being in AI training corpora rests on URL stability. Every URL killed is a citation killed.

Three rules that pay back over months:

Never just delete a page. Use 301 redirects when restructuring. If a feature is sunset, leave the page up with a "this feature is no longer supported, here is the current alternative" notice and link to the replacement. The URL is what AI engines remember; the content can change underneath it.
Canonical tags on every product page, pointing to the version you want indexed. Especially important if you syndicate content to dev.to, Hashnode, or Medium (which is exactly what this post is doing, by the way: the canonical of this article is https://peerpush.net/blog/2026-indie-saas-launch-playbook, declared in the canonical_url frontmatter dev.to reads).
sitemap.xml discipline. Submit it via Google Search Console. Update it on schedule. AI training pipelines often hit sitemap.xml as a seed for discovering a site's structure; an up-to-date sitemap with a <lastmod> per URL signals which pages are current.

How to test if your changes worked

A practical loop for testing whether AI assistants are picking up your changes:

Pick 5-10 questions a real user might ask in your category. Examples for a project management tool: "What is the best project management tool for engineering teams?" "What are alternatives to Linear?" "Does Jira have a free plan?"
Run each question through ChatGPT (paid), Claude (free), Perplexity (free), and Gemini (free). Record whether your product is mentioned, at what position in the answer, and which competitors are mentioned alongside.
Repeat the same prompts weekly. Single-week deltas are noise. The trend over 6-12 weeks tells you whether the structured data work is moving the needle.

PeerPush runs a daily version of this loop internally to measure AI citation rate. The same loop works for any product team that cares about being recommended.

Common mistakes that kill AI extraction

Hiding pricing behind "Contact sales." The pricing page is the first page assistants fetch when asked about cost. No numbers = no recommendation in cost-sensitive answers.
description written as marketing copy. Use noun phrases that name who the product is for and what it does, not adjective phrases that describe how it feels.
Single huge JSON-LD blob that doesn't validate. Google's Rich Results Test (search.google.com/test/rich-results) catches schema errors. If it doesn't pass there, AI extractors built on similar parsers won't pass either.
Generic "alternatives" page with no real tradeoffs. A page that says "we're better than [competitor] in every way" is not the page assistants cite. The page that says "[competitor] is the better choice if you need X, but here is when we are" is.
Robot.txt blocking AI crawlers without thinking it through. Some SaaS sites block GPTBot, ClaudeBot, etc. in robots.txt to "protect content from AI training." That choice trades short-term content protection for long-term invisibility in AI recommendations. Worth thinking about explicitly rather than blocking by default.

What to ship this week

A practical checklist, in priority order:

Audit your product's /pricing page. Are there real numbers, real plan names, real trial terms? If not, fix that first.
Add JSON-LD with SoftwareApplication + Offer to the homepage and the pricing page.
Build one /alternatives-to-<competitor> page with the comparison-table pattern from earlier in this post.
Add a FAQPage JSON-LD block with 5-10 questions on the homepage or a dedicated FAQ page.
Ship llms.txt at the root of your domain with the format shown above.
List the product on three directories that fit your category. PeerPush at https://peerpush.net/submit is one option among several; others include BetaList, AlternativeTo, SaaSHub.
Set up the test loop described above and check it weekly.

Most of this is implementable in a single afternoon. None of it depends on a viral launch day. All of it compounds in AI training corpora over the next 24+ months.

The new shelf is permanent. The structured data is the door key.