Schema Markup for AEO: A Copy-Paste Implementation Guide

What structured data actually does

Google describes structured data as a standardized format for providing information about a page and classifying its content.

In practical terms, it lets you state explicitly that:

This explicitness is especially useful when you are trying to improve entity clarity and Knowledge Graph readiness.

Schema does not guarantee AI visibility

This is the most important limitation in the entire guide.

Google explicitly says that even correctly implemented structured data does not guarantee that a particular search feature will appear.

Google also says there is no special schema.org markup required to appear in AI Overviews or AI Mode.

Citation visibility depends on a broader chain involving access, relevance, answer quality, entity clarity, evidence and external corroboration. That framework is covered in How to Get Your Brand Cited by ChatGPT, Perplexity & AI Overviews.

Which schema types matter most for a typical B2B website?

Do not add every Schema.org type you can find. Start with the entities and page types that genuinely exist on the website.

1. Copy-paste Organization schema

Put your main Organization object on the homepage or another appropriate site-level location.

Replace every example value with accurate information about the real organization. Do not add an address, founding date, social profile or business identifier unless it is true and appropriate to publish.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Company",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png"
  },
  "sameAs": [
    "https://www.linkedin.com/company/example-company"
  ]
}

The @id creates a stable identifier that other structured-data objects on your site can reference.

2. Copy-paste WebSite schema

The website and the organization are related entities, but they are not the same thing.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com",
  "name": "Example Company",
  "publisher": {
    "@id": "https://example.com/#organization"
  }
}

Notice how the publisher does not repeat the entire Organization object. It references the stable Organization @id.

Google also uses WebSite structured data as one input for site-name preferences in Search.

3. Copy-paste Article schema

Article markup is appropriate for editorial pages that are genuinely articles.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/article/#article",
  "headline": "Example Article Title",
  "description": "A concise description of the article.",
  "url": "https://example.com/article",
  "datePublished": "2026-08-18",
  "dateModified": "2026-08-18",
  "image": [
    "https://example.com/images/article-feature.png"
  ],
  "author": {
    "@type": "Person",
    "name": "Jane Smith",
    "url": "https://example.com/about/jane-smith"
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  }
}

Keep the headline, canonical URL, author, dates and images aligned with the content users actually see.

Do not mark every commercial landing page as an Article simply because Article schema is easy to implement.

4. Copy-paste BreadcrumbList schema

Breadcrumb structured data can make your page's position inside the site hierarchy explicit.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Insights",
      "item": "https://example.com/insights"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Article",
      "item": "https://example.com/insights/article"
    }
  ]
}

The hierarchy should reflect a meaningful site structure, not an invented breadcrumb path designed only for markup.

Connect related entities with @id and @graph

One of the most useful structured-data patterns is to stop creating isolated objects that know nothing about each other.

A stable @id allows multiple schema objects to refer to the same entity.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Company",
      "url": "https://example.com",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Example Company",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}

How to add JSON-LD in Next.js

Next.js recommends rendering JSON-LD as a script element in a page or layout.

Its documentation also recommends sanitizing the serialized payload when values may contain unsafe strings. One documented approach is to replace the less-than character with its Unicode equivalent.

export default function Page() {
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: "Example Article",
    url: "https://example.com/article",
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
        }}
      />

      <main>
        {/* Visible page content */}
      </main>
    </>
  );
}

Structured data must match visible content

A common schema mistake is putting useful-looking facts into JSON-LD that are not actually supported by the page.

Google's structured-data guidelines specifically warn against markup that misrepresents the page or describes content hidden from users.

Should you add FAQPage schema to every AEO article?

No.

Adding FAQPage markup everywhere because "AI likes FAQs" is not a useful AEO strategy.

Google reduced FAQ rich-result visibility and says those rich results are generally limited to well-known, authoritative government and health sites.

You can still write genuinely useful FAQ content. The value of the content should not depend on receiving a special search appearance.

Do not confuse FAQPage with QAPage

QAPage has a specific purpose.

Google says QAPage markup should be used when a page focuses on one question and users can submit answers.

A normal company FAQ, blog article or guide where the publisher writes the answers itself should not be marked up as QAPage merely to target answer engines.

The 8-point structured-data audit

The same checks fit naturally inside the broader 15-Point AEO Checklist.

How to validate your implementation

Validation should happen before you treat the implementation as finished.

Where schema fits inside AEO

Structured data is one layer, not the whole optimization system.

If you want to audit those layers manually, use the DIY AEO Audit.

7 schema mistakes that hurt more than they help

Schema markup for AEO FAQs