How to Audit JSON-LD for AI Search

To audit JSON-LD for AI search, pull the structured data from the live rendered page, then check every value against what a visitor can actually see. Keep markup that’s accurate and visible, fix anything that drifted, and remove anything that describes content, reviews, or entities the page doesn’t show. Don’t add new schema types hoping an AI engine will notice. Google says there’s no special schema.org markup needed for AI Overviews or AI Mode. The best controlled test we found showed that adding schema barely moved AI citations.

Here’s the usual situation. Someone on your team installs a schema plugin, a developer adds FAQ markup to the template, and a year later nobody knows what your pages claim in code. The site still ranks. But the JSON-LD now says things the page doesn’t.

I’m Satya Phanindra Reddy, founder of Magic Teams AI. Below is the audit order we use, the rules behind each step, and a worked example from this blog, two real bugs included.

What does JSON-LD actually do for AI search?

JSON-LD is a block of structured data in your page’s HTML that labels things: this is an article, this is the author, this is the organization that published it. Search engines use it to understand a page and to qualify it for rich results.

For AI answers, the evidence is thinner than most schema advice suggests. Three sources worth knowing:

• Google: its AI features guide says you don’t need new machine-readable files or markup to appear in AI Overviews or AI Mode. It does list making sure structured data matches the visible text as a worthwhile practice.
• Microsoft: Bing’s Fabrice Canel said in March 2025 that schema markup helps Microsoft’s LLMs understand content, as reported by Search Engine Land.
• Ahrefs: a May 2026 study tracked 1,885 pages that added JSON-LD against matched controls. Google AI Overview citations fell 4.6% relative to controls, a small but statistically significant drop. Ahrefs notes both groups were already declining, so it can’t say schema caused it. AI Mode rose 2.4% and ChatGPT rose 2.2%, which Ahrefs said were statistically indistinguishable from zero.

So the honest position is this. JSON-LD is hygiene that helps machines read you correctly. It’s a weak lever for getting cited. That makes accuracy the whole game, because wrong markup is a liability and extra markup is mostly noise.

What counts as a JSON-LD problem?

Google’s structured data policies set the boundary in plain words: don’t mark up content that isn’t visible to readers, provide up-to-date information, and make the structured data “a true representation of the page content.” Breaking those rules can lead to a manual action that removes rich result eligibility.

That gives you three kinds of problems:

1. Parity failures. The JSON-LD says something the page doesn’t show. A FAQ answer that isn’t on the page, a price that changed, an author name that differs from the byline.
2. Unsupported claims. Markup describing things the page has no business claiming. Star ratings for your own business on your own site, sameAs links to profiles that aren’t you, an Organization description that contradicts your About page.
3. Dead weight. Types Google no longer uses for display. Google deprecated How-to rich results in September 2023 and limited FAQ rich results to well-known, authoritative government and health sites. In June 2025 it phased out seven more types, including Course Info, Claim Review, and Estimated Salary.

The first two are worth fixing this week. The third usually isn’t urgent. Google says structured data that isn’t being used “does not cause problems for Search”. Treat it as cleanup when you have time.

How do you audit JSON-LD step by step?

We use a five-check order we call the Visible-First JSON-LD Audit: Inventory, Parity, Support, Entities, Freshness. There’s nothing proprietary in it. We took Google’s three policy rules, put them in a sequence, and added the two checks that caught real bugs when we audited our own blog.

The order matters for one reason: you can’t judge markup until you know what’s actually shipped.

Step 1: Inventory what the live page ships

Don’t audit your CMS settings or your template file. Audit what a crawler receives. Plugins, tag managers, and theme code can each add their own blocks, and you’ll often find two Organization entries that disagree.

Use view-source or a curl of the live URL and list every application/ld+json block. The Rich Results Test also shows rendered output, and the Schema Markup Validator checks syntax against schema.org for any type, not only the ones Google supports.

Step 2: Check parity against visible content

For each value, ask one question: can a reader find this on the page? Headline, author, dates, FAQ questions and answers, prices, addresses. If a value only exists in the JSON-LD, it fails.

Normalize before you compare. Curly quotes, stripped links, and extra whitespace make exact string matches fail on text that’s actually identical. We learned that the hard way (more below).

Step 3: Check that each type is supported and earned

Look up each type in Google’s search gallery, and in Bing’s docs if Copilot matters to you. Then ask whether the page earns it. A blog post can claim BlogPosting. It can’t claim Product with an aggregateRating because you’d like stars.

Google’s review guidelines are explicit here. Organization and LocalBusiness review markup is only for sites that capture reviews about other businesses. Reviews of yourself, on your own site, aren’t eligible for star snippets.

Step 4: Check that entities agree

This is the step that matters most for AI search, because answer engines are trying to work out who you are. Check that the person’s name, job title, and organization match across every page’s JSON-LD, the visible byline, and the author page.

