Schema Markup for AI Search: What It Can and Cannot Do

What is schema markup, and how does JSON-LD work?

Schema markup is structured data that describes the meaning of information on a webpage using a shared vocabulary, commonly Schema.org. JSON-LD is a format for expressing that information through machine-readable objects and relationships. It can identify an article’s author, a product’s attributes, a business’s identity, or the relationship between a webpage and the organization responsible for publishing it.

The distinction between ordinary webpage content and structured data begins with how information is represented.

A human visitor reading an article may recognize the headline, byline, publication date, and publisher because those elements are presented through familiar visual conventions. A search engine can also interpret page content, but structured data provides an additional standardized description of the entities and attributes involved.

For example, a webpage may visibly state that a named author wrote a research article. Its JSON-LD markup can represent the publication as an Article, identify the author as a Person, and associate the publication with its corresponding WebPage.

The markup does not create the authorship relationship. It communicates a relationship that the published information should already support.

Google describes structured data as a way to provide explicit information about a page and help its systems understand the content. It also documents how supported markup can make pages eligible for enhanced search appearances.

Source: (opens in a new tab)Google Search Central, Introduction to Structured Data (opens in a new tab).

Schema.org is a vocabulary, not a search-ranking system

Schema.org provides definitions for entities, properties, and relationships that publishers can use to describe their content.

A schema type defines the kind of entity being represented. Examples include Organization, Person, Product, Article, and LocalBusiness.

A schema property describes an attribute or relationship associated with that entity. Examples include name, url, author, publisher, datePublished, and sameAs.

These definitions make structured information more consistent across different implementations. They do not require every search engine to support every vocabulary type, nor do they prescribe how a search engine must rank pages.

This creates an important distinction between Schema.org validity and platform-specific support.

A website may use a legitimate Schema.org type that Google does not support for a particular rich-result feature. The markup can still convey information, but its vocabulary validity alone does not establish eligibility for search enhancement.

What is JSON-LD?

JSON-LD stands for JavaScript Object Notation for Linked Data.

It is a structured data serialization format that allows entities and their relationships to be expressed through JSON syntax, using linked-data identifiers and vocabulary references.

Google recommends JSON-LD for implementing supported structured data because it is generally easier to maintain than formats that require properties to be embedded throughout the visible HTML.

A simplified example illustrates the basic structure:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Understanding Structured Data",
  "author": {
    "@type": "Person",
    "name": "Example Author"
  }
}

This example identifies an article and associates it with a person described as its author. It demonstrates vocabulary structure, not a complete implementation for an existing publication.

The author name is illustrative and must be replaced with accurate information when the example is adapted for production.

Understanding the core JSON-LD properties

Each JSON-LD property has one job, such as naming the vocabulary, typing an entity, identifying a node or linking an author.

These properties should be selected according to the real relationships being represented. An implementation does not become more accurate simply because it includes more fields.

Structured data should clarify existing information

The most important implementation principle is consistency between structured data and the underlying content.

If a page identifies one author while its JSON-LD names someone else, the website communicates contradictory information.

If a product’s visible price differs from its marked-up offer, the inconsistency may affect eligibility for relevant product features.

If an organization uses sameAs to reference an unrelated entity, the resulting graph contains a misleading identity relationship.

Google’s (opens in a new tab)general structured data guidelines (opens in a new tab) require that eligible markup represent content accurately and comply with the relevant technical and content requirements.

This means that structured data should be treated as a representation of factual information, not as an opportunity to add unsupported claims that readers cannot verify.

What does Google officially say about schema markup and AI search?

Google does not require special Schema.org structured data for AI Overviews or AI Mode. Its official 2026 guidance states that publishers should continue using established SEO practices and implement structured data where it supports legitimate Search features, rather than creating additional AI-specific markup intended to influence generative answers.

This is one of the clearest documented answers in the broader discussion of schema and AI visibility.

In its May 2026 guide to optimizing for generative AI features, Google explicitly addresses several popular optimization recommendations, including special AI markup, llms.txt, arbitrary content chunking, and rewriting information solely for AI systems.

For structured data, Google’s position is that it remains useful as part of an overall SEO strategy, particularly for eligible rich results. Still, it is not a special requirement for generative AI Search.

Source: (opens in a new tab)Google, Optimizing for Generative AI Features (opens in a new tab).

Google’s AI eligibility requirements are not schema requirements

Google AI Overviews and AI Mode operate within the broader Google Search environment.

To qualify as a supporting link in those features, a page must meet Google’s applicable Search requirements, including indexation and eligibility to appear with a snippet. The website must also satisfy the applicable generative AI participation controls documented by Google.

These are separate from structured data implementation.

A page without JSON-LD may still meet the relevant technical eligibility conditions.

Conversely, a page containing technically valid Article, Person, and Organization markup may fail to qualify for the intended Search experience if Google cannot access or index its content, or if the applicable publisher controls exclude participation.

The presence of schema does not override those conditions.

Google also cautions that satisfying technical requirements does not guarantee that a page will be indexed, displayed, or selected as a supporting source.

Source: (opens in a new tab)Google, AI Features and Your Website (opens in a new tab).

Why Google still recommends structured data

Google’s position should not be interpreted as a recommendation to remove existing schema.

Structured data continues to support specific Search applications.

For example, Organization markup can communicate administrative information and help distinguish an organization from similarly named entities. Product markup can support eligible shopping and product-related search experiences. Breadcrumb markup can describe navigational hierarchy, while Article markup can clarify publication metadata.

These are documented applications that retain value regardless of whether the content is cited in AI-generated answers.

The appropriate decision is therefore based on the intended feature and the accuracy of the information, rather than on the assumption that every schema property influences AI retrieval.

Rich-result eligibility is not a ranking guarantee

Google explicitly distinguishes eligibility for an enhanced search presentation from the guarantee that an enhanced result will appear.

A valid Product implementation may qualify for supported product features without those features appearing for every relevant search.

An Organization implementation may help Google interpret organizational details without establishing that the organization will receive a Knowledge Panel.

Article markup can provide information about authorship, headlines, and publication dates without guaranteeing a particular ranking position.

The same distinction applies to AI search. Accurate information does not determine how often Google will select the page as supporting evidence in a generated answer.

The three separate questions publishers should ask

Ask three separate questions: is the page eligible for Search, is it eligible for a specific enhancement, and is it actually appearing in AI experiences?

These questions should be investigated independently.

A passing structured data test does not answer all three.

What this means for technical SEO

A technically responsible implementation should begin with a documented purpose.

If the objective is to represent an organization’s identity consistently, relevant Organization markup may be appropriate.

If the objective is to support eligible product search features, Product and Offer markup may be appropriate where the underlying facts and feature requirements are satisfied.

If the objective is to increase ChatGPT citations, adding generic JSON-LD should not be presented as an independently proven intervention.

That last claim requires empirical evidence rather than extrapolation from schema’s established uses in conventional Search.

Does adding schema markup increase AI citations?

Current empirical research has not demonstrated that adding JSON-LD alone reliably increases AI citations. Large observational studies and smaller platform experiments suggest that structured data’s established SEO value should not be confused with a confirmed direct effect on source selection in generative AI answers.

The strongest available evidence comes from research that attempts to distinguish between websites that already use schema and those that introduce schema at a particular point in time.

That distinction is essential because schema adoption is not random.

Websites implementing structured data may also have stronger technical maintenance, more established brands, better content, stronger link profiles, and larger editorial resources. Their visibility may be associated with several characteristics beyond the markup itself.

Ahrefs: Why correlation was not enough

In May 2026, Ahrefs published a study titled (opens in a new tab)We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved (opens in a new tab).

The research began with an analysis of approximately six million URLs and found that pages cited in AI-generated answers were almost three times as likely to contain JSON-LD as pages that were not cited.

That initial relationship might appear to support the argument that schema improves AI visibility.

However, the comparison could not establish causation.

The pages containing schema may have differed from non-schema pages in content quality, domain authority, technical maturity, or other characteristics associated with citation selection.

