Does schema markup actually help LLM citations?

Yes — but indirectly. Schema doesn't 'tell' an LLM to cite you. It gives both classic crawlers and LLM retrieval systems unambiguous signals about what each page is, who wrote it, when it was updated, and how it relates to other entities. Sites with consistent schema graphs are systematically over-represented in LLM citation samples.

Which schema types matter most for AI engines?

FAQPage, HowTo, Article (with author + publisher), Organization, Person, Speakable, Product, Service, and BreadcrumbList. The strongest gains come not from any single type but from a connected schema graph where Article references Author by @id, Author references Organization by @id, and so on.

Will Google penalize me for using schema?

Only for misuse — fake reviews, off-page schema, schema describing content not on the page. Correctly implemented schema for content actually on the page is unambiguously beneficial and has been since 2014. The 2024 review-snippet manual-action wave was about fake reviews, not schema use.

How is schema different for AEO than for classic SEO?

The intent is similar (machine-readable disambiguation) but the consumers are broader. For classic SEO, schema unlocks SERP features. For AEO, schema increases the probability that an LLM correctly identifies your page as the canonical source for a query. Speakable, Claim, and Citation schema matter much more for AEO.

Do I need to use JSON-LD or can I use microdata / RDFa?

JSON-LD is now the dominant format and the one Google explicitly prefers. New implementations should use JSON-LD exclusively. Microdata and RDFa still work but are increasingly ignored in tooling.

How often should I audit schema?

Quarterly at minimum. Schema validation tools change, schema.org evolves, and Google's specific support shifts. We rerun the validator on the top 50 URLs every quarter and on the top 10 monthly.

Is more schema always better?

No. Schema describing content not actually on the page is a documented penalty trigger. Use the types that map to what's actually rendered, then stop.

Schema for AI Engines: A Practical Deep Dive (2026)

Why schema matters more for AI engines than for SERPs

Schema markup gives both classic crawlers and LLM retrieval systems unambiguous, machine-parseable signals about what a page is, who wrote it, when it was updated, and how it relates to other entities. For a SERP, schema unlocks rich results — review stars, FAQ accordions, sitelinks. For an AI engine, schema directly affects the probability that the engine correctly identifies your page as the canonical source for a query and quotes it accordingly.

The asymmetry is large. A page without schema can rank #1 organically and still be miscategorized by an LLM that has to infer entity relationships from prose. A page with a clean schema graph hands the LLM the answer to 'what is this page' in a form it cannot misread.

The schema stack we ship on every engagement

Every Toronto SEO engagement ships a layered schema stack with seven node types. Each node has a stable @id so the relationships between them survive across pages.

Organization (sitewide)

One canonical Organization node, on every page, referenced by stable @id. Holds name, logo, sameAs links, contact.

Person (per author)

One Person node per real human contributor. Holds credentials, sameAs (LinkedIn, GitHub), worksFor reference.

WebSite (sitewide)

Holds SearchAction, language, publisher reference. One node, referenced by every page.

WebPage (per page)

Per-URL identification. Holds inLanguage, isPartOf, breadcrumb, primaryImageOfPage.

Article (per editorial page)

Holds headline, datePublished, dateModified, author + publisher references, wordCount.

FAQPage (where applicable)

Question + acceptedAnswer pairs. Visible Q&A in DOM must match schema text.

Speakable (per editorial page)

Marks H1 + summary as machine-readable. Material lift on voice and AEO citations.

A connected schema graph is the cheapest E-E-A-T lever in modern SEO. It costs an engineering sprint and pays for itself in citation share within a quarter.

— Internal methodology note, Toronto SEO

Type-by-type: which to use, when, and how

Type	Use when	Critical fields	Common mistake
Organization	Every page, in the global graph	name, url, logo, sameAs, contactPoint	Multiple competing Organization nodes per page
Person	Editorial pages with named authors	name, jobTitle, sameAs, worksFor, knowsAbout	Person referenced by name string instead of @id
Article / TechArticle	Editorial content > 500 words	headline, datePublished, dateModified, author, publisher, image, wordCount	datePublished newer than dateModified (impossible)
FAQPage	Pages with > 3 visible Q&A pairs	mainEntity[].name, mainEntity[].acceptedAnswer.text	Schema Q&A text doesn't match visible DOM Q&A
HowTo	Procedural content with > 3 steps	step[].name, step[].text, totalTime, supply, tool	Steps in schema not matching steps on page
Service	Service pages where you sell something defined	serviceType, areaServed, provider, offers	Pricing in schema not matching visible pricing
Product	Product pages — physical or digital	name, sku, brand, offers, aggregateRating (real reviews only)	Fake aggregateRating — fastest manual penalty
Speakable	Long-form articles, AEO-targeted pages	cssSelector pointing at H1 + summary	Selector matching nothing on the rendered page
BreadcrumbList	Every page with > 1 hierarchy level	itemListElement[].position, name, item	Position numbering not 1-indexed

