Structured Data and AI Visibility: What Should You Actually Examine?

Knowing that a website has structured data tells you very little. It doesn’t tell you what the markup describes, whether it is accurate or coherent, whether any platform uses it, or whether it has changed anything an AI system does.

Three different things are often treated as one: an implementation that exists, an implementation that is technically coherent and fit for a documented purpose, and an implementation whose claimed effect on AI visibility has actually been demonstrated. Each needs a different kind of evidence. Inspection can establish the first and much of the second. Platform documentation establishes the rest of the second. Only outcome evidence can establish the third, and as of October 2026 that evidence is thin.

This article works through the questions a technically competent reviewer should investigate, whether the implementation is proposed or already delivered, and what can legitimately be concluded from what they find. The evidence required should match the claim being made. Markup that keeps a site accurate and supports a documented search feature doesn’t need to prove an AI visibility effect to be worthwhile. Markup sold on the promise of AI recommendations does.

As a foundation: Schema.org is a shared vocabulary of types and properties, and JSON-LD, Microdata and RDFa are formats for embedding statements in that vocabulary in a page. The result is a set of machine-readable assertions about entities and their relationships.

Level One: What Inspection Can Establish

What is the markup intended to describe?

Start by listing what the markup actually asserts: which organizations, people, services and pieces of content it declares, and how it says they relate. Then compare that list with what the business needs described.

A purposeful implementation represents identifiable entities and the relationships between them. Potential warning signs include templates applying inappropriate types, properties populated with irrelevant or unsupported claims, and markup added without a clear relationship to the page’s purpose.

Form isn’t the issue. Several separate JSON-LD blocks on one page aren’t a defect in themselves, and neither is repeating organization markup across many pages. The question is whether the assertions add up to a clear description of something real.

Does it accurately represent the business?

Accuracy is checked by comparison, not validation. Google’s structured data guidelines (updated July 10, 2026) require markup to be “a true representation of the page content” and prohibit marking up content readers can’t see. A reviewer can compare each assertion with the visible page and with the organization’s actual records: names, addresses, roles, services.

What this can’t do is substantiate the claim behind an assertion. Schema.org defines knowsAbout as indicating a topic that is known about, “suggesting possible expertise but not implying it.” Markup can express that a partner specializes in seismic retrofit. It is still the firm describing itself, and there is no public documentation of how any AI system weighs that against other sources, particularly when those sources disagree.

Are the entities and relationships coherent?

Entity relationships provide a useful way to examine implementation coherence.

Consider a hypothetical professional-services firm. Its homepage declares an Organization named “Example Engineering”. Its contact page declares another Organization named “Example Engineering Partners LLC”, with no shared identifier. Its team page gives each person a worksFor value that is a separate, nested Organization object identified only by name, without referring to either of the others. Each statement can be structurally valid. Together they leave it unstated whether the site describes one organization or several, and the people are attached to a name rather than to a defined entity.

Different names aren’t the problem in themselves. A legal name, a trading name and a brand can all legitimately refer to the same business. The problem is the failure to establish that they do.

A coherent version gives the organization a stable identifier and refers to that same identifier wherever the organization appears, whether the full description is repeated on each page or not:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example-engineering.com/#organization",
      "name": "Example Engineering Partners",
      "url": "https://www.example-engineering.com/",
      "sameAs": ["https://www.linkedin.com/company/example-engineering-partners"]
    },
    {
      "@type": "Person",
      "@id": "https://www.example-engineering.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "jobTitle": "Managing Partner",
      "worksFor": { "@id": "https://www.example-engineering.com/#organization" },
      "knowsAbout": "Seismic retrofit of occupied buildings"
    }
  ]
}

The same organization identifier can then be used as the publisher of articles and the employer of every team member, and sameAs can point to reference pages that “unambiguously” indicate its identity.

What this improves is specific: the consistency of the publisher’s own machine-readable assertions. The site now says one thing about who the firm is and who belongs to it. It doesn’t establish that any system will reconcile those assertions as intended, or that recommendations will change.

