Schema markup for AI search: a step-by-step implementation guide

Step 1. Audit the page and its existing markup

Do this: Inspect the visible page and the JSON-LD already emitted by the template. List incorrect facts, duplicated nodes and missing relationships before changing code.

A structured description can be syntactically perfect and factually wrong. For an expert’s website, the useful first task is to check author, organization, role, dates and URLs against visible, verifiable information. Adding properties before resolving those facts creates a more elaborate error.

Google’s AI-features guidance does not require special schema for AI Overviews or AI Mode. Accurate structured data can describe content and support eligible search features, but it is not a universal citation instruction for ChatGPT or other providers.

This guide covers implementation for a personal expert site and its articles. For the broader question of confusing people or organizations, use the entity identity guide. Correct identity is useful even when a later AI-visibility test shows no change.

Before moving on: The page facts are verified and the existing output is recorded, including any schema produced by plugins.

Step 2. Choose only the relevant types

Do this: Use the table to identify what this page actually represents. List the types and verified properties you need, then check the relevant feature documentation.

Schema.org supplies the vocabulary. JSON-LD supplies a way to express linked data. @id identifies a node; sameAs supplies an identity reference. These jobs differ. A type being available in Schema.org does not mean Google offers a rich result for it on your site. Check current feature-specific documentation.

For articles, Google’s Article documentation explains properties such as headline, image, author and dates. Include information that fits the content and the supported feature rather than copying every property from another site.

Before moving on: Each chosen type has a visible counterpart or a factual relationship on the page.

Step 3. Build the graph with real identifiers

Do this: Adapt the illustrative relationship example to the verified page facts. Replace every demo value and connect the article author to the intended Person node.

Illustrative example with reserved example domains: the following graph describes a fictional author and article. It is displayed as a code sample, not installed as this page’s structured data. Replace the URLs, name, headline and dates with verified page facts before using it. It is a small relationship example, not a complete feature-eligibility template.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/#jane-doe",
      "name": "Jane Doe",
      "url": "https://example.com/about",
      "sameAs": [
        "https://profiles.example.org/jane-doe"
      ]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/measurement-guide#article",
      "url": "https://example.com/blog/measurement-guide",
      "headline": "A practical measurement guide",
      "datePublished": "2026-09-01",
      "dateModified": "2026-10-04",
      "author": {
        "@id": "https://example.com/#jane-doe"
      }
    }
  ]
}

The article’s author.@id matches the Person node exactly. Reuse that person identifier on other pages about the same author. The article identifier remains distinct. A fragment identifier does not create a separate article URL or replace the page’s canonical link.

The profile in sameAs is hypothetical. In production, include a profile only after checking that it identifies that same person. An employer’s homepage belongs in an appropriate organization relationship, not in a person’s sameAs. A Wikipedia or Wikidata entry is not required. Do not add an uncertain namesake just to fill the field. See the property definition.

On a static site, JSON-LD can sit inside a script element with type="application/ld+json" in the HTML. In a CMS, check what the template or plugin already emits before adding another graph. Keep EN and ES page identities distinct while referencing the same real author. Translations need factual consistency, not identical sentences.

Before moving on: No fictional identity or example-domain URL remains in production data; the actual person and article have distinct identifiers.

Step 4. Validate the draft and published output

Do this: Work through the validation table. Resolve errors and factual mismatches before release; then inspect what the published URL actually serves.

Use the Schema.org Validator and Rich Results Test for their distinct purposes. Neither can establish that a professional credential is true. Google’s structured-data guidelines require relevant, representative content and explain that correct markup does not guarantee a rich result.

Record the exact page version, test date, findings and corrections. Review canonical and language links separately: schema validation does not replace those checks. Preserve the original publication date; use modification dates for substantive changes rather than scheduled freshness claims.

Before moving on: The validation record states the tested URL/version, tools, findings and unresolved issues. A syntax pass is not the final check.

Optional follow-up: investigate impact separately

Do this: If you want to study visibility effects, retain a baseline before deploying the change and record other simultaneous edits.

A successful implementation means the markup accurately represents the page and passes the checks relevant to its purpose. It does not mean the page has acquired citation authority. To investigate outcomes, save a baseline, document the markup change and preserve any simultaneous content or technical changes.

Repeat a fixed question panel under declared conditions and record exact-page citations, not just mentions. Variability, indexing delays and platform changes remain alternative explanations. A before-and-after result alone cannot isolate schema’s contribution. The AI visibility guide defines the rates and denominators.

Google’s Generative AI performance report can provide available AI-feature impressions; it is not a causal test of structured data and does not measure other platforms. Start with one page, verify its actual graph, and correct the first mismatch between markup and reality.

Before moving on: Implementation completion is reported separately from any observed AI outcome.

Check your finished work

Copy-and-complete template

This is a working template, not observed results.

Page URL / language / version: [ ]
Existing graph / changes made: [ ]
Article ID / author ID / verified identity links: [ ]
JSON parse / vocabulary / feature test: [result and date]
Visible-fact check / remaining issue: [ ]
Published-output check / reviewer: [ ]

• The markup agrees with the visible author, content and dates.
• Article and Person identifiers connect correctly without conflating entities.
• Demo URLs and fictional example values are absent from production markup.
• Syntax, vocabulary and feature-specific findings have been reviewed.
• The actual published URL serves the intended graph and language links.
• Any unresolved factual issue is fixed before the implementation is called complete.