Schema markup for AI Overviews: how to add JSON-LD (technical guide)

Adding JSON-LD schema means adding to the page’s code a structured description of its content that search engines and AI agents can read without having to interpret it visually. Five types cover most of what an editorial or e-commerce site needs: Article, FAQPage, Product, HowTo and Organization, each with its own fields recommended by Google. Markup does not guarantee a citation in AI Overviews, but it removes the ambiguity that Google and language models otherwise have to guess from the raw text. This guide gives the exact code to copy for each type, where to place it in the page and how to test it before publishing.

Schema markup for AI Overviews: what it really changes, and what it does not guarantee

A JSON-LD script renders nothing on screen. It describes, in the schema.org vocabulary, the entities on the page (an article, a product, an organisation) with named, typed fields, whereas the visible text leaves Google to guess the same information from the layout. That difference, machine-readable versus machine-guessed, is what justifies adding it, not a promise of automatic visibility.

It is worth being straightforward on that last point. One study tracked 1,885 pages that added JSON-LD markup between August 2025 and March 2026, compared with 4,000 control pages left without schema. The result: no measurable increase in citations in AI Overviews, Google AI Mode or ChatGPT, and even a 4.6% drop in AI Overview citations for the pages that added schema, a gap judged statistically significant. Adding schema therefore does not mechanically get a page cited. What gets a page cited is a set of content and structure criteria; schema is a technical layer that comes after them.

What JSON-LD actually does

In practice, a JSON-LD block is a <script type="application/ld+json"> placed in the source code, invisible to the visitor. Google recommends this format over microdata or RDFa because it stays separate from the visible HTML: instead of mixing attributes into the tags, you write a self-contained JSON object. This block is what lets Google attach an author, a date, a price or a rating to the right entity without ambiguity, and it feeds both the rich results that are still active and the overall understanding of the page by the systems that rely on Google’s index.

What a recent study shows about citations in AI Overviews

The 4.6% figure quoted above deserves context rather than being ignored. It does not say schema is useless: it says that adding it without changing anything else on a page brings no gain in citations. JSON-LD remains good practice for eliminating parsing errors, unlocking the rich results that still exist (Product, review stars, breadcrumbs) and giving a clean entity signal for the author and the organisation. It is a matter of technical hygiene, not a citation lever on its own.

Article schema in JSON-LD: the fields that matter for editorial content

For the Article type, Google’s documentation lists no strictly required field: it recommends adding the properties that apply to the content. In practice, five fields determine eligibility for article rich results, and three others, from the standard schema.org vocabulary, remain useful for any system that reads the page, AI agents included.

The properties Google recommends (headline, image, dates, author, publisher)

• headline: the title of the article, truncated by Google beyond a certain length, so keep it concise.
• image: one or more representative images, ideally in 16:9, 4:3 and 1:1.
• datePublished and dateModified: in ISO 8601 format with the time zone.
• author: a Person or Organization object with at least name and url, with one separate author field per author if there are several.
• publisher: the name and logo of the site, never to be confused with the author’s name.
• description and articleBody: standard schema.org properties, less closely checked by Google’s Rich Results Test, but they give an automated reader a summary and the body text without having to extract it again from the HTML.

A ready-to-copy JSON-LD Article schema example

The schema markup generator on this site fills in this structure without writing a line of code; here is the result for a typical blog post.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Article title, around 110 characters at most",
  "image": [
    "https://www.example.com/images/article-16x9.jpg",
    "https://www.example.com/images/article-4x3.jpg",
    "https://www.example.com/images/article-1x1.jpg"
  ],
  "datePublished": "2026-10-07T08:00:00+02:00",
  "dateModified": "2026-10-07T08:00:00+02:00",
  "author": {
    "@type": "Person",
    "name": "First Last",
    "url": "https://www.example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Site name",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.example.com/logo.png"
    }
  },
  "description": "One-sentence summary of the article.",
  "articleBody": "The full text or a representative extract of the article."
}
</script>

FAQPage schema: what changed, and why keep it anyway

FAQPage schema pairs questions with their answers in a format that Google long displayed as an accordion directly in the search results. That behaviour went away in two stages.

Why the FAQ rich result disappeared from Google Search

In August 2023, Google had already restricted this rich result to well-known, authoritative government and health sites, after widespread abuse by sites adding generic FAQs for the sole purpose of taking up more space in the results. On 7 May 2026, Google removed the feature for all remaining sites, including that exception. The official documentation for the FAQPage type was itself withdrawn in June 2026, with an explicit statement that the rich result no longer appears in Google Search. FAQPage remains a perfectly valid schema.org type and causes no validation error, but it no longer offers the SERP visibility that made it worthwhile in the first place.