To investigate whether implementing schema itself made a measurable difference, Ahrefs conducted a follow-up analysis of pages that introduced JSON-LD.

The 1,885-page implementation study

The researchers identified 1,885 pages that added JSON-LD between August 2025 and March 2026 and compared their citation trends with approximately 4,000 control pages.

The study examined citation activity during the 30 days before and after the detected implementation period.

Its preferred analysis used matching and a difference-in-differences approach to estimate whether the pages that introduced schema experienced changes beyond those observed among comparable control pages.

The reported results were:

See Figure 1 for a visual comparison of these estimates.

The most defensible interpretation is that this study did not demonstrate a meaningful, reliable citation uplift from the introduction of JSON-LD on the tested pages.

It would be incorrect to interpret the small positive estimates for ChatGPT and Google AI Mode as confirmed improvements.

It would also be incorrect to claim that the negative AI Overview estimate proves schema reduces citations.

Why the negative Google AI Overview result needs caution

Ahrefs reported that citations declined in both the treatment and control groups during the study period. The treated group experienced a somewhat larger decline under the preferred model.

That pattern raises an important methodological question.

AI search systems, their retrieval behavior, and the demand reflected in observed answers may change during the same period in which a website introduces schema. Even a comparison with matched control pages cannot eliminate every possible confounding factor.

The detected implementation date was also based on successive crawler observations, which limits the precision with which the exact schema change could be timed.

Furthermore, the study’s pages were drawn from an already cited population. Its findings should not automatically be generalized to newly created websites, previously uncited pages, or every structured data use case.

The correct conclusion is narrower than either “schema works” or “schema hurts.”

The study did not establish a reliable positive causal effect on AI citations, while leaving open the possibility of smaller effects or different outcomes in other settings.

OtterlyAI: A smaller cross-platform experiment

A separate study by (opens in a new tab)OtterlyAI (opens in a new tab) examined five schema types across seven AI search experiences over approximately three months, from December 2025 to March 2026.

The experiment used 319 prompts and focused on OtterlyAI’s own website.

The researchers reported that six of the seven tested systems failed to retrieve or accurately identify the implemented schema when directly prompted under their test conditions. Gemini was the exception reported in the study.

This observation is relevant because it challenges the assumption that every AI assistant can predictably expose or use a webpage’s JSON-LD.

However, the study has important limitations.

It evaluated one company’s website and a specific set of prompts. The ability of a conversational system to reproduce structured data when explicitly asked is not necessarily equivalent to the way its underlying retrieval or ranking infrastructure processes that data.

An assistant’s failure to report the JSON-LD accurately does not prove that none of its internal components can process structured data.

The study also reported changes in certain search features during the observation period, but those changes should not be automatically attributed to schema implementation without sufficient control for other factors.

What both studies actually establish

The Ahrefs and OtterlyAI investigations used different methodologies.

Ahrefs emphasized observed citation trends across a large set of pages that introduced structured data. OtterlyAI examined retrieval behavior and visibility observations within a single brand’s controlled testing environment.

Their findings are not identical measurements and should not be combined into one numerical estimate.

Nevertheless, both investigations reinforce the need to separate the technical presence of markup from demonstrated citation outcomes.

The research supports a practical allocation of effort.

Structured data should be implemented when it accurately describes important information or serves a documented platform feature. Claims about additional AI citation benefits should be treated as hypotheses requiring independent measurement.

For websites with limited development capacity, this approach prevents speculative AI optimization work from displacing more clearly justified improvements.

How do Google, Bing, ChatGPT, Claude and Perplexity differ in their use of structured data?

Major search and AI platforms do not disclose one universal approach to processing Schema.org markup. Google documents structured data applications in Search, while Bing provides tools to inspect JSON-LD and uses structured information within its search ecosystem. For ChatGPT, Claude, and Perplexity, publicly documented crawler access and retrieval behavior do not establish a universal schema requirement or guaranteed citation benefit.

A technically valid JSON-LD graph can be interpreted by software that can parse the format. That does not establish whether a particular AI search platform retrieves the graph, retains its fields, uses the information in source ranking, or incorporates it into generated answers.

Those are separate technical questions.

Google: Documented feature support without an AI citation guarantee

Google provides extensive documentation describing the structured data types and properties recognized for supported Search features.

For example, Product markup has defined applications in product-related results. Organization markup can describe organizational information, and BreadcrumbList can present eligible breadcrumbs.

Google also explicitly states that no special Schema.org markup is required for AI Overviews or AI Mode.

Therefore, structured data should be evaluated against its documented Search use case rather than an assumed AI citation advantage.

Google’s position is more precise than the broad assertion that schema is either essential or irrelevant to AI search.

It supports structured data for defined purposes while rejecting unsupported claims about special AI requirements.

Bing and Microsoft Copilot: Structured information is supported, but citation effects require evidence

Microsoft has supported JSON-LD within Bing Webmaster Tools for years.

Its (opens in a new tab)JSON-LD announcement (opens in a new tab) describes structured data as information that helps Bing interpret webpage content.

Bing’s (opens in a new tab)URL Inspection documentation (opens in a new tab) also describes a markup inspection component that can identify JSON-LD and other supported markup formats.

Microsoft has also published guidance on connecting structured product information to search and AI-assisted discovery use cases.

This establishes that structured data has recognized applications within Microsoft’s search ecosystem.

However, that does not quantify the independent contribution of adding schema to the likelihood that a particular page will receive a Copilot citation.

Microsoft introduced AI citation reporting through Bing Webmaster Tools in February 2026. Those reports can help publishers observe relevant citation activity, but a measured increase in citations after a markup deployment is not automatically evidence that the markup caused the change.

The difference between documented infrastructure support and demonstrated outcome effects must remain explicit.

ChatGPT Search: Search crawling is not proof of JSON-LD citation weighting

OpenAI crawling a page does not show that ChatGPT weighs its JSON-LD when it chooses citations.

OpenAI publishes documentation describing web crawlers such as OAI-SearchBot, GPTBot, and ChatGPT-User, which serve different purposes: search, training, and user requests.

Those distinctions are important for understanding crawler access, but they do not establish that adding Organization, Article, or FAQ markup directly improves ChatGPT citation selection.

Source: (opens in a new tab)OpenAI, Web Crawler Documentation (opens in a new tab).

A large language model can interpret JSON-LD supplied directly in a prompt. That capability should not be confused with evidence that ChatGPT Search retrieves and weights JSON-LD from webpages as an independent ranking factor.

The retrieved content may be processed through systems whose complete internal behavior is not publicly disclosed.

The evidence-based position is therefore that ChatGPT’s exact use of webpage schema for citation selection is not established by its crawler documentation.

Claude: Crawler permissions and structured data are separate questions

Anthropic distinguishes Claude-SearchBot, ClaudeBot, and Claude-User in its official crawler documentation.

These identities define different categories of access, but they do not provide a public specification that requires publishers to implement Schema.org markup for Claude’s search-related responses.

Source: (opens in a new tab)Anthropic, Crawler Documentation (opens in a new tab).

An accessible page containing accurate JSON-LD may be suitable for technical experimentation. However, the presence of that markup should not be promoted into a proven mechanism for increasing Claude citations.

Any observed effect would need to be evaluated through an appropriate research design.

Perplexity: Retrieval access is not a universal schema requirement

Perplexity documents separate automated search crawling and user-requested retrieval mechanisms.

Its published crawler guidance explains how website owners can manage relevant access policies, but does not establish a universal Schema.org requirement for being cited in Perplexity answers.

Source: (opens in a new tab)Perplexity, Crawler Documentation (opens in a new tab).

A website can therefore evaluate Perplexity crawler access and examine citation behavior without assuming that a particular JSON-LD graph is mandatory for inclusion.

Platform comparison

Documented schema support is specific to Google Search features; nothing established makes schema a general citation requirement on any platform.

The important distinction is between technical possibility and documented platform behavior.

