What does structured data do for AI search?
JSON-LD gives machines an explicit graph of the page: who published it, what entity it describes, when it changed, and how its parts relate. That reduces ambiguity during extraction and attribution. It does not force an engine to crawl, trust, rank, or cite the page, so structured data belongs after access and visible content are correct.
Treat structured data as a factual label on visible content. If a visitor cannot verify a claim on the page, do not add that claim only to JSON-LD.
Which schema types should you use?
| Page purpose | Primary type | Critical properties |
|---|---|---|
| Company or brand | Organization | name, url, logo, sameAs |
| Editorial content | Article or BlogPosting | headline, author, datePublished, dateModified |
| Named expert | Person | name, jobTitle, affiliation, sameAs |
| Product or software | Product or SoftwareApplication | name, brand, offers, operatingSystem where relevant |
| Visible questions and answers | FAQPage | Question and acceptedAnswer matching the page |
| Visible ordered procedure | HowTo | name and complete ordered steps |
How do you build a consistent entity graph?
- Choose one stable @id for the organization and reuse it across the site.
- Reference that organization as publisher, provider, brand, or affiliation where appropriate.
- Create Person entities only for real named people with visible profiles and credentials.
- Use sameAs for authoritative identity pages, not every social URL you can find.
- Connect each page to its mainEntity or about topics when the relationship is specific and visible.
- Keep names, URLs, logos, dates, prices, and availability synchronized with the page.
What is a safe implementation workflow?
Generate JSON-LD from the same source of truth that renders the visible page. This prevents pricing, availability, dates, FAQ answers, and authorship from diverging. Server-render the script in the final HTML, escape serialized values safely, and avoid adding multiple contradictory entities from plugins and custom code.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data for AI search",
"author": { "@id": "https://example.com/#organization" },
"datePublished": "2026-09-22",
"dateModified": "2026-09-22",
"mainEntityOfPage": "https://example.com/guide"
}How should structured data be validated?
| Check | Question | Failure example |
|---|---|---|
| Syntax | Is the JSON valid? | Trailing comma or unsafe serialization |
| Vocabulary | Are types and properties valid schema.org terms? | Property used on the wrong type |
| Eligibility | Does the target search feature support this markup? | Expecting an unsupported rich result |
| Parity | Does every material claim match visible content? | Hidden FAQ or different price |
| Delivery | Is the script present in production HTML? | Client-only injection fails for a crawler |
Which structured-data mistakes cause the most harm?
- Adding FAQPage for questions that are not visibly answered on the page.
- Using aggregate ratings or reviews that visitors cannot inspect and verify.
- Publishing stale price, availability, author, or dateModified values.
- Creating different Organization entities with inconsistent names and URLs on each template.
- Marking every page as multiple unrelated primary types.
- Assuming a validator pass proves quality, eligibility, indexing, or citation.
How do you measure the value of schema for AI visibility?
Measure whether engines identify and describe the entity more accurately after markup is corrected. Track validation coverage, extraction errors, search enhancements where applicable, crawler visits, and citation accuracy for a fixed prompt set. Do not attribute a visibility change to schema when content, links, or crawl access changed at the same time.