What structured data can and cannot do for AI search

What structured data can do

Structured data provides explicit clues about a page's meaning, such as an organization, product, article, or other supported entity. Google recommends JSON-LD in many cases because it is straightforward to maintain, but the data must describe the page where it appears and match what people can see.

For supported Google Search features, complete and policy-compliant markup can make a page eligible for a richer appearance. A valid result in the Rich Results Test means the markup is technically suitable for that feature; Google still decides whether to show the feature. Markup can also help keep machine-readable identity facts consistent across a site.

Sources for this section: Google: introduction to structured data, Google: structured data general guidelines.

What it cannot do for AI answers

Google explicitly says there is no special schema.org structured data required to appear in AI Overviews or AI Mode. Adding FAQ, HowTo, or a made-up 'AEO schema' does not bypass crawl and indexing requirements or force a supporting link. A rich result eligibility test is not an AI citation test.

Markup cannot repair a page that is blocked, noindexed, thin, or unclear to readers. It also cannot make a claim true. If the visible page says one thing and JSON-LD says another, that mismatch can violate Google's structured data guidance and undermine the site's credibility.

Sources for this section: Google: AI features and your website, Google: structured data general guidelines.

Work through one page before generating markup

Imagine a software product page that visibly states its product name, publisher, a concise description, a current screenshot, and plan information. The first task is editorial: make sure the page itself explains what the software does, who it serves, and any qualification on the plan information. A schema generator should not become the source of truth. Once the public copy is approved, list which visible facts could map to an applicable supported structured-data type and which cannot be described accurately yet.

For a supported software or product result, consult Google's documentation for the exact feature and required properties rather than copying a generic snippet from another site. Map a product name to the visible heading, the description to a real summary, the image to an image of that product, and any offer details to the plan and price actually shown. If prices vary by region or sales quote, avoid inventing one to satisfy a field. A feature may have requirements that your page does not meet; leaving that feature unused is better than publishing incorrect data.

Put the markup on the canonical page it describes. Use consistent organization naming and URL identifiers where relevant. If the visible page is updated, update the structured data in the same release. For a guide rather than a product page, article metadata should reflect the real title and publication details; it should not claim an author or review date that the site cannot substantiate. Accuracy is more valuable than the number of schema types in the page source.

Sources for this section: Google: introduction to structured data, Google: structured data general guidelines.

Choose and implement the right type

Start with a real page purpose and the supported Google Search feature list. Map visible fields to the type's required and recommended properties, then put the JSON-LD on the page it describes. For a service page, accurate organization and service descriptions may clarify the business, but do not assume they create a special AI search display.

Use one canonical URL and stable entity identifiers where relevant. Keep prices, availability, names, and images synchronized with visible content. Review generated markup in the rendered HTML; data injected only in a way crawlers cannot access will not solve the problem.

1. 01

   Select a real page

   Write down the content and feature you want to describe before choosing a schema type.

2. 02

   Map visible facts

   Use properties that match the page; avoid hidden claims and fabricated ratings.

3. 03

   Validate

   Run the Rich Results Test for supported features and inspect syntax and policy warnings.

4. 04

   Monitor

   After deployment, inspect the rendered URL and Search Console enhancement reports where available.

Sources for this section: Google: introduction to structured data, Google: structured data general guidelines.

Validate in layers, then check the published URL

Start with syntax. Confirm that the JSON-LD parses, uses the intended schema vocabulary, and contains properties of the right type. Then use Google's Rich Results Test for the specific supported feature. A passing result means the tested markup meets that test's technical checks; it is not a ranking score. Read warnings and policy guidance, and decide whether optional fields are actually known and visible before adding them. Do not fill empty fields with guesses to make a tool look greener.

Next test the deployed canonical URL, not just a draft snippet. A content management system can remove a field, escape JSON incorrectly, or publish stale data in one locale. Inspect rendered HTML and compare the markup with what a visitor sees. Check that the image URL is accessible, the canonical points to the intended page, and the product and offer facts still match. If Search Console provides an enhancement report for the feature, monitor it after Google crawls; a live test and an indexed report can reflect different times.

Finally, keep a change record: page URL, changed fields, why they changed, validation result, deployment date, and any later Search Console observation. This helps when a price update or template migration introduces a mismatch. The workflow also prevents a common error: celebrating a valid test while the published page contains a different or incomplete version of the markup.

Sources for this section: Google: introduction to structured data, Google: structured data general guidelines.

Avoid markup that looks complete but says the wrong thing

Do not place the same generic FAQ on every page merely to emit FAQ markup. Do not add reviews or ratings that are absent from the page or that your business generated for itself where policy forbids it. Do not label a service as a different product category to unlock a rich result. These shortcuts can make a page less trustworthy and can violate Google's feature policies. The markup must describe what is actually on that page, and the page must meet the relevant content guidelines.

Watch for stale metadata in reusable templates. A shared organization object may be appropriate across the site, but each article or product object should reflect that individual URL. When a guide title changes, its structured-data headline should change too. When a discontinued plan remains in JSON-LD after the visible page is updated, a crawler sees contradictory information. Add a content release check that compares visible title, description, images, and offers with their markup counterparts.

Separate schema claims from AI-search claims in reports. A Rich Results Test can answer whether markup qualifies technically for supported Google rich results. URL Inspection helps answer whether Google can fetch and index a page. A dated observation of an actual AI answer can show whether a source link appeared under recorded conditions. None of those instruments proves that structured data caused a citation. If you change markup and content together, the evidence is even less able to isolate one cause.

Sources for this section: Google: structured data general guidelines, Google: AI features and your website.

Prioritize the page before the markup

If a buyer cannot tell what the page offers, who it serves, or how a claim is supported, fix the visible copy first. If the page is blocked or not indexed, fix access and discovery first. Add structured data when it accurately describes a stable page and supports a documented feature or entity understanding need.

Measure the result with the right instrument: Search Console for search appearance and performance, a Rich Results Test for eligible markup, and saved consumer answer observations for actual AI citations. Do not attribute a citation change to markup alone without considering content, indexing, and query conditions.

Sources for this section: Google: introduction to structured data, Google: AI features and your website.

Decide when schema is the right next task

If a high-value page is blocked, noindexed, or has no useful answer, fix those problems first. If the page is accessible, accurate, and aligned to a supported rich-result feature but its markup is missing or broken, a structured-data task has a clear purpose. If the proposed type has no documented feature for the page, ask what user or maintenance problem it solves before investing time in it. An unsupported type is not automatically harmful, but an unsupported promise of AI visibility is not a good business case.

Use the reader's question as the final check. Can a person understand the product, compare alternatives, and verify the claim from the visible page? If yes, markup may add a precise machine-readable description and possible eligibility for a documented search appearance. If no, better markup only labels a weak answer. The most durable implementation pairs useful public content with accurate data and ongoing validation whenever the page changes.

Sources for this section: Google: introduction to structured data, Google: AI features and your website.