A platform may process structured information internally without disclosing the exact mechanism. That possibility does not justify claiming that publishers can improve citations by implementing arbitrary markup.

Equally, the absence of a public citation-weighting specification does not prove that structured data is never considered.

A responsible article should acknowledge both limitations.

What can and cannot schema markup do?

Schema markup can communicate structured facts, clarify described relationships, and help qualifying pages participate in documented search enhancements. It cannot guarantee rankings, manufacture authority, override indexing restrictions, or ensure that AI search platforms retrieve and cite a website. Its practical value depends on the accuracy of the content it represents and the requirements of the system that consumes it.

This distinction provides a more reliable basis for deciding whether a structured data implementation is worthwhile.

What schema can legitimately accomplish

Structured data can make certain information more explicit.

An Organization graph may communicate an organization’s public name, website, logo, and appropriate external identity references.

Article markup can describe a publication’s author, headline, and dates.

Product markup can represent relevant product attributes and, where applicable, information required for supported product enhancements.

Breadcrumb markup can describe a navigational relationship between pages.

These applications are valuable because they provide structured descriptions of information that should already exist on the website.

When Google supports a specific search enhancement, implementing accurate markup in accordance with the documented requirements can establish technical eligibility for that enhancement.

That is a meaningful, testable outcome.

What schema cannot establish

Structured data does not independently prove that an organization’s claims are true.

A JSON-LD graph can assert that a person holds a credential, but the assertion is not automatically verified merely because the syntax is correct.

Similarly, assigning an entity a stable @id does not guarantee that Google will create or display a Knowledge Panel.

Adding sameAs references does not establish that every external profile is authentic, relevant, or recognized by a particular AI system.

The markup also cannot override technical restrictions preventing content from being crawled or indexed.

An inaccessible page with extensive JSON-LD remains subject to the same access problems as an inaccessible page without structured data.

Capability and limitation matrix

Schema can describe entities and support documented features; it cannot guarantee rich results, rankings, Knowledge Panels or AI citations.

This matrix separates supported implementation outcomes from unsupported marketing promises.

Why implementation still matters

The absence of proven AI citation uplift should not be used as an argument against the accuracy of structured data.

A publisher may benefit from supported search enhancements, more consistent entity descriptions, easier maintenance of structured information, or improved quality assurance across its website.

Those benefits do not require a claim about generative AI citations.

For an e-commerce business, correctly implemented product attributes may have clear operational value.

For a research publication, accurately associated author and article metadata can establish a consistent representation of the publication’s editorial structure.

For a professional website, appropriate Person and WebSite relationships can reduce contradictory identity declarations across templates.

The strongest implementation rationale is therefore based on a verifiable technical or search-feature requirement.

How does Schema.org vocabulary differ from Google rich result support?

A Schema.org type can be valid without being eligible for a Google rich result. Schema.org defines a vocabulary for describing information, while Google independently determines which structured data types and properties it recognizes for particular Search features. Passing a generic schema validator does not establish eligibility for a Google enhancement, and passing Google’s Rich Results Test does not guarantee the enhancement will appear.

Confusing these validation layers is one of the most common errors in structured data implementation.

Vocabulary validity

Schema.org defines a broad collection of types and properties representing people, organizations, creative works, products, services, locations, events, and many other concepts.

A valid JSON-LD implementation may correctly describe an entity using that vocabulary.

The (opens in a new tab)Schema Markup Validator (opens in a new tab) can help inspect whether the markup conforms to the expected vocabulary and syntax.

However, the validator does not determine whether Google currently supports the type for a specific rich result.

For example, Service is a legitimate Schema.org type. That does not mean Google provides a general Service rich-result feature for every service page.

The same distinction applies to Person markup. It can describe an author or individual, but a valid Person node does not automatically create a person-specific Google rich result.

Google feature eligibility

Google documents its supported structured data features and their specific requirements.

For eligible features, the (opens in a new tab)Google Rich Results Test (opens in a new tab) can assess whether the relevant markup meets the applicable technical requirements.

However, Google explicitly states that correctly implemented markup does not guarantee the display of rich results.

Its search systems may determine that a different presentation of results is more appropriate for a particular query or user context.

Source: (opens in a new tab)Google, General Structured Data Guidelines (opens in a new tab).

The complete validation process must therefore distinguish syntax, vocabulary, feature support, factual consistency, and actual search appearance.

Google can discontinue features while the vocabulary remains

Google can retire a search feature while the Schema.org type stays valid, so schema advice needs dates.

Two examples demonstrate why structured data advice must be maintained.

Google discontinued its How-to rich-result feature in September 2023.

In May 2026, Google announced the removal of FAQ rich results from Search, effective May 7, and removed the corresponding feature documentation in June.

These changes did not delete the HowTo or FAQPage types from Schema.org.

They changed the Google Search features that publishers could reasonably expect from implementing those types.

Source: (opens in a new tab)Google Search Central, Documentation Updates (opens in a new tab).

A tutorial recommending FAQ markup in 2026 solely to obtain Google FAQ rich results would therefore be outdated.

The same applies to tutorials promising the former How-to rich-result presentation.

WebSite markup provides another useful example

Google removed the sitelinks search box visual feature in November 2024.

However, that change did not eliminate every supported use of WebSite structured data.

Google explicitly explained that its site-name functionality continued to use relevant WebSite markup.

This demonstrates why a schema type’s applications must be evaluated individually rather than declared entirely useful or useless when one associated search feature changes.

Source: (opens in a new tab)Google, Farewell, Sitelinks Search Box (opens in a new tab).

The five verification questions

Verify five things in order: vocabulary, syntax, truthfulness, platform support and observed outcome.

Before recommending structured data, determine:

• Does the Schema.org vocabulary support the intended type and property?
• Is the JSON-LD syntactically and semantically appropriate?
• Does the markup truthfully describe the page?
• Does the target search platform support the intended application?
• Has the intended outcome actually been observed?

Each question establishes a separate form of evidence.

A positive result at one level should not be substituted for missing evidence at another.

Which schema types are worth implementing?

The most useful schema types are those that accurately represent a website’s real content and serve a documented technical or search-feature purpose. Organization, WebSite, Article, BreadcrumbList, Product, and LocalBusiness markup may be appropriate in their respective contexts. Person, ProfilePage, and Service markup can also describe legitimate entities and relationships, but their practical applications and Google feature support must be evaluated separately.

The correct selection begins with the page’s purpose.

A publisher should not add every available schema type simply because it appears in an AI SEO checklist.

The markup should describe what the page actually represents.

Organization and WebSite

Organization markup is relevant when a website needs to communicate accurate organizational information.

Google documents properties such as the organization’s name, official URL, logo, contact details, and appropriate external identity references.

It recommends using the most specific applicable Organization subtype and placing organizational information on the homepage or an appropriate organization page rather than duplicating it unnecessarily across every page.

Source: (opens in a new tab)Google, Organization Structured Data (opens in a new tab).

WebSite markup describes the website as a digital resource and can support documented site-name information.

The organization that operates a website and the website itself should remain distinct entities.

Person and ProfilePage

Person markup is appropriate for representing individuals such as authors, contributors, and professionals.

Properties can describe an individual’s name, relevant URL, and other supported attributes.

ProfilePage markup may be appropriate for qualifying pages primarily describing a person or organization associated with the website.

However, Google has specific ProfilePage guidelines. A homepage containing many unrelated sections should not automatically be marked as a ProfilePage simply because it contains an author biography.

The implementation should reflect the page’s actual primary subject.

Source: (opens in a new tab)Google Profile Page Structured Data (opens in a new tab).

Article and BlogPosting

Article and BlogPosting markup can describe the identity and publication metadata of editorial content.

Google’s documentation specifically identifies article-related fields including headline, author, publication date, modification date, and applicable image information.

The author relationship should refer to the correct person or organization rather than an unrelated publisher entity.

Publication dates should reflect the actual editorial history.

A website should not update modification dates simply to create the appearance of freshness.

