Structured Data for LLMs: Schema.org in the Age of AI Search

Schema.org markup spent a decade earning rich results on Google. Now it does double duty: the same structured data that produces a star-rating snippet also helps a large language model understand — and correctly represent — what your page is about when it answers a question.

Why structured data matters for AI

An LLM reading your page has to infer meaning from prose. Structured data hands it the facts directly: this is a SoftwareApplication, it costs this, it is published by this organization. That reduces the chance the model misdescribes you, and increases the chance it cites you accurately.

Which types to prioritize

• Organization and WebSite — establish who you are across the whole site.
• SoftwareApplication or Product — describe what you sell and what it costs.
• FAQPage — pairs questions with answers in a format both search and LLMs lift directly.
• Article and BreadcrumbList — give content pages provenance and place them in your hierarchy.

Use one graph, not four islands

The mistake that costs the most is not a missing type — it is emitting several unconnected blocks. A page with an Organization here, a Product there and an Article somewhere else describes three unrelated objects, and a machine has no reason to conclude they are facets of one thing.

The fix is @id. Give your Organization and WebSite stable identifiers once, site-wide, and have every other node reference them rather than restating them. An article then says "published by the thing over there", and the graph resolves into a single entity.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/post#article",
      "headline": "...",
      "author":    { "@id": "https://example.com/#organization" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

The fragment convention (#organization) matters more than it looks: it is a durable identifier that survives a URL changing path. Use absolute URLs throughout, and if you cannot construct one — because the canonical origin is not configured at build time — emit no identifier rather than a relative or guessed one. A wrong @id merges your entity into someone else's.

Keep it honest

Only mark up what is actually on the page. Structured data that asserts a rating, price or offer the page does not show is the kind of dishonesty search engines penalize and LLMs propagate. Say what is true, and nothing extra.

The rule of thumb: structured data may only describe what the page actually shows. A FAQPage whose questions appear nowhere in the rendered HTML, a rating on a page with no reviews, an offer with a price the page does not display — all of these are the kind of mismatch that gets manual actions in search and gets propagated as fact by a language model that trusted you.

Two dates worth getting right

datePublished and dateModified are the fields most often faked, usually accidentally: a build pipeline stamps dateModified with the deploy time, so every page claims it changed today. That is worse than omitting it. A consumer that learns your modification dates are always "now" discounts the signal entirely — and it is a claim about the content, not the deployment. Emit a real revision date or none.

Structured data is necessary, not sufficient

Perfect markup does nothing if the crawler never arrives, or if the content only exists after hydration. Check the boring things first: that AI crawlers are not disallowed, that nothing is blocking them at the CDN, and that your pages are not shipping a `noindex`. AEO vs SEO covers the rest of that ground.

ShipReady reports pages that carry no structured data at all and articles that publish no author or date attribution. It does not validate your JSON-LD against the schema.org vocabulary — Google's Rich Results Test and the Schema Markup Validator both do that well, and there is no reason to duplicate them badly.