Schema Implementation

1. What to deploy and in what order

Schema.org defines several hundred types, but an AI-focused deployment needs about six. Their order matters more than their number because each tier offers a different level of value. Organization, Person, and sameAs identify who you are in a form that can be reconciled with an external graph. The remaining types describe what the page is, which a parser can largely infer from the HTML. Work through the tiers in order and stop when the next one no longer justifies the effort.

Before writing JSON, understand the limits of what markup can accomplish. Ahrefs used a difference-in-differences design to compare 1,885 pages that added JSON-LD between August 2025 and March 2026 with roughly 4,000 matched controls. Citations changed by −4.6% in AI Overviews, +2.4% in AI Mode, and +2.2% in ChatGPT; the last two results were statistically indistinguishable from zero. The study concluded, “Adding schema produced no major uplift in citations on any platform” (Ahrefs, 2026). Google likewise lists excessive focus on markup as a common mistake: “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add” (AI optimization guide).

The benefit is narrow, not nonexistent. Markup provides a reliable machine-readable description and an entity that a machine can resolve. Both are inexpensive to maintain and costly to reconstruct later, but neither guarantees inclusion in an answer. The GEO benchmark results often cited by practitioners (Aggarwal et al., KDD ‘24, arXiv:2311.09735 · paper summary) measured changes to content substance and structure, including added sources, statistics, and quotations. The study did not test schema markup as a variable, so its results cannot justify an investment in markup.

2. Make four decisions before deployment

Four decisions determine how the rest of the implementation works. If you choose the wrong delivery layer, valid markup may never reach the intended crawlers.

Gather these inputs before you start. You need the rendered HTML returned by a non-JavaScript fetch, an authoritative list of the organization’s official profiles and registry identifiers, an author roster with real and resolvable identities, and an inventory of the available templates and their data.

When to implement or revisit schema. Do so when launching a site or template, migrating a CMS or framework, renaming, merging, or rebranding an entity, changing the author model, or correcting markup that a full GEO audit found to be missing, invalid, or inconsistent with the page. For existing markup whose origin or behavior is unclear, begin with a Schema Audit.

3. Tier 0: Establish entity identity

Tier 0 requires both code and editorial judgment because every identity claim must be accurate and externally corroborated.

3.1 Add a site-wide Organization block

Emit one block across the site and give it a stable @id that every other node can reference. This avoids creating duplicate organization nodes.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "legalName": "Example Company Ltd.",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/assets/logo.png",
    "width": 512,
    "height": 512
  },
  "description": "Short factual description matching the About page.",
  "foundingDate": "2019-03-01",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000",
    "https://www.linkedin.com/company/example-co",
    "https://github.com/example-co"
  ]
}

Google’s Organization documentation explicitly states that none of these properties is required: “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization” (Organization structured data). Any checklist of required fields reflects its author’s convention, not a Google rule. Each field makes a distinct assertion:

One aspect of @id often causes confusion: it is an identifier, not a page that must resolve. Using a real URL fragment on a real page, such as https://example.com/#organization, makes the graph easier to inspect in the page source and prevents the collision described in §8.

3.2 Represent authors as resolvable Person identities

Use the same pattern for authors, linking each person to the organization by reference instead of repeating the organization data.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/authors/jordan-lee#person",
  "name": "Jordan Lee",
  "url": "https://example.com/authors/jordan-lee",
  "jobTitle": "Principal Engineer",
  "worksFor": { "@id": "https://example.com/#organization" },
  "knowsAbout": ["structured data", "search infrastructure"],
  "sameAs": [
    "https://www.wikidata.org/wiki/Q000001",
    "https://orcid.org/0000-0000-0000-0000",
    "https://github.com/jordanlee"
  ]
}

The main decision comes before the syntax. A Person block for a byline with no public footprint creates an identity that nothing can corroborate and that an engine cannot connect to other sources. The author should either have a genuine, resolvable presence reflected in the sameAs list, or the page should be attributed to the Organization without a Person block. A fabricated author cannot be externally corroborated, and fabricated authorship also raises trust concerns. Whether an engine can connect the identity to other sources depends on entity recognition.

3.3 Choose sameAs targets as factual claims

A plugin cannot make this decision because it is not merely a configuration choice. Each entry asserts that this entity is the one represented at that URL, and the claim can be checked.

Follow three rules. Every target must represent the same entity, not a related or parent organization. A short list is better than one containing unverifiable or aspirational links because the wider web may contradict those claims. The list must also remain consistent with the entity’s existing public footprint.

The documentation supports a narrower interpretation of sameAs than the industry often presents. Google’s Organization page defines it as “the URL of a page on another website with additional information about your organization”. When that page identifies the properties used “behind the scenes to disambiguate your organization from other organizations”, it names iso6523 and naics, not sameAs. For authors, Google explicitly states that it understands sameAs when disambiguating (Article structured data). The property is therefore well supported as an identity signal for Person and a reasonable, though unstated, inference for Organization. It remains inexpensive and accurate, but the registry identifiers that Google explicitly names provide stronger support for deployment.