Coherence also has to survive change. When people leave, services are dropped or the firm is renamed, markup that isn’t updated becomes one more outdated source.

Is it technically valid, and is it deployed?

The Schema Markup Validator checks syntax, types, properties and value structure against Schema.org. Google’s Rich Results Test answers a narrower question: whether the markup supports specific Google Search features. For example, a page can contain valid Service markup without qualifying for a Google rich result, because Google does not document a dedicated Service rich-result feature. A Rich Results Test reporting no eligible items is not a verdict that the markup is invalid. Nor does either test establish whether the markup influences generative AI systems.

Deployment needs checking too, because it affects what any later evidence means. Markup present in the served HTML and markup injected with JavaScript aren’t necessarily treated alike; the Ahrefs study discussed below examined only the former. URL inspection tools show whether markup is present in the indexed or live version of a page, and a successful live test doesn’t show that the latest markup has been indexed.

At the end of level one, a reviewer can say whether the implementation exists, what it describes, whether its assertions agree with the page and records examined, whether it is coherent and valid, and whether it is actually served. None of that is yet evidence that any system uses it.

Level Two: What Platform Documentation Establishes

Which systems are documented to use it?

This is checked type by type and platform by platform, against current documentation.

Google Search. The Organization documentation (updated September 8, 2026) says the markup can help Google understand an organization’s administrative details, disambiguate it in search results and influence the logo shown in results and knowledge panels, while noting that Google “does not guarantee that features that consume structured data will show up.” The Profile page feature (updated September 8, 2026) uses a Person or Organization as the main entity of pages “where creators… share first-hand perspectives,” including company employee pages; its documented properties include name, description, identifier, image and sameAs, but not jobTitle, worksFor or knowsAbout. Google’s list of supported features (updated June 15, 2026) includes no feature for Service.

Absence from feature documentation isn’t proof that Google ignores a property. Google says it uses structured data more generally to understand page content and gather information about the world. It does mean any claimed benefit from those properties rests on inference.

Bing. When it added JSON-LD support to Bing Webmaster Tools in 2018, Bing described structured data as “one of the clues that Bing uses” to understand page content. That is search-engine support. A March 2025 Search Engine Land report said Microsoft’s Fabrice Canel confirmed that schema helps Microsoft’s language models understand content; the report paraphrases rather than quotes him, and Microsoft hasn’t documented the mechanism for Copilot.

Generative AI features and assistants. Google says there is “no special schema.org structured data that you need to add” to appear in AI Overviews or AI Mode (AI features guidance, updated December 10, 2025). For OpenAI, Anthropic and Perplexity, we found no public documentation of how structured data is treated in indexing or at retrieval time.

At the end of level two, a reviewer can say which parts of the implementation map to a documented purpose on a named platform. For Google Search, an implementation may include Organization markup with documented uses, Person information eligible for specific features on qualifying profile pages, and Service assertions for which no dedicated rich-result feature is documented. These differences establish the limits of published feature support, not the full extent of how Google interprets the information. A standalone Person declaration, like the one in the example above, doesn’t by itself qualify for the profile page feature, which requires a qualifying page marked up as a ProfilePage with the person as its main entity. No generative AI provider reviewed here documents a use for any of these types.

Level Three: What Outcome Evidence Establishes

What outcome is being claimed?

Claims about “AI reading schema” often move between quite different outcomes: that markup is parsed, that it is indexed, that it helps a system tell the business apart from others, that it is cited, that the business is included in answers, or that it is recommended. Each is a separate claim. Evidence for an earlier one isn’t evidence for a later one.

It helps to pin down which outcome is being claimed before looking for evidence. A disambiguation claim can be partly supported by documentation. A recommendation claim can’t.

What evidence would support it?

