Schema Markup for AEO: What Matters and What Doesn’t

Schema markup matters for AEO in exactly one way, which is stating unambiguously which entity your brand name refers to, and it does not matter at all as a ranking lever for AI answers. Google’s documentation says directly that there is no special schema.org structured data needed to appear in its AI features, and no other engine publishes a proprietary vocabulary either, so anybody selling you AEO schema is selling something that does not exist.

That leaves a narrower and more useful question than the one usually asked. Not which schema types rank, because none of them do, but which ones remove ambiguity about who you are.

What structured data actually does here

Three things, and only the first is specific to answer engines.

• It resolves identity. A machine-readable statement that this name refers to this organisation, linked to records elsewhere describing the same entity. This is the part that matters for AI answers and the part almost nobody implements.
• It qualifies you for rich results. Ordinary search features, unrelated to AI answers, still worth having.
• It states facts without interpretation. Founding date, location, what you sell. Removes the need for a system to infer them from prose, and inference is where errors enter.

Notice what is not on that list. Structured data does not make a passage more quotable, does not improve retrieval ranking, and does not create eligibility for anything in Google’s AI surfaces that indexing alone did not already provide.

That distinction is worth holding onto when a proposal arrives, because it separates two claims that sound similar and are not. Saying structured data helps a system understand who you are is accurate and useful. Saying it improves your chances of being cited is a claim nobody has evidence for, and it is the claim most often made. The honest position is that markup removes a specific obstacle rather than providing a specific advantage, and removing obstacles is worth doing precisely because it is cheap.

The types worth implementing, ranked

Type	What it does for AEO	Worth it?
Organization with sameAs	Resolves your identity and links it to authoritative records	Yes, this is the whole game
Article with a real author	Attaches content to a named person rather than a faceless brand	Yes, cheap and useful
BreadcrumbList	States where a page sits in your structure	Yes, trivial to add
Product or SoftwareApplication	Describes what you sell in machine-readable form	Yes if you sell a discrete product
FAQPage	Marks up question and answer pairs	Only if the questions are genuinely on the page
HowTo	Marks up step sequences	Marginal, and rich result support has narrowed
Anything described as AEO schema	Nothing, because it does not exist	No

The block that matters, in full

Everything above the fold in importance is here. This is an Organization block with the identity links filled in, which is the version almost nobody ships.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Clausewise",
  "legalName": "Clausewise Software Ltd",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "description": "Contract review software for mid-market legal teams.",
  "foundingDate": "2019",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/clausewise",
    "https://github.com/clausewise",
    "https://www.crunchbase.com/organization/clausewise"
  ]
}

The sameAs array is the payload, since it points at the records a knowledge graph already trusts. Everything else in that block is a fact a machine could probably infer from your homepage. The identity links are the part it cannot infer and the part that resolves ambiguity, and crawl data consistently shows them sitting empty on the overwhelming majority of sites that have otherwise implemented structured data properly.

Two rules on top of the syntax. Keep @id stable permanently, because it is the anchor every other block references. And never state a fact in markup that a human cannot see on the page, since Google’s structured data policies treat that as spam and the penalty is worse than omitting the markup entirely.

Connecting the article to a person

The second most useful block, and the one that gets treated as a formality. An Article with a real author, referencing the organisation entity by its stable identifier, ties your content to a named human and to a resolved company at the same time.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Contract review thresholds for mid-market legal teams",
  "author": {
    "@type": "Person",
    "name": "Jane Okafor",
    "url": "https://example.com/authors/jane-okafor/",
    "sameAs": ["https://www.linkedin.com/in/janeokafor"]
  },
  "publisher": { "@id": "https://example.com/#organization" },
  "datePublished": "2026-08-29",
  "dateModified": "2026-08-29"
}

The publisher reference pointing at the identifier from the first block is the detail worth copying. It connects every article you publish back to one resolved organisation rather than restating your company details on every page and hoping they are read as the same entity.

