GuideJul 29, 202610 min read
How Automated Schema Markup Gets Your Brand Cited by AI Answer Engines
Schema markup removes the guesses an AI crawler would otherwise make about who you are, what a page is and whether it's current. What the 5 useful types do on a B2B SaaS site, what 'automated' actually covers, and a 10-minute audit you can run this afternoon.
- 5schema types worth having on a B2B SaaS site
- 10 minto audit what you have with two free tools
- 3different uplift figures the models quoted us for the same question
- 1Schema markup is JSON-LD that labels facts the prose leaves implicit: who published the page, what kind of page it is, what questions it answers, where it sits in the site. It reduces what a crawler has to infer; it does not rank you.
- 2The only first-party statements on schema and AI come from Google (May 2025) and Microsoft Bing (March 2025), and both describe understanding and eligibility, not citation. The 2.5x, 2.8x and 36% uplift figures the models repeat all trace back to vendor blogs.
- 3Organization schema with a consistent @id does most of the entity work, and it needs to be a real block on every page, because LLM crawlers fetch pages one at a time and do not resolve a bare @id reference.
- 4Every fact in your JSON-LD has to appear in the visible page body. That is Google's own published guideline, and it is the rule most implementations break.
- 5Most LLM crawlers do not execute JavaScript, so schema injected after page load is invisible to them. The first version of our own schema had exactly this problem.
Schema markup helps a brand get cited by AI answer engines by removing ambiguity. JSON-LD on each page tells a crawler who published it (Organization), what it is (Article, Service), what questions it answers (FAQPage) and where it sits (BreadcrumbList). Automated generation matters because that only works when every page carries it, consistently, and it stays in sync with the visible content.
Somewhere in the last year, someone has told you the site needs schema markup. An agency, a dashboard, a founder who read about it on a flight. On most of the sites we look at there's already some: a block the CMS theme dropped in with a name and a URL in it and nothing else. The question I get on calls is what that block does for an LLM crawler, and whether a marketing team can get it right without waiting on the dev queue.
The two first-party statements on this are shorter than the industry that's grown up around them. Google's Search Central team wrote in May 2025 that structured data is "useful for sharing information about your content in a machine-readable way that our systems consider", with the condition that you make sure "all the content in your markup is also visible on your web page". Two months earlier, at SMX Munich, Fabrice Canel from Microsoft Bing confirmed that schema markup helps Microsoft's LLMs understand content. Neither of them said it earns you a citation; both said it helps the system understand what it's reading, and that's the frame I'd keep.
When this exact question went through the four engines in our October scan, the uplift figures came back different each time: 2.5x in one run, 2.8x and 36% in another, and every one of them traced back to a vendor blog rather than a study. I'd hold those numbers loosely, since the mechanism underneath them is sound even if the multiplier isn't, at least from what we're seeing.
So what follows is what schema actually does for a crawler, the 5 types worth having on a B2B SaaS site, the one rule most implementations break, what "automated" means in practice, and a 10-minute audit you can run on your own site this afternoon.
What schema actually tells an AI crawler, and what it doesn't
Schema markup is a block of JSON-LD in a page's HTML that labels facts the prose leaves implicit: this page was published by this organisation, it's an article written by this person on this date, it answers these questions, it sits here in the site. An AI crawler fetching the page gets the prose and the labelled facts together, so the extraction step has less to infer.
The way the answer engines work, roughly, is that a retrieval step fetches pages, pulls the text out of them, and hands the model a wall of context to answer from. The model is very confident from very little information. If your homepage never quite says what category you're in, it'll pick one, and if your pricing page implies one audience while your About page implies another, it'll pick one of those too. Schema cuts down the number of places where it has to pick.
What it doesn't do is rank you. Google has said there's no special structured data to add for AI Overviews or AI Mode, and the normal rules apply: the page has to be indexed and eligible for a snippet before anything else matters. If you're reading schema as a lever that moves a visibility score, you'll be disappointed in about six weeks when nothing moves. The payoff I'd actually measure is fewer wrong descriptions of the company, which is slower to shift and less satisfying to put in a board deck, but it's the number schema can move.
The 5 schema types worth having on a B2B SaaS site
Most B2B SaaS sites have one or two of these, thinly filled. Five types do nearly all the work for a software company, and they're listed in the order I'd add them.
| Schema type | What it tells the crawler | Key fields | Priority |
|---|---|---|---|
| Organization | Which entity published everything on the site, what it's called, where it is, what it knows about | @id, name, alternateName, url, description, foundingDate, founders, address, sameAs, areaServed, knowsAbout | First |
| Article / BlogPosting | What was published, by whom, when, and when it last changed | headline, author (Person), datePublished, dateModified, publisher (@id), mainEntityOfPage | Every post and guide |
| FAQPage | Question and answer pairs in the shape a retrieval step lifts most easily | mainEntity (Question, acceptedAnswer with the full answer text) | Pages with a visible FAQ |
| Service | What the platform does, who provides it, who it's for, where it's offered | name, description, serviceType, provider (@id), areaServed, audience, offers | Product and platform pages |
| BreadcrumbList | Where the page sits in the site hierarchy | itemListElement (ListItem with position, name, item) | Last, once the template emits it |
Product and Offer schema matter if you sell something with a SKU and a price on the page. For a SaaS platform with plan tiers, Service with an offers block does the same job without pretending a subscription is a physical product. BreadcrumbList is last because its contribution is small, though it costs nothing once the template emits it, and it does help a crawler tell a pillar page from the posts hanging off it.
Why Organization schema and a consistent @id do most of the work
Organization schema is the block that tells a crawler which entity published everything else on the site, and @id is the stable identifier that lets every other block point back at it. Without a consistent @id, each page's Article, Service and FAQ blocks describe a publisher that might or might not be the same company, and the crawler is back to guessing.
Our own block, which the root layout emits on every page rather than just the homepage, has an @id of https://www.brandviz.ai/#organization and then the fields that do the entity work: an alternateName array with the four spellings people use for us (BrandViz, BrandViz AI, Brand Viz, brandviz.ai), founders as Person nodes with LinkedIn sameAs links, a foundingDate of 2025, a Brisbane postal address, areaServed, and a knowsAbout list of the topics we publish on. Every Article block on this blog names that same @id as its publisher, so a crawler reading a post can tie the author, the publisher and the homepage together without inferring any of it.
The full version doesn't need to be on every page. A compact stub with the name, url, description and the canonical @id is enough on a subpage, as long as it's a real block and not a bare reference. LLM crawlers fetch pages one at a time, and a subpage whose only Organization markup is {"@id": ".../#organization"} is relying on the crawler to go and fetch the homepage to resolve it. None of the labs publish how their crawlers handle JSON-LD references, so that's a hedge rather than a documented fact, but a stub on every page is cheap and finding out you needed one is slow.
A compact Organization stub for subpages
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Example Co",
"alternateName": ["Example", "ExampleCo", "example.com"],
"url": "https://www.example.com",
"description": "One or two sentences that also appear on the homepage.",
"foundingDate": "2025",
"sameAs": ["https://www.linkedin.com/company/example-co"]
}Schema is one input to entity resolution and not the whole of it. The off-site half, the profiles and directories that sameAs points at and the name variants that turn up in other people's content, is covered in the post on entity resolution in AI search, and the schema fields here are what make that off-site work land on the right entity.
The parity rule: if a fact isn't on the page, it isn't really in the schema
Every fact in your JSON-LD should also appear in the visible page body. AI crawlers extract from the text a reader sees, and the schema confirms and labels what they found. A foundingDate of 2025 in the markup, with no founding year anywhere on the page, is a claim the crawler can't corroborate, and Google's guidelines say the same thing in plain terms.
The content-schema parity check
If a fact appears in your JSON-LD but not in your visible page body, the models can't confirm it. Schema reinforces visible content; it never replaces it. Before a field goes into the markup, find the sentence on the page that says the same thing. If there isn't one, write it first.
The rule predates AI search. It's been in Google's structured data guidelines for years because hidden markup was how people used to game rich results, and it happens to describe exactly how an LLM crawler treats a page: the prose is the evidence, the markup is the label. Perplexity put it more bluntly than I would when we asked it this question, telling us not to add claims or Q&As in schema that visitors can't see.
The practical version is to read your Organization block field by field and go looking for each fact on the homepage or About page. areaServed needs a sentence about who you serve and where. knowsAbout needs pages about those topics, not a keyword list. An author with a jobTitle needs a visible byline. Where a fact is missing from the page, add it to the page first, and where it can't be added honestly, take it out of the schema.
What "automated" schema generation actually means
"Automated schema" covers three quite different things, and the gap between them is coverage and drift rather than convenience.
Tier 1
A generator you paste in
You fill in a form, download a JSON-LD snippet, and paste it into a page template. For one page that works. For 50 posts and 10 product pages it is 60 separate pastes with no check between them, and the brand facts drift as the product changes until a model is confidently describing a plan you retired a year ago.
Tier 2
CMS plugin defaults
Most CMS SEO plugins emit Article schema on posts and Organization schema on the homepage from a settings screen. That removes the per-page step. The output is usually the minimum required fields, the entity fields (alternateName, founders, knowsAbout, sameAs) sit empty unless someone fills them in, and two plugins running at once can emit two Organization blocks that disagree.
Tier 3
A platform that generates, checks and ships
The platform reads what each page says, generates the block with the entity fields populated from one source of truth, runs it through validation and the parity check, and ships it to the CMS or codebase as a draft for someone on your team to approve. Nothing publishes without sign-off. This is the tier we sit in, and the difference from tier 2 is that every page gets checked against every other page, so the @id and the facts match everywhere.
If your site is on a hosted CMS and the developer queue is measured in weeks, tier 3 is mostly a way of getting around that queue. The schema itself is the same JSON-LD anyone could write by hand; it just lands on every page and stays consistent as the site grows, which is most of what the technical layer of generative engine optimisation comes down to. How that shipping step works on each platform is covered in the post on GEO integrations for HubSpot, Webflow, WordPress and Git, and the broader case for tools that ship rather than report is in GEO tools that ship fixes to your CMS.
Four schema mistakes that leave a page less citable than having none
Bad schema does worse than nothing in a specific way: it hands the crawler two sources that disagree, and a crawler with two disagreeing sources has less confidence in either of them. That's the theory, anyway, and these four are the versions of it we keep finding.
Sparse schema with only the required fields
An Organization block with a name and a url is technically valid and tells the crawler almost nothing it could not read off the page title. The fields that do the entity work (description, foundingDate, alternateName, sameAs, knowsAbout) are optional in the schema.org specification and are where nearly all of the useful signal lives.
Schema that contradicts the visible page
A Service block that says you serve enterprise companies on a page whose copy is aimed at 10-person teams, or a description written two positioning cycles ago. The crawler now has the prose saying one thing and the markup saying another, and a model that has to pick between them will pick whichever it read first.
No @id, or a different @id on every page
The @id is how indexers deduplicate your entity across pages and across the web. Without one, each page describes an organisation that happens to share a name with the one on the next page. The fix is a single canonical value, usually your homepage URL with #organization appended, used in every block that refers to the company.
FAQPage schema with no visible FAQ section
Question and answer pairs that exist only in the JSON-LD break the parity rule outright. The models extract Q&A from the text they can see and use the markup to confirm the structure. If the questions are not on the page, there is nothing to confirm, and the block reads as the kind of hidden content the guidelines were written to catch.
A fifth one bit us. The first version of our own schema was injected by a script that ran after the page loaded. Google's renderer executes JavaScript, so Google saw it and we assumed we were done. Most LLM crawlers don't run JavaScript, so for as long as that version was live, GPTBot and ClaudeBot would have been fetching pages with no schema on them at all. It now goes out as a static script tag in the server-rendered HTML, which is where it should have been from the start, and the only reason we caught it is that we went looking at the raw source rather than the inspector.
How to audit your schema in 10 minutes
You need two free tools and the page source. Run this on the homepage, a recent blog post and a product or pricing page, because the three usually fail in different ways.
Run each URL through the Rich Results Test
Paste the three URLs into Google's Rich Results Test. It lists every schema block it detected, whether each one validates, and any errors or warnings. Write down which types are present and which are missing, and fix validation errors first, since an invalid block can take the rest of the page's markup down with it in Google's tooling.
Check field completeness in the Schema Markup Validator
The Rich Results Test only checks eligibility for Google's rich result types. Paste the raw JSON-LD into the Schema Markup Validator at validator.schema.org and look at what is empty: description, foundingDate, alternateName, sameAs and knowsAbout on Organization; dateModified and a Person author on Article. Those optional fields are where the entity signal lives.
Compare @id values across the three pages
View the source on each page and search for "@id". Every block that refers to the company should carry the same value. If the homepage says one thing, a post says another, and the pricing page has none, the entity signal is fragmented and that is the first thing to fix.
Count the ld+json blocks and look for duplicates
Search the source for "application/ld+json". If the same @type appears twice on one page, usually Organization or Article, two systems are emitting schema and at least one of them is wrong. Turn off schema output from all but one source.
Run the parity check on the Organization block
Read every field in the Organization JSON-LD and find the matching fact on the page. Founding year, location, name variants, who you serve. Anything in the markup that you cannot point to on the page either gets written into the page or comes out of the schema.
The tools are Google's Rich Results Test and the Schema Markup Validator; the field definitions for Organization are on schema.org. If the audit comes back clean and the models still describe you wrongly, the problem is upstream of the markup, which is the situation covered in why good SEO can still produce zero AI citations.
Common questions about schema markup and AI citations
Does FAQPage schema still matter now that Google has dropped FAQ rich results?
Yes, for extraction rather than display. Google limited FAQ rich results to government and health sites in August 2023 and stopped showing them altogether in May 2026, so the visual payoff is gone. The question and answer pair is still the easiest structure for a retrieval step to lift, provided the same questions and answers are visible on the page.
Which schema type has the biggest impact on AI citation rates?
Organization, with a consistent @id and the entity fields filled in: alternateName, founders, foundingDate, sameAs, areaServed and knowsAbout. It's the block every other block points at, so a thin one weakens all of them. On a content-heavy site, Article or BlogPosting with real datePublished and dateModified values is the next most useful, since the engines use those dates as a freshness check.
Is schema markup a ranking factor for AI answers?
No. Google says there's no special structured data for AI Overviews or AI Mode and that the normal indexing and snippet rules apply. Microsoft has said schema helps its LLMs understand content. Both describe comprehension and eligibility, and on the sites we look at the effect shows up as fewer wrong descriptions rather than a visible jump in how often the brand gets mentioned.
Do AI crawlers read JSON-LD that's injected by JavaScript?
Assume they don't. Most LLM crawlers fetch the raw HTML and don't execute scripts, so a block added by a tag manager or a client-side script after load isn't there when they read the page. Emit the script tag in the server-rendered HTML, then confirm it by viewing the page source rather than the rendered DOM in your browser's inspector.
The audit is 10 minutes with two free tools, and what you'll most likely find is a thin Organization block, a missing @id and an Article block with no dateModified, because that's the pattern on most of the sites we look at. Generating the full set, checking every block against the page it sits on, and shipping it as drafts across the whole site is what the Engine does in the first phase of every BrandViz.AI engagement.