Source: (opens in a new tab)Google, Article Structured Data (opens in a new tab).

BreadcrumbList

BreadcrumbList describes a navigational pathway through a website.

Google supports breadcrumb structured data for eligible Search presentations, with required properties and ordering rules defined in its documentation.

The markup should describe a reasonable user navigation path rather than an artificially constructed hierarchy intended to add keywords.

Source: (opens in a new tab)Google, Breadcrumb Structured Data (opens in a new tab).

Product and Offer

Product markup is relevant to websites presenting genuine product information.

For supported shopping and product-related search applications, publishers may need to provide appropriate product identifiers, images, offers, prices, currency, availability, or other applicable properties.

The exact requirements differ between product snippets and merchant listing experiences.

The markup should reflect real, visible product information and should not invent offers, ratings, review counts, or availability.

A service website should not automatically use Product markup to manufacture a shopping feature for something that does not meet the relevant product requirements.

LocalBusiness

LocalBusiness describes qualifying businesses with real-world location information.

Its implementation should accurately represent the relevant business location, opening hours, contact details, and other applicable attributes.

A national service provider should not automatically invent local business locations or use address markup to imply offices that do not exist.

The correct entity type depends on the actual business model.

Service

Service is a valid Schema.org type for describing genuine services.

It may help a publisher express the relationship between a provider and its offerings in a structured graph.

However, there is no general Google Service rich-result feature that every implementation can qualify for.

Its use should therefore be justified by an accurate, structured representation or a specifically supported consuming system, not by a promise of additional Google search enhancements.

Implementation priorities by page type

Choose schema types by page purpose, not by a checklist of every available type.

This table is a selection guide, not a recommendation to implement every listed type.

The relevant Google feature documentation must be consulted before deploying markup intended to support a specific search appearance.

How do Organization, Person, WebSite and author entities connect?

A coherent structured data graph should describe the organization or person responsible for a website, the website itself, the individual webpages it contains, and the authors or publishers associated with its content. Stable identifiers and accurate relationships help prevent contradictory declarations, but they do not independently establish authority or guarantee recognition by an AI search platform.

Entity representation becomes particularly important when a website publishes multiple types of content.

A professional website may contain a homepage, author biography, service pages, technical articles, research reports, and downloadable resources.

Each resource has its own identity and purpose, while some entities recur across several pages.

A consistent graph should represent those relationships without merging distinct entities merely because they belong to the same website.

A person is not the same entity as their website

A person and their website are different entities and need separate, linked nodes.

Consider a professional who operates a personal website.

The individual can be represented as a Person.

The website can be represented as a WebSite.

A particular article can be represented as an Article or BlogPosting.

The article’s public URL can be associated with a WebPage.

These are distinct entities.

The author relationship connects the article to the individual. The website relationship identifies where the content is published. Additional properties may connect the article to its publisher and the corresponding webpage.

Using one URL indiscriminately as the identifier for all these nodes can obscure their intended meanings.

Understanding stable identifiers

The @id property identifies a node within the structured data graph.

A publisher may use stable identifiers such as:

https://example.com/#website

https://example.com/#person

https://example.com/articles/schema-guide/#article

The specific naming convention is a local implementation decision. The important principle is consistency.

When several pages refer to the same author, they should not accidentally describe several unrelated people simply because the theme and SEO plugin generate different identifiers.

However, a stable @id remains a graph identifier, not a Google-issued entity verification certificate.

Its presence does not establish that Google or an AI assistant will recognize or prioritize the entity.

Author versus publisher

The author-publisher relationship serves different functions.

An author property identifies the person or organization responsible for creating a particular work.

A publisher property identifies the organization or person responsible for publishing it, where applicable.

For a research article written and published by an independent professional, the relevant author and publisher relationships may refer to the same real-world individual.

For an editorial publication, the author may be a named writer while the publisher is a separate organization.

The graph should reflect the actual arrangement.

Creating an artificial organization solely because the publisher property is expected in an example template would misrepresent the underlying relationship.

What sameAs does and does not establish

The sameAs property can associate an entity with an appropriate external identity reference.

For an author, this might include a relevant professional profile or another webpage identifying the same person.

For an organization, it might reference an official external organizational profile.

However, publishers should not use sameAs to list every website that has mentioned the person or organization.

A citation from an unrelated article is not necessarily an alternative identity representation.

Likewise, including a social profile in structured data does not automatically prove ownership or establish that a search engine trusts the profile.

The referenced relationship should be accurate and supportable.

Entity consistency across website templates

A practical implementation should examine whether recurring entities are represented consistently.

If a WordPress SEO plugin defines a Person node on every article, the identifier and name should agree with the intended author identity.

If a theme adds separate WebSite markup, it should not unintentionally conflict with another WebSite node generated by a plugin.

If an article’s author is changed, its structured data should reflect the real editorial attribution.

If the publisher changes its public identity, the graph should be updated to reflect the actual organizational change.

These are information-governance issues, not simply syntax checks.

The difference between entity clarity and entity authority

A well-structured graph can make relationships explicit.

It cannot independently demonstrate that the described person is an expert, that an organization is trustworthy, or that the content deserves citation.

Those claims require evidence beyond the existence of structured data.

For a professional website, verifiable credentials, published research, accurate organizational information, relevant editorial experience, and inspectable source material may provide substantive evidence that structured data can describe.

The order matters.

The underlying facts should be accurate and supportable before they are expressed as JSON-LD.

The practical conclusion

A coherent schema graph is not necessarily the largest graph.

It is the smallest sufficiently complete representation that accurately describes the relevant entities and relationships for the intended use case.

Its quality should be evaluated through identity consistency, factual accuracy, vocabulary validity, and documented platform support.

The next stage of the technical audit should therefore move from deciding which entities need to be represented to verifying how the markup is delivered, whether its relationships are valid, and whether any intended Search feature is actually supported.

How do you implement Article, Product, LocalBusiness and Service markup correctly?

Structured data should be implemented based on the webpage’s actual purpose, the entities it describes, and the requirements of the intended search feature. Article markup should represent genuine editorial content, Product markup should describe real products, LocalBusiness markup should identify qualifying physical locations, and Service markup should describe actual service offerings. None of these types independently guarantees inclusion in AI-generated answers.

The most common implementation mistake is selecting structured data based on the search appearance a publisher wants rather than the information the page genuinely contains. A service provider may add Product markup because product results appear visually attractive. A professional may add LocalBusiness markup even if they operate without an identifiable physical business location. A publisher may generate several overlapping Article nodes because different WordPress plugins create markup independently.

The resulting JSON-LD may be syntactically valid while communicating inaccurate or contradictory information.

A better approach begins with the content itself. The page’s primary subject, publishing responsibility, visible factual claims, and intended Search feature should be identified before constructing the structured data graph.

Article and BlogPosting: Connect the publication to its author

Article markup describes an editorial work and its publication metadata. Google’s current documentation supports Article, NewsArticle, and BlogPosting for applicable content, with recommended properties including author information, headline, publication date, modification date, and representative images.

For a professional publication, the critical relationships are between the article, its webpage, the author, and the publisher. Where those entities are already defined elsewhere on the site, stable identifiers can be used to link them without creating duplicate inconsistencies.

The following example demonstrates a self-published article. Every name, URL, and date is illustrative.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Research Website"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#person",
      "name": "Example Author",
      "url": "https://example.com/about/"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/guides/schema/#webpage",
      "url": "https://example.com/guides/schema/",
      "name": "Understanding Schema Markup",
      "isPartOf": {
        "@id": "https://example.com/#website"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/guides/schema/#article",
      "headline": "Understanding Schema Markup",
      "datePublished": "2026-01-15T09:00:00+00:00",
      "author": {
        "@id": "https://example.com/#person"
      },
      "publisher": {
        "@id": "https://example.com/#person"
      },
      "mainEntityOfPage": {
        "@id": "https://example.com/guides/schema/#webpage"
      }
    }
  ]
}

