How to Optimize Schema Markup for AI Engines, Not Just Google

Four properties do a disproportionate amount of work for AI-engine extraction: sameAs, description, mainEntity, and citation. sameAs resolves entity identity by linking your organization or person to authoritative external records - Wikidata, LinkedIn, Wikipedia, Crunchbase. description gives a model a plain-language summary it can use verbatim or paraphrase for attribution. Without these two, a retrieval system is working from raw page text alone, which raises the odds it attributes the answer to a more clearly-structured competitor instead.

mainEntity and citation operate at the document level. mainEntity tells a model what the page is fundamentally about, not just its type but its actual subject - a WebPage with mainEntity pointing to a specific SoftwareApplication entity gives a retrieval layer a clear subject anchor instead of making it infer the topic from prose. citation is underused and worth prioritizing: referencing the sources your content draws from signals that your page is a synthesized, sourced document rather than a raw, unsupported opinion.

json { "@context": "https://schema.org", "@type": "Organization", "name": "Acme Corp", "description": "Acme Corp builds inventory management software for mid-market retailers.", "sameAs": [ "https://www.wikidata.org/wiki/Q000000", "https://www.linkedin.com/company/acme", "https://www.crunchbase.com/organization/acme" ] }

Treat these four as your audit baseline before touching anything else: check whether every Organization and Person block on the site has sameAs and description populated, and whether your primary content pages declare mainEntity and use citation where they reference outside sources.

The step has no url, no name as a distinct field, no image. When an engine extracts a step-by-step answer, it pulls from the richest available structured source. If a competitor's HowTo nests each step as a HowToStep object with name, text, and url, their version has a real structural advantage even if your prose reads better to a human. The restructure is a one-time JSON-LD edit that pays off every time that query gets answered.

json { "@context": "https://schema.org", "@type": "HowTo", "name": "How to install the Acme plugin", "step": [ { "@type": "HowToStep", "name": "Download the plugin", "text": "Download the latest release from the Acme dashboard.", "url": "https://acme.example.com/docs/install#step-1" }, { "@type": "HowToStep", "name": "Activate the license key", "text": "Paste your license key into Settings > Plugins.", "url": "https://acme.example.com/docs/install#step-2" } ] }

For Article schemas, one worthwhile addition is mainEntity nested inside the WebPage wrapper rather than inside the Article block itself - the WebPage is what gets indexed, the Article is the content type sitting inside it. Pointing WebPage.mainEntity at the article's primary subject (a Thing, Organization, or SoftwareApplication) gives a retrieval system a subject anchor that survives content edits. Add dateModified as a sibling to datePublished - recency is a real signal, and a stale datePublished with no dateModified reads as an unmaintained page.

Keep the Article author block accurate and visible. Add sameAs only for profiles that represent the same person, and use knowsAbout only for topics the page can substantiate. Do not describe either property as an AI citation weight or expertise score.

Properties like about, mentions, and knowsAbout are the connective tissue between your page's primary entity and the broader entity graph a model has learned from. A schema block with several of these relationship properties gives a retrieval layer more structured data points to work with than a flat block listing only headline, author, and datePublished - a richer, well-formed local subgraph is simply more useful input than a handful of disconnected fields, independent of prose quality.

The most practical property to add for B2B content is about on Article blocks. Adding about with a nested array of Thing objects (each with @type, name, and ideally sameAs pointing to a Wikidata or Wikipedia URL) turns your article from a typed document into something closer to a mapped set of entities. When a model resolves a query about one of those named entities, your article becomes a more legible candidate because the relationship is explicit in the markup rather than something the model has to infer from prose.

For Organization schemas on a homepage or About page, knowsAbout and hasOfferCatalog are the most useful relationship properties. knowsAbout accepts either topic strings or Thing objects; using Thing objects with sameAs links to authoritative definitions is the stronger version. hasOfferCatalog with nested Offer objects (each with name, description, and url) gives a structured product-to-entity mapping instead of leaving that relationship buried in prose.

One caution worth stating plainly: do not add relationship properties that are not true. knowsAbout populated with every keyword your content team wishes it ranked for is inconsistent with your actual page content, and a system that cross-references schema claims against visible text will simply treat the mismatch as a trust problem. Five to eight tightly-scoped knowsAbout values that genuinely mirror what your content covers in depth outperforms a long, aspirational list.

Conflicting schema types on the same page are one of the fastest ways to suppress AI citation. The specific failure mode: deploying both Product and ItemList at the root level of a single page - a common pattern on SaaS pricing or comparison pages - creates an ambiguous entity signal. A model parsing that page cannot cleanly determine whether the primary subject is one product or a list of products. Google's Rich Results Test often does not flag this, because Google's own systems resolve the ambiguity differently than an LLM's retrieval layer does - which is exactly why this class of conflict survives unnoticed for a long time.

The audit process is three steps: export every JSON-LD block from a page (browser developer tools or a crawler's structured-data report both work), list every @type present, and flag any page where two or more types sit at the same semantic level. Article nested inside WebPage is fine - that is a parent-child relationship, not a conflict. Product sitting alongside ItemList at the root is a conflict. Once flagged, pick the type that matches the page's dominant purpose and demote the other to a nested reference - a pricing page is primarily a Product page, and its comparison table can be represented as an ItemList nested inside the Product's offers property instead of competing with it at the root.

Redundant markup - the same entity described twice with slightly different property values - is a subtler problem, usually caused by a CMS generating automatic schema alongside a manually written JSON-LD block. The two blocks may agree on name but disagree on description or url. A system encountering conflicting values for what should be the same entity has reason to discount both rather than pick one. The fix is to disable CMS-generated schema wherever a manual JSON-LD block already exists for that page - most major CMS platforms have a per-page toggle for this.

After fixing conflicts, run a re-crawl check: submit the updated URLs through Google Search Console's URL Inspection tool and confirm rich-result status, then query each page's primary topic in an AI engine and note whether your domain shows up as a source over the following days. If it does not, check for a noindex directive or a robots.txt block that keeps an AI crawler from reaching the page in the first place - a schema fix cannot help a page the crawler cannot read.

There is no schema.org type built specifically for "mark this passage for an LLM" - be skeptical of any guide that names one, since inventing schema vocabulary is a real risk in this space and an invented type will simply be ignored by every real parser. What does exist and is worth using is speakable, a real schema.org property that takes a SpeakableSpecification pointing to a CSS selector or XPath for the specific passage you consider the canonical, extractable answer on the page. It was built for voice-assistant text-to-speech extraction, but the underlying idea - explicitly flagging your single best passage instead of leaving a model to guess - is exactly the control worth having for AI-answer extraction too.

json { "@context": "https://schema.org", "@type": "WebPage", "speakable": { "@type": "SpeakableSpecification", "cssSelector": [".answer-summary"] } }

The same discipline that would apply to any passage-marking approach applies here: mark one passage per page, not five or six - diluting the signal across multiple "most important" passages defeats the purpose. Pick the paragraph that most directly answers the page's primary search intent, the one you would want read aloud in a voice answer or pulled as a snippet, and keep it tight. A long, promotional, or hedge-filled passage is a worse extraction target than a short, direct one, regardless of what markup wraps it.

Verify this the same way you would verify any schema change: query your target questions in the AI engines you care about over the following weeks, and check whether the extracted text lines up with the passage you marked. If it consistently does not, the passage itself is probably the problem - too long, too promotional, or inconsistent with the surrounding page - not the markup.