Schema Markup That Answer Engines Actually Use

The best schema markup for AI search is accurate, sparse, and tied to visible content — Organization or LocalBusiness, Article or BlogPosting, and FAQPage only where the questions are on the page. A kitchen-sink JSON-LD blob that claims every Schema.org type does not force ChatGPT or Google AI Overviews to cite you. It trains crawlers to distrust the page.

This spoke is the schema layer of the Answer Engine Optimization playbook. Implement it next to llms.txt. I have been SEO certified since 2021. The AEO version of that work is still a fact sheet you can defend, not a plugin that dumps fifty @type values into the footer.

The short answer

• Ship four types that match what a human can read: Organization or LocalBusiness, Article or BlogPosting, and FAQPage only on URLs that render those questions
• Put Organization on the homepage or About page with a stable @id. Reference that node from posts. Do not reprint a slightly different Organization on every URL
• Schema clarifies who you are and what the page is. It does not buy a citation. Google says structured data helps Search understand a page; it does not promise a feature, and it does not promise an AI footnote
• Google stopped showing FAQ rich results on May 7, 2026. Keep honest FAQPage markup for machines that still read labeled Q&A. Do not keep it to chase a SERP widget that is gone
• If the visible copy says 2019 and the JSON-LD says 2014, you published a conflict. Delete the lie before you add another type

What does schema do for answer engines?

JSON-LD labels the type and attributes of things already on the page. Google’s own intro is blunt: structured data gives Search explicit clues about meaning. It can feed rich results. It can also feed a broader picture of people, books, and companies. It does not say “this block forces a citation in ChatGPT.”

Answer engines that retrieve your HTML can use those labels the same way Search does — to bind a name, a logo, an author, or a Q&A pair to the correct entity. When two sources disagree on founding year or phone number, consistent schema plus matching HTML is one more vote for your version. That is hygiene. It is not a citation button.

Claim you will hear	What is actually true
“Add 40 schema types and AI will cite you”	Extra types that do not match the page are noise. Google’s quality guidelines reject markup the user cannot see
“FAQ schema unlocks AI Overviews”	Google deprecated FAQ rich results effective May 7, 2026. FAQPage remains a Schema.org type. It is not a Google SERP feature anymore
“Organization on every URL is safer”	Google recommends one Organization page — home or About — not a reprint on every template
“JSON-LD ranks you”	Google does not guarantee a rich result even when markup is valid. Ranking and citation are separate systems
“A validator green check means AEO is done”	A validator checks syntax and Google-required fields. It cannot prove a model will name you

If you remember one sentence: schema reduces ambiguity. It does not compel a model to pick you.

Which four types are worth shipping?

Most brands do not need the Schema.org catalog. They need the four types that describe identity, the page, and honest Q&A. Everything else waits until those four validate cleanly in production.

Type	Where it lives	Job	Skip when
Organization	Homepage or About	Name, URL, logo, sameAs, contact, legal identifiers	You are a single-location shop that should use a LocalBusiness subtype instead
LocalBusiness	Location or service-area page	NAP, hours, geo, phone that match Google Business Profile	You have no public location and no honest service area
Article / BlogPosting	Post templates	Headline, dates, author Person, publisher Organization, image	The URL is a thin landing page pretending to be a post
FAQPage	Only URLs that render the questions	mainEntity Question / acceptedAnswer pairs that match visible text	You stuffed sitewide FAQs into a tag manager

Optional later, not launch week:

Type	When it earns a ticket	When it is soup
WebSite	You want a site-name node. Google still uses a WebSite variant for site names	You fake a SearchAction for a search box that does not exist. The sitelinks search box feature is gone as of November 21, 2024
BreadcrumbList	The visible crumbs match the graph	You invent a hierarchy the nav does not show
Product / Offer / Service	You sell a named SKU or package with public attributes	You mark every paragraph as a Product
AggregateRating	Real reviews you display and can defend	Star ratings you invented in a plugin

