JSON-LD for AI Search: Which Fields Actually Get Read

JSON-LD for AI search has two readers. Indexers like Google read the markup while processing a page. Converters that turn a page into text dropped almost all of it. In my scan of 40 ranking pages, none kept more than 4 of the 413 values found only in JSON-LD, so repeat key facts in visible text.

TL;DR

• JSON-LD is a block of schema.org data in a script element, and it has two readers. Indexers use it to understand a page, and Google says AI Overviews and AI Mode need no special schema.org markup (documentation updated 10 December 2025).
• Converters kept almost none of it. In my scan on 10 October 2026, 413 values on 29 of the 40 pages existed only inside JSON-LD script elements. The converters readability-lxml, html2text and markdownify kept none of them, while Jina Reader kept just 1 and trafilatura kept 4 values.
• No converter kept the sameAs links on any of the 11 pages where they appeared only in the markup.
• I found no documentation from OpenAI, Perplexity or Anthropic on schema.org use. At SMX Munich in March 2025, Microsoft's Fabrice Canel confirmed that schema markup helps Microsoft's large language models (LLMs) understand content, according to a summary of the talk reported by Search Engine Roundtable.
• Ahrefs (May 2026) tracked 1,885 pages that added JSON-LD markup. Citations in AI Mode (+2.4%) and ChatGPT (+2.2%) did not change significantly against matched controls, and AI Overviews fell 4.6%.
• Put the author, dates and FAQ in visible text, then generate the markup from that text so the two cannot drift.

What is a schema in AI, and who reads JSON-LD?

In AI (artificial intelligence) search, a schema usually means schema.org: a shared vocabulary of types such as Article, Person and FAQPage, and of properties such as headline, author and datePublished. JSON-LD (JSON for Linked Data) writes that vocabulary as a JSON (JavaScript Object Notation) object inside a <script type="application/ld+json"> element, apart from the visible text. Google recommends it when a site's setup allows (structured data introduction).

