Schema Markup for AI Search

An answer engine reading raw HTML has to guess at the role of every block of text. Is this heading a question or a marketing slogan? Is this line a publication date, a review date or an event date? Is this name the author, a quoted expert or a customer? Schema.org markup removes the guessing by attaching explicit labels, which is exactly the problem the extraction stage has to solve.

The payoff shows up in two places. First, segmentation accuracy: with FAQPage or HowTo markup present, the passage lifted from your page is far more likely to be the complete, intended answer rather than an arbitrary slice that begins mid-thought. Second, provenance: author and publisher markup makes the source attributable, and attributable sources are preferred in the categories engines treat most carefully.

What schema does not do is manufacture authority. There is no type you can add that makes a thin page competitive. Treat it as the labelling layer on top of substance, never as a substitute for it.

Almost every content page benefits from four. Article or WebPage establishes what the page is, who wrote it, who published it, when it was published and when it was last reviewed. BreadcrumbList places it in a hierarchy, which helps a model understand scope. Organization, usually declared once at the site level, establishes publisher identity. And FAQPage, where you genuinely have questions and answers on the page, hands over pre-cut passages.

Add HowTo when the page contains an ordered procedure with discrete steps, and only then — HowTo wrapped around a list of tips rather than a real sequence is misleading markup. Add WebApplication or SoftwareApplication for interactive tools, which is how a calculator page tells an engine it is a utility rather than an essay. Add Person for author entities, with a URL pointing at a profile page that actually resolves.

Resist the temptation to add everything. Overlapping, contradictory or speculative markup makes parsing harder rather than easier, and errors in one block can cause a validator — and by extension a parser — to distrust the rest.

Use JSON-LD in the document head, not microdata woven through the markup. JSON-LD is easier to generate correctly, easier to validate, and does not break when a designer changes the HTML. Emit it server-side so it exists in the initial response, since markup injected by client-side JavaScript may not be present when an AI crawler reads the page.

Give each entity a stable @id built from the absolute canonical URL — for example the page URL with a fragment such as #article or #author. Reference entities by @id rather than duplicating their full definition in every block. This keeps the graph consistent across pages and lets a parser recognise that the author of forty pages is one person rather than forty coincidentally identical strings.

Always use absolute URLs. Relative paths in schema are a recurring source of silent breakage, and they are especially damaging in canonical and author URLs where the whole point is unambiguous identity.

Four failures account for most of the damage. Markup describing content that is not on the page — invented FAQs, ratings nobody left, authors who do not exist — which is both a policy violation and a trust liability. Dates that never change, where dateModified is set to today on every render, teaching the engine that your dates carry no information. Canonicals that disagree with the schema's url property, which makes the identity of the page ambiguous. And markup that only appears after hydration, which means the crawler never sees it.

A subtler failure is inconsistency across a site. If your Organization name is written three different ways on three templates, the entity association weakens. Define the publisher once, in one module, and reference it everywhere rather than retyping it.

Validate on a schedule rather than once at launch. Templates change, someone adds a field, and a single malformed block can invalidate an entire graph. A monthly automated check on a sample of URLs catches this before it costs you anything.

Start with mechanical validation: run representative URLs through a structured data validator and Google's rich results test, and fix every error before considering warnings. Then fetch the page as a crawler would — no JavaScript — and confirm the JSON-LD is present in the raw response.

Then check semantics, which validators cannot. Read your own markup as if you were the parser: does the author @id resolve to a real profile? Does dateModified reflect a real edit? Does every FAQPage question appear verbatim on the page with its answer beneath it? Does the url property match the canonical exactly, including protocol and host?

Finally, test the outcome rather than the markup. Query the engines with the question the page answers and look at what they quote. If the passage lifted is the one your FAQ or answer block contains, the labelling is doing its job. If it is a random paragraph from the middle of the page, your segmentation signals are not landing and the structure needs work before more markup does.