Use the most specific Schema.org subtype that is true. Google’s Organization guide says the same: an ecommerce brand should prefer OnlineStore over a generic Organization; a restaurant should use the LocalBusiness subtype that fits, then follow the Local business fields. Specificity is not the same as stacking five @type arrays that contradict.

How do you ship Organization without multiplying entities?

Define the brand once. Give it a stable @id such as https://example.com/#organization. Point Article publisher and LocalBusiness parentOrganization at that @id. Google’s Organization documentation says you do not need this block on every page. Hundreds of production sites I have shipped fail this in the same way: the theme prints Organization, a plugin prints Organization, and the custom head prints Organization with a different founding year.

Property	Ship it when	Leave it out when
name / alternateName	They match the visible site name	Marketing wants a slogan in name
url	It is the canonical homepage	You point it at a campaign landing page
logo	The file is crawlable. Google asks for 112×112px minimum and a mark that still reads on white	You only have a dark-on-dark lockup
sameAs	Each URL is a real profile that loads	You paste a Wikidata Q-id you do not have, or a 404 LinkedIn
description	It matches the About paragraph	You stuffed keywords the page never says
foundingDate	The year is on the page and in the fact sheet	Two founders disagree and nobody wrote it down
address / telephone / email	You want them public and they match GBP or the contact page	You are a service-area brand hiding the street address on purpose
iso6523Code / vatID / legalName	You have the identifier and it is public	You guessed a DUNS number

sameAs is the property Google calls out as generally useful beyond a single rich-result type. Put real profiles there. Empty sameAs arrays and competitor copy-paste are how Organization nodes go bad.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Coatings Co",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "description": "Industrial powder coating for aerospace subcontractors in the Midwest.",
  "foundingDate": "1998",
  "sameAs": [
    "https://www.linkedin.com/company/example-coatings"
  ],
  "contactPoint": [{
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "hello@example.com"
  }]
}

Only include email if you want it public. Mirror description on About. If the About page says 1998 and this block says 1998, you have a fact. If they disagree, you have a ticket.

• One Organization @id in the fact sheet
• Homepage or About emits that node
• Blog publisher references the @id instead of cloning the object
• sameAs URLs return 200
• Founding year, legal name, and phone match visible copy

Does FAQ schema still help after Google dropped FAQ rich results?

Yes for honest Q&A. No as a Google rich-result play. On May 8, 2026 Google added a deprecation notice: FAQ rich results would no longer appear in Search starting May 7, 2026. In June 2026 Google removed the FAQ rich-result documentation because the feature was gone. FAQPage itself is still a Schema.org type. Unused structured data, Google has said since the 2023 HowTo/FAQ change, does not by itself cause Search problems.

That is the distinction teams miss. FAQ schema for AEO is still useful when a retrieval system wants a labeled question and a short answer. It is a liability when you inject forty sitewide questions from a tag manager onto URLs that do not show them. Google’s general structured-data guidelines still forbid marking up content the reader cannot see. A structured-data manual action removes rich-result eligibility. It does not “rank-ban” the URL — and it also does not help a model trust you.

Do	Do not
Render the questions as visible HTML, then emit matching mainEntity	Hide answers in JSON-LD only
Use the same question string the user can read	Rewrite the question in schema to chase a keyword
Keep answers short and true to the visible paragraph	Paste a 400-word essay into acceptedAnswer that the page never shows
Emit FAQPage from the template that renders the FAQ	Fire a global GTM tag on every URL
Delete FAQPage the day the FAQ block is removed	Leave stale Q&A in the graph for six months

Visible HTML:

Do you coat parts longer than 3 meters? Yes — the line accepts parts up to 4 meters with advance scheduling.

JSON-LD mainEntity must use that question text and the same answer meaning. If an editor changes the HTML and forgets the graph, rip FAQPage out until the template syncs. Schema is not a drawer for copy you were too lazy to render.

1. Inventory which templates actually render a FAQ block
2. Generate FAQPage only from that block’s source of truth
3. Unit-test that question count in HTML equals question count in JSON-LD
4. After a CMS change, view source and confirm the block disappeared with the UI
5. Do not measure success by a FAQ rich-result impression that Google no longer shows