The first reader is an indexer. Google says it "uses structured data that it finds on the web to understand the content of the page." It can also process markup that is available when it renders the page (Google's guide to JavaScript-generated markup). For this reader the markup states what kind of page it is and who wrote it.

The second reader is a fetcher, meaning a tool that retrieves a page when a user asks a question so that a model can use it. A model takes text, so somewhere the HTML (HyperText Markup Language) has to become text. The sources I found do not document how each AI product does that step, so I tested five common converters instead.

Does schema markup help AI?

Not reliably, on the evidence I found. Google says its AI features need no special markup, other vendors document little, and the measured evidence is mixed. The sources, one by one:

• Google. AI features and your website, updated 10 December 2025, says: "There's also no special schema.org structured data that you need to add." It lists matching structured data to the visible text among the fundamentals that stay worthwhile.
• Microsoft. Search Engine Roundtable reported on 20 March 2025 that Fabrice Canel of Microsoft Bing confirmed on stage at SMX (Search Marketing Expo) Munich that schema markup helps Microsoft's LLMs understand content. The report rests on David Mihm's LinkedIn summary of the talk, not on a transcript or a Microsoft document.
• OpenAI, Perplexity and Anthropic. I could not find documentation on whether their search pipelines use schema.org fields. The crawler pages I opened on 10 October 2026 (OpenAI, Perplexity and Anthropic) never mention schema.org, JSON-LD or structured data.
• Ahrefs (May 2026). Its study of 1,885 pages that added JSON-LD between August 2025 and March 2026 compared citations 30 days before and after with matched controls. AI Mode (+2.4%) and ChatGPT (+2.2%) showed no significant change, and AI Overviews fell 4.6%, a small but statistically significant drop that Ahrefs calls unexplained. All pages were already heavily cited.
• searchVIU (test of 30 October 2025). The experiment write-up describes a page with eight prices placed in different ways. None of the five AI systems asked returned the price that appeared only in JSON-LD, though two were asked after indexing. The authors say the test mainly shows direct retrieval.
• Mark Williams-Cook (February 2026). In a test reported by Search Engine Roundtable, ChatGPT and Perplexity returned an address that existed only in made-up JSON-LD, which was also invalid. He took this to mean that the systems treat the HTML as plain text.

These sources disagree on whether JSON-LD reaches the model at all. In searchVIU's test the markup was ignored. In Williams-Cook's it was read, even when invalid. Neither result shows typed fields doing special work at answer time, and Ahrefs measured no significant citation gain. My converter test sits closer to searchVIU's result. The May 2026 version of this article claimed that models ground answers in the markup, which I could not support.

You will also see a claim that FAQPage makes a page 3.2 times more likely to appear in AI Overviews. On 10 October 2026 I searched for its primary source and found only secondary articles, none with a method or a sample size, so I do not repeat it. FAQPage still hands a retriever question-and-answer pairs that are already split into fields, but no evidence I trust says what that is worth.

Is schema still relevant?

Yes, for indexers, though not as a shortcut to AI citations. Google's Article documentation, updated 8 September 2026, says there are no required properties and recommends author, dates, headline and image. In August 2023 Google limited the FAQ rich result to well-known government and health sites, and its documentation changelog says that from 7 May 2026 the feature no longer appears. Ahrefs, whose study found no significant citation gain, still lists rich results and entity recognition among the good reasons to use JSON-LD. Keep it for those jobs.

What survives the trip from page to model?

I tested five converters on pages that rank for three queries: json-ld for ai search, schema markup for ai and structured data ai search. On 10 October 2026 I took the top 20 English-language Google results for the United States for each query from DataForSEO, which gave 54 unique URLs. I dropped 14: nine social or video pages, four that returned a 403 status (two Medium posts, WordStream and Search Engine Land) and one that timed out. That left 40 pages.

For each page I listed every JSON-LD string value of 12 or more characters, plus every date in a date field. I kept only the values that appear nowhere else in the page source: not in the visible text, not in a meta tag and not in a link. I call these JSON-LD-only values. There were 413 of them, on 29 pages. A value counted as kept when a converter's output contained it as a whole phrase, and for dates the test string was the calendar day.

The converters were trafilatura 2.3.1 (markdown output with metadata), html2text 2025.4.15, markdownify 1.2.3, readability-lxml 0.9 (its extracted article passed through html2text) and the public Jina Reader endpoint at r.jina.ai. The first four converters received the same raw HTML, fetched once with a desktop Chrome user agent and no JavaScript. Jina Reader received the URL and fetched the page itself. A script element inside a textarea, where syntax highlighters keep code samples, did not count as JSON-LD, and a value that matched a relative link on the page did not count as JSON-LD-only. Rerunning these rules on another day will give a different result list, and Step 4 below is the single-page version of the check.

Across the five converters, at most 4 of the 413 values survived, about 1%. Together they kept four distinct values on four pages: two dates and two site names. The sameAs property fared worst. It appeared only in JSON-LD on 11 pages, and no converter kept any of those links.

The survivors are not random. The json_metadata.py module in trafilatura reads the publisher or organization name, author names, the article section and the headline from the JSON-LD block. It does not read sameAs, citation, @id, about or mentions. Trafilatura finds dates with the htmldate library, whose date extractors include patterns for datePublished and dateModified inside JSON-LD scripts. In this sample, the survivors were the kinds of value that trafilatura has code for.

A retriever that embeds converted page text works with that same input. The Embedding Playground shows the principle: paste a paragraph and a question, and the similarity score comes from those words alone. My working rule from this test is narrow. A value that exists only in JSON-LD almost never reached the output of these converters, so every fact I want read also appears in the visible text.

Which Article fields do the ranking pages emit?

The same 40 pages show what the guides themselves ship. Of the 40, 33 carry JSON-LD, 30 include an Article-type node, 16 use @graph and 11 include FAQPage. That is more than five months after Google stopped showing the FAQ rich result. The AEO (Answer Engine Optimization) Adoption Scan I ran on 9 August 2026 on 93 pages found JSON-LD on 81.7% and FAQPage on 25.8%, close to the 82.5% and 27.5% here.

Google lists headline, dates, author and image as recommended for Article, and those fields appear on 26 to 30 of the 30 nodes. Of the 28 nodes that name an author, only 7 give that author sameAs and 14 give a url. That is markup written for indexers. My test asks which of these values a text converter passes on.

Which JSON-LD fields should you fill, and where do you repeat them?

Fill the fields below for indexers, and make sure each value also appears in the visible text, the copy that converters are built to keep.

JSON-LD earns its keep with indexers. In my scan, the converters I tested kept at most 4 of the 413 values that existed only in JSON-LD. Dates and authors have their own article: recency and authority.

Can you give me an example of schema markup?

Yes. Put a <script type="application/ld+json"> block in <head> or near the end of <body>. You can use several scripts or merge the entities into one @graph, which is cleaner because it lets you connect objects through @id. The sample describes one article and its visible FAQ, and its example.com addresses stand in for your own.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/posts/json-ld-guide#article",
      "headline": "How to help AI understand your content with JSON-LD",
      "description": "Which JSON-LD fields reach a model, and which to repeat in visible text.",
      "image": [
        "https://example.com/images/cover-1x1.jpg",
        "https://example.com/images/cover-4x3.jpg",
        "https://example.com/images/cover-16x9.jpg"
      ],
      "datePublished": "2026-05-01T08:00:00+00:00",
      "dateModified": "2026-10-10T08:00:00+00:00",
      "inLanguage": "en-US",
      "author": {
        "@type": "Person",
        "name": "Olena Koval",
        "url": "https://example.com/authors/olena-koval"
      },
      "publisher": {
        "@type": "Organization",
        "name": "Example Media",
        "logo": {
          "@type": "ImageObject",
          "url": "https://example.com/logo.png"
        }
      },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://example.com/posts/json-ld-guide"
      }
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/posts/json-ld-guide#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Does JSON-LD replace Microdata markup?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "It can. Google recommends JSON-LD when a site's setup allows it, and it still supports Microdata and RDFa."
          }
        },
        {
          "@type": "Question",
          "name": "Will an AI fetcher see my markup if JavaScript injects it?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Googlebot can, because Google processes structured data that is available when it renders the page. In Vercel's December 2024 analysis, the crawlers of OpenAI, Anthropic and Perplexity did not render JavaScript, so ship the JSON-LD in the initial HTML."
          }
        },
        {
          "@type": "Question",
          "name": "Will I get a FAQ rich result in Google Search?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "No. Google stopped showing the FAQ rich result on 7 May 2026. Keep the markup only if the same questions and answers are visible on the page."
          }
        }
      ]
    }
  ]
}
</script>