sameAs creates an edge; it does not create the node at the other end. If an organization has no Wikidata item, adding sameAs cannot create one. Wikidata’s inclusion policy accepts an item if it has a valid sitelink to a Wikimedia project, refers to “an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references”, or fulfills a structural need (Wikidata:Notability). Creating that node requires separate evidence of notability and a broader knowledge graph presence.

4. Tier 1: Type pages and connect them with @graph

Tier 1 states what a page is and who is responsible for it. Four fields carry the most useful information in Article, NewsArticle, or TechArticle: headline, author pointing to a Person @id, datePublished, and dateModified. As with Organization, Google states that Article has no required properties, only recommended ones (Article structured data).

Dates require particular care. Google says they must describe the page rather than the events discussed on it, must not be in the future, and must match the date shown to readers: “Ensure that the date (and optional time and timezone) match between the equivalent user-visible and structured values” (Article publication dates). Connecting dateModified to the build timestamp, a common default in static-site setups, claims that the page changed every day even when it did not and repeatedly contradicts the visible date.

WebSite connects the site’s identity to the organization and belongs in the same block. BreadcrumbList describes the page’s position in the site hierarchy; omit it on flat sites where a breadcrumb would have to be invented. Both require little effort, but neither is critical on its own.

A maintainable implementation uses one @graph per page and connects nodes through @id references instead of repeating them inline:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Co",
      "url": "https://example.com",
      "sameAs": ["https://www.wikidata.org/wiki/Q000000"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Example Co",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/authors/jordan-lee#person",
      "name": "Jordan Lee",
      "url": "https://example.com/authors/jordan-lee"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/deploying-json-ld#article",
      "headline": "Deploying JSON-LD at build time",
      "isPartOf": { "@id": "https://example.com/#website" },
      "author": { "@id": "https://example.com/authors/jordan-lee#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "datePublished": "2026-07-02T09:00:00+00:00",
      "dateModified": "2026-08-04T11:30:00+00:00",
      "mainEntityOfPage": { "@id": "https://example.com/blog/deploying-json-ld" }
    }
  ]
}

Emitting a separate block for each entity is equally valid. Google does not distinguish between the approaches, and many production sites use separate blocks. @graph is a useful default for maintenance, not a requirement for correctness: each entity is defined once per template set, the article node references it, and an identity change needs to be corrected in only one place.

Connect the graph to templates so that the data remains consistent:

5. Tier 2: Describe assets and answer formats when present

Tier 2 is conditional. Add a type only when the page genuinely contains what that type describes.

Assets. For images, video, and audio, the most useful fields contain text because answer-engine pipelines pass text to the model rather than pixels.

Decorative images do not need ImageObject. Marking them up adds more data to validate without making a useful assertion. These text-bearing fields must be evaluated alongside the broader set of multimodal signals that engines can read.

FAQ and procedure markup. FAQPage and HowTo declare structures that a parser can already identify, and neither now provides a Google benefit. FAQ rich results stopped appearing in Google Search on May 7, 2026. Google added a deprecation notice that month, then removed the FAQ rich result documentation in June 2026 along with support in Search Console and the Rich Results Test (Search Central changelog · Search Engine Land). HowTo rich results were removed in 2023 (Google, 2023).

Existing FAQPage markup remains valid Schema.org and causes no harm, so it does not need to be removed urgently. Adding it now provides no benefit in Google, nor does it make the underlying answers easier to extract. Extractability still depends on the visible passage’s citability. Add FAQPage or HowTo only when the Q&A or procedure genuinely appears on the page and the markup is generated from that content. Do not create markup for a structure the page lacks.

speakable remains in beta and works only for English-language publishers and US Google Home users (Google). Be aware of it, but do not make it the basis of an implementation.

Do not add invented FAQ entries that users do not ask about, HowTo to a page without a procedure, ImageObject to decorative images, or speakable as a voice-search strategy.

6. Deliver JSON-LD in the initial HTML

Markup injected by client-side JavaScript reaches Googlebot and essentially no other AI crawler. Google explains its rendering process as follows: “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript” (JavaScript SEO basics). GPTBot, ClaudeBot, and PerplexityBot have not been observed doing the same. A tag-manager deployment is therefore invisible to those crawlers.

Use the following command to verify delivery. This step is easy to overlook in a plugin-based deployment:

# Count the JSON-LD blocks a non-rendering crawler actually receives
curl -sL https://example.com/your-page | grep -c 'application/ld+json'

# Dump every block and confirm each one parses as JSON without executing JS
curl -sL https://example.com/your-page \
  | python3 -c "import sys, re, json; \
      [print(json.dumps(json.loads(b), indent=2)) \
       for b in re.findall(r'<script type=\"application/ld\+json\">(.*?)</script>', \
                           sys.stdin.read(), re.S)]"