What belongs in Article or BlogPosting markup?

On posts, tell machines the headline, the dates, the person who wrote it, the organization that published it, and a real image. Google’s Article documentation accepts Article, NewsArticle, or BlogPosting. There is no markup requirement to appear in Google News features. The point is to say what the page is, who wrote it, and when it changed.

dateModified matters when you refresh AEO content. A spoke you rewrote in August 2026 that still claims dateModified equals the original May date is lying about freshness. The Rich Results Test will not always warn you. Google still recommends ISO 8601 with a timezone.

Property	Rule
headline	Match the visible title. Long titles get truncated in some surfaces
datePublished	First publish time, ISO 8601, timezone included
dateModified	Last real edit. Update it in the same PR as the copy
author	Person with name plus url or sameAs to a real bio. One object per author. Do not cram two names into one string
publisher	Organization with @id matching the sitewide node
image	Images that represent the article, crawlable, not a logo-only stand-in. Google asks for relevant art and prefers multiple aspect ratios

Author markup is where studios get sloppy. Google’s author best practices: include every byline you show, use Person for people and Organization for organizations, put only the name in author.name, and give each author a URL. Guest authors need a real Person page or the template should list staff only. Fake author entities are a trust problem for Search and for any system summarizing “who wrote this.”

• Blog template emits BlogPosting or Article, not a hand-pasted blob per post
• publisher.@id equals the Organization @id
• dateModified changes when the markdown lastModified changes
• Author URL returns a bio, not a 404
• Image URLs are indexable in URL Inspection

When should you use LocalBusiness instead of Organization?

When the public entity is a place or a service-area business, not a faceless brand. Google’s Organization guide sends local operators to the most specific LocalBusiness subtype and to that guide’s required and recommended fields. NAP in schema must match NAP on the page and on Google Business Profile. A restaurant that marks up as generic Organization and then lists different hours in GBP taught two systems two clocks.

Situation	Type to emit	Extra fields that must match GBP
One shop with a door	Most specific LocalBusiness subtype on the location URL	address, telephone, openingHoursSpecification, geo
Multi-location brand	One LocalBusiness per location page, parentOrganization → brand Organization	Per-location hours and pin. Do not average hours onto the homepage
Service-area, no walk-in	LocalBusiness (or subtype) with honest areaServed. Do not invent a storefront pin	Hidden street address on GBP if that is the real policy. Say so on the site
Pure software / studio with no public office	Organization on About	Skip geo you cannot defend

Local extras worth doing when they are true:

• openingHoursSpecification that matches the GBP grid, including holiday exceptions you actually post
• geo coordinates that match the pin, not a geocoder guess from a PO box
• priceRange only if you would print it on the site
• hasOfferCatalog when services are stably named

Do not attach AggregateRating unless the page shows those reviews. Google’s quality guidelines treat fake reviews as a manual-action risk. A structured-data manual action is not a ranking death sentence. It is still a public record that you marked up fiction.

• GBP name, address, phone, and hours pasted into the fact sheet
• Location template reads from that sheet
• Multi-location: one node per location URL
• Service-area brands do not publish a walk-in pin they do not have
• Reviews in schema equal reviews on the page

What is schema soup, and why delete it?

Schema soup is a graph that claims more types than the page can support, often from a plugin default, a competitor copy-paste, or a “schema pack” that turns every URL into Product + Review + HowTo + Speakable + FAQPage. Google’s specificity guideline says to use the most specific applicable type. It does not say to use every type. Completeness means required properties for the types you chose, not a high type count.

