Schema.org was not designed with generative AI in mind, but today answer engines read it. We show you how to implement Organization, FAQPage, and BreadcrumbList — the three schemas that weigh most when a model decides who to cite.
Why JSON-LD Matters More to AI than to Classic SEO in 2026
A change caught the SEO crowd off guard in May 2026 — Google dropped FAQ rich results. According to Search Engine Journal, Google "no longer shows FAQ rich results in search" as a public appearance. The easy reading is that the markup stopped working; the correct reading is that its use shifted.
Google itself was explicit about keeping the parsing. According to Google Search Central, the team "may continue to use FAQ structured data to better understand pages" even though it no longer renders them as a rich result. The signal did not die — it changed channel.
That channel is AI engines. According to Search Engine Land, "ChatGPT, Perplexity, and Google AI Overviews rely on structured data to understand, verify, and cite content accurately." What lost impact in classic SEO is gaining ground in LLM visibility.
The underlying idea is that JSON-LD is a machine-readable contract about what each thing on your page actually is. When a model assembles an answer, schema gives it named entities, relationships, and attribution — exactly what prevents it from confusing you with another brand or citing an inaccurate version of your position.
Schema.org itself framed it this way from the start. Its vocabulary "helps search engines and other applications understand the content" — and LLMs are exactly those "other applications" the spec left the door open for over a decade ago. This pairs with the authority signals an LLM can read and forms the technical foundation of AI visibility.
Organization: The Identity That Disambiguates Your Brand for Models
Organization is the most important site-level schema. It defines who you are: canonical name, URL, logo, official profiles. When an answer engine tries to attribute a mention of "Madbotz" to a concrete entity, this is the block it reads first.
The official spec is explicit about what you can declare. According to schema.org, Organization supports properties like name, url, logo, sameAs, and address — among many others — to represent "an entity with which an individual may have a relationship."
Google formalized the search-relevant subset in 2023. According to Google Search Central, the organization panel now accepts "name, address, contact information, and various business identifiers" in addition to the logo, turning Organization into the canonical identity source the knowledge graph consumes. The block now carries weight on both sides — search and AI answers.
Its usefulness for LLMs is not theoretical. If your site appears without Organization and a competitor with the same name has it, the model will pick the one with the explicit contract. Disambiguation is not vanity — it is the difference between getting cited yourself or losing the citation to a namesake.
This is what a minimal valid Organization block looks like:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Madbotz",
"url": "https://www.madbotz.com",
"logo": "https://blog.madbotz.com/content/images/size/w400/2026/05/Logotipo---Madbotz---No-back.png",
"sameAs": [
"https://www.madbotz.com"
]
}
That structure is what Madbotz injects on this post, its homepage, and every brand page. Concrete data point: among the 131 check items in the Visibility analyzer, several verify this exact block and flag when the logo is missing, when sameAs points to dead profiles, or when the name varies between pages.
FAQPage: The Rich Result Died, the Signal Lives On
The ugly part first. As mentioned, Google dropped FAQ rich results in May 2026. If you published FAQPage expecting that expandable box in SERPs, that box no longer appears — and is not coming back.
The useful part is still there. According to schema.org, FAQPage is "a WebPage presenting one or more frequently asked questions with their answers" — a semantic contract any parser can read, not only Google. ChatGPT, Perplexity, and Bing Copilot keep using it as a direct source for Q&A.
The reason is operational. Q&A answers are one of the easiest formats for an LLM to extract and cite: clear question, brief answer, declared entity. According to Joost de Valk, "FAQ structured data is still valid and useful — only who consumes it changed," and he proposes recycling the section inside a new FAQSection type embedded in the Article.
The implementation rule did not change either. According to Google Search Central, you should use FAQPage only when you provide "a single, official answer" — not user-generated content — and the question and answer must be visible on the page, not only in the markup. Any cautious LLM applies the same test: if it does not find the text in the HTML, it distrusts the schema.
This is what a FAQPage with two questions looks like:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"inLanguage": "en",
"mainEntity": [
{
"@type": "Question",
"name": "Do LLMs read JSON-LD the same way Google does?",
"acceptedAnswer": {
"@type": "Answer",
"text": "They read it, but they use it differently..."
}
},
{
"@type": "Question",
"name": "Is FAQPage still useful now that Google dropped the rich result?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Google removed the expandable SERP box..."
}
}
]
}
This post implements FAQPage in its own code injection — the four questions below also travel as JSON-LD in the header. We practice what we preach.
BreadcrumbList: Hierarchy as Narrative Context for the LLM
BreadcrumbList is the most undervalued schema of the three. It does not change your SERP appearance dramatically, but it gives the model something no other block does: where the page sits within the site.
The spec describes it as a linked chain of web pages. According to schema.org, each item must declare position, name, and item — the canonical URL for that level — and the convention is ascending order from the homepage to the current page.
Google is strict on the rules. According to Google Search Central, "Google recommends providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure" — and a BreadcrumbList must contain at least two ListItems to be eligible.
For an LLM, this translates to narrative context. If a page is "Madbotz → Blog → Schema.org JSON-LD for AI," the model knows it is a post on a corporate blog, not a commercial landing or a technical doc. The difference matters when it cites or summarizes: the hierarchy tells it the type of content before reading a single word.
This is the BreadcrumbList for this very post:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Madbotz", "item": "https://madbotz.com/"},
{"@type": "ListItem", "position": 2, "name": "Blog", "item": "https://blog.madbotz.com/en/"},
{"@type": "ListItem", "position": 3, "name": "Schema.org JSON-LD for AI", "item": "https://blog.madbotz.com/en/schema-jsonld-ai/"}
]
}
Three levels, all with absolute URLs, human-readable names, and ascending position. The same goes on every blog post, changing only the last ListItem.
How to Combine the Three Schemas in a Single Header
The practical question: do they go in separate blocks or in one? Both options are valid and depend on how you prefer to debug.
The simple option is one JSON-LD script per schema. It is the most readable and the easiest to validate piece by piece in the Rich Results Test. It is a good default when you are learning and want to isolate errors.
The combined option is to use @graph with the three @types inside a single script. Useful if your CMS emits each schema from separate templates and you want to consolidate them without duplicating @context. The spec explicitly allows it — and it is what this post uses in its code injection.
This aligns with the first principle of the Searchability framework — being findable and readable for the bot — applied at the most technical level. Without valid schema, the other levers lose part of their effect.
| Schema | What it describes | Where it goes | What signal it sends the LLM |
|---|---|---|---|
| Organization | Business identity (brand, site, corporate author) | Global header of the site or each page | Who you are and your exact name |
| FAQPage | Official questions and answers for a page | Header of the page with visible FAQ | Q&A blocks ready to cite as direct answers |
| BreadcrumbList | Page hierarchy within the site | Header of every content page | Where the page fits and what type of content it is |
Whichever format you pick, all three must validate cleanly in the Rich Results Test and in validator.schema.org. Do not publish a schema that throws warnings — a cautious LLM will ignore it rather than risk citing it wrong.
Anti-Patterns That Break the Contract
Four patterns we see operating in the wild that break the contract between your site and the model:
- Hidden markup that does not match the visible content — the classic "FAQ schema without an FAQ section on the page."
- A logo that points to an inaccessible SVG, a CDN with blocked CORS, or a low-resolution PNG.
- A BreadcrumbList that inverts the order or duplicates the homepage as the first and last ListItem.
- Organization with different data across pages — name here, legal name there, another logo on the homepage.
The first one is the most dangerous. If the LLM cross-references the JSON-LD with the rendered HTML and does not find the declared question, it distrusts the whole site. A declared contradiction is worse than having no schema at all. It is the same pattern we saw in the llms.txt cargo cult — implementing signals without verifying they match the actual page.
The operational rule is simple: if it does not appear literally on screen, it does not belong in the markup. This applies from FAQs to organization names — the contract is only valid if you hold up your end on the public side. And if your CMS regenerates the schema from templates, it is worth manually reviewing at least the first few posts.
Frequently Asked Questions
Do LLMs read JSON-LD the same way Google does?
They read it, but they use it differently. Google cross-references it with its index to decide rich results and knowledge graph entities. LLMs extract it as additional context about entities and as Q&A blocks they can cite. JSON-LD is the format both parse most reliably.
Is FAQPage still useful now that Google dropped the rich result?
Yes. Google removed the expandable SERP box in May 2026 but confirmed it still uses the markup to understand the page. ChatGPT, Perplexity, and Bing Copilot keep extracting FAQPage as a source of direct answers, so the value shifted to the AI channel.
Can I put all three schemas on the same page?
Yes, and that is the recommended approach. You can inject one script per schema or group the three inside a single @graph sharing one @context. Both options validate cleanly. This post combines the three into a single @graph in the header code injection.
Does Organization go on every page or only on the homepage?
It goes on every page, with the exact same block. Consistency is what helps the model unify entities. Changing the name, logo, or sameAs between pages makes the LLM doubt which version of your brand is canonical.
Conclusion
Three ideas to take with you:
- Schema.org is still the contract AI engines read — even when Google removes the public rich result for one of them.
- Organization, FAQPage, and BreadcrumbList cover the three levels an LLM needs: identity, direct answer, and site context.
- Implement all three in JSON-LD, place them in the header code injection, validate with the Rich Results Test, and check that the HTML matches.
If you want to know what your site is missing on these three fronts — and on the other 128 check items of the Searchability framework — the Visibility analyzer tells you in under 60 seconds.
Analyze your site for free — enter a URL and get your AI Visibility Score in under 60 seconds.