JSON-LD schema markup: how to implement it, test it and what it does for AI

JSON-LD is the format in which you record facts about your organization, products and pages in a machine-readable way, in a separate script block that is independent of your visible HTML. That makes it the easiest format to maintain, and Google recommends it. The types that matter for most sites are Organization, WebSite, BreadcrumbList, Article and, if you sell something, Product.

What schema does not do is automatically get you into AI answers more often. That is explained honestly further down, with the numbers. It does remain the way to qualify for rich results in Google and to record your facts so that no system has to guess what a number or name means.

Why JSON-LD is the preferred format

There are three formats for structured data: Microdata, RDFa and JSON-LD. They can express the same information, but JSON-LD has three advantages:

1. Separate from your HTML. JSON-LD sits in a <script type="application/ld+json"> block in the <head> or <body>. You can change it without touching your templates.

2. Easy to generate. It is plain JSON. Any CMS, framework or build script can produce it from the same data as your page.

3. Recommended by Google. Google calls JSON-LD the recommended format in its documentation on structured data.

The same information in the three formats:

<!-- Microdata: woven into the HTML -->
<div itemscope itemtype="https://schema.org/Organization">
  <span itemprop="name">Golden Crust Bakery</span>
</div>

<!-- RDFa: attributes in the HTML -->
<div vocab="https://schema.org/" typeof="Organization">
  <span property="name">Golden Crust Bakery</span>
</div>

<!-- JSON-LD: fully separate from the HTML -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Golden Crust Bakery"
}
</script>

With Microdata and RDFa your HTML structure and data structure must coincide. With JSON-LD they do not, which saves a lot of maintenance.

What does schema do and not do for AI visibility?

Schema makes your facts unambiguous and makes your page eligible for rich results in Google, but there is no evidence that it gets you cited more by AI search engines. Anyone claiming otherwise should bring data.

This is what is known:

• Google sets no extra requirements. According to Google, there are no additional requirements to appear in AI Overviews or AI Mode, and no special schema.org markup is needed for the generative AI features. Google does recommend structured data as part of regular SEO, and asks that it matches the visible text.
• Adding it produced no measurable gain. Ahrefs followed 1,885 pages that added JSON-LD between August 2025 and March 2026 and compared them with similar pages without schema. In AI Mode (+2.4%) and ChatGPT (+2.2%) the difference could not be distinguished from zero; in AI Overviews it was even slightly negative (-4.6%), although the researchers could not establish schema as the cause. Caveat: these were pages that were already cited often, and the measurement window was 30 days.
• Correlation is not causation. Pages AI does cite have JSON-LD more often than pages it does not. That mainly says something about the kind of site that is well maintained, not that schema causes the citation.

So why do it anyway? Because schema still enables rich results in Google (product prices, reviews, breadcrumbs), because it describes your organization unambiguously for knowledge graphs, and because it does no harm when it is correct. See it as good maintenance, not as a lever for AI citations. What does correlate with citations is how your text is structured; read how AI crawlers read your site.

Article schema

Article schema tells who wrote an article, when it was published and when it was last updated. Google has no required fields for Article, but recommends headline, image, datePublished, dateModified and author (Google).

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose the right sourdough starter for home",
  "image": "https://www.example.com/images/sourdough.jpg",
  "datePublished": "2026-09-14T09:00:00-07:00",
  "dateModified": "2026-10-02T11:30:00-07:00",
  "author": {
    "@type": "Person",
    "name": "Sarah Johnson",
    "url": "https://www.example.com/team/sarah-johnson",
    "jobTitle": "Head baker"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Golden Crust Bakery",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.example.com/logo.png"
    }
  },
  "mainEntityOfPage": "https://www.example.com/blog/choosing-sourdough",
  "inLanguage": "en-US"
}
</script>

Notes on the fields:

• headline equal to the H1 on the page.
• datePublished and dateModified in ISO 8601, with a time zone. Only move dateModified forward for a real content change.
• author as an object (Person or Organization) with a url, not as loose text. An author with their own page is a clear signal of who is behind the content.
• inLanguage helps on multilingual sites.

FAQPage schema after May 2026

Since May 7, 2026, Google no longer shows FAQ rich results, for any site. That is in the Google Search Central changelog. In August 2023 they had already been limited to well-known government and health websites; now they are gone completely. In June 2026 the FAQ report disappeared from Search Console and support was removed from the Rich Results Test (TechWyse).

What does that mean for your existing markup?

• You do not have to remove it. FAQPage is valid schema.org and causes no errors or penalties.
• Do not expect expandable questions in Google’s results anymore.
• The visible FAQ is the most important part. A clear block of questions and short answers is good for visitors and fits how AI search engines look for answers. In Semrush’s research, cited pages scored 25.5% higher on question-and-answer format. That is about the visible text, not the markup.

If you use FAQPage, keep the same rule as always: every question and answer in the schema is also literally visible on the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you deliver on Saturdays?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, we deliver business orders Monday through Saturday. Order by 3 p.m. the day before."
      }
    }
  ]
}
</script>

Google has not shown HowTo rich results since 2023 either. So HowTo markup, like FAQPage, is mainly descriptive.

Organization schema

Organization schema describes who you are: name, logo, contact details and your profiles elsewhere. You place it on your homepage or site-wide. It helps search engines and knowledge graphs see your business as a recognizable entity, independent of the body text.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Golden Crust Bakery",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "postalCode": "97205",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "addressCountry": "US"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "email": "hello@example.com",
    "availableLanguage": ["en"]
  },
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.instagram.com/example"
  ]
}
</script>