Anti-pattern	What breaks	Fix
Whole site marked Product	Offer and price fields that do not exist	Product only on URLs that sell a named thing
AggregateRating without reviews	Manual-action risk; models that repeat a fake 4.9	Delete the rating node
Empty or 404 sameAs	Organization identity points at dead profiles	Drop the URL or fix the profile
Competitor schema copied wholesale	Their founding year, their VAT, their @id	Rewrite from your fact sheet
Five overlapping @type arrays	Parsers cannot tell which node is canonical	One specific type, or a clean @graph with @id links
Hidden text that exists only for markup	Violates “don’t mark up what readers cannot see”	Render it or delete it
Theme plugin plus custom component both printing Organization	Two founding years, two logos	Count <script type="application/ld+json"> blocks. Keep one owner
Speakable and other experimental types on day one	Easy to misuse; weak support	Skip until the four core types are clean

Nothing is better than wrong things. An empty graph is quieter than a graph that swears you are a Product with 312 reviews.

How must JSON-LD match the visible page?

Google’s quality bar is the AEO bar: structured data must be a true representation of the page. The example they give is a woodworking site labeling instructions as recipes. The AEO version is an About page that says “founded 2014” while JSON-LD says 2009, or a FAQ block of six questions while mainEntity still lists the old eleven.

Visible HTML	Allowed in JSON-LD	Not allowed
“Founded in 1998” on About	foundingDate: 1998	foundingDate: 1992 because a deck said so
Six FAQ H3s	Six Question objects	Eleven questions from a leftover CMS field
Byline “Jamie Chen”	author.name: Jamie Chen	author.name: “Staff Writer, SEO Team”
No reviews on the page	No AggregateRating	A plugin default of 5.0 / 47 reviews
Hours Tue–Sat 10–6	Matching openingHoursSpecification	24/7 because a directory still says that

Put the structured data on the page it describes. If you have duplicate URLs for the same article, Google recommends the same structured data on the duplicates, not only the canonical. That is a Search rule. For AEO it is the same idea: do not let the AMP or preview host emit a different @id than production.

1. Open the live URL, not localhost
2. Read the visible facts into a three-column sheet: field, HTML, JSON-LD
3. Any row that disagrees is a ticket, not a “nice to have”
4. Fix the source of truth (CMS field or config module), not one JSON file by hand
5. Re-fetch after cache. CDNs serve old JSON-LD longer than teams expect

How do you generate markup so founding years cannot drift?

Do not let marketing freestyle JSON in a tag manager. Generate JSON-LD from a single typed config module — the same fact sheet that feeds llms.txt. I have watched this fail on hundreds of production sites in the same pattern: the theme has a founding year, the About page has another, and a contractor pasted a third into GTM before a launch.

Source of truth	Owns	Must not own
Typed config / fact sheet	Organization name, @id, foundingDate, sameAs, NAP	Per-post headlines
Blog template	Article fields from frontmatter (date, lastModified, author, title, image)	A second Organization clone
FAQ component	FAQPage from the same array the HTML maps over	A hardcoded leftover list
Location template	LocalBusiness from the location record	Homepage hours for all shops

Engineering rules that hold:

• Unit-test that required keys exist in CI
• Avoid duplicating Organization on every blog post; reference publisher with @id
• Fail preview deploys when schema validation fails
• Acceptance criteria in tickets, not vibes: “Given About, Organization foundingDate matches the visible year”
• Given a blog update, dateModified changes
• Given FAQ removal, FAQPage disappears
• Watch @id values on staging. Localhost and preview hostnames copied to production are a recurring bug
• When marketing spins a landing-page builder outside the CMS, assume schema is missing until you view source

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Schema Markup That Answer Engines Actually Use",
  "datePublished": "2026-05-28T09:00:00-04:00",
  "dateModified": "2026-08-16T12:00:00-04:00",
  "author": {
    "@type": "Person",
    "name": "William Spurlock",
    "url": "https://example.com/studio"
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  }
}

The publisher object is a pointer, not a second biography.

How do you validate schema after a deploy?

Validate for two jobs. The Rich Results Test tells you whether Google can use the types it still supports. The Schema Markup Validator tells you whether the graph is valid Schema.org. A page can pass one and fail the other. After May 2026, do not expect the Rich Results Test to celebrate FAQPage. That is not a reason to delete honest FAQ markup. It is a reason to stop treating a missing FAQ enhancement as an outage.