The example demonstrates how several nodes can reference the same author without redefining that individual in every relationship.

It does not mean that every professional website should use Person as its publisher. An article published by a separate organization should reference the appropriate organization instead.

For an actual implementation, publication dates must match the editorial history. The page’s visible headline and attribution should match the markup, and any representative image included in the Article data should genuinely belong to the article.

Google’s (opens in a new tab)Article structured data documentation (opens in a new tab) states that there are no universally required Article properties for its supported application. Instead, publishers should provide the applicable recommended properties and follow the broader structured data guidelines.

The purpose is an accurate representation of the publication, not maximizing the number of nodes.

Product: Distinguish product snippets from merchant listings

Product markup can support eligible product-related search experiences, but Google distinguishes product snippets from merchant listings. Product snippets may apply to product information and relevant reviews, while merchant listings are intended for pages where shoppers can purchase products directly from the merchant.

This distinction is particularly important for businesses that operate as aggregators, provide quotes, or display products without offering direct online purchasing.

Google’s merchant listing guidelines specify that qualifying product pages must allow customers to purchase the product from the merchant. A page linking shoppers to another seller does not qualify merely because its Product markup contains an Offer.

The following fictional example illustrates how a directly purchasable product and its offer might be represented:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Adjustable Desk Lamp",
  "description": "An adjustable desk lamp for indoor use.",
  "image": "https://example.com/images/desk-lamp.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/desk-lamp/",
    "price": "49.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

The product, price, inventory status, and URLs are fictional demonstration values. They are not verified commercial information, and the example has not been submitted to Google’s Rich Results Test.

In a production environment, the offer must correspond to an actual purchasing opportunity, and its price and availability must reflect the visible product information.

The marked-up product should also be the principal focus of the relevant page.

Google provides separate documentation for (opens in a new tab)Product snippets (opens in a new tab) and (opens in a new tab)Merchant listings (opens in a new tab), each with feature-specific requirements.

Adding Product markup to a generic services page does not make that page an eligible shopping result.

LocalBusiness: Represent an actual physical business location

LocalBusiness markup should describe a real, qualifying business location and its accurate identifying information. Google supports LocalBusiness structured data, including applicable subtypes, but its required properties and quality guidelines must be satisfied for relevant features.

A national organization may operate several legitimate locations. Those locations should not be represented by a single invented address or by multiple fictional offices intended to improve local search visibility.

The following example demonstrates the basic vocabulary structure for an illustrative physical business:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Bicycle Repair",
  "url": "https://example.com/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Example Street",
    "addressLocality": "Exampleville",
    "addressRegion": "CA",
    "postalCode": "90000",
    "addressCountry": "US"
  }
}

The business and address are fictional placeholders and must not be published as real location information.

Google’s (opens in a new tab)LocalBusiness documentation (opens in a new tab) identifies the business name and physical address as required properties for its applicable feature.

Other fields may be relevant depending on the business, including opening hours, contact information, images, and departments.

A legitimate location-specific implementation should use an appropriate business subtype, verify the published address, and ensure the structured data is consistent with the information users can see.

A remote professional or nationwide service provider should not add physical-location claims that cannot be substantiated.

Service: Describe an offering without inventing a Google rich result

Service markup can describe a real service and its provider using Schema.org vocabulary, but Google does not document a general Service rich-result feature comparable to its Product or LocalBusiness features. Its legitimate purpose should therefore be framed as structured information representation rather than guaranteed enhanced presentation in Google Search.

A simplified Service graph may look like this:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/audit/#service",
  "name": "Technical Website Audit",
  "serviceType": "Technical SEO Auditing",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Consulting Company",
    "url": "https://example.com/"
  },
  "url": "https://example.com/services/audit/"
}

This example illustrates the relationship between a service and the organization that provides it.

The serviceType property is part of the Schema.org vocabulary, but its availability does not imply that Google provides a specific rich-result entitlement for that description.

A company may reasonably use Service markup when it accurately represents its offerings and is compatible with the site’s structured data architecture.

It should not claim that doing so automatically improves ChatGPT recommendations, Google AI Overviews, or conventional organic rankings.

Decide what to implement by page purpose

Decide what to implement from the page's purpose and a documented consumer, not from a template.

Implementation rule: Choose the markup because the content and intended consuming system justify it, not because a schema type appears on a list of supposed AI ranking factors.

Why is FAQPage and HowTo schema advice often outdated?

FAQPage and HowTo remain valid Schema.org vocabulary types, but Google no longer displays their former rich-result features in Search. Google discontinued How-to rich results in September 2023 and removed FAQ rich results effective May 7, 2026. Publishers should not implement either type solely to obtain those discontinued Google enhancements.

The difference between a surviving vocabulary type and a discontinued search feature is often overlooked in technical SEO advice.

A webpage can continue to contain helpful questions and answers or step-by-step instructions without requiring special markup. The content’s usefulness is not determined by whether it appears inside a particular JSON-LD structure.

FAQPage: The May 2026 change

In May 2026, Google announced that FAQ rich results would no longer appear in Search beginning May 7.

The associated documentation was removed in June 2026.

Before this change, FAQ rich-result eligibility had already been restricted significantly. However, the 2026 update ended the remaining Google Search feature.

Google’s (opens in a new tab)Search documentation updates (opens in a new tab) confirm the removal.

For publishers, this means that adding FAQPage structured data should no longer be recommended as a way to obtain Google’s former FAQ-rich search presentation.

The Schema.org type remains available for systems that genuinely consume it, but its presence should not be described as a general AI citation enhancement.

HowTo: The September 2023 change

Google discontinued How-to rich results across desktop and mobile Search in September 2023.

The change did not remove procedural content from Search or prevent publishers from writing practical instructions.

It removed a particular enhanced search-result presentation associated with HowTo structured data.

Google documented the change in its (opens in a new tab)August 2023 announcement and September update (opens in a new tab).

A tutorial published in 2026 that recommends using HowTo markup to obtain Google’s former step-by-step rich result relies on outdated product behavior.

Should existing FAQPage or HowTo markup be deleted?

The answer depends on its intended use.

If the markup is accurate, maintained, and consumed by another documented system, an organization may have a reason to retain it.

If it exists only to support a Google rich-result feature that has been discontinued, the original implementation objective no longer applies.

Removing the markup may simplify maintenance, but it should not be presented as a requirement for improving rankings.

The decision should consider whether the data serves another legitimate purpose and whether maintaining it creates unnecessary complexity or contradictory declarations.

Current interpretation

FAQPage and HowTo remain valid Schema.org types, but Google no longer shows their former rich results.

The continued existence of a Schema.org type is not evidence that a platform uses it for an active search enhancement.

This distinction should guide every schema recommendation, not only the treatment of FAQPage and HowTo.

How do you write accurate JSON-LD without inventing facts?

Accurate JSON-LD should be generated from a reliable source of truth, use valid Schema.org vocabulary, and reflect the information actually presented on the webpage. Its implementation should preserve stable entity identifiers, avoid contradictory declarations, and include only factual properties that can be supported. A larger schema graph is not necessarily more useful than a smaller, accurate one.

A common implementation mistake is treating JSON-LD as an independent content source.

A developer may write an Organization graph containing business information that does not appear elsewhere on the website. An SEO plugin may add generic author information regardless of who wrote the article. Product markup may contain a cached price that no longer matches the visible purchase information.

These failures create inconsistencies that syntax validation alone may not identify.

Establish an authoritative data source

The correct source depends on the entity.

For an article, the publishing system should ordinarily supply the headline, author, publication date, modification date, and canonical URL.

For a product, the commerce system should supply the actual price, inventory availability, and purchasing URL.

For a physical business location, verified organizational records should supply the address and contact information.

For author identity, an approved profile record should supply the name, official profile URL, and appropriate external identity references.

Where the same fact appears in several systems, its authoritative source should be defined before automated markup generation is implemented.

Construct entity relationships consistently

Use stable identifiers when multiple graph nodes refer to the same entity.