Then check every sameAs URL. It should resolve, and it should clearly be about the same person or company.

Step 5: Check freshness and validity

Confirm dateModified changes when the content does, not on every deploy. Confirm image, logo, and @id URLs return a 200. Re-run the validator after any template change.

What does the decision look like for each property?

Once you’ve run the checks, every property gets one of three outcomes. This is the rule we apply.

The last branch has a fair alternative. If the information is true and useful, add it to the visible page and then keep the markup. Just don’t do it backwards.

Worked example: what did auditing this blog turn up?

This is first-hand. On October 18, 2026, we ran the five checks against the live HTML of blog.magicteams.ai, using curl and a short Python script rather than reading our template code. Our posts emit Organization, WebSite, BlogPosting, Person, BreadcrumbList, a FAQPage when a post has a FAQ section, and HowTo when a post uses numbered step headings.

Here’s what we found.

Check	Finding	Decision
Inventory	116 of 118 posts emit FAQPage, 4 emit HowTo	Proceed
Parity	One post’s FAQ answer contained raw component code for a chart. Readers saw a chart. The JSON-LD said <Visual template="PhaseBars"...	Fix
Parity	First pass flagged 4 of 5 FAQ answers on another post as missing. After normalizing curly quotes, all 5 matched	No change, fix the test
Support	HowTo on 4 posts, a type Google no longer shows as a rich result	Keep for now: steps are visible and accurate
Entities	Person.name is “Phanindra Reddy” while post intros say “Satya Phanindra Reddy”	Fix: one canonical name, plus alternateName
Entities	Organization.sameAs points to a site whose homepage doesn’t mention Magic Teams AI	Fix or remove, pending confirmation
Freshness	Logo, cover image, and author page @id URLs all return 200	Keep

Two lessons from that table. Validators only check syntax, so a clean report proves very little about accuracy. And the entity problems were the quiet ones. Nothing broke, but our markup was telling machines a slightly different story about who writes this blog than the pages tell people.

What should go on a parity checklist?

Use this list per template, not per page. If your blog template passes, most posts using it will pass too, so spot-check a few posts with unusual content like tables, charts, or embedded components.

Visible-content to JSON-LD parity checklist

• headline matches the visible H1 or title
• author name matches the byline and author page
• datePublished and dateModified match visible dates
• Every FAQ question and answer appears on the page as written
• Prices, hours, and addresses match what readers see today
• No ratings or reviews you can't show on the page
• Every sameAs URL resolves and is about the same entity
• One Organization block per page, with one consistent description
• Image, logo, and @id URLs return 200
• No markup text that never renders, such as code, placeholders, or old copy

How often should you audit JSON-LD?

Run the full audit once, then re-run parity and entity checks whenever a template, plugin, or CMS setting changes. Those are the moments drift happens.

For most agency or practice sites, a quarterly check on a handful of templates is enough. If you publish daily, automate the parity check so it runs on every build. That would have caught our chart leak the day it shipped.

If your site is in a regulated field like law, accounting, or health, check claims in markup with the same care as claims on the page. Structured data is still a public statement about your business. When in doubt, ask whoever reviews your marketing for compliance.

Frequently asked questions

Do I need special schema for ChatGPT or Perplexity?

We haven’t found any documented AI-only schema type these engines require, and Google says the same for its AI features. Accurate, standard schema.org markup that mirrors your visible content is the safe default.

Should I remove FAQPage and HowTo markup now that Google doesn’t show those rich results?

Usually you can leave it. Google says unused structured data doesn’t cause problems, and tools outside Google Search may still read it. Keep it if it mirrors visible content exactly. Remove it if it doesn’t.

Can a validator tell me my JSON-LD is accurate?

No. The Rich Results Test and the Schema Markup Validator check syntax and required fields. They can’t tell whether a value matches what’s on the page. That’s a manual or scripted parity check.

Will fixing my JSON-LD get me cited in AI answers?

We can’t promise that, and neither can anyone else. The best available test showed little citation change from adding schema. Fixing it removes a source of confusion about who you are, which is worth doing on its own.

Where does this fit in a wider AI search setup?

JSON-LD is one layer of answer engine optimization for B2B, and not the biggest one. Clear pages, crawlable HTML, and consistent entities do more work. The audit matters because it keeps your markup from contradicting all that.

It’s also a check that drifts if nobody owns it. That’s why we’d put the Visible-First JSON-LD Audit inside the recurring review step of an AI search content system, rather than treating it as a one-off. If you’re deciding whether automating it is worth the time, weigh it like any other workflow using how to measure ROI on AI automation.

At Magic Teams, we build connected, reviewable workflows like this for founders whose site, content, and checks have drifted into separate jobs. If that sounds familiar, a fit call is a quick way to find out whether it’s the right problem to fix now.