Tool	What it answers	What it cannot answer
Rich Results Test	Eligible Google features, critical errors on supported types	Whether ChatGPT will cite the URL
Schema Markup Validator	Type and property validity against Schema.org	Whether the facts match the HTML
URL Inspection	What Googlebot fetched, including JSON-LD	What a chat model retrieved last Tuesday
View source + count of ld+json blocks	How many injectors you actually have	Which injector is “the” one until you label them
Search Console rich-result reports	Production validity after crawl	FAQ impressions after the May 2026 cutoff

Week-one kit:

1. Export JSON-LD from five templates: home, About, one service or location, one article, one FAQ page
2. Paste each into both validators
3. File every error. Ship Organization and Article fixes before any exotic type
4. Update the fact sheet so engineering and marketing argue from the same founding year
5. Recrawl after deploy. Spot-check three live URLs, not the preview host
6. Count <script type="application/ld+json"> blocks. Two thoughtful blocks beat six accidental ones
7. Re-run the kit after major launches. Name an owner. When someone goes on leave, transfer the ritual

Google also says to keep pages crawlable. robots.txt, noindex, or a login in front of the only Organization URL means Search never sees the node you spent a week polishing.

What does a FAQ-schema failure actually look like?

A SaaS marketing site injected sitewide FAQ schema from a tag manager. The visible FAQ lived only on pricing. Rich-result tests flickered while the feature still existed. Retrieval that grounded on a blog URL saw Q&A pairs the reader never saw. That is the exact mismatch Google’s quality guidelines call out.

The fix was not “add more types.” The fix was deleting the global injection and emitting FAQPage only from the pricing template. Citations did not spike the next morning. A confusing trust signal disappeared. The pricing FAQ became safe to expand because the graph and the HTML finally agreed.

Symptom	Likely cause	First move
Validator lists questions the page does not show	Global GTM or plugin FAQ pack	Disable the injector. Re-test one URL
FAQPage present after the FAQ UI was removed	Template still emits the old array	Gate the script on the same condition as the component
Two FAQPage blocks with different answers	Theme plus custom component	Keep the component that renders HTML. Delete the other
Rich Results Test ignores FAQPage in 2026	Feature deprecated May 7, 2026	Stop filing that as a Sev-1. Check Schema.org validity instead
Model quotes a pricing answer on a blog URL	Sitewide FAQ graph leaked onto the post	Confirm view-source on the post. The graph should not include those questions

Moral: schema is not a place to stash copy. If the user cannot see it, the graph should not claim it.

Should you use @graph or multiple script tags?

Google understands both nested items and separate items on one page. Its multiple-items guidance says you can nest related objects or list them as individual blocks. Either pattern is fine if each node has a job and a stable @id. Soup starts when three injectors each emit a full Organization plus a partial Article and nobody owns the merge.

Pattern	Use it when	Failure mode
One @graph array	Your framework already builds a single JSON-LD document	A missing comma after a CMS field kills the whole graph
One script per type	Theme, blog template, and FAQ component are owned by different files	Two Organization nodes with different foundingDate values
Nested publisher inside Article	You only need a pointer	You nest a second full Organization instead of { "@id": "https://example.com/#organization" }

Pick one house style and write it in the repo README next to the fact sheet. The test is not elegance. The test is: view source on home, About, one post, and one FAQ URL, and be able to say which file emitted each <script type="application/ld+json"> block.

• Label each injector in a comment or data-schema-owner attribute
• Prohibit GTM from adding Organization if the theme already does
• If you use @graph, validate the whole document, not one node in isolation
• If you use multiple scripts, grep production HTML for duplicate "@type": "Organization"
• Never let a page builder emit a third copy “just for this campaign”

How much schema is enough for launch week?

Minimum viable AEO schema pack:

1. Organization on the homepage or About, with sameAs and a stable @id
2. WebSite on the homepage only if you want a site-name node — not a fake SearchAction
3. Article or BlogPosting on the blog template
4. FAQPage only on URLs that render FAQs
5. LocalBusiness on location templates if you are local