For example, an Article node can reference an existing Person node through its @id rather than redefining the author with different information in every template.

However, stable identifiers should not be confused with canonical URLs.

A canonical URL identifies the preferred representative of duplicate or substantially similar webpage content. An @id identifies a node in a structured data graph.

They can be related, and some implementation conventions use URLs with fragments for entity identifiers, but they serve different conceptual purposes.

The correct relationship should be determined by the actual entities represented.

Handle multiple authors accurately

Google’s Article documentation recommends representing individual authors separately.

If an article has two authors, each should appear as a separate Person or Organization record where appropriate.

Combining two authors’ names into a single Person name field would misrepresent the authorship relationship.

A publisher should also avoid using an Organization type for a human author merely because the author runs a business.

The entity type should describe the actual author.

Avoid unsupported credentials and claims

JSON-LD must not be used to introduce unverified professional credentials, fictional reviews, invented awards, inaccurate affiliations, or fabricated service capabilities.

An author may have valid certifications and published research, but those credentials should be accurately documented before being represented in machine-readable form.

The presence of a claim in structured data does not make it true.

A factual review should examine the underlying evidence, not only the syntax.

Prevent duplicate schema generation

Content management systems can create structured data through several mechanisms.

On a WordPress website, a theme, an SEO plugin, a schema extension, and a custom code snippet may all generate JSON-LD.

Multiple structured data blocks are not inherently invalid, and several nodes may correctly describe different entities.

The problem occurs when those blocks define contradictory information about the same entity or duplicate the same publication with inconsistent identifiers.

For example, one plugin may identify the publisher as a Person while another creates a separate Organization node using the same name.

That conflict should be resolved in accordance with the actual publishing relationship.

A practical publishing control

Before deployment, confirm that each important field has an accountable source.

The quality of structured data should be evaluated based on factual consistency and the support for feature requirements, not on how many properties have been populated.

How do you audit schema in raw HTML and JavaScript-rendered pages?

A schema audit should inspect both the initial HTML response and the rendered document to determine which structured data is actually delivered and how its contents change during rendering. This is necessary because server templates, SEO plugins, JavaScript applications, or third-party scripts can insert JSON-LD. A schema block visible in browser developer tools is not always present in the original response.

The distinction matters for search systems that process pages differently.

Google supports JavaScript-generated structured data and can process markup available in the rendered document. However, Google’s behavior does not establish that other AI search crawlers render JavaScript in the same way.

Therefore, the audit should record what is available at each stage without assuming universal crawler capabilities.

Step 1: Retrieve the original HTML

Save the raw HTML the server returns and look for the JSON-LD in it.

A basic command-line request can save the returned page:

curl -sS -L \
  -D response-headers.txt \
  -o page-source.html \
  https://example.com/page/

Inspect the saved document for JSON-LD script elements:

<script type="application/ld+json">
  ...
</script>

The HTTP response should also be checked to ensure the intended document was delivered rather than a redirect, a login page, or a security challenge.

A successful HTTP 200 response alone does not establish that the expected article content was returned.

The request also reflects the testing client’s behavior, not necessarily that of Google’s or another provider’s authenticated crawler.

Step 2: Inspect the rendered DOM

Compare the rendered DOM with the raw HTML to see what JavaScript adds, removes or changes.

Open the page in a modern browser and inspect its rendered document after relevant JavaScript has executed.

Determine whether JSON-LD was inserted, modified, duplicated, or removed.

Compare the rendered graph with the initial HTML.

Important findings may include:

• JSON-LD available only after JavaScript execution.
• Duplicate article nodes generated by separate plugins.
• Canonical identifiers changing during rendering.
• Product prices updated in visible content but not in structured data.
• Missing author nodes caused by template conditions.
• JavaScript failures that prevent structured data from being generated.
• Markup describing content not present in the rendered page.

These observations should be recorded individually.

A page should not be classified as failing AI search merely because some markup is generated through JavaScript.

Step 3: Review the rendered page through Google testing tools

Google’s (opens in a new tab)JavaScript-generated structured data guidance (opens in a new tab) recommends using the Rich Results Test with the live URL to examine supported markup.

The URL-based test is preferable when JavaScript behavior matters, because copying only a code snippet into a validator may not reproduce the actual rendering process.

For supported rich-result types, inspect the detected markup and eligibility warnings.

Where the Rich Results Test does not support a type, inspect the rendered HTML and evaluate generic Schema.org validity separately.

A lack of a rich-result feature does not mean the schema vocabulary is invalid.

Step 4: Pay special attention to product data

Google recommends delivering Product markup in the initial HTML for merchant implementations where possible.

Its documentation warns that JavaScript-generated product information can introduce reliability concerns for shopping crawls, particularly where price or inventory information changes frequently.

This does not make JavaScript-generated Product markup universally invalid.

It means implementation choices should consider the freshness and reliability of the information supplied.

An e-commerce website should not assume that a working browser interface guarantees that every relevant product crawler obtains the latest offer.

Step 5: Compare the three representations

Preserve three distinct records of the page and compare them before you draw a conclusion.

The audit should preserve three distinct records:

The final interpretation should consider all three.

If an Article node identifies an author who does not appear in the relevant editorial content, this requires investigation regardless of whether the JSON-LD is syntactically correct.

If the raw HTML lacks JSON-LD but Google’s rendering test detects the correct markup, the finding differs from a situation where the markup is never generated.

The purpose of the audit is to identify the actual delivery condition, not to assign a blanket pass or fail based on one inspection method.

Schema Markup Validator, Rich Results Test or URL Inspection: which should you use?

The Schema Markup Validator checks general Schema.org vocabulary and syntax, Google’s Rich Results Test checks eligible Google search-enhancement markup, and Search Console URL Inspection provides information about how Google crawls, indexes, and processes a URL. These tools answer different questions. Neither independently proves that a webpage will receive AI citations.

A complete schema audit should use the tool appropriate to the claim being tested.

Schema Markup Validator

The (opens in a new tab)Schema Markup Validator (opens in a new tab) is appropriate for general inspection of structured data.

It can help identify vocabulary types, properties, parse problems, and structural inconsistencies.

Its primary purpose is not to determine eligibility for Google Search features.

A Service node can be valid in the Schema.org vocabulary even though Google does not provide a general Service rich-result feature.

Therefore, a passing generic validation result should not be described as a Google feature approval.

Google Rich Results Test

The (opens in a new tab)Google Rich Results Test (opens in a new tab) evaluates structured data for supported Google search enhancements.

It can identify qualifying types, applicable errors, warnings, and relevant page rendering information.

However, it does not validate every Schema.org type as a Google search feature.

An unsupported type may not appear as eligible even though the vocabulary is technically legitimate.

Google also explicitly states that passing the test does not guarantee the relevant enhancement will appear in Search.

Google Search Console URL Inspection

The (opens in a new tab)URL Inspection tool (opens in a new tab) provides information about Google’s indexed representation of a URL.

It can help investigate indexation, crawl accessibility, canonical selection, and supported live testing behavior.

Indexed-state information and live testing must be interpreted separately.

A successful live test does not guarantee indexing, and an indexed URL does not guarantee a structured data enhancement.

Validation decision table

Each tool answers a different question, so one passing test never replaces the others.

Why one successful test is insufficient

A markup implementation can be syntactically valid while describing false information.

It can be truthful while using a schema type that the target platform does not support for the intended feature.

It can be eligible for a supported Google enhancement without appearing in the search results for a particular query.

It can also appear alongside increased AI citations without being responsible for that increase.

The validation process must preserve these differences.

Severity should reflect the consequence

A missing required property for a feature the publisher actively uses may deserve immediate correction.

An invalid URL in an important article’s author markup may require a scheduled fix.

The absence of an optional Service node does not ordinarily justify the same priority.

The appropriate response depends on the documented feature, the affected page, the materiality, and the confidence in the observed failure.

What are the common structured data errors and misleading AI SEO claims?

