On this page · 11 sections
- What Google actually wrote, in its own words
- The 25 features Google's gallery actually lists
- What is worth shipping, with the JSON-LD
- The mechanisms Google says are actually at work
- What Google says to stop doing
- The one genuinely new surface: agents
- How to measure any of this
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. Google Search Central's generative AI optimization guide, last updated 10 July 2026, says it in one sentence: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add." The same page says Google Search ignores llms.txt files entirely, that content chunking is not required, and that AEO and GEO are, from Google's perspective, still SEO. Meanwhile the structured data gallery, last updated 15 June 2026, lists exactly 25 supported rich result features. FAQPage and HowTo are not among them. So the market has spent two years shipping JSON-LD for AI citations that Google says do not depend on it, while under-shipping the 25 types that still change what a result looks like. The two tools that actually verify any of this, the Rich Results Test and Search Console, cost $0. Here is what the guidance says, what to delete, and the JSON-LD worth keeping.
What Google actually wrote, in its own words
Three quotes carry the whole argument. All are from Google Search Central documentation, dated on the pages themselves.
From the generative AI optimization guide, last updated 10 July 2026, under a section headed "Mythbusting generative AI search: what you don't need to do":
"Overfocusing on structured data: Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search."
On llms.txt, from the same page: "You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them." It goes further: maintaining one "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them." That closes a question we examined earlier in does llms.txt help SEO on Google.
And on the terminology the industry has built businesses around: "From Google Search's perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO."
Read those together and the practical instruction is clear. Structured data is a rich results lever, not an AI citation lever. Both are worth having. They are not the same lever, and conflating them has produced a large amount of markup that does nothing.
The 25 features Google's gallery actually lists
Google's structured data gallery, last updated 15 June 2026, is the authoritative list of what markup can change in a result. It contains 25 entries: Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental, and Video.
Count the absences. FAQPage is not there. HowTo is not there. Both are still shipped on an enormous number of pages by CMS plugins that were written when those rich results existed. That markup is not a penalty. It is dead weight, and it produces validation noise that hides real errors.
The gallery also carries a caveat worth quoting before anyone promises a client a rich result: "The actual appearance in search results might be different." Eligibility is not entitlement.
| Markup | What it can still do in 2026 | What it will not do |
|---|---|---|
| Article | Title and larger-than-thumbnail image treatment in results | Make the page more likely to be cited in AI Overviews |
| Organization | Feed knowledge panels and attribution visual elements | Establish authority on its own |
| Breadcrumb | Show site hierarchy in place of the raw URL | Improve crawl coverage |
| Product | Show price, availability and review ratings | Substitute for a Merchant Center feed |
| FAQPage | Nothing, it is not in the gallery | Anything |
| HowTo | Nothing, it is not in the gallery | Anything |
| Video | Play control, key moments, live-stream labelling | Get an unindexed video into results |
What is worth shipping, with the JSON-LD
Four types cover most of what a content or services site needs. Everything below uses schema.org vocabulary in JSON-LD, which is the format Google recommends.
Article, for any editorial page:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data in 2026: 25 rich result types",
"image": ["https://example.com/hero-16x9.jpg"],
"datePublished": "2026-07-22T09:00:00+05:30",
"dateModified": "2026-07-22T09:00:00+05:30",
"author": [{
"@type": "Person",
"name": "Author Name",
"url": "https://example.com/team/author-name/"
}],
"publisher": {
"@type": "Organization",
"name": "Example Ltd",
"logo": {"@type": "ImageObject", "url": "https://example.com/logo.png"}
}
}
The author.url matters more than most teams treat it. It is the join between the article and a page that describes the person, which is what makes the byline resolvable rather than a string.
Organization, once, on the homepage:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Ltd",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://github.com/example"
],
"contactPoint": [{
"@type": "ContactPoint",
"contactType": "sales",
"email": "contact@example.com",
"telephone": "+91-00000-00000"
}]
}
BreadcrumbList, on every deep page:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{"@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/"},
{"@type": "ListItem", "position": 2, "name": "SEO and AI search", "item": "https://example.com/category/seo-and-ai-search/"},
{"@type": "ListItem", "position": 3, "name": "Structured data in 2026"}
]
}
The last item deliberately has no item property. It is the current page, and pointing it at itself is the most common breadcrumb error we see.
Product, for anything with a price:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Widget",
"image": ["https://example.com/widget.jpg"],
"sku": "EW-001",
"brand": {"@type": "Brand", "name": "Example"},
"offers": {
"@type": "Offer",
"url": "https://example.com/widget/",
"priceCurrency": "INR",
"price": "2499.00",
"availability": "https://schema.org/InStock"
}
}
One rule governs all four: the markup must match what a human sees on the page. Google's structured data guidelines treat mismatched markup as a violation, and the failure mode is a manual action, not a quiet downgrade.
The mechanisms Google says are actually at work
If markup is not the lever, what is? The guide names two systems by name.
Retrieval-augmented generation, which Google also calls grounding, relies "on our core Search ranking systems to retrieve relevant, up-to-date web pages from our Search index." So AI Overview eligibility runs through ordinary indexing and ranking, not a parallel pipeline.
Query fan-out is the second: "A set of concurrent, related queries generated by the model to request more information and fetch additional relevant search results." Google's own example for "how to fix a lawn that's full of weeds" includes fan-out queries such as "best herbicides for lawns" and "remove weeds without chemicals."
That second mechanism is where a lot of teams are about to make an expensive mistake. The obvious move is to publish a page per fan-out query. Google addresses it directly: doing so "primarily to manipulate rankings or generative AI responses in Google Search violates Google's scaled content abuse spam policy." It adds that "a high quantity of pages doesn't make a website higher quality or more relevant to users." Target selection beats volume, which matches what we found building a keyword selection framework for AI Overview click survival.
There is also a hard eligibility gate that has nothing to do with schema. A page "must be indexed and eligible to be shown in Google Search with a snippet," and separately "a site must be included in Search generative AI features in Search Console to be eligible for display in generative AI features on Google Search." That is a Search Console setting, and it is worth confirming before optimising anything else. The same control surface is covered in our note on the Search Console AI Overviews opt-out control.
What Google says to stop doing
The mythbusting section is unusually blunt for Search Central. Four practices are named and dismissed.
| Practice | Google's position | What to do instead |
|---|---|---|
| llms.txt and AI text files | "Google Search ignores them" | Nothing, unless another service you use reads them |
| Chunking content into small pieces | "There's no requirement" | Write at the length the subject needs |
| Rewriting content for AI systems | "You don't need to write in a specific way" | Write for readers; synonyms are understood |
| Seeking inauthentic mentions | "isn't as helpful as it might seem" | Earn coverage that survives spam systems |
| Overfocusing on structured data | "isn't required for generative AI search" | Ship it for rich results eligibility |
Google's positive instruction is a content one. It draws a line between commodity and non-commodity work, and gives examples: commodity content is "something like '7 Tips for First-Time Homebuyers'", which "is often based on common knowledge, which could originate from anyone." Non-commodity content is "something like 'Why We Waived the Inspection & Saved Money: A Look Inside the Sewer Line'", which provides "unique expert or experienced takes that go beyond common knowledge and the ordinary."
That distinction is the actual optimisation target, and it is a harder one than adding markup. It is also consistent with what we measured comparing ranking position against AI Overview citation data.
The one genuinely new surface: agents
The guide's last section is about AI agents, and it is the part most technical teams have not read.
Google describes how browser agents work against a site: they "may access your website to gather the data they need to complete these tasks, such as analyzing visual renderings (like screenshots), inspecting the DOM structure, and interpreting the accessibility tree."
None of those three inputs is JSON-LD. An agent reads what a screen reader reads. That reframes semantic HTML from an accessibility nicety into an agent-readability requirement, and it explains why Google's advice on semantic HTML sits under a link to agentic experiences.
Google also points at emerging protocols, naming the Universal Commerce Protocol and linking to ucp.dev, saying protocols like it "are emerging that will allow Search agents to do more." For merchants, that lands next to the standards work we mapped in the UCP, ACP and AP2 agentic commerce guide.
Notably, Google's stance on semantic HTML is not maximalist: "While it's not required to have perfectly semantic HTML (the web in general is not valid HTML, and Google can understand it), it's generally a good idea to try to use semantic HTML when possible."
How to measure any of this
Google names one report and warns about the alternatives. The Generative AI performance report in Search Console is the stated way "to measure how your content is performing in generative AI features on Google Search and Discover." We covered what that report does and does not contain in our review of the Search Console AI performance report.
The warning attached to it is worth reproducing: "Be wary of third-party tools that promise ranking success or claim to use 'internal' Google metrics. No third-party tool has access to our internal ranking or AI systems."
For markup specifically, validate with the Rich Results Test. Both it and Search Console are free, which makes the cost comparison against paid visibility tooling straightforward.
India-specific considerations
Three points change the calculus for Indian teams.
Currency and locale matter in Product markup. Use "priceCurrency": "INR" and a real rupee value that matches the page, because a mismatch between markup and visible price is the fastest route to a manual action. A widget listed at ₹2,499 must carry 2499.00 in the offer, not a converted dollar figure.
Local business markup is a separate feature from Organization in the gallery, and it drives knowledge panel details including hours and directions. For a Gurugram or Bengaluru services firm competing on city-modified queries, that is the higher-value of the two.
Personal data in markup deserves a second look. ContactPoint and Person blocks publish identifiers into a machine-readable format that is trivially scraped. Under the Digital Personal Data Protection Act 2023, publishing an employee's direct line as structured data is a decision someone should make deliberately rather than inherit from a CMS default. Use role-based contacts, not individuals.
FAQ
How eCorpIT can help
eCorpIT is a CMMI Level 5 certified technology organisation in Gurugram, and our senior engineering teams build and audit structured data for content, ecommerce and services sites. We audit existing markup against the current gallery, strip the types that no longer produce anything, implement Article, Organization, Breadcrumb and Product correctly against the visible page, and check the Search Console eligibility settings that sit upstream of all of it. If your site is carrying markup written for a version of Google Search that no longer exists, contact us.
References
Last updated: 22 July 2026.
