Structured data for LLM visibility: schema.org beyond rich snippets

Here's a question that decides whether an AI assistant recommends you correctly: when a model encounters the string "Fathomly" on a pricing page, a G2 review, and a Reddit thread — how does it know these are the same thing? And when it tells a buyer your starting price, where does that number come from?

Prose makes machines infer. Structured data lets them read. That distinction was mildly important when the payoff was a rich snippet; it's centrally important now that the consumer of your page is often a language model assembling an answer, deciding in milliseconds which facts are extractable and which are too ambiguous to repeat.

This post covers what schema.org markup actually does in a generative-engine world, the handful of types worth implementing, a worked JSON-LD example, and the myths worth retiring.

What structured data does for a language model

Schema.org is a shared vocabulary — launched in 2011 by the major search engines, now spanning roughly 800 types and 1,400+ properties — for annotating web content with typed, machine-readable statements.¹ A paragraph saying "our sensor is accurate and reasonably priced" becomes, in markup, Product → offers → price: 449, priceCurrency: "EUR" and a PropertyValue of ±0.1 °C. The vague became checkable.

Three mechanisms make this matter for AI visibility:

1. Extraction confidence. Generative engines synthesize from retrieved pages, and they preferentially repeat facts that are cleanly stated and internally consistent. JSON-LD is the cleanest statement a page can make: no layout parsing, no pronoun resolution, no guessing whether "$49" is the monthly or annual figure.
2. Knowledge-graph ingestion. Search engines have consumed markup into entity graphs for years — Google's documentation is explicit that structured data helps it understand what a page is about and who is behind it.² Those graphs feed both classic results and the retrieval layer behind AI features. Facts that make it into an entity graph persist across queries, not just per-page.
3. Corroboration. The evidence from generative-engine research points the same direction: content with clear, attributable claims — statistics, citations, quotations — earned up to ~40% more visibility in generated answers in the original GEO study.⁴ Markup is the machine-readable version of that same principle: it makes your claims easy to attribute and hard to garble.

The schema types that earn their keep for GEO

Schema.org is huge; your implementation shouldn't be. For a brand that wants to be mentioned, recommended and described accurately, six types cover the ground:

Two of these deserve emphasis because they're chronically underused.

Product with real offers and specs. Most SaaS and manufacturer sites mark up a name and a description and stop. The GEO value is in the boring fields: a machine-readable price ends the "starts at $199 (according to a 2023 blog post)" failure mode, and additionalProperty entries for specs — accuracy, capacity, limits, integrations — give engines a fact table instead of a paragraph to paraphrase badly.

sameAs. The cheapest high-leverage markup on the internet. If your brand name is ambiguous — shared with a common word, a band, or a competitor in another country — sameAs links from your Organization markup to Wikipedia, Wikidata, LinkedIn and Crunchbase are how graphs resolve which entity you are. Ambiguous entities get hedged, blended or skipped in answers; resolved entities get described.

A worked JSON-LD example

JSON-LD in a <script> tag is the format Google recommends and the easiest to maintain — one block, no microdata woven through your templates.² Here's a condensed but realistic block for a B2B SaaS pricing page, combining Organization, Product and FAQ:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://fathomly.com/#org",
      "name": "Fathomly",
      "url": "https://fathomly.com",
      "logo": "https://fathomly.com/logo.png",
      "description": "Customer analytics platform for B2B SaaS teams.",
      "foundingDate": "2021",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q000000",
        "https://www.linkedin.com/company/fathomly",
        "https://www.crunchbase.com/organization/fathomly",
        "https://github.com/fathomly"
      ]
    },
    {
      "@type": "Product",
      "name": "Fathomly Growth Plan",
      "brand": { "@id": "https://fathomly.com/#org" },
      "description": "Account-level analytics with churn prediction,
        for teams up to 25 seats.",
      "offers": {
        "@type": "Offer",
        "price": "199",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "url": "https://fathomly.com/pricing"
      },
      "additionalProperty": [
        { "@type": "PropertyValue",
          "name": "Data sources", "value": "40+ integrations" },
        { "@type": "PropertyValue",
          "name": "Compliance", "value": "SOC 2 Type II, GDPR" }
      ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [{
        "@type": "Question",
        "name": "Does Fathomly offer a free trial?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Yes — 14 days, full-featured, no credit card
            required. Annual plans include a 30-day guarantee."
        }
      }]
    }
  ]
}
</script>

Details that separate working markup from decorative markup:

• Use @id and reference it. Giving your Organization a stable @id and pointing brand at it tells parsers every product belongs to one entity — on every page, forever.
• Markup must mirror visible content. Facts that exist only in JSON-LD are ignored at best and a spam signal at worst; Google's guidelines are explicit that markup should describe on-page content.²
• Keep prices current or omit them. A stale machine-readable price is worse than none — it's wrong with confidence, and it will be repeated with confidence.
• Validate on deploy. Schema Markup Validator or Rich Results Test in CI, not once at launch. Silent template regressions are the most common way markup dies.

Entity consistency: the part markup can't do alone

Knowledge graphs are reconciliation machines. They take statements about an entity from many sources — your site's markup, Wikipedia, Wikidata, LinkedIn, Crunchbase, review platforms, news — and try to merge them into one coherent record. Your markup is one vote among many, and it's the vote with the most obvious self-interest.

That has a practical consequence: what moves engines is agreement. When your site says "customer analytics platform, founded 2021, starts at $199" and G2, Crunchbase and a couple of industry roundups say the same thing, that description hardens into the consensus a model reaches for. When your site says "AI-powered revenue intelligence suite" while every third-party source still calls you "a dashboard tool," you've created exactly the ambiguity that makes models hedge — or default to the third-party framing you were trying to escape.

A minimal entity-consistency audit, in order:

1. Write one canonical description — category, buyer, differentiator, in a sentence — and use it verbatim in your Organization markup, homepage, and social bios.
2. Fix the profiles you control: LinkedIn, Crunchbase, GitHub, app marketplaces. Same name, same category language, same founding facts.
3. Wire up sameAs to every profile from step 2, plus Wikipedia/Wikidata if you legitimately have entries.
4. Then work the sources you don't control — analyst listings, review categories, directory descriptions — toward the same language. Slower, but this is where consensus actually forms.

Myths worth retiring

Three more, quickly:

• "LLMs don't read JSON-LD, so it's pointless." Half-true, wrong conclusion. A model generating text isn't parsing your script tag — but the retrieval and knowledge-graph systems that decide what the model sees have been consuming markup for a decade. You're optimizing the pipeline, not the poet.
• "More types = more visibility." Coverage of six types done accurately beats thirty done vaguely. Wrong or contradictory markup is worse than none, because it's a confident wrong vote in the reconciliation process.
• "We added FAQ markup and rankings didn't move, so it failed." Wrong success metric. The question is whether assistants answer questions about you correctly and cite you when they do — which you can only see by sampling actual AI answers, repeatedly. That measurement loop is the kind of thing a platform like MentionBeat automates, but however you run it, run it: markup changes without answer-level measurement are faith-based.

Frequently asked questions