Guide

AEO Structured Data Checklist

Complete checklist of structured data to implement for AI visibility

Structured data is the most reliable way to tell a machine what a page actually means. For traditional search it powered rich results. For answer engines — ChatGPT, Perplexity, Gemini, Copilot, Claude — it does something more useful: it removes ambiguity. When an assistant is deciding whether your page answers a question, and whether it can safely attribute a claim to you, unambiguous machine-readable facts make the difference between being cited and being skipped.

This checklist covers the schema types that matter for answer engines, the properties each one actually needs, the mistakes that quietly invalidate markup, and how to validate what you ship.

Why structured data matters for answer engines

Assistants do not read your page the way a person does. Most retrieval pipelines strip a page down to text, then try to reconstruct entities: who published this, when, what is it about, what is the price, who is the author. Every one of those reconstructions can go wrong. A publish date rendered as "Updated Tuesday" is unusable. A price shown only in an image is invisible. An author byline with no supporting entity is just a string.

JSON-LD gives the model an explicit, unambiguous version of those same facts, sitting right next to the prose. Three practical benefits follow:

  • Extraction accuracy. Dates, prices, ratings and authorship are parsed rather than guessed.
  • Attribution. A clear publisher and author entity makes it easier for an engine to name you as the source.
  • Freshness signals. Explicit datePublished and dateModified help engines decide whether your page is current enough to quote.

Structured data does not force a citation. It removes the reasons not to give you one.

JSON-LD vs. microdata vs. RDFa

Schema.org markup can be expressed three ways. Microdata and RDFa are woven into your HTML as attributes on existing elements. JSON-LD is a separate block, usually a script tag with type="application/ld+json", that describes the page independently of its layout.

Use JSON-LD. It is the format Google explicitly recommends, it is trivially easy to parse, and — critically for answer engines — it survives templating changes. Microdata breaks the moment a designer restructures a component, and it is far harder to audit at scale because the data is scattered across the DOM. If you have inherited microdata, you can migrate incrementally, but do not mix two formats describing the same entity on the same page; conflicting descriptions are worse than one clean description.

One more consideration specific to AI crawlers: many fetch raw HTML without executing JavaScript. If your JSON-LD is injected client-side by a tag manager or a framework hydration step, a meaningful share of crawlers will never see it. Render structured data server-side, in the initial HTML response.

The schema types that matter

Organization

This is the foundation. It establishes who you are as an entity and is what publisher references on every other page point back to. Put it on your homepage, and reference it by @id elsewhere rather than repeating it.

Essential properties: name, url, logo, description, and sameAs — an array of authoritative profiles (Wikipedia, Wikidata, LinkedIn, Crunchbase, X). The sameAs array is how you connect your site to entities the model already knows about, and it is the single most under-used property in most implementations.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Inc.",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://en.wikipedia.org/wiki/Example_Inc."
  ]
}
</script>

Article and NewsArticle

Use Article for evergreen content, NewsArticle for time-sensitive reporting, and BlogPosting for blog entries. The distinction matters less than getting the properties right.

Required in practice: headline, datePublished, dateModified, author, publisher, image, and mainEntityOfPage. Keep headline aligned with the visible H1 — a mismatch is a common cause of markup being discounted. Use full ISO 8601 timestamps with a timezone offset for dates, not bare date strings, and never set dateModified to the build time of your site; that is a freshness lie that engines learn to ignore.

Person

Author entities are increasingly load-bearing. An author value that is a bare string tells a model nothing. An author that is a Person object with a url pointing to a real author page, a jobTitle, and sameAs links to professional profiles gives the engine something to evaluate. Pair the markup with an actual author bio page — markup describing a person who has no presence anywhere else adds little.

FAQPage

FAQ markup maps directly onto the question-answer shape that assistants consume. Each entry is a Question with an acceptedAnswer of type Answer. Two rules: the questions and answers must be visible on the page, and the answer text in the markup must match the visible text. Marking up hidden or invented FAQs is the fastest way to have your structured data distrusted sitewide.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long does setup take?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Most teams complete setup in under an hour."
      }
    }
  ]
}
</script>

HowTo

For procedural content, HowTo encodes the sequence explicitly: step as an ordered array of HowToStep objects, each with name and text, plus optional tool, supply, and totalTime in ISO 8601 duration format. Ordering is the value here — it prevents an assistant from reshuffling or dropping a step when it summarizes your process.

Product, Offer, Review and AggregateRating

Commercial pages need Product with name, image, description, sku, brand, and a nested offers object carrying price, priceCurrency, availability, and ideally priceValidUntil. Price must be a plain number — no currency symbols, no thousands separators.