A few principles keep this block useful rather than decorative:

• The @graph property puts several entities in one script and links them through @id. The fragment (#article, #faq) keeps each identifier stable.
• The mainEntityOfPage property ties the Article to one canonical URL, the same one that <link rel="canonical"> and og:url name (see the invisible tags). Three places that agree are fine, and three that disagree make the page's identity ambiguous.
• The image property is recommended, not required. Google's Article page says "There are no required properties" and, for best results, recommends multiple high-resolution images in 16x9, 4x3 and 1x1 aspect ratios, which is why the sample lists three.
• Dates follow ISO (International Organization for Standardization) 8601 and carry a timezone offset. Without one, Google says it defaults to the timezone used by Googlebot.
• The FAQPage node copies its text from the visible questions and answers. Google's structured data guidelines say not to mark up content that readers of the page cannot see.

Implementation in Next.js (App Router)

The page below builds the visible FAQ and the FAQ markup from one array, so the two cannot drift. The Next.js JSON-LD guide warns that JSON.stringify does not sanitize strings that could inject script, so the replace call swaps every < for its unicode escape before the payload reaches the page.

import type { Metadata } from "next";
 
interface PageProps {
  params: Promise<{ slug: string }>;
}
 
const faq = [
  {
    question: "Does JSON-LD replace Microdata markup?",
    answer:
      "It can. Google recommends JSON-LD when a site's setup allows it, and it still supports Microdata and RDFa.",
  },
  {
    question: "Will I get a FAQ rich result in Google Search?",
    answer:
      "No. Google stopped showing the FAQ rich result on 7 May 2026. Keep the markup only if the same questions and answers are visible on the page.",
  },
];
 
export async function generateMetadata({ params }: PageProps): Promise<Metadata> {
  const { slug } = await params;
  return {
    title: `Article ${slug}`,
    alternates: { canonical: `https://example.com/posts/${slug}` },
  };
}
 
export default async function PostPage({ params }: PageProps) {
  const { slug } = await params;
  const canonicalUrl = `https://example.com/posts/${slug}`;
 
  const jsonLd = {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "Article",
        "@id": `${canonicalUrl}#article`,
        "headline": "How to help AI understand your content with JSON-LD",
        "description":
          "Which JSON-LD fields reach a model, and which to repeat in visible text.",
        "image": [
          "https://example.com/images/cover-1x1.jpg",
          "https://example.com/images/cover-4x3.jpg",
          "https://example.com/images/cover-16x9.jpg",
        ],
        "datePublished": "2026-05-01T08:00:00+00:00",
        "dateModified": "2026-10-10T08:00:00+00:00",
        "inLanguage": "en-US",
        "author": {
          "@type": "Person",
          "name": "Olena Koval",
          "url": "https://example.com/authors/olena-koval",
        },
        "publisher": {
          "@type": "Organization",
          "name": "Example Media",
          "logo": {
            "@type": "ImageObject",
            "url": "https://example.com/logo.png",
          },
        },
        "mainEntityOfPage": {
          "@type": "WebPage",
          "@id": canonicalUrl,
        },
      },
      {
        "@type": "FAQPage",
        "@id": `${canonicalUrl}#faq`,
        "mainEntity": faq.map(({ question, answer }) => ({
          "@type": "Question",
          "name": question,
          "acceptedAnswer": { "@type": "Answer", "text": answer },
        })),
      },
    ],
  };
 
  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
        }}
      />
      <article className="max-w-3xl mx-auto py-10 px-4 sm:px-6 lg:px-8">
        <header className="mb-8">
          <h1 className="text-3xl font-bold tracking-tight text-gray-900">
            How to help AI understand your content with JSON-LD
          </h1>
          <p className="mt-2 text-sm text-gray-500">
            By <a href="https://example.com/authors/olena-koval">Olena Koval</a>,{" "}
            <time dateTime="2026-10-10T08:00:00+00:00">updated October 10, 2026</time>
          </p>
        </header>
        <section>
          <h2>FAQ</h2>
          {faq.map(({ question, answer }) => (
            <div key={question}>
              <h3>{question}</h3>
              <p>{answer}</p>
            </div>
          ))}
        </section>
      </article>
    </>
  );
}