A FAQPage schema example, and when it is still useful

Keeping this schema makes sense when the page contains a genuine editorial FAQ (not one added only for the markup): it neatly structures the questions and answers for any automated reader, including an AI agent trying to extract a precise answer from a page, even without a dedicated rich result in the classic SERP.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is FAQPage schema still useful?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It has not produced a rich result in Google Search since May 2026, but it remains a valid schema.org vocabulary that structures a page's questions and answers for any system that reads it."
      }
    }
  ]
}
</script>

Product schema for e-commerce: the fields that unlock rich results

On a product page, Product schema follows a stricter rule than Article: the name field is required, and you also need at least one of the three fields review, aggregateRating or offers for the page to be eligible for product rich results.

Name, offers, aggregateRating: at least one of these three proofs

• name: the only strictly required field, the product name.
• offers: price, currency and availability, as an Offer object; it is also the condition for being eligible to show a price drop.
• aggregateRating: average rating and number of reviews, to fill in only if genuine reviews actually exist on the page, as Google considers a rating shown without proof to be a misleading practice.
• brand, image, sku: not required but recommended to enrich the display.

A ready-to-copy e-commerce Product schema example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Product name",
  "image": "https://www.example.com/images/product.jpg",
  "brand": {
    "@type": "Brand",
    "name": "Brand name"
  },
  "offers": {
    "@type": "Offer",
    "price": "49.90",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://www.example.com/product/"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

HowTo and Organization schema: status and good practice

These two types follow opposite logics: one lost its SERP visibility in 2023, the other never had a dedicated rich result but remains the foundation of any entity recognition by Google.

HowTo, a rich result gone since 2023

Google removed the HowTo step carousel in September 2023, on desktop and mobile alike, with no exception or remaining eligibility condition: the feature simply no longer exists. Adding this schema brings no penalty, but no visible effect either. It keeps a marginal interest for structuring a sequence of steps (step, with a name, a text and an image per step) for a system that would read the page without going through the visual rendering, but it is no longer an implementation priority.

Organization and sameAs, for the entity and the knowledge panel

Organization schema has no strictly required field either, but it is the one that pays off most for minimal effort. It ties the site to a single entity recognised by Google: name, url, a logo of at least 112 x 112 pixels, and above all sameAs, the list of profiles (social networks, reference pages) confirming that it is the same organisation elsewhere on the web. This entity signal, combined with the author signal in the Article schema, does the most to establish who publishes the content, a criterion that generative AI systems weigh as heavily as Google when deciding how far to trust a page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Site name",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.youtube.com/@example"
  ]
}
</script>

Where does JSON-LD go in the page, and how does Google read it?

The position of the block in the document has no functional effect: Google neither favours nor penalises a schema depending on whether it sits in the head or just before the closing body tag. What matters is that it is present in the final DOM, after JavaScript has run if it is injected dynamically.

In the head or at the end of the body: both placements are valid

By convention, most WordPress SEO plugins (Yoast, Rank Math) inject JSON-LD through the wp_head hook, so in the document head. A theme can just as well output it through wp_footer, just before the closing body tag: Google extracts it the same way in both cases. The only real requirement is not to duplicate the same schema type in two different places on the page with contradictory values.

How Googlebot extracts schema without touching the visible rendering

Googlebot fetches the page, runs it through a rendering engine close to Chrome to get the final DOM, then performs a separate extraction of every <script type="application/ld+json"> block in that DOM. This extraction changes nothing in what the user sees: it feeds a layer of structured understanding, used for the rich results that are still active and to attach the page to the entities in Google’s index, alongside the usual visual rendering.

How to test and validate your JSON-LD schema before publishing

Two free tools are enough, and it is better to use both rather than one, because they do not check the same thing.

Rich Results Test and the Schema.org validator

• Rich Results Test (search.google.com/test/rich-results): paste the URL or the code, and the tool tells you whether the page is eligible for one of the rich results Google still supports, with details of errors and warnings on missing fields.
• Schema.org validator (validator.schema.org): it checks pure compliance with the schema.org vocabulary, including types Google no longer shows as rich results (FAQPage, HowTo) or does not test (Organization as such), which the Rich Results Test does not cover.

The mistakes that invalidate a schema

• A JSON syntax error: an extra comma before a closing brace, an unclosed quotation mark, a missing brace.
• A missing nested @type, for example an author without "@type": "Person".
• A relative URL where schema.org expects an absolute one, especially for image, url and logo.
• Two JSON-LD blocks describing the same entity with different values on the same page.
• A dateModified that is never updated even though the content has changed.
• An aggregateRating shown without any genuine review visible on the page: Google calls this practice misleading and can sanction it with a manual action.