Structured data for AI search: describe facts, validate meaning

Start with the visible entity

Identify whether the page describes an organisation, service, article, product or another supported entity. Choose types because they match the real content, not because a competitor emits them. A commercial service page can describe an actual Service and provider without inventing an Offer price. An editorial Article needs truthful authorship and meaningful dates. Breadcrumbs should match the user’s real route through the site.

Build a factual validation matrix

For each field record the visible source, responsible owner and the validation rule. Check business name against approved identity, service scope against the page, URL against canonical and language against the actual copy. If legal address or professional credentials are unverified, leave them out until resolved. A syntactically valid JSON-LD object can still mislead by describing facts the visitor cannot verify.

Separate general vocabulary from Google features

Schema.org types and Google-supported rich-result features are different layers. Test relevant eligibility in current vendor documentation rather than assuming every schema type receives a feature. FAQPage is not a general promise of richer results for an agency site. Google’s AI guidance does not require special AEO markup. Readable HTML and useful evidence remain necessary.

Review after publication

Inspect the served source, parse every JSON-LD block and compare properties with the rendered page. Recheck after template or service changes so old prices, contacts or claims do not persist in machine-readable output. Keep the validation result and publication date. Treat crawler selection and actual answer citations as separate observations; they are not schema-validation outcomes.

Continue with the related decision

• AEO learning paths
• llms.txt: a discovery aid, not a substitute for useful pages
• Discuss the scope of AEO and AI-search work