How does this site derive FAQPage and citation from the visible text?

This site used to keep each FAQ answer twice: as prose in the post and as a faq: array in front matter. According to the comment in src/lib/blog-faq.ts, 9 of the 16 question-and-answer pairs in the first three posts that did this had drifted apart by the time the posts shipped. Now extractFaq reads the ## FAQ section of a post. It takes each ### heading as the question and the text under it as the answer, and it strips links, emphasis and code ticks.

The citation property works the same way. The file src/lib/blog-citations.ts reads the external markdown links that a post already shows. It skips fenced code, links to this site and the author's own profiles taken from sameAs, and it emits each remaining link as a WebPage. Before commit cd40a4c on 10 September 2026, none of the site's 19 articles carried citation. Afterwards, 107 sources appeared across 13 articles.

None of this proves that any engine reads citation. I found no documentation that one does, and none of the 30 Article nodes in my scan used it. I emit it because deriving it is cheap and the claim is checkable: these are the sources the article leans on.

Deriving the markup moved the risk into the rules, and one rule failed quietly. The résumé module switched the LinkedIn address to the www form so that it matches the one Wikidata publishes. The bio block at the foot of eleven posts still linked the bare-host form, so the comparison stopped matching. Those eleven articles would have cited their own author as an independent source, and an existing unit test caught it before release. The fix is to canonicalise both sides before comparing:

