Skip to content
siterank.info
Sign in Start free

Technical SEO

Structured Data for AI and Search: What Actually Matters?

Schema.org is a real standard with real search uses and no documented role in AI citation. Here is where it earns its place and where the claims run out.

By ankitkumarvig@gmail.com Published September 9, 2026 Last reviewed September 9, 2026 Sources verified September 9, 2026 7 min read

Structured data occupies an odd position in GEO discussions. It is one of the few genuinely machine-readable things a page can carry, which makes it an attractive story: mark up your content, and the machines will understand you. The standard is real, Google's use of it is documented, and the honest assessment of its role in AI answer engines is that nobody has published one. This article separates the three.

What structured data is

Structured data is a standardised format for describing what a page is about and classifying its content. Schema.org is the vocabulary; JSON-LD, Microdata and RDFa are the syntaxes that carry it. Google supports all three and recommends JSON-LD, describing it as the easiest solution to implement and maintain at scale.

The vocabulary itself is an ESTABLISHED STANDARD. Schema.org is a published, versioned vocabulary maintained collaboratively by the major search companies, and it is used to describe entities and their relationships in a way that does not depend on how a page is laid out.

In practice that means a block like this in the page's HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/guide/#article",
  "headline": "A practical guide to X",
  "datePublished": "2026-04-02",
  "dateModified": "2026-08-19",
  "author": { "@id": "https://example.com/#/schema/person/asmith" },
  "publisher": { "@id": "https://example.com/#organization" }
}
</script>

Google states that JSON-LD can be read when it is dynamically injected into a page's contents by JavaScript or a CMS widget, which is why nearly every WordPress SEO plugin emits it from a template hook rather than asking authors to paste it.

What Google documents it for

Google's position is narrow and specific: structured data helps it understand the content of a page, and may make the page eligible for rich results — the enhanced presentations in search results. The word doing the work is "eligible". Google's intro documentation says explicitly that structured data does not guarantee a rich result; the markup must be valid and complete, and eligibility is decided by Google.

The general structured data guidelines add the rules that make the whole system trustworthy, and they are worth reading as policy rather than advice:

Guideline What it requires Consequence of breaking it
Content quality Marked-up content must be visible to readers of the page Rich result ineligibility
Relevance Markup must truthfully represent the page — no labelling woodworking instructions as recipes Ineligibility, manual action
Completeness All required properties for the feature type must be present Disqualified from that rich result
Location Markup goes on the page it describes Ignored
Specificity Use the most specific applicable Schema.org type Weaker interpretation
Images Image URLs must be crawlable and indexable Feature may not render
Deception No impersonation, no fake reviews, no false ownership claims Manual action

Google notes that a structured data manual action costs rich result eligibility but does not remove the page from ordinary web search ranking. That is a useful calibration: bad markup is not a site-killing penalty, but it does forfeit the only thing markup was going to buy you.

The completeness guidance also contains a line worth quoting to anyone who wants to stuff every recommended property in: it is more important to supply fewer but complete and accurate recommended properties than to attempt every possible one with poor data.

One coherent graph, not two

The single most common real defect on WordPress sites is not missing markup. It is conflicting markup. Yoast, Rank Math and All in One SEO each emit a connected @graph describing the site, the page, the author and the organisation. Adding a second graph from another plugin does not produce a richer description — it produces two entities claiming to be the same thing with different @id values, and a machine now has to guess.

Google's guidelines cover the mechanism for avoiding this: linking related items via @id helps it understand connections between them. Stable, absolute, site-wide @id values are what make cross-page entity identity possible at all. The correct move when an SEO plugin already owns the graph is almost always to extend it through that plugin's filters, not to emit a parallel one. SiteRank's structured data inspector reports which plugin emitted which types, and where two emitters disagree, precisely because that is the defect that actually exists on real sites.

Placement

Google recommends Organization markup on the home page or on a single page that describes the organisation, such as an About page — not on every page. Google states there are no required properties for Organization; you add the ones that genuinely apply. That is a different discipline from the required-property lists attached to rich result features, and it matters for entity clarity.

What it does not do for AI

Here is where discipline is required, because the field is full of confident claims with no source behind them.