AggregateRating requires ratingValue, reviewCount or ratingCount, and should declare bestRating if your scale is not out of five. Only mark up ratings that come from genuine, visible reviews on that page. Self-serving review markup — a company rating its own product — is explicitly disallowed by Google's guidelines and is a reputational risk with answer engines that surface the rating verbatim.

LocalBusiness

For any physical location, use the most specific subtype available (Restaurant, Dentist, AutoRepair) rather than the generic parent. Include address as a full PostalAddress object, telephone, geo coordinates, openingHoursSpecification, and priceRange. Consistency with your other listings matters more than completeness — a phone number that differs between your markup and your business profile creates exactly the ambiguity you are trying to eliminate.

BreadcrumbList

Cheap to implement, disproportionately useful. BreadcrumbList gives an engine your site hierarchy explicitly, which helps it understand whether a page is a hub or a leaf, and how topics relate. Each ListItem needs position, name, and item. Positions start at 1 and must not skip.

Common implementation mistakes

  • Markup that contradicts the page. If the JSON-LD says one price and the page shows another, the markup is discounted. Generate structured data from the same data source that renders the page.
  • Client-side injection. Structured data added after page load is invisible to non-executing crawlers.
  • Orphaned entities. Multiple disconnected blocks describing the same organization, with no @id linking them. Use @id references so entities resolve into one graph.
  • Wrong date formats. Bare dates, missing timezones, or a dateModified earlier than datePublished.
  • Relative URLs. Every URL in JSON-LD should be absolute.
  • Copy-pasted templates. Boilerplate left with placeholder names and example.com URLs is more common than you would expect.
  • Over-marking. Applying FAQPage to a page with no FAQ, or HowTo to a listicle, to chase a rich result. Answer engines cross-check against visible content.
  • HTML inside text fields. Escape it properly or strip it; raw tags in an Answer text field produce invalid JSON or garbled extraction.

Validation tooling

Validate every template, not every page — but validate every template before it ships.

  1. Schema.org Validator (validator.schema.org) checks conformance to the vocabulary itself. Use this first; it catches invalid types and misspelled properties regardless of any search engine's requirements.
  2. Google Rich Results Test checks eligibility for specific rich result types and reports required-property errors and recommended-property warnings. Test the live URL, not pasted code, so you see what a crawler that does not run JavaScript would see.
  3. Google Search Console gives you the aggregate view: enhancement reports flag errors across your whole site and show when a template regression has occurred.
  4. A JSON linter in your build pipeline. A trailing comma silently invalidates the entire block, and nothing downstream will tell you.

Treat validation as a build-time check rather than a periodic audit. Structured data breaks during refactors, and a broken block fails silently.

The practical checklist

  1. Define one canonical Organization entity on the homepage, with logo and a populated sameAs array.
  2. Add a WebSite entity with name, url, and publisher referencing your organization.
  3. Reference the organization by @id from every other page rather than duplicating it.
  4. Mark up all editorial pages with Article, NewsArticle, or BlogPosting, including both date fields with real timestamps.
  5. Make author a Person object linked to a real author page, not a string.
  6. Confirm headline matches the visible H1 on every template.
  7. Add BreadcrumbList to every page below the homepage.
  8. Add FAQPage only where visible questions and answers exist, with matching text.
  9. Add HowTo to genuinely procedural content, with ordered steps.
  10. Mark up commercial pages with Product and a complete offers object, price as a plain number.
  11. Add AggregateRating only where real, visible reviews back it.
  12. Add LocalBusiness with the most specific subtype and a full PostalAddress for each location.
  13. Render all JSON-LD server-side in the initial HTML response.
  14. Use absolute URLs everywhere, and link entities with @id.
  15. Run the Schema.org Validator and the Rich Results Test against one live URL per template.
  16. Add JSON validation to CI so a malformed block fails the build.
  17. Watch Search Console enhancement reports for regressions after each release.
  18. Re-audit templates whenever the design system or CMS changes.

Where structured data fits in a wider AEO program

Structured data solves the extraction problem. It does not solve discovery, access, or measurement. Crawlers still have to be able to reach your pages and understand what your site is for, which is where a well-formed llms.txt file and sensible crawler access policy come in. And once assistants do start quoting you, you need to know it is happening — citation tracking tells you which pages are actually being surfaced, and by which engines, so you can invest in the templates that earn mentions rather than guessing.

Taken together, structured data, machine-readable access policy, and citation measurement form the core of an agent experience strategy: making your site legible to the software that increasingly reads it on your behalf.

Start with the Organization entity and your highest-traffic article template. Those two fixes cover most of the ambiguity an answer engine encounters, and everything else on this list is incremental from there. If you would like a review of what your site currently exposes, run a free AEO audit or book a demo.

Want Personalized Recommendations?

Get a custom AEO audit for your specific domain.

Book a Demo Free Audit