Schema markup for AI search: a practical guide

By LinkinGrow. Published October 14, 2026. Last reviewed October 14, 2026. About a 15 minute read.

Schema markup makes a page’s factual structure more explicit. It does not make an AI engine trust a business, cite a page, or recommend a product on command.

For marketers adapting to AI search, that distinction matters. Structured data can describe who published an article, what a product costs, or how a page fits into a site. Those are useful tasks. Treating it as a hidden ranking lever turns a sensible technical practice into an unsupported promise.

This guide explains the standards, the documented platform requirements, and a practical way to implement and maintain markup. Recommendations about workflow and measurement are LinkinGrow analysis, not results from a controlled AI visibility experiment.

The short answer: describe reality, not a desired ranking

Schema markup is structured information embedded in a page using a shared vocabulary, usually Schema.org. Search systems can use supported markup to interpret specific facts and determine eligibility for particular search appearances. Eligibility is not a guarantee of display, and display is not the same as being recommended in an AI answer.

Google’s AI features guidance says there are no additional technical requirements or special schema needed for AI Overviews or AI Mode. Pages must meet the relevant Search eligibility conditions, including being indexed and eligible to appear with a snippet. Ordinary SEO foundations and helpful, accessible content remain important.

The useful question is therefore not “Which schema forces AI to cite us?” It is “What facts on this page can we describe accurately, using a supported vocabulary, without contradicting what a reader sees?”

Schema, structured data, and JSON-LD are not the same thing

Structured data is the broader concept

Structured data represents information in explicit fields and relationships rather than leaving everything inside prose. A product page can say that an item costs $79 in a sentence; structured data can label the amount as a price and identify USD as its currency. The visible price still needs to be correct.

Schema.org supplies the vocabulary

Schema.org’s data model defines types and properties for describing entities. A type says what something is, such as an Organization, Person, Product, or Article. Properties describe attributes and relationships, such as name, author, publisher, or offers. The vocabulary is broader than any single search engine’s supported features.

JSON-LD is one way to express it

JSON-LD is a W3C standard for expressing linked data in JSON. On a webpage, it commonly appears inside a script element with the type application/ld+json. It is not an instruction to execute code or persuade an assistant. It is a data representation. Other formats, including Microdata and RDFa, also exist.

In JSON-LD, @context identifies the vocabulary, @type identifies a class, and @id identifies an entity. An @graph can hold multiple related entities. These are structural tools, not ranking signals with known weights. A valid graph can still contain false claims, unsupported properties for a search feature, or facts that are out of date.

What schema can—and cannot—do in AI search

AI search is not one uniform pipeline. A system may retrieve indexed pages, consult other sources, use tools, or generate an answer without live web search. You cannot infer from a JSON-LD script on your site that every engine reads it, retains it, or uses it when selecting brands.

Google documents the role of structured data in specific Search features, while explicitly saying special AI schema is unnecessary. Bing’s webmaster guidelines connect discovery, indexing accuracy, and content clarity with eligibility in AI-powered experiences. Neither statement establishes a universal schema-to-citation formula across providers.

OpenAI’s crawler documentation separates OAI-SearchBot, which concerns search discovery, from GPTBot, which concerns content that may be used for model training. That is an access-policy distinction, not a promise that schema markup will earn a recommendation. Crawl permissions, indexing, retrieval, source use, and answer generation are separate stages.

Our practical interpretation is to remove avoidable ambiguity in the public record. Accurate markup can complement accurate prose, consistent identity, good internal navigation, and genuine evidence. It cannot replace those things or prove that an engine regards a publisher as authoritative.

Choose types that fit the page and the documented use case

Editorial pages: explain provenance

Google’s Article documentation covers Article, NewsArticle, and BlogPosting. Choose the type that describes the content rather than calling every evergreen guide a news story. Identify the real author or responsible organization, the headline, and truthful publication and modification dates. Do not invent a named expert or credentials to make the page seem stronger.

Organizations and people: make identity consistent

Organization markup can describe administrative and identity details. Keep the business name, official URL, logo, and contact information consistent with the site. A Person profile should represent an actual person with accurate affiliations. Markup is a statement about identity; it is not verification of expertise.

Products: keep transactional facts current

Google’s Product snippet guidance defines a specific feature with its own requirements. Do not assume all Product markup qualifies for every shopping appearance. Check the documentation for the intended feature, and keep offers synchronized with the visible page. Never add AggregateRating values without legitimate underlying ratings and compliance with the relevant policies.

Navigation: express a real hierarchy

BreadcrumbList markup describes a page’s position in a navigational hierarchy. It is not a list of target keywords. For a guide under Blog, use actual labels and working URLs. Breadcrumbs can clarify location, but they do not certify the quality of the article.

