JSON-LD and AI Search: What Structured Data Actually Does

What JSON-LD actually tells a machine

A visitor can read your About page and work out which company runs the website. Structured data makes some of those relationships explicit: this is an organization, this is its website, and this organization publishes this content.

Three terms often get mixed together. Structured data is the information expressed in a machine-readable structure. Schema.org supplies a shared vocabulary, including types such as Organization and Product. JSON-LD is one format for expressing that information. Google also supports Microdata and RDFa, so a page without a JSON-LD script can still contain structured data. See Google’s introduction to structured data.

For an audit, the useful question is therefore not simply “Does this page have JSON-LD?” It is “What entities and properties were found, in which format, and do they accurately describe this page?”

Does structured data improve AI search visibility?

It provides explicit information that a system can interpret. That does not establish how much weight a particular AI search product gives it, or whether that product will cite your page. Treat claims of a guaranteed AI ranking boost as claims that need evidence.

Google explicitly says there is no special Schema.org markup required for AI Overviews or AI Mode. A supporting page must be indexed and eligible for a Search snippet, and ordinary SEO foundations still matter. Read Google’s AI features guidance. That statement applies to Google’s features; it is not documentation of every other AI service.

In an AI search visibility checklist, keep markup quality separate from access, content availability and observed citations. A correct Organization block cannot repair a blocked request or replace a missing product description. If you have not checked access yet, start with which AI bots can access your website and the full AI visibility checklist.

Step 1: Decide what each page actually describes

Start with a small inventory of page templates. You do not need every Schema.org type on every URL. Choose a type because it represents the real content, not because a competitor uses it.

These are modeling starting points, not a universal checklist of required fields. Google’s Organization documentation recommends relevant properties and does not define a universal set of required Organization properties. Do not invent an address, social profile or identifier to make a completeness score turn green.

Step 2: Connect entities with stable identifiers

The fictional example below separates the company from the website it publishes. It illustrates relationships, not a complete implementation or a rich-result eligibility template. Replace the example identity and URLs with verified information before using it.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Studio",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}
</script>

In JSON-LD, @id identifies a node. Reusing the organization’s identifier in publisher links the website to that node. @graph groups nodes; merely placing objects in an array does not establish a publisher relationship. These mechanisms are described in the W3C JSON-LD specification.

As an implementation convention, choose stable identifiers and reuse them consistently across templates. Avoid having one plugin describe your company as /#organization while a custom snippet creates a second, conflicting company under another identifier.

Use sameAs for pages that identify the same entity. An official company profile may fit; the homepage of a review platform does not identify your particular company, and an article that mentions your business is not automatically an identity link either. See the Schema.org definition of sameAs.

Step 3: Inspect what the server and browser actually deliver

Do not stop at the settings screen of your SEO plugin. Inspect a published URL while logged out. A correct template setting can still produce missing, stale or duplicate output.

• Save the initial HTML response and its final URL after redirects. Record the HTTP status and test time.
• Inspect the rendered page after JavaScript has run, and compare it with the initial response.
• Look for JSON-LD scripts, Microdata attributes and RDFa markup. Parse the data instead of relying only on text matches.
• Record which entity types and properties appear in each version. If a request fails, report that limitation rather than calling the markup absent.

Google documents support for structured data generated with JavaScript. That does not demonstrate that every crawler processes your scripts. Our practical recommendation is to deliver important markup in the initial HTML when feasible, especially if it can be generated from the same server-side data as the page. See why AI crawlers may not see your JavaScript content.

For example, if Product markup appears only after a visitor selects a variant, record that dependency. Test the default URL and a representative variant state separately. Do not report the whole shop as covered after checking only its homepage.

Step 4: Validate the structure, then verify the facts

Use complementary checks. The Schema.org Markup Validator helps inspect Schema.org markup across JSON-LD, Microdata and RDFa. The Google Rich Results Test focuses on supported Google search features. A “no items detected” result in a feature-specific test is not, by itself, proof that the page contains no structured data.

The validator’s documentation describes its extraction and syntax checks. Neither a parser nor a green validation result can confirm that your company phone number, product availability or author identity is true.

• Syntax: does each JSON-LD block parse?
• Model: do the types, properties and relationships describe the intended entities?
• Feature requirements: for a particular Google feature, use that feature's current documentation.
• Factual consistency: compare markup with the visible page and the authoritative CMS or commerce records.
• Coverage: repeat on representative URLs from each affected template.

Google requires structured data to represent the page content and follow its quality policies, and states that correct markup does not guarantee a rich result. See the general structured data guidelines.

Common errors worth fixing first

Multiple blocks are not automatically a defect. A page can legitimately describe an organization, an article and breadcrumbs. The issue is contradiction, incorrect modeling or unnecessary duplication — not the number of script tags.

Do not add invented ratings, reviews or credentials to satisfy a tool. If a field is irrelevant or unavailable, the honest result may be “not applicable” or “not verified.” More populated fields do not automatically mean better data.

Step 5: Give your developer a reproducible task

A useful task identifies an exact mismatch. “Improve schema for AI” leaves too much room for guesswork. The example below is a suggested ticket format, not a finding from an audited website.

Separate the observation from the likely cause. A stale cache is a hypothesis until you inspect it. Likewise, an outside scan cannot prove which plugin or backend job created a value unless additional evidence identifies it.

Agencies that hand this kind of evidence to clients can deliver it under their own brand with white-label website audits.

Step 6: Verify the fix before claiming a visibility gain

Retest the same URLs after deployment. Confirm that the intended fields changed, relationships remain intact and no second source still emits conflicting data. Save the new evidence alongside the original finding.

Then track outcomes separately: markup correctness, supported search appearance, organic traffic and observed AI citations answer different questions. If traffic increases after a release that also changed content, internal links and page speed, do not attribute the entire increase to JSON-LD.

For repeated AI checks, record the query, service, date and cited URL. Keep the query set reasonably consistent and describe the sample size. A single favorable answer is evidence of that answer, not a reliable estimate of overall visibility.

The practical goal is a website whose public facts are clear and consistent across its content and machine-readable output. Make that reliable first; assess discovery and business results with their own measurements.

Frequently asked questions

Technical references

• Google Search Central – Introduction to structured data
• Google Search Central – AI features and your website
• Google Search Central – Organization structured data
• Google Search Central – Generate structured data with JavaScript
• Google Search Central – General structured data guidelines
• Google Rich Results Test
• Schema.org Markup Validator
• Schema.org – sameAs
• W3C – JSON-LD 1.1

Go deeper