No provider documents structured data as an LLM citation mechanism. Not OpenAI, not Anthropic, not Perplexity, not Google. Google's own AI features documentation goes further in the other direction: it states there are no additional requirements to appear in AI Overviews or AI Mode and no special optimisations necessary, and specifically that no special Schema.org markup is needed.

So the claim "add schema and LLMs will cite you" sits at HYPOTHESIS. It is not absurd — the reasoning that explicit machine-readable facts are easier for a machine to use is coherent — but reasoning from first principles is exactly what HYPOTHESIS means, and under our evidence rules a hypothesis is never scored as a deficiency and never phrased as a fix.

Three distinctions to hold onto:

  • Schema ≠ citation. Markup describes a page. Citation is a decision a generative system makes about which retrieved passage to attribute. No published mechanism connects the two.
  • Eligible ≠ shown. Even in conventional Search, valid markup buys eligibility for a rich result, not the rich result.
  • Machine-readable ≠ read by this machine. An answer engine that ingests rendered text is not necessarily parsing your JSON-LD at all, and none of them say whether they do.

An honest tier table

Practice Tier Why
Emit valid JSON-LD describing what the page actually is ESTABLISHED STANDARD Schema.org is a published vocabulary
Use JSON-LD rather than Microdata or RDFa OFFICIAL PROVIDER GUIDANCE Google states JSON-LD is recommended
Include all required properties for a targeted rich result OFFICIAL PROVIDER GUIDANCE Google states missing required properties disqualify the feature
Mark up only content visible on the page OFFICIAL PROVIDER GUIDANCE Explicit in the general guidelines
Maintain one coherent graph with stable @id values OFFICIAL PROVIDER GUIDANCE Google documents @id linking; the failure mode is observable
Keep Organization identity consistent site-wide EMERGING PRACTICE Sensible and widely practised; no provider ties it to AI outcomes
Add schema specifically to increase LLM citation HYPOTHESIS No provider documents the mechanism
Add FAQPage markup to content that is not a visible FAQ Prohibited Violates the visibility and relevance guidelines

What actually matters, in order

1. Type the page honestly. A category archive is a CollectionPage, not an Article. A listing is not a Product. This is the specificity and relevance guidance, and it is also just accuracy.

2. Fix parse errors first. A malformed JSON-LD block is ignored in its entirety — not partially applied. A trailing comma silently discards everything you wrote. Validate the rendered page, not the template, with the Schema Markup Validator for vocabulary correctness and the Rich Results Test for Google eligibility.

3. Resolve conflicts before adding anything. Two Organization entities with different names or different @id values is worse than one incomplete one. Find every emitter before you become another.

4. Establish one publisher identity. One Organization (or Person, for a personal site), one stable @id, referenced from every page's graph rather than redefined per page.

5. Only then extend. Article with real datePublished/dateModified and a linked Person author, BreadcrumbList reflecting the actual hierarchy, WebSite with potentialAction where site search genuinely exists.

6. Never invent a value. Person credentials, addresses, ratings and review counts come from the site owner, not from a model and not from plausible inference. Marking up an aggregate rating a site does not collect is a policy violation and a fabricated trust signal. If a field is unknown, leave it out and ask.

What not to assume

  • That valid markup produces a rich result. Google says otherwise, explicitly.
  • That Google still supports a given rich result type. The supported list changes; FAQPage and HowTo rich results were substantially reduced. Check the current search gallery before promising anything.
  • That your site has no schema. Nearly every WordPress site with an SEO plugin already emits a full graph. Inspect before you write.
  • That more properties is better. Google's own guidance prefers fewer, accurate ones.
  • That structured data influences whether an AI system cites you. Nobody has published that it does.

Key takeaways

  • Schema.org is an ESTABLISHED STANDARD; Google's use of it for rich result eligibility is OFFICIAL PROVIDER GUIDANCE; its role in AI citation is HYPOTHESIS.
  • Markup describes a page; it never adds facts. Every marked-up value must be visible to a reader.
  • The realistic defect on a WordPress site is conflicting graphs from multiple plugins, not absent markup. Inspect, then extend through the existing owner.
  • Google states no special Schema.org markup is required for its AI features. Treat any product claiming otherwise as unsourced.
  • Validate the rendered page, keep one publisher entity with a stable @id, and leave unknown fields empty.

Official sources & further reading