The most important schema errors are those that misrepresent real information, prevent eligibility for intended Google features, or create contradictory relationships among entities. Missing optional schema types and unsupported promises about AI citations should not be treated as equivalent technical failures.

A reliable schema audit should distinguish actual implementation errors from speculative optimization recommendations.

Error 1: Implementing every available schema type

Adding Organization, Service, Product, FAQPage, HowTo, and several other types to every page does not, by default, create a stronger representation.

Each node should describe the relevant page or an appropriately related entity.

Correction: Map the page’s actual content and intended search features before choosing markup.

Error 2: Creating multiple conflicting identities

Different plugins may define separate author or organization nodes with inconsistent identifiers and names.

Correction: Establish an approved entity graph and consistent references.

Error 3: Adding unsupported credentials or authority claims

A valid JSON-LD property does not verify the information it contains.

Correction: Publish accurate factual evidence before expressing the corresponding claim in markup.

Error 4: Marking up content that users cannot see

Google’s structured data guidelines prohibit misleading markup and require relevant information to be represented in visible page content.

Correction: Compare the actual webpage with the generated structured data.

Error 5: Using Product markup for ineligible commercial pages

A service page or third-party product listing may not satisfy Google’s merchant listing requirements.

Correction: Apply the specific Product feature guidelines appropriate to the real page and purchasing arrangement.

Error 6: Inventing reviews, ratings, prices, or availability

Generated testimonials or fictional commercial properties can make structured data misleading and may violate applicable search policies.

Correction: Use genuine, current business information.

Error 7: Assuming FAQPage and HowTo produce rich results

Google’s former FAQ and How-to rich results are discontinued.

Correction: Evaluate those types only against legitimate present-day use cases.

Error 8: Treating a valid schema test as an AI ranking certificate

A validator cannot establish a direct citation benefit.

Correction: Separate implementation success from observed downstream outcomes.

Error 9: Confusing Person, Organization, and WebSite

These nodes describe different entities and should not be merged indiscriminately.

Correction: Establish the real relationships before generating the graph.

Error 10: Adding arbitrary sameAs links

References to unrelated articles or profiles do not automatically establish entity identity.

Correction: Use only appropriate, verifiable identity representations.

Error 11: Ignoring JavaScript-generated differences

The markup present in raw HTML may differ from the rendered DOM.

Correction: Inspect both representations and apply platform-specific testing.

Error 12: Claiming AI systems universally prefer JSON-LD

Different AI retrieval systems may use structured data differently, and many details remain undisclosed.

Correction: Distinguish documented platform behavior from technical hypotheses.

Error 13: Treating missing schema as a technical eligibility blocker

Google does not require special schema for its generative AI Search features.

Correction: Do not classify the absence of optional markup as an AI citation eligibility failure.

Error 14: Assuming every post-deployment increase is causal

Citation behavior can change for reasons unrelated to structured data.

Correction: Record baseline conditions, comparison groups, concurrent changes, and uncertainty.

Corrective-action matrix

Match each common error to its corrective action, then re-verify the result.

This classification should be adjusted to the website’s actual circumstances rather than treated as a universal severity standard.

Can schema changes be connected to AI citation outcomes?

Changes in schema implementation can be compared with AI visibility observations, but a before-and-after increase in citations does not establish that the markup caused the increase. A credible evaluation should document the deployment, verify its technical impact, preserve the relevant baseline, and account for concurrent changes in content, demand, indexing, platform behavior, and source selection.

The research should begin by defining two separate outcomes.

The first is whether the intended structured data was implemented correctly.

The second is whether search appearance or AI citation activity changed.

These outcomes require different evidence.

Outcome A: Technical implementation success

The technical experiment should verify that the markup appears in the relevant delivered page, parses correctly, accurately describes the visible content, and meets any applicable Google feature requirements.

If the objective is to correct an invalid Product node, technical success can be established by confirming that the original error no longer exists and the page meets the applicable requirements.

That is a valid improvement even if the page receives no measurable AI citations.

Outcome B: Observed search or citation activity

The visibility assessment should examine available first-party reports and controlled observations.

For Google, the dedicated Generative AI Performance report provides impressions for supported AI Overviews and AI Mode experiences.

For Microsoft, Bing Webmaster Tools offers AI citation reporting.

For additional AI experiences, a well-documented answer-monitoring process may record citations for a fixed set of prompts.

These are distinct reporting populations and should not be combined into a single undifferentiated citation measure.

The challenge of causal inference

Suppose a publisher adds Article markup to several research pages and later observes more citations.

The increase could be associated with the implementation, but other explanations remain possible.

The pages might have received new backlinks, attracted more topical demand, been updated editorially, or become more relevant to the sampled questions.

The AI platform might also have changed its retrieval or citation behavior.

Without a credible comparison, the timing alone cannot establish the markup’s contribution.

Design a controlled evaluation

A practical experiment could compare similar pages with and without a defined schema change.

The pages should be selected based on comparable purpose, content characteristics, baseline exposure, and technical conditions where possible.

The implementation should avoid modifying unrelated SEO elements during the same experimental period.

A sufficient observation period should be selected based on event volume and the stability of the relevant reporting.

The study must preserve the dates when changes were deployed and when they became observable to the relevant platform.

Suggested experimental record

Record every experiment with its treatment, control, windows, metrics and concurrent changes.

Interpret results independently by source

An increase in Google generative AI impressions should not be treated as equivalent to an increase in Bing citations.

Likewise, a higher number of citations in a fixed sample of ChatGPT prompts does not represent the total citation activity across all ChatGPT users.

Each source should retain its own metric definitions and denominator.

A responsible experiment may conclude that the quality of technical schemas improved while the effects of citations remained undetermined.

That is an acceptable result.

What the existing research means for experimentation

The May 2026 Ahrefs study found no convincing positive citation uplift from adding JSON-LD across the platforms it tested.

A smaller website experiment should not claim to overturn those findings because a few monitored prompts began citing the site after a schema deployment.

Instead, the purpose should be to establish whether the implementation was correct, whether a documented feature became eligible, and whether there is sufficient evidence to justify further research into downstream effects.

Research conclusions should remain proportional

A useful technical case study need not demonstrate increased citations.

It can show that an invalid schema implementation was corrected, a contradictory author graph was reconciled, or an inappropriate Product node was removed.

Those are verifiable technical outcomes.

Citation changes, if observed, should be reported separately and evaluated according to the strength of the research design.

What is the complete schema evidence audit checklist?

A complete Schema Evidence Audit should verify the presence, validity, factual consistency, platform support, and observed outcomes of structured data without treating all failures as equally important. The audit must distinguish required fields from optional properties, documented Google features from generic Schema.org vocabulary, and technical correctness from AI citation performance.

The following inventory consolidates the practical checks required by the methodology.

A. Structured data presence and delivery

Presence and delivery checks confirm the markup is actually there and delivered correctly.

B. Syntax and vocabulary validity

Syntax and vocabulary checks confirm the markup parses and uses valid Schema.org types and properties.

C. Factual consistency

Factual consistency checks confirm every declared fact matches the visible page.

D. Search feature support

Feature support checks confirm the target Google feature is current and its requirements are met.

E. Outcome measurement

Outcome checks keep technical verification separate from any observed search or AI result.

Required audit statuses

Give each check one of five results, and record severity separately.

Every check should receive one of five results:

Pass, Fail, Inconclusive, Not Tested, or Not Applicable.

Severity should be recorded separately.

A missing optional schema type should not automatically receive a critical severity rating.

An inaccurate or misleading structured claim may deserve a more urgent correction than an ordinary missing recommended property.

Example findings register

Every finding starts as Not Tested until real evidence replaces it.

This table describes an audit template. It does not claim that any specific website has these problems.

Final decision rules

If the markup is inaccurate, correct the underlying facts or remove the misleading declaration.

If the markup is technically invalid, correct the syntax or vocabulary usage.

If the intended Google feature is unsupported, change the implementation objective.

