The complete schema markup guide for AEO: FAQPage, Product, Organization
· PION
PION explains how to apply schema markup for AEO, covering BlogPosting, FAQPage, BreadcrumbList, Organization, and Product JSON-LD, along with practical validation tools.
AI search doesn't read a page whole and summarize it. It picks out only the fragments of fact it needs for an answer. For that extraction to be accurate, the page has to declare itself in a machine-readable way: "this is the publishing entity, this is a question, this is an answer, this is a price." schema markup is exactly that declaration.
Put a JSON-LD block written in schema.org vocabulary in the page HEAD. For content articles, use BlogPosting, FAQPage, and BreadcrumbList as a set of three; for company sites, place Organization, WebSite, and Service (or Product) globally. The implementation format has consolidated to JSON-LD alone. Microdata and RDFa survive only in the standards documents but are finished in practice, so for a newly built site there's no reason to even look at them.
Why schema is the minimum qualifying condition for AEO
schema is not a device that pushes up your visibility. It's the entry ticket that gets your name onto the list of citation candidates. When ChatGPT or Perplexity composes an answer, it decides which sentences from this page to cite, and with plain HTML alone the basis for that judgment is hazy. That's because it isn't nailed down in tags what question this Q&A answers, who the publisher is, or how much the product costs.
In a controlled experiment Search Engine Land ran in September 2025, a case was reported in which, of two pages with identical content, only the one with well-crafted JSON-LD appeared in Google AI Overviews (AI summaries). The same pattern appears in practice. When you tear apart pages with a citation rate of 0 on a category's core prompts, in most cases they either have no schema at all, or they have it but the company information is inconsistent from page to page.
But don't misunderstand. Adding schema doesn't make you appear in answers automatically. Without it you're excluded from consideration entirely; only with it do you finally make the candidate pool. From there, what separates the visible ones is a next-stage question: how well the content answers the question and the company's trustworthiness.
Content articles: BlogPosting + FAQPage + BreadcrumbList as a set of three
For a single blog or guide page, bundle the three types together. Because each of the three handles a different signal, attaching only one leaves you with half the job.
| Type | Signal handled | Fields you must fill |
|---|---|---|
| BlogPosting | Who, when, and on what topic the article is | headline, datePublished, dateModified, author, publisher, mainEntityOfPage |
| FAQPage | The question–answer pairs on this page | Question inside mainEntity[] → acceptedAnswer(Answer) |
| BreadcrumbList | The article's location within the site | position, name, item of itemListElement |
Don't leave dateModified blank. AI answers give citation priority to the most recent articles. If yours looks years old, it is at a disadvantage. Even if you didn't heavily overhaul the wording, if you've reviewed the content once, it's right to bump the date up to that point in time.
FAQPage has the most direct AEO effect of the three. If you follow schema.org's FAQPage definition (putting Question items into the mainEntity array and connecting an acceptedAnswer to each Question), each question-and-answer pair becomes a finished answer that AI can lift and use as is. There's a principle, however, that Google Search Central's FAQPage documentation nails down: mark up only the Q&A actually visible in the body text. Slipping a question that isn't on the screen into the schema alone is a policy violation.
BreadcrumbList is inconspicuous, but it's a waste to skip it. AI engines use this value to grasp the site structure, and the Knowledge Panel uses it to display the source path. It's an item with good return on effort: you're done once you just write out position, name, and item in order.
For reference, PION's own blog automatically attaches these three when an article is published. When you wrap the body FAQ in a className="faq-section" container, the builder scrapes the questions and answers and injects the FAQPage JSON-LD into the page.
Company sites: Organization + WebSite + Service/Product
Core pages like the home, about, services, and products pages need their own schema that registers the company itself as a single entity. Separate from the per-article schema, this is a layer you lay down across the whole site.
The key field in Organization is sameAs. Anyone fills in name, url, logo, and description. The catch is sameAs. If this array is empty, AI has no reference point to check whether "that company at getpion.com" and "that company appearing on LinkedIn and in press coverage" are the same place, so the company name may appear inconsistently when it cites you. That said, just dropping in LinkedIn, Crunchbase, and article links isn't enough either. If the company name, domain, and logo are all over the place on the very pages you linked to, the effect dies. This field works only when external sources consistently use the same name.
WebSite is metadata for the domain itself. If you include SearchAction, a within-site search box can appear in the Knowledge Panel, and the publisher connection ties it to the BlogPosting of individual articles.
Whether it's Service or Product is decided by your business model. A marketing agency like PION is Service; an e-commerce brand that sells goods is Product. Making this choice carelessly costs a lot. For example, to be cited in a prompt like " how much is the cream", you have to fill in Product's sku, brand, offers, and aggregateRating in full. If it's Service, you put in provider (a reference to Organization), areaServed, serviceType, and hasOfferCatalog.
Where and in what form to place it
The standard is to place JSON-LD in the page HEAD. It works if you put it at the end of the BODY too, but it needs to be in the HEAD for the crawler to catch the metadata first, up front in the document. When you place multiple schemas on one page, bundle them in a graph or lay them out side by side, each in its own <script type="application/ld+json"> block.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How do I apply schema markup for AEO?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Insert a JSON-LD block into the page HEAD and ..."
}
}
]
}
</script>
Follow two rules during operation:
- Text in the schema = text in the on-screen body. The moment you fill the schema with a sentence that isn't in the body, it's a Google policy violation, and your attempt to do well comes back as a penalty.
- Link the entities to each other with @id. When Organization, WebSite, BlogPosting, and Person reference each other via @id, the AI engine recognizes the whole site as one connected bundle of entities. Without references, it perceives the same site as scattered pages.
Validation: deploy only after passing both tools
Once you've written the schema, be sure to pass it through two tools before deploying. The tools serve different purposes, so you can't rely on just one.
- Google Rich Results Test shows the rich result types Google recognizes, along with errors and warnings, when you enter a URL or code snippet. It's the standard for Google's display policy.
- Schema.org Markup Validator checks the grammar of the standard vocabulary itself. It catches vocabulary errors that the Rich Results Test can't.
Passing both tools doesn't mean you'll appear in AI answers. Passing validation only means the grammar is correct; actual citation is the next matter. So when the agency PION modifies a client site, after checking once with the two tools, it throws the category's core prompts at the actual AI engines (ChatGPT, Perplexity, Gemini) and verifies through follow-up measurement how the citation rate moves. Because schema's results aren't captured immediately but are reflected in the next indexing cycle, PION makes re-measurement at 2–4 week intervals a standard procedure.
Frequently asked questions
How do I apply schema markup for AEO?
Put a JSON-LD block written in schema.org vocabulary in the page HEAD. For content articles, use BlogPosting + FAQPage + BreadcrumbList as a set of three; across the whole site, place Organization + WebSite + Service (or Product). The text inside the schema and the on-screen body text must match exactly, and you deploy only after passing both the Google Rich Results Test and the Schema.org Validator.
How do I write the FAQPage, Product, and Organization schemas?
For FAQPage, put Question items into the mainEntity array and connect an acceptedAnswer(Answer) to each Question. For Product, you have to fill in sku, brand, offers, and aggregateRating for it to qualify for price and rating citations. For Organization, fill in name, url, logo, description, sameAs, founder, and foundingDate, and use sameAs to attach external reference points like LinkedIn, Crunchbase, and press coverage so the identity of the company entity is confirmed.
Do I have to write schema markup only in JSON-LD?
For new sites in 2026, use JSON-LD alone. Microdata and RDFa remain in the schema.org standard, but Google has nailed down JSON-LD as the recommended format, and the older formats are effectively no longer used in practice. JSON-LD also has the advantage that, being a script block separated from the HTML body, it has the lowest risk of the schema breaking even when you edit the content.
If I apply schema markup, will my content appear in AI answers right away?
It won't appear right away. schema is only a gate that opens citation eligibility; actual visibility is decided by how well the content answers the question, the trustworthiness of the company entity, and the site's authority. Because the AI engines' index refresh cycle is 2–4 weeks, you need to re-measure around a month after deploying the schema to capture the change.
Where do I validate schema markup?
Use both tools: the Google Rich Results Test and the Schema.org Markup Validator. The tools serve different purposes: the former is the standard for Google's display policy, the latter the grammar standard for schema.org's standard vocabulary. Deploy only after resolving all errors and warnings from both tools, and check again that the text inside the schema matches the on-screen body text exactly.