Schema Markup for AI Discovery: The JSON-LD Types That Matter

When a model reads your homepage it has to infer the basics: company name, category, location, services, price range, who to contact. JSON-LD removes the inference. It is a JSON block embedded with <script type="application/ld/json"> in the page, stating facts in a vocabulary machines already share, schema.org, so the same information is available whether the reader is a search engine, an assistant resolving an entity, or an agent building a vendor list.

The benefit is resolution, not magic. Structured data does not rank you and does not, by itself, get you cited. It reduces ambiguity at the moment a system decides what your business is and which claims belong to you, and ambiguity is exactly what makes an assistant hedge, merge you with a competitor, or leave you out of the answer.

The type list is long, but the ranking for AI discovery is short:

Order of operations matters more than volume. If you implement three things, implement Organization on the homepage, Service on each core offer page, and FAQPage wherever you have a visible FAQ block. That covers identity, offer, and buyer questions, the three facts an assistant needs before it can describe you accurately.

Then expand along the same rule: one type per page, describing only what that page shows. A Service block belongs on the service page, not repeated on every URL. A FAQPage block belongs under questions a visitor can actually read without clicking anything. Sites that spray one WebPage full of everything from the rest of the site are describing a page that does not exist.

Drop this into the <head> of your homepage, then replace every value:

{

"@context": "https://schema.org",

"@type": "Organization",

"name": "Your Company",

"url": "https://example.com",

"logo": "https://example.com/logo.png",

"description": "One sentence on what you do and for whom.",

"contactPoint": { "@type": "ContactPoint", "contactType": "sales", "email": "hello@example.com" },

"sameAs": ["https://www.linkedin.com/company/yourcompany"]

}

Then add a Service block to each service page and a FAQPage block to your FAQ page, reusing the same identifiers. Every value must be byte-identical to what the page shows: if the visible copy says $2,500, the schema says $2,500, not $2500 and not "from $2500".

Structured data is a formal claim about your page, and mismatched claims are treated as spam signals. The failures we see most often:

The operating rule is simple: the page is the source of truth, and the schema describes it. Google's AI optimization guide frames it the same way, structured data helps systems understand your content, but it is one input among many, not a ranking switch.

Honest limit: perfect JSON-LD on an unclear message changes nothing. We have seen flawless schema on sites whose positioning is mush, three service names that mean the same thing, pricing hidden behind a contact form, claims that contradict the homepage. Machines resolve entities; they do not fix your message. Clarity of content is the strategy, and schema is how you make that clarity machine-legible.

Run the audit to see whether your schema exists, matches the visible copy, and covers Organization, Service, and FAQPage, it feeds the Data Quality score, alongside roughly 40 other checks and a prioritized fix list. For the wider picture, AEO vs SEO explains what structured data does and does not move, and this layer ships as part of our services.