JSON-LD for AI agents: practical schema examples

JSON-LD gives software an explicit description of the facts on your page. Use these examples to mark up your business, services and products, then validate the result against the information customers actually see.

Reviewed October 1, 2026 · 6 min read

JSON-LD is a structured data format, commonly placed in an application/ld+json script on a web page. With the Schema.org vocabulary, it can describe a business, an offer, a product or a set of questions and answers. The script does not normally appear in the visible page.

Its value is precision: a price can be identified as a price, with a currency and an associated offer. That makes the information easier for supporting systems to interpret. Valid markup does not prove that a fact is true or guarantee that an assistant will cite it.

Google documents structured data as one way it understands page content. Its structured data guidance also stresses accurate, complete information. Treat markup as a clear description of your page, not a substitute for useful content or a working purchase flow.

Below are examples for business identity, services, products and FAQs, followed by validation checks. For the wider context, see generative engine optimization and agentic commerce.

Why use JSON-LD?#

Google supports JSON-LD, Microdata and RDFa. JSON-LD is often the easiest to maintain because the data sits in a separate block rather than being spread through HTML attributes. Use the format your publishing system can keep accurate, and revalidate after template changes.

Choose types that match your content#

These four patterns cover common business pages. You do not need every type on every site. A valid Schema.org type also does not necessarily qualify for a Google rich result.

1. LocalBusiness: your identity block#

Use a valid type that fits the business, such as Restaurant, Plumber or MedicalClinic. Be careful with similar names: Physiotherapy is an enumeration value, not a business type. This fictional practice uses MedicalClinic:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "name": "Riverside Physio",
  "url": "https://physio.example",
  "telephone": "+1-512-555-0142",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "412 Riverside Dr",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78704",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "08:00",
    "closes": "18:00"
  }],
  "areaServed": "Austin, TX",
  "priceRange": "$$"
}
</script>

2. Service with an Offer: what you do and what it costs#

A Service describes the work you offer; an Offer describes its price and terms. Put the markup on the matching service page and explain what the quoted price includes. This example uses a fixed assessment fee:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Initial Physiotherapy Assessment",
  "serviceType": "Sports physiotherapy",
  "provider": { "@type": "MedicalClinic", "name": "Riverside Physio" },
  "areaServed": "Austin, TX",
  "offers": {
    "@type": "Offer",
    "price": "140.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}
</script>

3. Product with an Offer: catalog data#

Keep product markup consistent with the visible product page and any merchant feed. The rating below is illustrative: replace it with genuine, visible product review data or remove it. Never copy sample ratings into production as if they were real.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Recovery Foam Roller Pro",
  "description": "High-density foam roller, 45cm, for post-training recovery.",
  "sku": "RFR-PRO-45",
  "image": "https://example.com/img/roller.jpg",
  "brand": { "@type": "Brand", "name": "Riverside" },
  "offers": {
    "@type": "Offer",
    "price": "39.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/foam-roller-pro"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "132"
  }
}
</script>

4. FAQPage: your canonical answers#

FAQPage describes visible question-and-answer pairs. It does not guarantee citation or special search presentation. Google retired its FAQ rich result feature in May 2026. Keep FAQs because they answer useful questions, and use markup only when it accurately describes the page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do you take walk-in appointments?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "No, all visits are by appointment. Same-day slots are often available and can be booked online."
    }
  }]
}
</script>

Keep the markup accurate#

A small, accurate graph is more useful than a large one full of stale or unsupported details. Build these checks into your publishing process:

• Match the visible page. Do not add hidden services, prices or claims that customers cannot find there.
• Generate changing values from maintained data. Recheck prices, availability and currency against checkout, including cached pages.
• Use the expected formats: valid dates and times, supported enumeration values, absolute URLs and a price value with currency in its own field.
• Connect related entities with stable @id values where useful, and use consistent names and canonical URLs.
• Use @graph if it makes related entities easier to maintain. Several valid script blocks can also work; correctness matters more than packaging.

Validate before you trust it#

Test the published URL with Google's Rich Results Test for supported search features, and with the Schema.org validator for vocabulary and syntax. Inspect both the initial HTML and rendered page if scripts add the data. A successful test in one tool does not mean every crawler can access the same response.

Where JSON-LD stops#

Structured data describes an offer; it does not reserve stock or create an appointment. Those actions need a supported transaction flow, whether through a website, API or connected MCP tool. Read what an MCP server does when you are ready to connect live actions.

Adapt the examples to your own pages and remove fields that do not apply. If your platform generates markup, check its output rather than assuming it is complete. Nexez generates supported structured data from listing information, which reduces duplicate editing but still depends on accurate source data.