If the markup is valid but the page does not receive AI citations, investigate AI visibility independently.

If a technical improvement has been completed, verify its implementation without automatically attributing subsequent changes in ranking or citations to it.

The final audit should therefore produce a clear record of what was tested, what was found, what remains uncertain, and which actions are justified.

Frequently asked questions about schema markup and AI search

Does schema markup help AI search?

Schema markup can describe entities and relationships in a standardized format, and Google documents its usefulness for certain Search applications. However, Google does not require special schema for AI Overviews or AI Mode, and existing research has not established that adding JSON-LD alone reliably improves AI citations. Any benefit should be assessed against the specific platform and intended use case.

Does Google require structured data for AI Overviews?

No. Google’s official generative AI optimization guidance states that special Schema.org markup is not required for AI Overviews or AI Mode. Pages must satisfy the applicable Search eligibility requirements, and structured data remains relevant for supported search enhancements rather than serving as a separate AI citation requirement.

Can schema markup improve ChatGPT citations?

A reliable positive effect has not been established. Ahrefs’ May 2026 study reported a small positive estimate for ChatGPT that was not statistically distinguishable from zero. OpenAI’s public crawler documentation does not establish a universal Schema.org requirement or specific JSON-LD citation-weighting mechanism.

Which schema type is best for AI search?

There is no universally best AI search schema type. The correct markup depends on the content and intended application. Article markup may suit editorial publications, Organization markup may represent organizational information, and Product markup may support eligible product features. The relevant type should be selected for accuracy and documented platform support, rather than an assumed AI-ranking advantage.

Does Article schema help Google recognize authors?

Article markup can explicitly describe an article’s author and related publication information. Google documents supported author properties and recommends accurate author identity references. However, markup alone does not verify expertise, guarantee search visibility, or specify how an AI search system selects sources.

Is FAQ schema still useful in 2026?

FAQPage remains a legitimate Schema.org vocabulary type, but Google discontinued FAQ rich results effective May 7, 2026. Publishers should not implement it solely to obtain the former Google FAQ presentation. It may still serve another system that explicitly consumes it, provided the information is accurate.

Does HowTo schema still generate Google rich results?

No. Google discontinued How-to rich results in September 2023. The Schema.org HowTo type still exists, but its vocabulary validity does not restore the former Google Search feature.

Does JSON-LD improve rankings?

Google documents structured data primarily to communicate information and to support eligible search features. It does not guarantee a general increase in ranking from adding JSON-LD. Ranking effects should not be inferred merely because a marked-up page appears prominently in Search.

Can schema markup generate a Google Knowledge Panel?

Structured data may help describe an organization’s or person’s identity, but it does not automatically generate a Knowledge Panel. Google combines information from various sources and uses its own systems to determine which entities and information appear. A valid Organization or Person graph is not an entity verification certificate.

Is schema markup necessary for a service website?

No universal requirement applies to every service website. Relevant Organization, Person, WebSite, BreadcrumbList, Article, or Service markup may be appropriate depending on the site’s content and intended features. A generic Service node does not automatically qualify a service page for a special Google rich result.

Should schema be included in the raw HTML?

For reliability, important structured data can be included in server-delivered HTML. Google can also process JavaScript-generated structured data when it appears in the rendered DOM. For merchant product information, Google recommends delivering HTML initially where possible, as frequently changing prices and availability can create additional crawling and rendering challenges.

Why does schema pass validation but fail to generate rich results?

A page may contain valid Schema.org markup while using a type unsupported for the intended Google feature. It may also fail feature-specific requirements, conflict with visible content, or be ineligible under Google’s broader Search policies. Even a fully eligible implementation is not guaranteed a rich-result presentation.

How do I test whether Google recognizes my schema?

Use the Schema Markup Validator for general vocabulary inspection, Google’s Rich Results Test for supported Google search features, and Search Console URL Inspection for relevant crawl and indexing evidence. Compare the markup with the visible page and review any feature-specific requirements. These checks establish technical conditions, not guaranteed AI citation performance.

Does adding more schema increase entity authority?

No established rule states that a larger structured data graph creates greater entity authority. A coherent graph can represent relationships more explicitly, but authority and credibility depend on evidence beyond markup. Unsupported claims do not become trustworthy because they are expressed as JSON-LD.

Can I measure whether schema improves AI citations?

You can monitor citation activity before and after deployment, ideally using comparable control pages and stable measurement procedures. However, the resulting changes may reflect multiple factors. A technically valid implementation is directly verifiable, while a causal claim about increased AI citations requires stronger evidence than timing alone.

Final analysis: structured data describes evidence; it does not create it

Structured data remains an important component of technical search optimization because it provides a standardized way to describe entities, attributes, and relationships. It can make authorship information explicit, represent organizational identity, communicate product details, and support eligibility for selected search enhancements. These applications are documented, technically meaningful, and independently verifiable.

However, the existence of legitimate structured data applications should not be extended into unsupported claims about AI-generated answers. Google’s current guidance does not require special Schema.org markup for its generative AI Search features, and the available empirical research has not established that adding JSON-LD alone reliably increases citations across major AI search experiences.

The distinction is not between schema being useful and schema being useless. It is between what the technology is designed to communicate, what individual search platforms document as supported behavior, and what measurable outcomes can actually be attributed to implementation.

A valid structured data graph can describe an author without establishing the author’s credibility. It can identify a publisher without proving that the publisher is authoritative. It can communicate product information without guaranteeing a shopping result. It can provide explicit relationships without ensuring that an AI assistant will select the associated webpage as a source.

These limitations should not discourage accurate implementation. They should encourage better technical decision-making.

Publishers should begin by identifying the information that deserves structured representation, selecting the appropriate Schema.org vocabulary, and ensuring that the declared facts match the visible webpage. The implementation should then be tested for syntax, entity consistency, platform support, and eligibility for relevant features.

Where citation visibility is important, it should be measured separately through appropriately documented observations. Any claimed effect of the markup itself should be evaluated against plausible alternative explanations.

This approach yields more reliable conclusions than either indiscriminately adding schema to every page or dismissing structured data, since the direct benefit of AI-driven citation remains unproven.

For technical SEO specialists, developers, and website owners, the practical objective is not to create the largest possible JSON-LD graph. It is to create an accurate, maintainable representation of real information that serves documented search applications and can withstand independent verification.

Structured data can describe evidence. It cannot fabricate evidence, confer authority on its own, or guarantee that an AI system will cite the page.

That is the foundation of responsible schema implementation in the age of AI search.

Sources and method

The platform statements and research findings in this guide rest on the primary documentation and studies below; the JSON-LD examples are fictional and the audit tables are templates.

The following sources establish the platform requirements, feature limitations, implementation guidance, and research findings addressed in this article.

1. Google: Introduction to Structured Data (opens in a new tab)
2. Google: General Structured Data Guidelines (opens in a new tab)
3. Google: Optimizing for Generative AI Features (opens in a new tab)
4. Google: Article Structured Data (opens in a new tab)
5. Google: Product Snippet Structured Data (opens in a new tab)
6. Google: Merchant Listing Structured Data (opens in a new tab)
7. Google: LocalBusiness Structured Data (opens in a new tab)
8. Google: Generate Structured Data with JavaScript (opens in a new tab)
9. Google: Structured Data Testing Tools (opens in a new tab)
10. Google: Search Documentation Updates (opens in a new tab)
11. Google Search Console: URL Inspection (opens in a new tab)
12. Google Search Console: Generative AI Performance (opens in a new tab)
13. Schema.org: Service Type (opens in a new tab)
14. Ahrefs: We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved (opens in a new tab)
15. OtterlyAI: Schema Markup’s Real Impact on AI Search (opens in a new tab)

Method The JSON-LD examples in this article use fictional demonstration information. They have not been independently submitted to live structured data validation tools. The Schema Evidence Audit and experimental procedures are implementation methodologies rather than reports of completed tests on a real website. No AI citation uplift, ranking improvement, or commercial result has been fabricated.