Skip to main content
RankRift
Menu
AI Readiness

Schema For AI Search: What's Actually Worth Implementing

Separating documented uses from cargo cult, and a minimum viable schema set with the reasoning attached.

schemastructured-datatechnical-seo

An audit tool handed you nineteen structured-data recommendations, a developer asked which ones actually matter, and you did not have a defensible answer. That is the normal state of schema work right now, and it got worse once "AI search" entered the conversation, because a second layer of advice arrived on top of the first with even less evidence behind it.

This post sorts the recommendations into three buckets: types with a documented consumer, types that are cheap enough to justify on general principle, and types that got added to your backlog because someone else's checklist had them. The sorting rule is simple. If nobody can point to documentation describing what reads a field and what it does with it, that field is not a priority, however tidy it looks in a validator.

What structured data does and doesn't do for retrieval

Structured data is a machine-readable restatement of what a page already says. It sits in the markup as JSON-LD (or microdata), it names entities and their attributes, and it removes ambiguity that a parser would otherwise have to infer from prose.

That is the whole mechanism. It is genuinely useful, and it is much narrower than the claims made for it.

What it plausibly does:

  • Disambiguates entities. A sameAs array pointing at your official profiles and reference entries makes it easier for any consuming system to decide that the "Acme" on your page is the same Acme discussed elsewhere. This is the same problem covered in entity clarity, approached from the markup side.

  • States attributes explicitly. Availability, price, author, publication date, and organisation identity are stated as fields rather than left to be parsed out of a sentence.

  • Feeds search features that are documented. Search engines publish which structured-data types are eligible for which result features, and those docs are specific and dated. What it does not do:

  • It does not make a page more likely to be retrieved by an assistant simply because the markup exists. No provider documentation that we are aware of describes a general "more schema, more retrieval" relationship, and we are not going to assert one.

  • It does not substitute for the page saying the thing. If a claim only exists in JSON-LD, a system that reads the rendered text will not find it.

  • It does not fix a page that is unretrievable for other reasons. If a crawler is blocked, or the content only appears after client-side rendering, schema changes nothing about the outcome.

The honest summary: structured data is a clarity intervention, not a distribution intervention. Treat it as insurance against being misread, and the priorities fall out easily.

The minimum viable set, and the justification for each type

Below is the set we would implement first on a typical business or publisher site, with the reason attached to each. Where the justification is weak, we say so rather than dressing it up.

TypeWhere it goesJustificationEvidence status
OrganizationOne canonical instance, usually the homepageEstablishes the entity, its name, logo, and sameAs links; the anchor everything else referencesDocumented use in search features; entity-disambiguation value is reasoned, not measured
WebSiteHomepage, alongside OrganizationNames the site and its publisher relationshipDocumented use in search features
Article / BlogPostingEditorial pagesCarries author, datePublished, dateModified, and publisher; date fields matter when a system has to decide whether your page is currentDocumented use; freshness signalling is plausible but unproven for assistant retrieval
ProductProduct pagesStates price, currency, availability, and identifiers as fields rather than proseDocumented use in shopping features
BreadcrumbListAny page below the top levelMakes hierarchy explicit for a parser that only sees one pageDocumented use; low cost
FAQPageOnly where a real Q&A block is visible on the pageMarks self-contained question–answer units, which is the shape a retrieval system can lift cleanlyEligibility for search features has changed over time and should be re-checked against current docs before you rely on it
PersonAuthor pages, referenced from ArticleGives a stable identifier for the human making the claimsReasoned, not documented for assistants

Three of those entries say "reasoned, not documented" or "plausible but unproven." That is deliberate. Organization with a well-maintained sameAs array costs an hour and is defensible even if its retrieval effect is zero, because it is simply a true, structured statement of who you are. Person on author pages is the same trade: cheap, honest, and possibly useful. We would rather label a low-cost bet as a bet than invent a mechanism to justify it.

Product deserves a separate note. Product markup that disagrees with the page is the most common self-inflicted wound in this whole area, and the fix belongs with the broader work on product pages built for retrieval rather than with the markup alone.

Types commonly implemented without a reason