The schema graph: connecting nodes by @id

The single largest improvement most sites can make to their schema is moving from disconnected schema blocks (one Article block, one Organization block, no relationships) to a connected graph where each node references others by stable @id.

The pattern looks like this:

Define stable @ids for every long-lived entity
https://torontoseo.com/#organization, https://torontoseo.com/#website, https://torontoseo.com/team#martin-vassilev. These don't change.
Reference, don't redefine
Every Article references publisher by { '@id': '...#organization' }, not by re-stating the Organization. Same for author.
Use isPartOf to nest pages under the WebSite
Every WebPage isPartOf the WebSite node. Tells the engine 'this URL belongs to this site identity.'
Use mainEntityOfPage on Article
Connects the Article node to the WebPage node by URL. Disambiguates which Article belongs to which URL.
Use sameAs aggressively on Person and Organization
LinkedIn, X, GitHub, Crunchbase, Wikipedia, Wikidata. Every legitimate identity link tightens entity disambiguation.

The result is a graph the engine can traverse: Article → author → Person → worksFor → Organization → publisher of → Article. Every relationship is explicit. The engine doesn't have to infer.

Validation: tools, gotchas, and what really matters

Schema Markup Validator (validator.schema.org)

The schema.org official validator. Use first — checks valid schema.org structure regardless of Google support.

Google Rich Results Test

Checks Google-specific rich-result eligibility. A page can be valid schema.org and still not be Google-eligible for a particular feature.

Search Console enhancement reports

Per-feature error reports across the entire indexed site. Quarterly review minimum.

Custom CI validation

We run JSON-LD validation in CI on every commit. Stops broken schema from ever reaching production.

The most common gotcha: FAQPage schema where the question and answer text in the schema doesn't exactly match the visible text on the page. Google's quality systems treat this as a deception signal. We've audited dozens of sites where the FAQPage schema was generated separately from the visible FAQ component and the two drifted apart over time.

Schema anti-patterns to avoid

Fake AggregateRating
Inventing review counts and stars to earn a SERP star rating. Documented penalty trigger; the fastest manual action we've seen issued. Do not.
Schema describing content that isn't on the page
FAQPage with 10 questions, only 4 visible. HowTo with steps not present. Both detected and demoted.
Speakable selector matching nothing
Speakable schema with cssSelector pointing to a class that doesn't exist after render. Silent failure.
Multiple competing Organization nodes per page
One Organization node sitewide. Multiple competing nodes confuse entity consolidation.
Author schema without sameAs links
Person nodes that don't link out to verifiable identity (LinkedIn, GitHub, Wikipedia) carry minimal weight.
Outdated dateModified
Refreshing dateModified without actually updating the content. Detected; trust signal degrades.

The 30-day schema-for-AI rollout playbook

Week	Workstream	Output
Week 1	Audit + entity inventory	List of Organization, Person, Service, Product nodes the site needs. Stable @id assignment plan.
Week 2	Sitewide graph (Organization + WebSite + Person + Speakable)	Schema appears on every page; graph is connected by @id; validates without errors.
Week 3	Per-page Article + FAQPage + BreadcrumbList rollout	Top 50 editorial pages have Article + FAQPage + Breadcrumb shipped + validated.
Week 4	CI validation + monitoring + first audit	JSON-LD validation runs on every PR; Search Console enhancement reports baselined.

By the end of week 4 the site has a complete connected schema graph, automated validation, and the baseline metrics in place to measure citation-share lift over the following quarter. The work then becomes maintenance: keeping dateModified honest, adding new author Person nodes as needed, and quarterly audits.

The honest summary

Schema for AI engines is not exotic — it's the same disciplined application of schema.org that has worked in classic SEO for a decade, plus a small number of AEO-specific additions (Speakable, tighter Person graphs, more aggressive sameAs use). What's changed is the asymmetry of the payoff. In 2018, schema unlocked SERP features. In 2026, schema increasingly determines whether an LLM can correctly identify your page as the source it should cite for a given query. The work is the same; the stakes are higher.

Frequently Asked Questions

What clients ask before commissioning a schema rebuild.