What to skip, and why

FAQPage on pages with no real questions. Marking up invented questions to game a rich result is a well-travelled road that ends badly. If the questions are genuinely on the page and genuinely asked, use it. Otherwise leave it.

Marking up everything. Coverage is not the goal. An accurate Organization block beats fourteen types implemented approximately, and every additional type is another place for markup to drift out of sync with the visible page.

Any file or vocabulary described as AI-specific. Google states no new machine-readable files are needed for its AI features. Treat a proposal built on proprietary AEO markup as information about the vendor.

Where the markup should live

A question that causes more confusion than it should. The organisation block is declared once, on a page that will never move, and every other page references it by its identifier rather than restating it.

Practically that means your homepage or a dedicated about page carries the full Organization declaration, and every article carries a lightweight Article block whose publisher points at that identifier. You end up with one authoritative statement of who you are and hundreds of pages agreeing with it, which is exactly the consistency a resolution system is looking for.

The failure pattern is the opposite. Every page declares its own full organisation block, the blocks drift apart as templates are edited, and a machine reading your site finds fifteen slightly different accounts of the same company. That is worse than declaring nothing, because inconsistency is itself evidence that the facts are unreliable.

Describing what you actually sell

Worth adding if you sell a discrete product, because it lets a system state what your software does without inferring it from marketing copy. Keep it short and keep every claim checkable.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Clausewise",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/product/",
  "publisher": { "@id": "https://example.com/#organization" },
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "GBP",
    "priceValidUntil": "2027-06-30"
  }
}

If you publish a price, publish the real one and keep it current. Stale pricing in structured data is worse than no pricing, because a machine treats it as a stated fact rather than an approximation, and it will repeat it confidently long after you have changed it.

What breaks, and how to spot it

Structured data is written once and then quietly degraded by ordinary site maintenance. Four failure modes account for most of what we find.

Template drift. Somebody edits a template, a field is dropped, and every page loses it at once. Nothing visibly changes on the page, so nobody notices for months.

Duplicate and conflicting organisation blocks. A theme emits one, a plugin emits another, and they disagree about your name or founding date. A system reading both has no way to choose, so it trusts neither.

Identifiers that move. A site migration changes the @id value and every reference pointing at it silently breaks. This is why keeping it stable permanently matters more than choosing a good one.

Markup describing a page that no longer exists. Content is rewritten, structured data is not, and the two now contradict each other, which is the specific condition Google’s policies treat as spam.

All four share a cause, which is that structured data has no visible failure state. A broken image is obvious to anybody loading the page. A broken sameAs array looks exactly like a working one, which is to say it looks like nothing at all, so it survives indefinitely unless somebody deliberately goes and checks.

The fix is a calendar entry rather than a tool. Validate after any template change, any migration, any plugin update that touches output, and once a quarter regardless. It takes about ten minutes and it is the difference between markup that works and markup that worked once.

Validate it, then check it again in a month

Two tools, both free. The schema.org validator checks your markup against the vocabulary itself, which is the stricter and more useful test. Google’s rich results test checks eligibility for its own features, which is a different question and worth running separately.

The re-check matters more than the first pass. Structured data is generated by templates, templates get edited by people who do not know what sameAs is for, and a block that validated in March is frequently broken by September. If you have a syntax reference to hand, json-ld.org is the canonical one.

One closing thought on proportion. Structured data is the part of this work with the best documentation, the clearest right answers and the smallest independent effect, which is exactly the combination that makes it dominate checklists. It is satisfying to complete and easy to verify. Neither of those is the same as being decisive, and a company with immaculate markup and a blocked crawler is invisible in precisely the same way as one with no markup at all.

---

None of this works if a crawler cannot reach the page in the first place, so if you have not done the access and rendering work yet, the technical playbook puts these steps in the order they actually need doing.

We publish our structured data audits as we run them, including the ones where everything validated and the company was still invisible. The newsletter is where those go out.