Structured data for AI search

Structured data is a machine-readable description of what a page is about, usually written as JSON-LD with the schema.org vocabulary. For AI search, the documented facts are short. Google says it isn't required and that no special markup gets you into its AI features. It does help ordinary search features, it has to match what the page shows, and it only reaches the AI crawlers that run no JavaScript if your server sends it in the HTML. This guide covers what is documented, the placement rule, which types to use, and two templates that pass the validator. It is one part of an AI-ready website.

What is documented, and what isn't

Google's AI optimization guide, updated on 10 July 2026, is direct: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add." Its page on AI features says the same: there are "no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary."

That doesn't make structured data useless. Google's May 2025 post on AI search, by John Mueller, describes it as "useful for sharing information about your content in a machine-readable way that our systems consider", and makes pages eligible for rich results. The same post sets the rule that matters most: make sure "all the content in your markup is also visible on your web page" and validate the markup.

Three more facts to plan around:

• FAQ rich results are gone from Google. Google stopped showing them on 7 May 2026 and removed the documentation in June 2026. Adding FAQPage for that reason no longer works.
• Other AI vendors haven't documented anything. OpenAI's and Anthropic's crawler pages describe their bots and robots.txt without mentioning schema.org.
• The popular figures have no source. Claims such as "2.5 times more likely to appear in AI answers" or "up to 40% more AI Overview appearances" circulate without a primary source, and Google's own guide contradicts them.

So add structured data because it states the facts of your page precisely and helps ordinary search, not because it promises AI citations.

The placement rule

Where the JSON-LD lives decides who can read it.

Google renders JavaScript, so it can read JSON-LD that a script adds: "Google Search can understand and process structured data that's available in the DOM when it renders the page." It adds a warning for shops: "dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price."

Most AI crawlers don't render at all. Vercel and MERJ's December 2024 measurement found that none of the major AI crawlers run JavaScript, apart from Gemini and Applebot. How AI agents read websites covers what that means for the rest of the page. For structured data it means one thing: markup added by a script, a tag manager or a client-side component never reaches those crawlers.

We tested it on 6 October 2026 with two copies of the same product page, served locally. One had the JSON-LD in the HTML. The other added the same JSON-LD from a deferred script, the way a client-side app or a tag manager would:

Both look identical in the DevTools Elements panel, because it shows the page after scripts have run. Only the HTML the server sent shows the difference. That is the version a crawler without JavaScript gets.

Which types to use

Describe what the page really is, with the types that fit it. Here is a short map:

Google's policies list what not to do: "Don't mark up content that is not visible to readers of the page," and don't mark up "irrelevant or misleading content, such as fake reviews." Leave AggregateRating out until you have real reviews shown on the page.

Two templates that validate

Both templates passed the Schema Markup Validator with 0 errors and 0 warnings on 6 October 2026. To check that the validator catches mistakes, we changed price to prise in the product template, and it reported 1 error. Replace every value with your own before you publish.

A service business. One @graph holds the organization and the service, and the service's provider refers to the organization by its @id, so the facts are written once:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Northlight Studio",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "email": "[email protected]",
      "sameAs": ["https://www.linkedin.com/company/northlight-studio"]
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/brand-identity#service",
      "name": "Brand identity design",
      "serviceType": "Brand identity design",
      "description": "Logo, typefaces, palette and guidelines for food and hospitality businesses, in six weeks.",
      "url": "https://example.com/services/brand-identity",
      "provider": { "@id": "https://example.com/#org" },
      "areaServed": "Europe",
      "offers": {
        "@type": "Offer",
        "price": "4800",
        "priceCurrency": "EUR",
        "description": "Starting price, excluding VAT"
      }
    }
  ]
}
</script>

A product in a store:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/shop/stoneware-mug#product",
  "name": "Stoneware mug, ash glaze",
  "description": "A 330 ml wheel-thrown mug in an ash glaze. Dishwasher safe.",
  "image": ["https://example.com/images/mug-ash-1200.jpg"],
  "sku": "MUG-ASH-330",
  "brand": { "@type": "Brand", "name": "Northlight Ceramics" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/shop/stoneware-mug",
    "price": "38.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

The schema.org validator checks the vocabulary. Google's Rich Results Test checks Google's own required properties for each feature, which can be stricter, so run both.

Keep the price in one place

The price in the markup, the price on the page and the price the checkout charges should be one number from one source. When they differ, the markup states something false about your page, and Google's guidelines require the markup to match what visitors see. In practice that means rendering the JSON-LD from the same product record as the visible price, on the server, in the same build. A price edited in the page copy but not in the markup, or set by a script after load, is how they drift apart. Payments on your website covers how checkout fits in.

Mistakes that make markup wrong

• Markup for a page that isn't there. A sitewide template that prints the same Product or FAQPage block on every page describes things most pages don't show.
• Two organizations. A theme and a plugin each print their own Organization with different names or logos. Pick one source and give it a stable @id, such as https://example.com/#org, so other blocks can refer to it.
• Relative or broken URLs. url, image and logo should be absolute URLs that return 200.
• Stale dates. A dateModified that changes on every build, whether or not the content did, says nothing true. Change it when the content changes.
• Copy that differs from the page. A description written for the markup alone, with claims the page never makes, breaks the rule that markup matches what visitors see.

How to check your markup

1. See what the server sends. View the page source, or count the blocks from a terminal:

   curl -s https://example.com/ | grep -c 'application/ld+json'
   

   A count of 0 means a script adds the markup, or nothing does. (grep -c counts lines, so two blocks on one line count once; view-source settles it.)

2. Validate the vocabulary at validator.schema.org, by URL or by pasting the code.

3. Test Google's features with the Rich Results Test. Google recommends the URL input over the code input, because the code input has JavaScript limitations.

4. Compare markup and page. Every name, price, date and answer in the JSON-LD should appear on the page, in the same words or numbers.

On a Laarpi site

Laarpi Surface puts the JSON-LD in the server HTML on every publish and never adds it from the browser: Organization on every site, plus Service for service sites, FAQPage where a page has questions, and Product for stores, with the same price as the page and the checkout. This guide follows the same rule: its Article, FAQPage and BreadcrumbList markup, with the sources below listed as citations, is in the HTML our server sends. The rest of the agent door, including llms.txt and Markdown versions of every page, is listed on what an AI-ready Laarpi site includes.