Everything else is optional until that pack validates on production URLs. Teams that start with Product + Review + HowTo + Speakable on day one usually ship broken JSON and spend the week firefighting. Sequence prevents soup from returning the Monday after cleanup.

Day	Work	Done looks like
1	Inventory current ld+json on five templates	A sheet of types, injectors, and conflicts
2	Lock the fact sheet (name, @id, foundingDate, NAP, sameAs)	One row per field, one owner
3	Ship Organization + Article from templates	Preview validators clean
4	Wire FAQPage to the FAQ component only	Question counts match
5	Production recrawl + three URL spot-checks	Live HTML matches staging
Later	Product, HowTo, or catalog types	Only after the minimum stays clean for a week

Translated pages need schema in the page language with the correct inLanguage. Do not leave an English Organization description on a Spanish About page. Hreflang remains an SEO concern. Language-mismatched schema is avoidable confusion for multilingual retrieval.

Be conservative with experimental types. If a type is poorly supported or easy to misuse, skip it. Revisit quarterly, not during an emergency rewrite.

How should schema stay aligned with llms.txt?

llms.txt and JSON-LD are two encodings of the same fact sheet. When they disagree, you published two official truths. The llms.txt spec for brands is the prose file. Schema is the typed file. A rename of a package, a new location, or a founding-year correction ships in the same PR as the page title, the llms.txt line, and the Organization node.

Change	Pages	Schema	llms.txt
Legal name change	About, footer	name / legalName / alternateName	Brand line
New location	Location URL	New LocalBusiness node	Locations list
Package rename	Pricing, offers	hasOfferCatalog or Service name	Offers list
FAQ rewrite	The URL that shows it	mainEntity strings	Only if the file quotes those answers
Author change	Post byline	Article author	Authors / team section if you list them

When a spoke post adds FAQs, the content checklist includes “schema updated or the template covers it.” AEO breaks in the seams between teams. Write that into the ticket, not into a slide.

If you need a second pair of eyes on the baseline, the visibility lane exists for that reason: /visibility. The work is still the same ritual — sparse types, matching HTML, one @id.

FAQ

What is the best schema markup for AI search?

Start with accurate Organization or LocalBusiness, Article or BlogPosting on posts, and FAQPage only where real FAQs exist. Add Product or Service when offers are concrete and public. Accuracy beats coverage. A four-type graph that matches the page will outperform a fifty-type graph that does not.

Does FAQ schema help AEO?

Yes when the FAQ is genuine, visible, and useful — retrieval systems can lift a labeled question and a short answer. Google stopped showing FAQ rich results on May 7, 2026, so do not keep FAQPage to chase a SERP widget. Fake or sitewide FAQ schema is a trust problem. Skip it.

Should every page have Organization schema?

No. Prefer one strong Organization definition on the homepage or About page and reference it with @id. Google says you do not need the block on every URL. Repeating slightly different Organization objects is how founding years drift.

Is JSON-LD better than microdata for AEO?

JSON-LD is what we ship by default because it is easier to generate from a template and easier to test. Google recommends JSON-LD for the same reason and still accepts microdata and RDFa when they are valid. Consistency and validity matter more than the encoding flavor.

Does schema markup force AI citations?

No. Schema does not force ChatGPT, Google AI Overviews, or any other answer engine to cite you. It reduces ambiguity about identity, authorship, and Q&A when a system already retrieved the page. Measure citations with a prompt panel. Do not treat a green validator as a citation.

How often should we validate schema?

After every template deploy, and quarterly as a full five-URL audit. Include both the Rich Results Test and the Schema Markup Validator. Re-fetch live HTML, not staging. If FAQPage disappears from Google’s rich-result reports after May 2026, that is expected. Invalid Organization or Article is not.

CTA

Ship less schema. Make it true. Keep it aligned with the page and with llms.txt.

Return to the AEO playbook for the full stack. For a schema baseline on your domain, visit /visibility or request a visibility audit.