Tips:

• Give your organization a fixed @id. Other blocks, such as publisher in your Article schema, can then refer to it without repeating everything.
• Use exactly the same name, address and profiles as on your site, your Google Business Profile and other listings. More in GEO for local businesses.
• If you have a physical location, use the more specific LocalBusiness type (or a subtype such as Bakery).

Product schema

Product schema records price, availability and optionally ratings. Google uses it for product results and for price and stock in the search results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Whole wheat sourdough loaf, 28 oz",
  "image": "https://www.example.com/images/whole-wheat-28.jpg",
  "description": "Whole wheat sourdough with a 24-hour rise, baked in a stone oven.",
  "sku": "SD-WW-28",
  "brand": {
    "@type": "Brand",
    "name": "Golden Crust Bakery"
  },
  "offers": {
    "@type": "Offer",
    "price": 8.50,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://www.example.com/bread/whole-wheat-sourdough"
  }
}
</script>

Note:

• Only put ratings (aggregateRating, review) in your schema if they are really visible on the page and come from customers. Made-up or invisible reviews in markup violate Google’s guidelines.
• Keep price and stock equal to the page. Generate them from the same database.
• If you sell through a feed or to AI agents, the offers object becomes even more important; see agentic commerce for Shopify, WooCommerce and Magento.

Combining multiple schema types

You can put several JSON-LD blocks on one page. A blog post, for example, has Article, BreadcrumbList and optionally FAQPage. You can put them in separate <script> blocks or combine them in one @graph:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "How to choose the right sourdough starter for home",
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.example.com/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://www.example.com/blog" }
      ]
    }
  ]
}
</script>

Both work. Separate blocks are easier to debug; @graph with @id references avoids repeating the same organization details in ten places.

One technical condition: put your JSON-LD in the HTML your server sends. If it is only injected with JavaScript, Google usually sees it, but the crawlers of ChatGPT, Claude and Perplexity do not, because they do not run JavaScript. See why AI crawlers do not see your JavaScript.

Testing and validating structured data

You validate schema in three layers: is the syntax right, are the recommended fields per type present, and does what is in the schema match what is visible on the page. That last check is skipped most often, and it is exactly what Google explicitly asks for.

The tools

Tool	For	Limitation
Rich Results Test	Syntax and fields for the types Google shows rich results for	Only tests those types; FAQPage no longer supported since June 2026
Schema Markup Validator	All schema.org types, including FAQPage, HowTo and Organization	Says nothing about rich results in Google
Google Search Console	Which pages Google sees with valid markup in practice, per type, over time	No direct test; lags behind
Bing Webmaster Tools	How Bing reads your markup (Bing is also the index behind Copilot)	Bing only

Start with the Rich Results Test, use the Schema Markup Validator for the rest, then look in Search Console. A sudden drop in the number of valid pages there almost always points to a template change that broke your schema.

Checks no tool does for you

1. Schema equals the visible text. Every price, name, date and FAQ question in the markup is also on the page.
2. The same organization details on every page. “Company LLC”, “Company, LLC” and “Company” are three different names to a system that links entities. Keep your Organization data in one central place in your code.
3. Dates present and honest. datePublished and dateModified on every article, and dateModified only for real changes.
4. Author as an object. An author as loose text is valid, but says little. Compare:

"author": "Sarah Johnson"

"author": {
  "@type": "Person",
  "name": "Sarah Johnson",
  "url": "https://www.example.com/team/sarah-johnson",
  "sameAs": ["https://www.linkedin.com/in/example"]
}

5. Product complete and current. price, priceCurrency and availability present and equal to the page.

A fixed workflow

1. Generate your schema from the same source as your visible content.
2. Test one sample page per template with the Rich Results Test and the Schema Markup Validator.
3. Compare your Organization schema on a few different pages.
4. Check in Search Console after a week whether Google picks up the markup.
5. Test again after every change to your templates or CMS. That is where most errors appear, not when writing the schema itself.

The technical scan checks, among other things, whether your Organization, WebSite, Breadcrumb and FAQPage markup is present and in the HTML.

On WordPress, your SEO plugin already sets up the basis of this schema. Which plugin does what is in the best WordPress SEO plugins.

Common mistakes

1. Schema that says something different from the page. An FAQ question that appears nowhere, a price that differs, a rating without visible reviews. Google explicitly asks for consistency, and it undermines your credibility.

2. Wrong data types. Dates without a time zone, an invalid URL in availability, a price with a currency symbol in it. Small errors that make the markup unusable.

3. Schema only via JavaScript. Google usually renders it, other crawlers do not.

4. Implementing once and forgetting. New products, changed prices and moved pages must follow. Because schema should come from the same source as your content, this goes right automatically if you set it up that way.

5. Seeing schema as an AI lever. If you expect schema alone to bring more AI citations, you are spending time on the wrong thing. First your page has to be findable, readable and the best answer to the question.

Where to start

Start with Organization and WebSite site-wide, Article on your blog and Product if you sell something. Generate your schema from the same data as your page, validate per template and check after every major change. For most sites that is an afternoon of work, and after that it mostly maintains itself.

For the rest of the technical foundation, such as robots.txt, rendering and speed, use the technical GEO checklist.

Read also

• How AI crawlers read your site and what to set up technically
• E-E-A-T for AI
• Getting found in AI search engines