Suppose an AI answer correctly describes Jane Doe as a managing partner specializing in seismic retrofit. That shows the system has the information. It doesn’t show where the information came from. A search engine may have processed the markup during indexing; a system may have parsed it when fetching the page; or it may simply have read the visible page, or other sources, as text.

Two small experiments show how difficult isolation is. In October 2025, searchVIU built a single test page with one price available only in JSON-LD; none of the five systems tested reported it, though the test mixed direct page fetching with index-based answers and reports two different counts of repeated queries. In June 2026, Mark Williams-Cook placed an address only inside deliberately invalid JSON-LD, and ChatGPT and Perplexity both returned it, showing that information can be extracted from the text of a JSON-LD block without the markup being valid Schema.org. Recovering information from JSON-LD isn’t evidence of Schema.org-aware parsing, and failing to recover it in one retrieval test says nothing about indexing.

Google’s requirement that structured data represent visible page content makes it difficult to identify markup as the source of a particular fact in an AI answer. Experiments that place information exclusively in markup can test whether systems recover it, but such markup would not meet Google’s production guidelines if the information were absent from the visible page. Controlled comparisons using compliant pages can still investigate whether adding markup changes outcomes, although they may not reveal the internal mechanism.

Stable identifiers and sameAs relationships are useful candidates for further investigation because they express explicit entity relationships that ordinary page text may leave implicit. Google documents a disambiguation role for some organization information, but the research reviewed here does not isolate whether these declarations affect generative AI outputs.

Establishing a causal effect requires a credible comparison with what would have happened without the intervention. Matched control pages are one approach, although the comparison must account for other changes and differences between the groups. The largest attempt so far, Ahrefs’ study published May 11, 2026, compared 1,885 pages that added JSON-LD with a reported control sample of approximately 4,000 that didn’t, over 30 days, using a matched difference-in-differences design. The treated pages already had substantial AI Overview exposure. Changes in ChatGPT and AI Mode citations were statistically indistinguishable from zero; AI Overviews showed a small, unexplained relative decline. The authors’ summary: “schema had no clear positive or negative effect.” The design is observational, schema types were pooled and the outcome was citations, not recommendation. Even a study of that size doesn’t establish a citation benefit from adding markup.

For a single business, the bar is harder to meet. Ahrefs suggests running a small test with 5 to 10 treated pages and 5 to 10 controls over 30 days or more. That is a reasonable design, but samples that small will only detect large effects, and AI citations move for reasons unrelated to any page change.

Among the studies reviewed, we found no robust controlled evidence establishing a positive causal effect of structured data on AI citations or recommendations. That is a gap in the evidence rather than proof that no effect exists.

What You Can Legitimately Conclude

What you find	What you can conclude	What you can’t
Markup is present	An implementation exists	That it is accurate, coherent or used
It validates, is served in the HTML and matches the page and records	The implementation passes the checks performed and its assertions are consistent with the page and records examined	That the records themselves are accurate, or that any platform uses it
Entities share stable identifiers and reference each other consistently	The publisher’s assertions are coherent	That any system reconciles them as intended
Its types and properties map to a documented feature	The implementation has a documented potential use, subject to the feature’s requirements	That the page meets all eligibility requirements, the feature will appear, or AI outputs will change
An AI answer contains information the markup states	The system has that information	That it came from the markup
AI citations rose after implementation	The two coincided	That the markup caused the rise, without a controlled comparison

The first four rows are within reach of any competent review. They are also enough to justify markup that serves a documented purpose or corrects inaccurate information. The last two are where claims about AI visibility usually sit, and where the evidence currently available to a reviewer is weakest.

What would change this: provider documentation describing how structured data is used in generative answers; controlled studies covering pages with little existing AI visibility, specific types such as identifiers and sameAs, and longer windows; and research that measures inclusion and recommendation rather than citations alone.

For the business decision involved in commissioning this work, see Will Adding Schema Markup Make AI Recommend Your Business? For why accurate representation still isn’t the same as authority, see AI Can Make Your Authority More Visible. It Can’t Give You Authority.