Home→Insights→Schema for AI Search: What Helps and What Doesn't
SEO, GEO & AEO
Schema for AI Search: What Helps and What Doesn't
Sukhdeep Singh
Content Marketer
· 26 min
Structured data has 3 buckets in 2026: helps a lot, helps a little, and noise. Ship the 5 types that lift AI search citation attribution and skip the rest.
SEO, GEO & AEO Solutions
Looking for a seo, geo & aeo partner?
We build domain-led systems tailored to your industry and workflow. 12 years. 2,100+ engagements.
Structured data markup, the small hidden code that tells search engines what your page is about, was always a quiet ranking signal in traditional Google search. In AI search it is doing something a bit different: it is helping ChatGPT, Claude, Perplexity, and Google AI Overviews map your site into the entities they already know about, so the answer layer can attribute your content to the right business and the right author. Some structured data types lift citation rates meaningfully. Others are theater that adds bytes to your HTML and no signal underneath.
We run a production RAG-grounded chatbot on our own site and ship structured data markup as part of the technical layer for client work, so the patterns are something we have watched up close. The 5 types of markup that matter for AI search are the ones the answer layer actually uses to identify and attribute content. The 10 or more types that exist in the spec but do nothing in AI search are the ones that exist for reasons the model is not paying attention to. Knowing which is which is the difference between a technical layer that lifts visibility and one that just inflates the page weight.
Below are the 3 kinds of structured data in 2026, the 5 types worth shipping in priority order, the 5 mistakes that waste engineering time, the 3 cases where generic markup is genuinely enough, and the before-and-after of a page with the right markup next to one without it.
5
Types of structured data markup that lift AI search retrieval and citation accuracy.
3
Common markup types that no longer move the needle for AI search citations.
0
Ongoing license fee or third-party dependency. The work is in your stack, not a vendor's.
1
Question that decides whether a markup type is worth shipping: can a model use it?
You will see which markup actually lifts citation accuracy in AI search, which is busywork in 2026, and how to maintain the layer once it is live.
3 Kinds of Structured Data in 2026, and How AI Search Treats Each
Every structured data type lives in 1 of 3 buckets when it comes to AI search citation. The buckets are not based on the spec; they are based on what the answer layer actually reads. The cleanest way to plan a structured data investment is to sort the types you might ship into the 3 buckets and spend the engineering time only on the first 2.
Helps / Helps a Little / Doesn't Help
3 Kinds of Structured Data, by What the Answer Layer Does With Each
Sorted by whether AI search engines use the markup to attribute, identify, or ignore your content. The first 2 buckets are where the engineering budget pays back.
Bucket A
Helps a Lot
Organization, BlogPosting (with author), FAQPage, Person, and Product. These are the 5 the answer layer uses to identify who you are, attribute what you publish, and pull your content into citations.
Spend here: the technical layer that the answer layer actually reads.
Bucket B
Helps a Little
BreadcrumbList, Review, AggregateRating, HowTo. Useful for traditional search rich results and occasional AI search context, but not consistent citation lifters in 2026.
Spend here second: ship after Bucket A is solid; ignore until then.
Bucket C
Doesn't Help in AI Search
SiteNavigationElement, Sitelinks Searchbox, generic WebPage, ImageObject without context. The spec includes them; the answer layer mostly ignores them. Page bytes for no return.
Skip these: ship them only if a separate non-AI reason requires it.
Bucket A Carries Almost All the Lift
When we ship the technical layer for clients, 90 percent of the citation lift comes from the 5 types in Bucket A done correctly. Bucket B adds modest rich-result coverage in traditional search. Bucket C adds nothing the answer layer rewards. The spend plan is to do Bucket A right, then decide whether Bucket B is worth the next sprint.
Almost every "we shipped a lot of structured data and saw no AI search lift" story we hear traces back to spending the budget in Bucket C while Bucket A was half-built. Ship Bucket A first, get it right, and the AI search visibility move shows up. Mix the buckets and the result looks like nothing changed even when the page weight quietly grew.
The 5 Markup Types Worth Shipping, in Priority Order
Inside Bucket A, the 5 types are not equal. The order below is what we see consistently across ChatGPT, Claude, Perplexity, and Google AI Overviews. Ship them in this order and you cover the layer the answer engines actually use to map and attribute your content.
Priority Order
5 Markup Types to Ship, Ranked by What the Answer Layer Uses Each For
1
Identity
Organization Markup
Tells the answer layer who runs the site. Name, logo, founding date, location, contact, links to your verified profiles on other platforms. This is what the model uses to attribute your content to the right business when it cites you. Skip this and the model may cite a competitor or a generic source for the same content because it cannot ground your pages to an entity it recognizes.
2
Attribution
BlogPosting Markup With Author
Marks each editorial page as a publication with a real author, a publication date, and a clear connection back to the organization above. The answer layer uses this to attribute citations to a person rather than a generic source, which is the single largest lift in AI search retrieval for editorial content. Without it, the model may quote your content without naming you.
3
Question Mapping
FAQPage Markup on Your FAQ Sections
Maps each question on the page to its answer in a way the model can read directly. This is the type that lifts citation rates on direct question queries the most, because the answer layer can match the user's question to your structured Q-and-A and lift the answer verbatim. Ship this on every page that has real FAQs.
4
Author Identity
Person Markup on Author Bio Pages
Builds a structured profile for each author: name, job title, organization, credentials, links to verified profiles. The answer layer uses this to evaluate whether the author behind a piece is a credible source, which decides whether the citation gets surfaced or filtered. Without it, the author byline is a string the model has nothing to attach credibility to.
5
Commerce Identity
Product Markup on Catalog Pages
For e-commerce sites, the type that lets the answer layer surface specific product details (name, price, availability, brand) in AI search answers. Lifts citation rates on product-comparison and shopping-intent queries. For non-commerce sites this slot can stay empty.
Types 1 and 2 Do the Heavy Lifting
Organization markup and BlogPosting markup with author are the 2 that lift attribution the most. Sites that ship those 2 cleanly see real movement on AI search citation rates. FAQPage, Person, and Product compound the effect. Bucket B and Bucket C add little or nothing on top.
The order is the spend plan. Ship Organization first because every other type points back to it. Add BlogPosting with author on every editorial page. Wire FAQPage on the pages that have real FAQs. Add Person for author bios. Add Product if you are an e-commerce site. The first 4 types cover almost every business; the 5th only matters for commerce.
5 Mistakes That Waste Engineering Time on Structured Data
The most common reasons a structured-data investment fails to lift AI search visibility are not in the spec; they are in the operational layer that maintains the markup once it ships. These 5 are the ones we see most often when reviewing existing client implementations.
Shipping Markup Without Validation Monitoring
Structured data is a small piece of JSON sitting inside your HTML, and a single deploy can break it without anyone noticing. Sites that ship the markup once without setting up recurring validation end up with broken or malformed structured data within a quarter, which the answer layer treats as worse than no markup. The visible piece is the JSON; the work is the recurring check that catches when it breaks.
Set-and-Forget on a Site That Keeps Changing
When the site's content, author list, or organization details shift, the structured data needs to reflect that. Sites that ship once and never review let the markup drift from the underlying truth, which the answer layer eventually catches and stops trusting. The set-and-forget pattern is the second-most-common failure mode after broken validation, and it is the harder one to spot because the markup still looks valid even when it is wrong.
Adding Every Type the Spec Includes
"More structured data is better" is the most expensive false premise in this category. Shipping types from Bucket C inflates the HTML payload, adds maintenance surface, and does nothing for AI search citation. Teams that try to cover the spec end up with a fragile layer that breaks on every deploy and is twice as costly to maintain as the 5-type Bucket A version that would have done the work.
Marking Up Pages With Nothing Citable on Them
Structured data is the wrapping; the content underneath is what gets cited. Pages that are generic explainers with no first-party substance gain nothing from being marked up with BlogPosting and Person; the answer layer reads the markup, looks at the content, and skips both. Spend the markup investment on the pages that carry the substance worth citing, not on lifting empty pages into the candidate set.
Treating It as a Plug-In Instead of a Layer
A CMS plug-in that adds structured data automatically gets the basics right and gets the judgment wrong. The plug-in does not know which author should be associated with which page, which FAQ is real and which is filler, which product page deserves Product markup and which is a category landing page. The plug-in ships the shape; the layer underneath needs to be reviewed by someone who knows the content. Sites that lean only on the plug-in ship markup that looks valid and points at the wrong substance.
Notice the pattern: every one of the 5 is an operational mistake, not a spec mistake. The structured data itself is small. The work that decides whether it pays back is the validation, the review, the alignment with content, and the maintenance through every site change. Sites that ship a plug-in and walk away land in 1 of these 5 failure modes within a quarter. Sites that treat the markup as an operational layer with monitoring and review keep the citation lift compounding instead.
3 Cases Where Generic Structured Data Is Genuinely Enough
Not every page on your site needs careful markup. Some pages exist to be found, parsed, and used, with no citation goal attached. Recognizing these cases keeps the markup investment focused on the pages that actually pay back.
Transactional and Service Pages
Pricing pages, account settings, terms of service, refund policies. The plug-in default is fine; no custom BlogPosting or FAQ markup is worth the build. The outcome is the customer completing an action, not the answer layer citing the page.
Internal and Utility Pages
Login pages, password resets, sitemap pages, error pages, anything that exists for site operation rather than reader value. Default markup is fine; custom markup is overkill. These pages were never going to be AI search citations regardless of what JSON you wrap around them.
Image-Only or Visual Pages With No Editorial
Gallery pages, image archives, portfolios with light captions. The structured data investment is wasted here because there is no text content for the markup to attribute. If the page later evolves into an editorial piece with real substance, add the markup then.
The Forward Read
Structured data adoption is going to consolidate over the next 2 years toward the 5 types in Bucket A. Bucket B will stay relevant for traditional rich results in Google search but will not gain new ground in AI search. Bucket C is fading as engines stop spending parsing cycles on types that add no signal. Sites that focus their structured-data investment on Bucket A and treat the layer as a maintained piece of operational infrastructure compound across the next 2 years. Sites that ship a kitchen-sink plug-in pay maintenance cost on a layer the answer engines mostly ignore. The 2 strategies look the same on day 1; by 2027 they are visibly different in AI search citation rates.
5 Questions Before You Ship a New Markup Type
Before adding a new structured data type to your site, these 5 questions decide whether the work will pay back or sit in a layer the answer engines ignore. Ask them at the planning stage.
Is the Markup in Bucket A?
If the type is Organization, BlogPosting, FAQPage, Person, or Product, the answer is probably yes and the work is worth doing. If it is anything else, the honest answer is to skip it for AI search and add it only if a non-AI use case requires it.
Is There a Real Author or Real Substance Behind the Page?
BlogPosting markup with a named author attached to a page of generic explainers is dressing on an empty plate. The answer layer reads both. Spend the markup investment on pages that carry first-party content, named authors, and defended positions. Skip pages where the markup would point at substance that does not exist.
Does the Markup Match What the Page Actually Says?
Misaligned markup, where the JSON says one thing and the page body says another, is the worst case. The answer layer catches the mismatch and stops trusting the rest of your structured data on the site. Confirm the markup reflects the page truth and not a wishful version of it before shipping.
Is There an Operational Layer Underneath?
Validation monitoring, recurring review against content changes, alerts when a deploy breaks the JSON. The markup is small; the operational layer that keeps it correct over time is the engagement-grade work. Without that layer, the shipment is a one-time investment that decays. With it, the layer compounds across every site change.
Will the Markup Still Be Right 12 Months From Now?
Author lists shift, organization details change, FAQs evolve, products get added and removed. The markup needs to reflect those shifts. Pages where the underlying entity is unstable should either get a thinner markup that survives the change, or a maintenance plan that updates the JSON when the underlying truth moves.
Before and After: a Page With and Without the Right Markup
The cleanest way to see what structured data actually does for AI search is to look at the same page rendered with and without the right markup. Same content, same author, same audience. The difference is what the answer layer can do with it.
Before and After
A Real-Content Page Without Bucket A vs the Same Page With It
Without Bucket A Markup
In AI Overviews. Content paraphrased without citation, attributed to no one in particular.
In ChatGPT. Page may be referenced as "a website" with no organization or author named.
In Perplexity. Page may appear in citations but without the author or organization visible to the reader.
In Google's classic search results. Misses rich-result eligibility for FAQ and author cards.
Maintenance cost. Low, because the layer does not exist.
Operational risk. The page is unverifiable to the answer layer; trust signals are weaker than they should be.
With Bucket A Markup
In AI Overviews. Cited with the organization name and the author named.
In ChatGPT. Page attributed to the named author and the organization they work for.
In Perplexity. Surfaced as a primary source with author credentials visible to the reader.
In Google's classic search results. Eligible for FAQ rich results and author cards.
Maintenance cost. Modest, paid against a layer that is monitored and validated.
Operational risk. Low, because the markup is reviewed against content changes on a recurring schedule.
The Right-Hand Column Is the Whole Investment
The content is the same in both columns. The structured data is what changes the answer layer's behavior. The maintenance cost is the price of staying in the right-hand column over time. Sites that ship the markup once and skip the maintenance drift back into the left column within 2 quarters.
The right-hand column is what the technical layer delivers. The left-hand column is what the absence of that layer looks like over time. The same content underneath, served the same way, with very different behavior in the answer layer depending on whether the markup is correct, complete, and maintained.
Frequently Asked Questions
Does AI search actually read structured data, or is it all about page content?
Both. The answer layer reads the page content to decide whether the substance is worth citing, and reads the structured data to decide who to attribute the citation to. Structured data does not invent citation-worthy content; it makes sure the citation that does happen is correctly attributed to your organization and author. The 2 layers complement each other: content drives citation, markup drives attribution. Sites that get both right show up cleanly in AI search citations; sites that get only one right show up with their content paraphrased and someone else credited.
If I already have a CMS plug-in that adds structured data, do I need to do anything else?
Probably yes, and this is the most common gap we find when we audit existing sites. The plug-in covers the spec mechanics: it generates valid JSON in the right places. What it does not do is align the markup with the actual substance on each page, attribute the right author to the right piece, decide which FAQs are real versus filler, or maintain the layer through content changes. That alignment work is the engagement value; the plug-in is the obvious piece. Sites running on a plug-in alone usually have valid markup pointing at the wrong substance, which the answer layer catches and treats as a weaker signal than markup with no errors.
How much does adding the right structured data lift AI search citations in practice?
Variable but real. For sites that already publish first-party content and add Bucket A correctly, we see meaningful lifts in attribution clarity within 4 to 8 weeks, with the steepest gains on FAQPage-rich pages and on pages where named-author content was previously attributed to "the website" rather than a person. The lift on sites without first-party content underneath is small to zero, because the markup is wrapping nothing the answer layer can cite. The structured data lift is a multiplier on the content underneath, not a replacement for it.
Does the markup format matter? Should we use one syntax over another?
Structured data placed in the page head as JSON is the format that AI search engines read most reliably in 2026. Other syntaxes (Microdata, RDFa) still work for search engine compatibility but are read less consistently by AI search retrieval, and the maintenance pattern for both is harder than for JSON. The format question matters less than the alignment question; the markup that exists in the head has to reflect what is on the page, regardless of how it is written.
How often does structured data need to be reviewed once it is live?
Quarterly at minimum for review; daily for automated validation. The validation check catches the breakage that comes from deploys, content management changes, and theme updates; the quarterly review catches the drift that comes from author lists shifting, FAQs evolving, and organization details changing. Sites that wire both into the same operational cadence as their AI search measurement stack keep the layer aligned with content; sites that ship the JSON once and walk away end up with markup the answer layer no longer trusts within a year. The recurring layer is where the value lives; the one-time build is the entry cost.
Does the structured data work alongside llms.txt or do we have to pick one?
Yes, and it should be wired into the same operational layer as the rest of your AI search technical infrastructure. The llms.txt file points the model at your strongest pages; the structured data on those pages tells the model who you are and who wrote the content. The 2 layers reinforce each other. Sites that ship one without the other leave half the signal on the table. We treat both as part of the same technical engagement so the operational cadence (validation, drift detection, recurring review) covers both files together rather than running on separate schedules.
Can Entexis own the structured data layer for our site?
Yes, that is exactly the work we do as part of a broader AI search technical engagement. The build is the small part: writing the JSON, placing it in the head, validating against the schema. The operational layer is where the engagement value sits: monitoring for validation breakage on every deploy, reviewing markup alignment when content changes, catching drift between the JSON and the page truth, refreshing organization and author details when the business shifts, and feeding the changes back into the recurring AI search measurement stack so the layer can be evaluated against actual citation outcomes. We ship the same layer on our own site and have the operating cadence to know which patterns hold up and which fall apart in production. If your structured data has been shipping but the citation lift has not materialized, the answer is almost always the operational layer underneath, not the markup itself.
For the broader thesis behind this, why first-party data is the AI search moat and why structured data only helps when the content underneath is worth citing, the anchor piece is here: Why First-Party Data Is the AI Search Moat.
The most important thing to take from this is the reframe. Structured data is not a checklist of markup types to add to your site. It is a small layer of code that tells the answer layer who you are and what you publish, paired with an operational layer that keeps the code aligned with the content underneath. Ship Bucket A correctly, maintain it through every site change, and the citation attribution moves in your favor. Ship the kitchen-sink version and the maintenance cost catches up to you while the answer engines mostly ignore what you added.
Want Structured Data Done Right and Maintained Properly?
At Entexis, we build the structured data layer for clients as part of a broader AI search technical engagement. The visible piece is the JSON in the page head; the engagement is the operational layer underneath: validation monitoring on every deploy, recurring review when content shifts, drift detection between the markup and the page truth, and integration with the rest of the AI search measurement stack so the layer is evaluated against actual citation outcomes. We run the same layer on our own site so the patterns are something we already practice. If your structured data has been shipping but the citation lift has not arrived, the answer is almost never another type from the spec. It is the operational layer that keeps what you already have honest. Start the conversation with Entexis.
Ready to Win AI Search?
Manual SEO cannot keep pace with GEO and AEO. We build the workflows and automation that keep your brand visible across AI answer engines. Tell us what you need.
We'll get back within one business day.
Thank You!
We've received your message and will get back to you within one business day.