These show up in backlogs constantly. Some are fine; none of them are priorities; a couple are actively risky.

  • HowTo on pages that are not instructions. Marketing pages get HowTo markup because a plugin offered it. If the page has no numbered procedure a reader can follow, the markup is a false description of the page.

  • Review and AggregateRating on your own products, from your own reviews. Self-serving rating markup has been a repeated target of search-engine policy changes, and the rules on what a first party may mark up have shifted. Check the current documentation before implementing, and never mark up ratings that are not visible to a human on the same page.

  • Speakable. Narrow, historically limited to specific programmes and locales, and not something to spend a sprint on.

  • Deep Course, Event, or JobPosting markup on a site with one of each. These types are valuable when they describe your core inventory and pointless when they describe a single page.

  • Everything nested five levels deep because the vocabulary allows it. Schema.org is enormous. Coverage is not a goal. A small, correct, maintained graph beats a sprawling one that nobody updates.

  • Markup that exists to signal effort. If you cannot say what consumes a field and what it does with it, the field is decoration.

If a schema type describes content that is not visible on the page, do not implement it. Add the content first, or drop the type. There is no version of this where the markup alone is the win.

Consistency between schema and visible content

This is the part that turns schema from a mild positive into a liability, and it is worth being blunt about.

Structured data is a claim you are making in machine-readable form. If it contradicts the visible page, you have published two conflicting statements about yourself and handed any consuming system a reason to distrust both. In brand-visibility terms that is a genuine risk: inconsistent attributes are exactly the raw material for a model describing you as the wrong kind of company, or quoting a price you no longer charge.

The contradictions worth checking for first:

  • Price or availability in Product markup drifting from the live commerce data because they come from different systems.
  • dateModified updating on every deploy while the article text has not changed since 2023.
  • Author names in Article markup that do not match the byline shown to readers.
  • FAQPage markup carrying questions that were removed from the page in a redesign.
  • Organization name, legal name, and address differing between markup, footer, and third-party profiles.

Two rules keep this under control. First, generate markup from the same data source that renders the page, not from a separate CMS field a human maintains by hand. Second, when a value cannot be generated from the rendered content, leave it out. An absent field costs you nothing. A wrong field costs you credibility with both readers and parsers.

The structural work matters more than the markup here. A page whose sections are self-contained and correctly labelled is easier to quote accurately with or without JSON-LD, which is the argument made in full in chunk-friendly structure.

Validating and maintaining it

Schema is not a project. It is a small piece of infrastructure that rots quietly, because nothing visibly breaks when it goes wrong.

On every deploy that touches templates

  • Run the markup through a validator for syntax and required-property errors. Both the schema.org validator and search-engine testing tools exist for this; check which one reflects current eligibility rules before you treat a warning as important.

  • Diff the generated JSON-LD for one page per template against the previous build. Unexpected diffs are the earliest warning that a data source changed.

Monthly

  • Spot-check five pages per template type, comparing three or four marked-up values against what a reader sees. Price, availability, author, and dates are where drift concentrates.
  • Confirm sameAs targets still resolve. Profiles get renamed and deleted.

Quarterly

  • Re-read the current documentation for every type you rely on and record the date you checked it. Eligibility rules and required properties change, and a type that earned its place a year ago may no longer do anything.

  • Remove types that no longer have a documented consumer. Deletion is maintenance.

After any redesign or migration

  • Full re-validation across all templates before launch, then again a week after. Migrations are where entire blocks of markup silently disappear.

Log each check with a date, the same way you would log any other verification. If nobody can say when the markup was last confirmed against the page, you do not have maintained schema — you have markup that happened to be correct once.

In Plain English

Structured data makes a page harder to misread. It does not make a page more likely to be picked up, and anyone telling you a specific schema type improves your standing in AI answers should be asked for the documentation.

Implement a small set — Organization, WebSite, Article, Product where relevant, BreadcrumbList, and FAQPage only where a real Q&A exists — and know why each one is there. Skip anything you cannot justify. Never mark up content that is not on the page. Check the markup against the visible page monthly, re-read the documentation quarterly, and re-validate after every migration.

This helps most if you have a backlog of schema recommendations and limited developer time, and you need to defend which ones you are declining. It helps least if your pages are not being crawled or rendered at all, in which case fix that first — the AI readiness hub covers that sequence.

Download the AI-readiness audit checklist to work through the markup and the retrievability checks in one pass.

Primary-source verification

Checked July 28, 2026. The operational and factual guidance above was reviewed against the primary references below. Provider features, prices, policies, interfaces, jurisdictions, and account-specific results can change; recheck the controlling first-party document and your own account or measured data before acting.