If the count is zero, non-rendering crawlers do not receive the markup. Crawler rendering support varies, and server-side delivery avoids the limitations of client rendering (SSR vs CSR for AI Crawlers · AI Crawlers).

7. Run four separate validation checks

Run the following four checks in order. Each answers a question that the others do not, so passing one cannot stand in for the complete sequence.

The two validators are not interchangeable. One asks whether the markup conforms to Schema.org; the other asks whether Google may show a particular feature. Search Console provides ongoing monitoring rather than a predeployment result. It reports “structured data (and its validity) found on your site” and counts items rather than pages, so one template bug can appear as hundreds of invalid items.

Also perform a manual comparison. Place the emitted block beside the rendered page and confirm that every asserted fact is visible, including author names, dates, prices, ratings, and organization descriptions. No tool performs this comparison, yet it catches content-markup mismatches that validators miss and takes about two minutes per template.

Do not rely on a composite “schema score” that assigns a grade from 0 to 100 without publishing its formula. A number based on an undisclosed method is not a meaningful measurement. Apply the same provenance standard used for scores in the citability audit, and report a separate pass or fail for each check above.

Use the free Schema Markup Checker to verify no-JavaScript delivery and inspect connections within the page graph. It reports evidence for each finding without assigning a composite score.

8. Anti-patterns and the rollback rule

The following problems arise from deployment rather than vocabulary. They differ from the vocabulary errors identified in Schema.org for AI.

The @id collision is worth seeing, because it produces no error anywhere in the toolchain:

// Broken: one @id created for two different entities
[
  { "@type": "Organization", "@id": "https://example.com/#id", "name": "Example Co" },
  { "@type": "WebSite",      "@id": "https://example.com/#id", "url": "https://example.com" }
]

// Fixed: one @id per entity; the second references the first
[
  { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Co" },
  { "@type": "WebSite",      "@id": "https://example.com/#website",
    "url": "https://example.com",
    "publisher": { "@id": "https://example.com/#organization" } }
]

Of these anti-patterns, only content mismatch has a documented penalty. Google’s structured data guidelines define its scope precisely: “A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search” (General Structured Data Guidelines). Live-fetch engines handle the same mismatch more directly because they do not parse the markup as structured data. In May 2026, Mark Williams-Cook demonstrated this behavior with a fictional company whose address appeared only in deliberately invalid JSON-LD that used a fabricated @context and invented types. ChatGPT and Perplexity still returned the address. He concluded that “they were not parsing it as schema. They were doing what LLMs always do: reading the visible-ish text of the page, picking out the bit that looked like an address, and presenting it” (Williams-Cook, 2026). That conclusion matches an earlier controlled test showing that live-fetch chatbots did not extract JSON-LD as structured data (searchVIU, 2025) and an independent observation that they returned values from invalid schema (Search Engine Roundtable, observation).

For a live-fetch model, JSON-LD is simply oddly punctuated text on the page. If it contradicts the visible content, the model receives two competing versions of the facts.

The rollback rule: Invalid or content-mismatched markup is worse than none. When a block cannot be made consistent with the page, remove the block rather than the fact from the page.

9. Deployment checklist and revalidation cadence

Use this checklist for each deployment.

• Tier 0 emitted site-wide from a single source of truth
• Every @id unique, stable, and referenced rather than repeated
• sameAs list verified entity by entity, with no aspirational or placeholder links
• Authors are resolvable, or the page is attributed to the Organization
• Tier 1 wired per template, with dateModified reflecting real edits
• Tier 2 present only where the asset or the form genuinely exists
• No-JS curl fetch returns every expected block
• Schema Markup Validator clean
• Rich Results Test clean for any feature you are targeting
• Manual comparison completed for each template
• Search Console rich result reports monitored

Revalidate after relevant changes, not only on a calendar. Do so after adding a template or theme, updating the CMS or a plugin, renaming or rebranding the entity, changing the author roster, or migrating the framework or rendering mode. A quarterly spot check of the highest-value templates can catch other problems.

For sites with a build step, add a low-cost CI check for one representative URL per template. Confirm that each expected @type is present and that every block parses. This check catches the silent removal of entity data after a plugin update, which the remaining checks do not detect.

10. Further reading

• Concepts: Schema.org for AI explains what each type signals to an engine and why markup is not a citation lever. JSON-LD covers the format, keywords, placement rules, and failure modes.
• Entities: Entity Recognition explains how an identity claim is evaluated. Knowledge Graph Presence describes what a sameAs edge points to and how nodes are established.
• Related procedures: Schema Audit inventories markup that is already live. Full GEO Audit includes the structure and machine-readability checks supported by this implementation.
• Delivery: SSR vs CSR for AI Crawlers and AI Crawlers explain which engines execute JavaScript.
• Assets: Multimodal Signals describes what engines actually read from images, video, and audio.
• Citation work: Citability and Writing for AI Citation explain how visible content affects whether a page is used in an answer.