Schema Markup for AI Search
Which JSON-LD types actually help an AI assistant understand and quote your page, how to add them correctly, and how to catch the ones that silently break.
Schema markup does not make an assistant cite you; it removes the ambiguity that keeps it from trusting what it already read. Organization, Person, Product and FAQPage are the types worth prioritising, added correctly, validated after every change, and never used to describe content that is not actually on the page.
That is the technical half of a wider effort. The strategy behind why structured facts matter for citation at all is in our generative engine optimization playbook; this post is the implementation checklist.
On this page
Does schema markup actually help AI answers cite you?
Indirectly, and the mechanism matters. When an assistant fetches a page live during a conversation, it is generally reading the rendered text, not parsing your JSON-LD block directly. Schema's real audience is the crawlers and indexes that build the data these systems draw from later, plus any tool — including a search engine's own AI features — that explicitly reads structured data to build a rich answer.
The experimental research on what makes a passage get used more often in generated answers names citations, statistics and clear attribution as the properties that help [4]. Schema is how you make those same facts machine-readable rather than only human-readable, which is a real lever even though it is one step removed from the citation itself.
There is a second, less obvious audience for schema: the search engine's own AI features. Google's AI Overviews and AI Mode are built on the same index and the same structured-data pipeline as ordinary search, so a page whose facts are unambiguous to that pipeline is more likely to be pulled cleanly into an AI-generated summary there, even before any third-party assistant enters the picture. Treat schema as feeding two different systems at once — your search engine's own generative features, and, indirectly, everything downstream that learns from what gets indexed.
Which schema types matter most for AI visibility?
Four, in roughly this order of leverage: Organization on your homepage, Person for each named author, then Product or Article depending on the page, and FAQPage on pages that genuinely answer discrete questions. Each one answers a different "who or what is this" question that an assistant would otherwise have to infer from prose alone.
| Type | What it tells a reader | Where to use it |
|---|---|---|
| Organization | Who runs this site, and how to verify it independently | Homepage, once per domain |
| Person | Who wrote this and what they are credentialed to say | Author bio, every byline |
| Product | Exact name, price and availability, not marketing language | Every product or pricing page |
| FAQPage | A clean question paired with a complete, standalone answer | Pages with genuine Q&A content |
| Article | Publish and update dates, and a named author | Blog posts and guides |
How do you add Organization and Person schema correctly?
Start with what must be true, not what looks impressive. Organization schema needs a legal name, a URL, a logo, and sameAs links to profiles that actually name your company — your LinkedIn page, your X account, any directory listing you control. Person schema needs a name, a job title, and a URL to a page that exists and actually describes that person.
The most common mistake is treating this as a copy-paste task. A block lifted from a template with placeholder logo dimensions, a sameAs array pointing at a generic social profile that never mentions your company by name, or a job title that does not match what the person's own bio says elsewhere on the site — all of these validate cleanly and all of them undermine the one thing schema is supposed to provide, which is an unambiguous, checkable claim. A system that can trivially disprove one field on your page by cross-checking it has very little reason to trust the rest.
Write the Organization block once
One JSON-LD block on the homepage, or injected site-wide via your layout. Never duplicate it with conflicting details on other pages.
Give every author a real page
Person schema pointing at a team page with three sentences and a job title is honest. Pointing it at a page that does not exist is worse than no schema at all.
Match sameAs to profiles that actually name you
Only list a profile once it exists and clearly identifies your company or person — an empty or generic profile does nothing but add noise.
Re-check after any redesign
A template change is the single most common way schema silently breaks, because nobody re-tests markup that used to work.
Should every page carry FAQPage schema?
Not every page, but every page that genuinely answers discrete questions should. The value is less about the rich result Google may or may not render and more about the discipline it forces on you: a real FAQPage entry needs a complete question and a complete, standalone answer, which is exactly the shape a passage needs to be quotable on its own [1].
Do not add FAQPage schema to a page that does not visibly contain those questions and answers as readable text. Markup describing content that is not actually there is the clearest version of the rule Google's own guidance warns against, and it is easy to catch and easy to penalise [3].
How do you validate it before publishing?
Two tools, every time you touch a template: Google's Rich Results Test for how Google parses it, and schema.org's own validator for whether the JSON-LD is even syntactically correct [2]. Run both after any change to a page's layout, not only when markup is first added — a redesign is the most common way schema breaks without anyone noticing.
What breaks schema without anyone noticing?
Three things, in order of how often we see them: a CMS update that strips a custom field the schema block depended on, a redesign that moves content the markup described without updating the markup to match, and a copy-paste of one page's schema onto another page without changing the entity it describes. All three produce a page that looks fine and describes itself incorrectly, which is arguably worse than describing itself not at all.
The copy-paste failure deserves its own warning because it is the easiest to introduce and the hardest to notice. A team builds one working Product schema template, applies it across the catalog, and six months later a price change on one item never makes it into the corresponding schema block because the two update through different systems. The page shows the correct new price to a visitor; the schema still claims the old one. Nothing about that mismatch is visible without deliberately checking, which is exactly why it needs to be a scheduled check rather than a one-time launch task — add a monthly spot-check of five random product pages against their own markup to a recurring calendar reminder, and the drift gets caught in weeks instead of quarters.
Does markup language or vocabulary choice matter?
Less than the fields themselves, but it is not nothing. Use the schema.org vocabulary directly rather than a proprietary variant a plugin invented, and prefer JSON-LD over Microdata or RDFa when you have a choice — it is the format schema.org's own getting-started guidance leads with, and it is far easier to keep correct because it lives in one script block instead of being woven through your visible HTML [2]. A JSON-LD block can be generated, tested and swapped without touching the page's actual markup at all, which is exactly the separation you want when the person maintaining your CMS template is not the person who understands schema.
Where does digital PR fit alongside markup?
Schema makes your own pages legible. It does nothing for the third-party pages an assistant reads to decide whether to trust you in the first place — that is a separate, earned-media problem, covered in digital PR for AI visibility. The two are complementary: clean markup makes your page a better source once someone points an assistant at it, and PR is what gets someone pointed at it.
Pair the two with a habit of checking whether either is working. Comparing AI visibility tools is where you find out if the citation rate actually moved, and listicles in AI answers explains one of the formats your PR effort should be aiming at.
Which schema types carry the most weight also depends on what you sell — GEO for ecommerce and GEO for B2B each cover the markup that matters most for their category specifically.
Questions people also ask
Does schema markup directly cause ChatGPT or Perplexity to cite a page?
Not directly — most assistants read rendered text, not your JSON-LD, when they answer a live query. Schema's job is making the facts on the page unambiguous to any system parsing it, search engine or assistant, which is a real but indirect effect.
Which schema type should I add first?
Organization, on your homepage, and Person for whoever is named as the author of your content. Those two establish who is talking before anything else on the page can be trusted or reused.
Is FAQPage schema still worth adding?
For the page itself, yes, because it forces you to write a clean question-and-answer pair, which is the exact shape an assistant lifts. Whether Google still renders the visual rich result for it is a separate, smaller question.
How do I know my schema isn't broken?
Run the page through Google's Rich Results Test and Schema.org's validator after every template change, not just once at launch. A single missing comma silently drops the whole block, and nothing in the rendered page will tell you it happened.
Can a page have too much schema?
Yes. Marking up content that is not actually visible on the page, or repeating the same entity with conflicting details across pages, reads as an attempt to game the system rather than describe one honestly, and can do more harm than adding nothing.
Sources
- Intro to how structured data markup works — Google Search Central (checked 22 September 2026)
- Getting started with schema.org using Microdata — schema.org (checked 22 September 2026)
- FAQPage structured data — Google Search Central (checked 22 September 2026)
- GEO: generative engine optimization — Aggarwal et al., KDD (checked 22 September 2026)
Want your schema audited against what actually renders?
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- Generative engine optimization: the playbookHow answer engines pick what to cite, what a quotable page looks like, which crawlers to allow, how to measure it, and a 90-day plan built on evidence.
- AI Visibility Tools ComparedProfound, Peec AI, Otterly.AI, Ahrefs Brand Radar and Semrush's AI toolkit compared: what each one tracks, what it costs to run, and which to start with.
- Listicles and Reddit in AI AnswersAI assistants lean on listicles and forum threads more than official pages when they answer buying questions. What that means for where you spend effort.
- Digital PR for AI VisibilityWhich digital PR tactics actually feed AI citations, why a generic press release rarely helps, and how to pitch journalists and list authors who do.