Schema markup for AI search: what to add first

Structured data is the cheapest AEO work there is. It's an afternoon, it doesn't require writing anything new, and it converts claims a machine would otherwise have to infer from prose into assertions it can simply read.

The catch is that most schema advice is written for Google rich results, which is a different goal. Rich-result markup optimises for a visual snippet. AEO markup optimises for identity — making it unambiguous what your business is and what it offers.

The four that matter, in order

Everything else — BreadcrumbList, WebSite, LocalBusiness, Review — is worth having, but none of it changes whether a model can state what you are.

1. Organization

The single most valuable block on your site. sameAs is doing more work than it appears: it's how you connect your domain to profiles that already exist in a model's knowledge, which is the mechanism corroboration runs on.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.com/#organization",
  "name": "Acme",
  "url": "https://acme.com",
  "logo": "https://acme.com/logo.png",
  "description": "Shopify agency for fashion and lifestyle brands doing $1M–$50M in revenue.",
  "foundingDate": "2019-04-01",
  "areaServed": ["US", "GB", "IN"],
  "sameAs": [
    "https://www.linkedin.com/company/acme",
    "https://x.com/acme",
    "https://github.com/acme"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "hello@acme.com"
  }
}

2. Service or Product

Organization says who you are; Service says what you sell. This is the block that answers “best X for Y” questions, because serviceType plus audience is exactly the shape of that query.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Shopify Plus migration",
  "serviceType": "Ecommerce replatforming",
  "provider": { "@id": "https://acme.com/#organization" },
  "areaServed": "US",
  "audience": {
    "@type": "Audience",
    "audienceType": "DTC fashion brands on Magento or WooCommerce"
  },
  "offers": {
    "@type": "Offer",
    "price": "18000",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Note provider referencing the Organization by @id rather than repeating it. That's the linking pattern in the next section, and it's what turns a pile of separate blocks into one description of a business.

3. FAQPage

The highest-leverage block per line of code, with one rule: the questions and answers must be visible on the page. Marking up FAQs that a human can't see is a guidelines violation, and it's also just a bad idea — the visible version is what gets quoted.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How much does a Shopify migration cost?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Most Magento-to-Shopify Plus migrations run $15,000–$40,000 depending on catalogue size, custom checkout logic and how much data needs transforming."
      }
    }
  ]
}

4. Article

On guides and blog posts. dateModified matters more than most people expect: recency is a common tiebreaker between two pages that answer a question equally well.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to rank on ChatGPT",
  "datePublished": "2026-09-03",
  "dateModified": "2026-09-03",
  "author": { "@id": "https://acme.com/#organization" },
  "publisher": { "@id": "https://acme.com/#organization" },
  "mainEntityOfPage": "https://acme.com/blog/how-to-rank-on-chatgpt"
}

Link the blocks with @id

The mistake that wastes most of the value: publishing four unconnected JSON-LD blocks. A parser then sees four unrelated things rather than one entity described four ways.

Give the Organization a stable @id — the convention is https://yoursite.com/#organization — and reference *that* from every other block, as provider, author, publisher. Wrapping site-wide blocks in an @graph array makes the relationship explicit:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://acme.com/#organization", "name": "Acme" },
    {
      "@type": "WebSite",
      "@id": "https://acme.com/#website",
      "url": "https://acme.com",
      "publisher": { "@id": "https://acme.com/#organization" }
    }
  ]
}

Verify it, then check it renders server-side

1. 1

   Validate the syntax

   Run the page through validator.schema.org and Google's Rich Results Test. Both catch malformed JSON and invalid property names.

2. 2

   Confirm it's in the HTML source

   Schema injected by client-side JavaScript is invisible to crawlers that don't execute JS. curl the page and grep for ld+json.

3. 3

   Check the @id references resolve

   Every @id you reference should be defined somewhere on the site. A dangling reference is a broken link in the graph.

curl -s https://yoursite.com | grep -o 'application/ld+json' | wc -l
# 0 means your schema isn't server-rendered