export const canonicalUrl = (url: string) =>
  url
    .toLowerCase()
    .replace(/\/+$/, '')
    .replace(/^(https?:\/\/)www\./, '$1');

A citation entry tells a machine that the article leans on that source, so an entry pointing at the author's own profile makes a false claim. Deriving the markup removes drift between two copies, but it does not remove the need to test the derivation.

How do you verify the markup, and what does a fetcher see?

Four checks are enough. The first three confirm that the markup is present and valid, and the fourth, new in this version of the article, shows what survives conversion to text.

Step 1: Browser DevTools, an instant presence check

Open the page and run this snippet in the DevTools console. It reads the rendered page, so it also finds blocks that JavaScript added after load:

const blocks = document.querySelectorAll('script[type="application/ld+json"]');
console.log(`JSON-LD blocks found: ${blocks.length}`);
 
blocks.forEach((block, i) => {
  try {
    const parsed = JSON.parse(block.textContent);
    console.group(`Block #${i + 1}`);
    console.log(parsed);
 
    if (parsed["@graph"]) {
      const types = parsed["@graph"].map((item) => item["@type"]);
      console.log("Entity types in @graph:", types);
    } else if (parsed["@type"]) {
      console.log("Entity type:", parsed["@type"]);
    }
 
    console.groupEnd();
  } catch (err) {
    console.error(`Block #${i + 1} contains invalid JSON:`, err.message);
  }
});

The snippet shows how many blocks there are, whether each one parses and which entities it holds. Zero blocks means the rendered page carries no markup, and a JSON.parse error means broken syntax that no later validator can fix. The AEO Checker extension runs this first check on any page you open.

Step 2: Schema Markup Validator, syntax and vocabulary

Visit validator.schema.org. It checks JSON-LD syntax against the schema.org vocabulary and lists every entity, field and unknown property it finds, independent of any search engine.

Step 3: Rich Results Test, Google's view

Open the Rich Results Test and test by URL rather than by pasted code, which Google recommends when JavaScript generates the markup. Article has no required properties, so a clean Article result proves little. The test earns its place for feature types that do list required properties.

Step 4: Converter run, what a fetcher keeps

This script fetches the raw HTML, runs trafilatura as my scan did and reports which of your values appear in the output:

import sys
 
import trafilatura
 
url, *values = sys.argv[1:]
html = trafilatura.fetch_url(url)
if html is None:
    sys.exit(f"Could not fetch {url}")
 
text = trafilatura.extract(html, url=url, output_format="markdown", with_metadata=True) or ""
for value in values:
    print("kept   " if value in text else "MISSING", value)

Run it with uv, passing the page address and then the values you care about, such as the author name, a profile link and the publication date:

uv run --no-project --with trafilatura==2.3.1 python check_fetch.py https://example.com/post "Olena Koval" "2026-10-10"

A value marked MISSING never reaches a model through a converter like this one. If it is also absent from the visible text, add it there or accept that it works for indexers only.

Which structured-data syntax should you use?

All three syntaxes are valid to a parser, and only one is pleasant to maintain.

The maintenance rows are the whole argument. In Microdata, an itemprop normally belongs to the item whose itemscope contains it, with itemref as the exception. A template change that moves the element outside detaches the property, and in review that change looks purely visual.

What are the limits of this test?

A scan like this is easy to over-read, so here is what it does not cover:

