Structured data for AI search: what to implement and verify

Start with the page and the consumer

Identify what the page actually describes and which documented feature or integration needs the markup. Google uses supported structured data to understand pages and determine eligibility for specific search features. Eligibility is not a promise of display. Other services may use different inputs; do not assume they all consume JSON-LD or reward the same fields. Important information should remain readable in the page itself.

Choose types that match the visible facts

Organization can describe the organisation behind a website. Article can describe an article and its actual author and dates. Product belongs on appropriate product content; LocalBusiness can describe an eligible local business. A page may describe several related entities, so there is no universal one-type limit or priority order that earns citations. Use real identifiers and profile links. Do not invent ratings, credentials, contact details or business locations to complete a template.

A complete fictional Organization example

Suppose a fictional business, Example Workshop, displays its name and website address on its homepage. The following is an illustrative JSON-LD block, not a claim about a real business. Replace every example value with a verified fact, omit information that does not apply and check that an existing CMS plugin is not already producing conflicting markup. The script type is application/ld+json; paste the JSON as its content or use the supported CMS field.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Workshop",
  "url": "https://example.com/"
}

Keep questions useful without promising FAQ citations

Write questions customers actually need answered and provide enough context for the answer to make sense. There is no established universal 40-to-60-word formula or evidence here that FAQPage is the best schema type for AI citations. Google retired its FAQ rich-result feature in May 2026. Useful visible questions and answers can remain; retain FAQ markup only for a consumer that actually uses it, with answers consistent with the page.

Validate syntax, feature eligibility and deployed content separately

Use Schema Markup Validator to inspect syntax and recognised types. Use Google's Rich Results Test for supported Google features; a type without a Google rich result is not automatically invalid Schema.org markup. Then inspect the deployed URL, not just the editor: compare the visible name, price, availability, author and dates with the delivered markup. If JavaScript generates the data, inspect the rendered result too. Neither validator measures AI citation probability or certifies every factual claim.

1. Choose a representative live page and identify the intended schema type.
2. Inspect the actual delivered markup and the corresponding visible facts.
3. Resolve syntax errors and any applicable feature-policy failures.
4. Repeat the checks after publishing a factual or template change.

Record what changed and measure outcomes separately

For the fictional example, a useful change record would say that the homepage now declares the verified organisation name and canonical website URL, the JSON parses and the deployed page matches those values. It would not say that the business is now trusted or guaranteed to be cited. If AI referrals or citations matter to the business, measure those outcomes separately using a defined query set, engine, geography and period. AuditHQ's website-signal review helps investigate readiness; it does not establish the internal selection rules of every answer engine.

Frequently asked questions

Turn website findings into an action plan

Create an account to start a Full Audit of your website, with supporting evidence and a prioritised action plan.