Schema.org also contains types such as Service and FAQPage. A vocabulary entry is not evidence of a Google rich result or a special AI benefit. Before adding any type, ask whether it accurately describes the page and whether the target platform documents a relevant use. A useful question-and-answer section does not need a visibility promise attached to it.

Connect entities without inventing authority

A page, an article, its author, and its publisher are related but distinct. Stable identifiers let you describe those relationships without repeatedly creating slightly different versions of the same entity. For example, an article’s publisher can reference the organization’s @id, while its author references an actual author profile.

Use a consistent identifier such as your official homepage URL with a #organization fragment. This is an entity identifier, not necessarily a clickable section on the page. If the business changes its name or URL, review references deliberately instead of generating a new identity on every page.

Use sameAs for URLs that identify the same entity, such as an official profile—not for publishers you want to be associated with, competitors, press articles that merely mention you, or unrelated businesses with similar names. Use author and publisher for the relationships those words actually describe.

Linking entities in your own markup does not mean a search engine has accepted a knowledge graph entry or verified the relationships. It is your assertion. The underlying pages and external records must support it. A complicated graph built from weak evidence is still weak evidence.

A worked JSON-LD example for an editorial guide

The following fictional example connects a publisher, an author, a webpage, and a blog post. The domain, organization, and author are placeholders; the example is not a record of a real publication or a complete feature-eligibility template. Replace them with verified facts before using a similar structure.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Research",
      "url": "https://example.com/"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/example-author#person",
      "name": "Example Author",
      "url": "https://example.com/team/example-author"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/guides/inventory#webpage",
      "url": "https://example.com/guides/inventory",
      "name": "How batch tracking works",
      "mainEntity": {
        "@id": "https://example.com/guides/inventory#article"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/guides/inventory#article",
      "headline": "How batch tracking works",
      "description": "A guide to batch identifiers, traceability, and implementation limits.",
      "datePublished": "2026-10-14",
      "dateModified": "2026-10-14",
      "author": {
        "@id": "https://example.com/team/example-author#person"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": {
        "@id": "https://example.com/guides/inventory#webpage"
      }
    }
  ]
}

Place a completed JSON-LD object inside a script element of type application/ld+json. Generate it from the same editorial data that supplies the visible headline, byline, and dates. This reduces discrepancies and makes updates easier to maintain. Safely serialize dynamic values; do not assemble scripts by joining untrusted strings.

The example omits an image because it supplies no real image URL. Add an appropriate, crawlable image when you have one and the target feature calls for it. Do not fabricate a logo, rating, or author profile just to populate an optional field. Consult the current Article documentation for recommended properties and image guidance.

The organization and person nodes describe the fictional entities. The webpage node describes the document location. The BlogPosting node describes the editorial work. References connect them through @id. Keeping those distinctions clear is more useful than adding every available Schema.org property.

Implement, validate, and inspect the published page

1. Audit what is already present

Check rendered pages and their source for existing structured data. Themes, plugins, commerce systems, and custom code may all emit markup. Two matching descriptions are not automatically a problem, but contradictory prices, authors, or organization identities are. Choose a responsible source for each set of facts.

2. Build from authoritative site data

Article fields should come from the editorial record. Product fields should come from the product and offer records. Organization fields should come from verified business details. Make missing information explicit in your workflow; an unknown fact is not a reason to invent a default value.

3. Validate at more than one level

Use the Schema Markup Validator to inspect vocabulary and structure. Use Google’s Rich Results Test for supported Google features. A type can be valid Schema.org markup without producing a supported rich result; that is not inherently an error.

Neither tool verifies every factual claim or guarantees display. Manually compare the markup with the visible page. Google’s structured data guidelines require representative, accurate content and distinguish technical validity from quality eligibility. Warnings deserve review, but do not add a false field simply to remove a warning.

4. Check access and the live version

Verify the final URL, response status, canonical, indexing controls, and access to the page and any required images. Inspect the version that a crawler can retrieve, not only what your editor displays. When available, use Search Console URL Inspection and relevant enhancement reports. Passing a code-only test is not the same as confirming a deployed page.

5. Keep markup maintained

Assign owners and review triggers: price changes, discontinued products, new authors, name changes, and substantive article updates. Keep modification dates honest rather than refreshing them daily to imply editorial activity. Review representative pages after template changes, because one template defect can affect hundreds of URLs.

Common mistakes that create ambiguity or risk

Marking up claims a reader cannot verify. Hidden endorsements, fictional awards, invented ratings, and inaccurate credentials do not become acceptable because they are machine-readable. Schema should reinforce the page’s factual record, not create a second, more flattering version.