• One slice. One snapshot, one market, one day and 40 pages: Google results in English for the United States on 10 October 2026. This is not a trend.
• No rendering for four of the five. The four libraries saw raw HTML, so pages that inject JSON-LD with JavaScript look poorer to them than they do to Googlebot, which renders them. Jina Reader fetched each page itself, and I did not check whether it renders JavaScript. Seven of the 40 pages showed no JSON-LD in their raw HTML, and some may add it in the browser.
• Five converters are not all AI search. How ChatGPT search, Perplexity or Claude prepare a page for a model is not documented in the sources I found, and this test does not prove it. It shows what common open libraries and one public reader do.
• Visible values are not counted. A headline or an author name is usually visible, so it reaches a model through the text and not through the markup. The test cannot say where a converter got such a value.
• Matching is exact. A value counted as kept only when it appeared as a whole phrase, and dates were matched by calendar day. A converter that rewrote a date as "Sep 28, 2026" would register as losing it, so the date counts are a floor.
• Coverage gaps. Strings under 12 characters, apart from dates, were not tested. One JSON-LD block on one page failed to parse and was skipped. The field counts read only the first Article-type node on each page.
• Indexers are out of scope. Indexers such as Google process structured data when they index a page. This test does not measure them, and nothing here argues for removing the markup.

FAQ

Does schema markup help SEO?

Yes, but mainly for understanding and display. Google says Article markup can help it show better title text, images and date information, and that it does not guarantee features built on structured data will appear. A structured data manual action costs rich result eligibility but, per Google, does not affect web ranking.

Is ChatGPT an AI search engine?

Partly. ChatGPT is a chatbot that includes search features. OpenAI's crawler page lists OAI-SearchBot as the bot that surfaces websites in those features, and ChatGPT-User for certain user-initiated actions. The page never mentions schema.org or JSON-LD, so how ChatGPT search prepares a page for the model is undocumented in the sources I could find.

Does structured data matter more for AI than for search?

The evidence does not say so. Google documents no special schema for its AI features, and in my scan no converter kept more than 4 of 413 JSON-LD-only values. Structured data still helps indexers, but a model can quote only what reaches it, and visible text is the copy most likely to arrive.

Do I need both Article and FAQPage on the same page?

Only when the page has a visible FAQ section. On 7 May 2026, Google stopped showing the FAQ rich result, so this markup can no longer earn it. Google said in August 2023 that unused structured data does not cause problems for Search. If you keep it, put it in the same @graph as the Article and build it from the visible questions, as this site does.

What happens if the markup and the visible page disagree?

Google's guidelines say structured data must be a true representation of the page content and that you should not mark up content readers cannot see. The documented consequence is a manual action that removes rich result eligibility, not a ranking change. On this site, 9 of 16 duplicated pairs had drifted apart, because each answer was typed twice.

Will an AI fetcher see JSON-LD that JavaScript injects?

Googlebot can: Google says Search processes structured data that is available when it renders the page. In Vercel's December 2024 analysis, the crawlers of OpenAI, Anthropic, Meta, ByteDance and Perplexity did not render JavaScript, while Gemini uses Googlebot's rendering. In searchVIU's October 2025 test, none of five AI systems returned a price carried by JSON-LD that JavaScript had inserted. Ship JSON-LD in the HTML the server sends.

How do I check my JSON-LD is actually valid?

Run four checks, cheapest first. DevTools confirms the block is on the page, and the Schema Markup Validator finds vocabulary errors. The Rich Results Test shows what Google can process, and a converter run shows which values reach text. The AEO Checker extension does the first check on any page you open.

Sources

• Google Search Central: AI features and your website, Article structured data, structured data guidelines, documentation updates and changes to HowTo and FAQ rich results.
• Evidence: Ahrefs, searchVIU, Search Engine Roundtable on Williams-Cook's test and on Canel's remark, Vercel.
• Reference: schema.org/Article, schema.org/FAQPage, schema.org/citation and the Next.js JSON-LD guide.

Part of the Answer Engine Optimization (AEO) cluster: the full reading order in dependency sequence, plus a glossary of every term used across these articles.

Does your markup say what your page says?

Follow me on LinkedIn for new posts. If you need an architecture review, deep schema implementation or an AEO-aware Next.js setup, email me about a consulting engagement.