The schema stack that matters for AEO and GEO

Six schema.org types do most of the work for AEO and GEO: Organization, Person, Article (or BlogPosting), Product, BreadcrumbList, and FAQPage used as entity markup. Together they state who publishes the site, who wrote each page, what the page is, what it sells, where it sits in the site, and which questions it answers, in a form a machine can read without inferring any of it. Google says no special structured data is needed to appear in AI Overviews or AI Mode, so none of this is a ticket into an answer. It is a way of making facts that are already on the page unambiguous, and a way of removing contradictions between what the page says and what its markup says.

This post covers what each of the six types states and where it belongs, which rich results Google has retired so you can stop treating their markup as a reason, the rules that apply to all structured data, and how to audit what your site actually emits. It sits under Citability and entity signals: a GEO guide.

Does structured data matter for AI search at all?

It matters as a statement of fact, not as a requirement. Google’s guidance on AI features is direct: there is “no special schema.org structured data that you need to add” to appear in AI Overviews or AI Mode, and the one structured-data practice it lists is “making sure your structured data matches the visible text on the page.” Google’s introduction to structured data says it uses the structured data it finds “to understand the content of the page,” and to gather information about the web and the world more generally.

Outside Google, how assistants use JSON-LD is not something we could verify against vendor documentation, so this post treats it as undocumented. What can be said without any vendor claim is that JSON-LD is the one place on a page where the publisher, author, date, price, and position in the site are stated as named fields instead of being inferred from layout. When that statement is correct and agrees with the visible page, it removes ambiguity. When it is wrong or contradicts the page, it adds some.

Which six types matter?

The right column is about Google’s visible search features only. It is there so nobody adds or removes markup on the belief that a rich result depends on it.

Organization: who is behind the site?

Organization markup identifies the publisher as one entity, with a name, URL, logo, and sameAs links to the profiles that confirm it. Google says it has no required properties and belongs on the home page or one page that describes the organization. Its job in this stack is to be the node everything else points at: an article’s publisher and a WebSite block’s publisher should both reference it by @id, not redefine it. Organization schema and sameAs covers it in full.

Person: who wrote this?

Person markup names the author of a page as a person with their own identity, as distinct from the company. Google’s Article documentation recommends author with author.name and author.url, where the URL points to a page that uniquely identifies the author, such as a profile or bio page, and says sameAs can be used as well. It also says to “use the Person type for people, and the Organization type for organizations,” and to list multiple authors as separate entries. Author bylines and Person schema covers the byline, the author page, and the markup together.

Article: what is this page?

Article markup states that the page is an article and carries its headline, dates, author, and image. Google’s Article documentation says there are no required properties and recommends author, datePublished, dateModified, headline, and image. The dates are where Article markup most often goes wrong, because templates stamp them at build time; Freshness signals and honest dateModified covers keeping them true and consistent with the visible date.

Product: what is for sale, and at what price?

Product markup states a product’s name and, through offers, its price, currency, and availability. For product snippets Google requires name plus one of review, aggregateRating, or offers; shopping pages are covered by its merchant listing documentation. Prices are one of the most frequently asked facts and one of the most frequently mis-rendered, often as an image or behind a script, so a correct Offer that matches the visible price is a direct way to state it as data. Product pages that answer engines can quote covers the visible side.

BreadcrumbList: where does this page sit?

BreadcrumbList states the page’s position in the site hierarchy as an ordered list of named URLs. Google’s breadcrumb documentation describes the trail as indicating “the page’s position in the site hierarchy,” requires at least two list items, and, since January 2025, describes the feature as available on desktop. It still belongs in the stack on mobile-heavy sites, because the value here is the hierarchy it states, not the display.

FAQPage: entity markup, not a rich-result tactic

FAQPage markup states that a page contains specific questions with specific answers. Treat it as that and nothing more. Google narrowed FAQ rich results to well-known government and health sites in August 2023, added a deprecation notice in May 2026 saying the feature would no longer appear in Search from 7 May 2026, and removed the documentation in June 2026. There is no rich result left to chase.

What remains is the reason to have a Q&A section at all: a question heading followed by a direct answer is a pre-chunked passage. If the page has a real, visible Q&A section, marking it up states the pairs explicitly. If it doesn’t, adding one to justify the markup is filler. FAQ sections: leverage or filler makes the case for when a Q&A section earns its place.

Which markup can you stop adding for rich results?

Anything whose rich result Google has retired. The record, from Google’s own blog and changelog:

Google said in 2023 that there’s “no need to proactively remove” markup whose rich result is gone, and its June 2025 post notes that use of those types outside Google Search is unaffected. So the rule is not “delete it.” The rule is: don’t add these types on the strength of a feature that no longer exists, and don’t count their presence as progress in an audit. Before planning work around any rich result, check that it is still in Google’s search gallery.

What rules apply to every type?

Three, and they matter more than which types you pick:

1. Mark up only what’s visible. Google’s general guidelines say: “Don’t mark up content that is not visible to readers of the page.” Markup that is not representative of the main content, or is potentially misleading, can make the page ineligible for rich results, and a structured data manual action removes that eligibility.
2. Describe one entity graph. One Organization node with an @id, referenced from every Article and WebSite block. Plugins that each emit their own Organization block produce several publishers with slightly different names.
3. Valid beats present. A block that fails to parse states nothing, and a Product with no offers or an Article with no headline is a partial statement. Fix what you have before adding new types.

How do you audit what your site actually emits?

By hand, take one URL per template and paste it into Google’s Rich Results Test and the Schema Markup Validator. List the types each template emits, flag any duplicates, and compare the key values with the visible page: headline against H1, dateModified against the visible date, offers.price against the displayed price, author.name against the byline.

Across a site, a crawler’s custom extraction does the same without a terminal. Extract every "@type"\s*:\s*"([^"]+)" match from the page source, plus the specific values you want to compare against visible text, and export. A pivot table of type by URL pattern shows which templates emit what. A COUNTIF on Organization per URL finds competing publisher blocks, and a column comparing the JSON-LD price to an XPath extraction of the visible price finds contradictions.

From a terminal, the types on one page:

curl -s "https://example.com/page/" | grep -oE '"@type"[[:space:]]*:[[:space:]]*"[^"]+"' | sort | uniq -c

GEOBee reads each page’s JSON-LD, reports the type it finds, and validates required fields: an Article needs a headline, a Product needs a name and offers. Missing or broken markup shows as None, Invalid, or Partial in the Schema column. Two signals use it: Answer-relevant schema in the AEO lens (10 of 100) and Entity clarity in the GEO lens (15 of 100), both listed in the three lenses. The detected types are FAQPage, QAPage, HowTo, Article, BlogPosting, Product, Organization, Person, WebSite, and BreadcrumbList; detecting HowTo doesn’t mean it earns a Google feature, which the table above makes clear. AI Overviews eligibility: every technical requirement covers the requirements that do apply.

To see which schema types every template on your site emits, and which are invalid or partial, download GEOBee and crawl it during the 7-day trial.