Using the wrong type for the desired appearance. A service landing page is not automatically a product review. An evergreen explanation is not breaking news. Match the content and the relevant feature documentation rather than copying a competitor’s markup.

Leaving stale offers and identities. If a visible page says a product is unavailable while its Offer says InStock, the problem is factual inconsistency. Fix the shared data source, not only the one page where someone noticed it.

Treating all validation warnings as mandatory facts. Some fields are recommended rather than required for a feature. Know the difference. Complete legitimate information where possible, but never invent a review, address, or image to get a cleaner test result.

Promising a citation boost. A vendor’s “AI schema score” is a vendor-defined metric unless its method and validation establish otherwise. Ask what it measures. Correct markup, rich-result eligibility, AI source use, and commercial outcomes belong on separate scoreboards.

Measure technical quality separately from AI visibility

Begin with implementation measures: which page templates have appropriate markup, whether their data matches visible facts, which errors remain, and whether eligible pages can be retrieved. These measures tell you whether the deployment is sound, not whether it caused a change in answers.

Then observe the search features for which the platform offers reporting. Keep impressions, clicks, and supported enhancement data distinct from AI mentions, citations, and recommendations. A rich-result appearance is not an AI recommendation. An assistant citing your article does not necessarily recommend your business.

If you investigate AI visibility, preserve the exact questions, locale, engine, search mode, timestamps, and source links across repeated observations. Log when markup changed and what else changed. A model update, new content, indexing changes, competitor activity, or seasonality can explain a different result.

A simple before-and-after comparison can generate a hypothesis, but cannot isolate schema as the cause. A stronger evaluation needs comparable pages or question groups, consistent collection, and explicit limits. We do not present a universal percentage lift or guaranteed timeline because the linked sources do not establish one.

A practical rollout plan for a marketing team

Start with a small factual inventory

List your main page templates, existing types, the owner of each field, and any contradictions. Prioritize identity, article provenance, actual navigation, and current product facts where relevant. Fix a misleading visible claim before describing it more precisely in markup.

Deploy one representative page per template

Validate the graph and any intended search feature, inspect the published page, and compare it with the editorial or product record. Include unusual cases: an organization byline, an unavailable item, a page without an image, or an article that has never been modified. Defaults should not invent facts for those cases.

Expand and review after changes

Roll out the verified pattern across the template, check a sample of URLs, and record the deployment date. Repeat checks after publishing-system updates and factual changes. Use AI to identify possible inconsistencies if useful, but have a responsible person verify the claims before release.

The goal is a maintainable factual layer, not the largest graph. If a proposed field has no reliable source, omit it. If a proposed page adds no useful information, markup will not rescue it. Editorial quality and technical clarity should reinforce each other.

Common questions about schema markup for AI search

Is there a special schema type for AI Overviews or AI Mode?

Google says special schema is not needed for its AI features. Use accurate, applicable structured data for the content and documented search features. Do not confuse a newly marketed “AI schema” package with an official requirement.

Will JSON-LD make ChatGPT cite my website?

No guarantee follows from adding JSON-LD. OpenAI documents search crawler access, but the cited documentation does not establish a schema-based citation formula. Useful public content and correct access are distinct from source selection.

Should every page have Article markup?

No. Use Article or an appropriate subtype when the page is an article. A contact page, product listing, and service overview serve different purposes. More markup is not automatically better markup.

Can we add ratings without publishing reviews?

Do not fabricate ratings or imply experiences that did not occur. Any rating markup needs legitimate evidence and compliance with the relevant platform policies. If you publish observations rather than reviews, describe the editorial work accurately.

Does a successful test prove the page will get rich results?

No. A test can identify technical eligibility or issues for supported features. Quality, access, indexing, and the platform’s selection still matter. Google explicitly does not guarantee appearance even when structured data is correct.

What should a small business do first?

Correct its public identity and core factual pages, check access and existing markup, and maintain a small number of appropriate types. That is a more defensible investment than buying a guaranteed AI ranking claim.

Sources, scope, and disclosure

This educational guide was prepared with AI assistance using the linked primary documentation. It reports no original benchmark, client outcome, or hands-on test of an engine’s schema consumption. The implementation sequence and measurement advice are LinkinGrow analysis. The JSON-LD example is fictional and is displayed as code, not published as this page’s identity. Platform requirements can change; consult current documentation before consequential decisions.

1. Google: AI features and your website
2. Google: General structured data guidelines
3. Schema.org: Data model
4. W3C: JSON-LD 1.1 specification
5. Google: Article structured data
6. Google: Organization structured data
7. Google: Product snippet structured data
8. Google: Breadcrumb structured data
9. OpenAI: Overview of OpenAI crawlers
10. Bing: Webmaster guidelines