Schema Markup Complete Guide: The 2026 Reference for Structured Data That Wins AI Search

Table of contents

1. Why schema matters more in 2026
2. The schema decision tree per page type
3. 12 schema types every site needs
4. JSON-LD vs Microdata vs RDFa
5. The @id graph — connecting your entity
6. sameAs and the Wikidata bridge
7. Schema validation tools + workflow
8. Common schema bugs we audit out
9. Schema for AI search specifically
10. 90-day implementation roadmap
11. FAQ

Why schema matters more in 2026

Schema’s role evolved dramatically between 2018 and 2026.

2010-2015: Schema = rich snippet eligibility. Sites added Recipe, Review, or Product schema to get star ratings or other SERP enhancements. Optional polish.

2016-2020: Schema = part of mainstream SEO. Search Console reports schema validation; competing tools (Yoast, SchemaPro) make implementation easier. Still primarily about rich snippets.

2021-2024: Schema = entity authority signal. Google’s Knowledge Graph relies heavily on schema-supplied entity data. sameAs linkage starts mattering for brand identity disambiguation.

2025-2026: Schema = the primary entity-disambiguation signal for AI search. When ChatGPT decides which “Resocial” the user is asking about, the structured data graph is the disambiguation layer. When Perplexity decides which “[brand name]” to cite, the @id graph and sameAs linkage are the primary signals. Schema is no longer optional polish — it’s the infrastructure layer that determines whether AI engines cite your brand confidently or conflate it with competitors.

The shift means:

• Schema breadth matters more (more page types covered) — not just Article schema on blog posts.
• Schema depth matters more — full sub-typing, complete properties, accurate values.
• Cross-page consistency matters more — the @id graph linking entities across pages.
• Third-party linkage matters more — sameAs connecting your brand to Wikidata, Wikipedia, social platforms.

Most sites we audit have partial schema — Organization on the homepage, BlogPosting on blog posts, nothing else. That’s 2020-era schema thinking. The 2026 baseline is substantially deeper.

The schema decision tree per page type

The schema you ship depends on what the page IS. The decision tree, by page type:

Homepage

• Required: Organization OR LocalBusiness (decide by Organization vs LocalBusiness logic) · WebSite (with potentialAction: SearchAction for site-search rich result)
• Common additions: BreadcrumbList (one-item, just home), sameAs schema linking social + Wikidata

About page

• Required: Same Organization/LocalBusiness reference (via @id), BreadcrumbList
• Common additions: Person schema for founders / leadership (with knowsAbout, alumniOf, jobTitle), Article if the about page is editorial

Blog post / article

• Required: BlogPosting (or Article), author Person, publisher (reference to your Org via @id), datePublished, dateModified, BreadcrumbList
• Common additions: FAQPage if the post has substantive Q&A, ImageObject for hero image

Service / product page

• Required: Service (for service businesses) or Product (for ecommerce), Offer / aggregateOffer, BreadcrumbList, FAQPage where present
• Common additions: Review or aggregateRating (only with verifiable review system)

Listing / category page

• Required: CollectionPage, BreadcrumbList, ItemList for the contained items
• Common additions: Per-item schema fragments where appropriate

FAQ page

• Required: FAQPage with mainEntity → Question / Answer pairs

Contact / location page

• Required: ContactPage, LocalBusiness with full address + geo + openingHoursSpecification

Pricing page

• Required: WebPage (default) — schema’s Pricing schema is awkward; most teams skip it and use a clear Offer block instead in their Service schema

Author / team page

• Required: ProfilePage, Person schema for the named person, sameAs to LinkedIn / Twitter

Job posting

• Required: JobPosting (Google’s job-listing rich result requires this; missing it removes the job from Google for Jobs)

Event

• Required: Event schema with eventStatus, eventAttendanceMode (for hybrid/virtual events)

Recipe

• Required: Recipe — applies to food / cooking sites specifically

Video

• Required: VideoObject with thumbnailUrl, uploadDate, duration

Course

• Required: Course — for educational content

For most B2B brands, the page types that matter are: Homepage, About, Blog, Service, Contact, FAQ, Author. The schema decision tree for those covers 90% of pages on a typical agency or SaaS site.

12 schema types every site needs

The 12 schema types that should appear somewhere on a modern site:

1. Organization (or LocalBusiness sub-type)

The brand entity. Defined once with a stable @id, referenced everywhere else. Properties:

• name, alternateName
• url, logo
• description
• address (PostalAddress)
• telephone, email
• sameAs (array linking to Wikidata, LinkedIn, Twitter, GitHub, etc.)
• founder (Person, with own @id)
• foundingDate
• knowsAbout (areas of expertise)
• areaServed

2. WebSite

The site itself, referencing the Organization. Includes:

• url, name, inLanguage
• publisher (reference to Organization via @id)
• potentialAction: SearchAction (for site-search rich result)

3. BreadcrumbList

Every non-root page. Each ListItem has position, name, item (URL).

4. BlogPosting / Article

Every blog post and article. Properties:

• headline, description
• url, mainEntityOfPage
• datePublished, dateModified
• author (Person, ideally with @id)
• publisher (reference Organization via @id)
• keywords, articleSection
• image (ImageObject)

5. Person

For authors, founders, named team members. Properties:

• name, jobTitle
• url, image
• sameAs (LinkedIn, Twitter, conference profiles)
• knowsAbout, alumniOf
• worksFor (reference Organization via @id)

6. FAQPage

For pages with Q&A. Each Question has name (the question) and acceptedAnswer.text (the answer).

7. Service

For service businesses. Properties:

• name, description
• provider (reference Organization via @id)
• serviceType, areaServed
• Offer or aggregateOffer for pricing

8. Product / Offer

For ecommerce or product-led brands. Properties:

• name, description, image
• brand, sku, mpn
• offers with price, priceCurrency, availability
• aggregateRating if applicable

9. Review / aggregateRating

For pages with user reviews. CRITICAL: only deploy with a verifiable review system. Schema-marked reviews without actual reviews trigger manual penalties.

10. ImageObject

For featured images on articles and product pages. Properties: url, width, height, caption, license (if applicable).

11. VideoObject

For embedded videos. Properties: name, description, thumbnailUrl, uploadDate, duration, contentUrl or embedUrl.

12. DefinedTerm

For glossary entries. Properties: name, termCode, description, inDefinedTermSet (link to your glossary index).

A B2B agency or SaaS site with these 12 types covered has comprehensive structured data. Most sites we audit have 3-5 of the 12 — meaning 60-70% of the entity disambiguation signal is missing.

JSON-LD vs Microdata vs RDFa

Three schema formats exist. The decision in 2026 is straightforward:

JSON-LD

Embedded <script type="application/ld+json">{...}</script> blocks in <head> or <body>. Use this exclusively. Reasons:

• Cleanly separated from HTML content; doesn’t pollute markup
• Easier to programmatically generate and validate
• Google explicitly recommends JSON-LD as the preferred format
• AI crawlers parse JSON-LD reliably

Microdata

Inline HTML attributes (itemscope, itemtype, itemprop). Older format. Don’t use for new projects. Reasons:

• Pollutes markup
• Harder to maintain
• Easier to break with HTML refactors

RDFa

Inline HTML attributes with vocabulary references. Older still. Don’t use. RDFa was the preferred format in 2010-2012 but has been largely deprecated in practice.

For any new site or schema overhaul, ship JSON-LD only. Legacy sites with existing Microdata can keep it during a transition period but should migrate to JSON-LD over 6-12 months.

The @id graph — connecting your entity

The single most under-implemented schema feature: the @id graph. The pattern:

Define your Organization once with a stable @id:

{
  "@type": "Organization",
  "@id": "https://yourdomain.com/#organization",
  "name": "Your Brand",
  ...
}

Then reference this entity from every other schema block on every page:

{
  "@type": "BlogPosting",
  "author": { "@id": "https://yourdomain.com/#organization" },
  "publisher": { "@id": "https://yourdomain.com/#organization" }
}

Why this matters: AI crawlers and search engines build a graph of how schema entities relate. With @id references, the system understands “the publisher of this article is the same Organization defined on the homepage”. Without @id references, each schema block declares a separate Organization — and the system has to guess if they’re the same brand.

Practical implementation:

• Pick a stable URL pattern for entity IDs: https://yourdomain.com/#organization, https://yourdomain.com/#website
• Define each entity once with @id; reference everywhere else
• For Person entities: https://yourdomain.com/#person-{name-slug}
• For Service entities: https://yourdomain.com/services/{slug}/#service

Resocial’s own implementation uses @id: "https://resocial.us/#organization" referenced from BlogPosting publisher, Service provider, Person worksFor, and several other entity links. The graph is consistent across all 116 pages of the site. Search Console picks up the unified entity; AI crawlers infer it correctly.

sameAs and the Wikidata bridge

The sameAs property links your brand entity to its representations on other authoritative sites. This is the bridge to entity authority outside your own domain.

Required sameAs targets

For B2B brands, the canonical sameAs list:

"sameAs": [
  "https://www.wikidata.org/wiki/Q{your-entity-id}",
  "https://en.wikipedia.org/wiki/{your-brand}",
  "https://www.linkedin.com/company/{your-brand}/",
  "https://twitter.com/{your-handle}",
  "https://github.com/{your-org}",
  "https://www.crunchbase.com/organization/{your-brand}",
  "https://www.bloomberg.com/profile/company/{your-ticker}"
]

Not all targets apply to every brand. The minimum required:

• Wikidata (any brand with Wikipedia presence has a Wikidata Q-number — your @id should sameAs to it)
• LinkedIn (if your brand has a company page)
• Twitter / X (if active)
• GitHub (for developer-focused brands)

The Wikidata bridge

Wikidata is the structured-data backbone of Google’s Knowledge Graph and is heavily used by AI assistants for entity disambiguation. Steps:

1. Search Wikidata for your brand: wikidata.org
2. If you have a Q-entity, claim it (verify ownership where applicable) and complete missing properties
3. If you DON’T have a Q-entity yet, create one (or have a Wikidata-experienced contributor create one). Notability requirements are looser than Wikipedia’s.
4. Once your Wikidata Q-entity exists, sameAs to it from your Organization schema

Brands with proper Wikidata representation get cited in ChatGPT more confidently than brands without. We measure this regularly: brands that ship Wikidata + sameAs see 1.3-1.8× AI citation rate improvement within 3-6 months, controlling for content investment.

Schema validation tools + workflow

Validation is non-negotiable. Schema that doesn’t validate gets ignored entirely.

Primary tools

1. Google Rich Results Test (search.google.com/test/rich-results) — checks for rich result eligibility specifically
2. Schema.org Validator (validator.schema.org) — checks for spec compliance more broadly
3. Search Console Enhancement reports — surfaces sitewide schema errors at scale

Validation workflow

1. At authoring time: developers / content authors paste schema into Rich Results Test before pushing
2. At commit time: CI / build pipeline runs schema validation against changed pages; failures block deploy
3. Weekly: Search Console enhancement report reviewed by Klara; new errors filed as tickets
4. Quarterly: site-wide schema audit (Sitebulb / Screaming Frog with custom extraction)

The most common failure mode: schema works fine when authored, then breaks 6 months later because a framework update changed how JSON-LD got injected (CSR vs SSR rendering issue). Continuous validation catches this; one-time validation doesn’t.

Common schema bugs we audit out

After auditing 200+ schema implementations:

Bug 1: Schema in non-rendered JS

JSON-LD generated by client-side JavaScript that fires after page load. Some crawlers don’t execute JS; others execute it but miss late-loading schema. Always render schema server-side (SSR or SSG).

Bug 2: Missing @id graph

Each schema block declares its own Organization, Person, etc. — without @id references. Schema processors treat these as separate entities. See @id graph section above.

Bug 3: Wrong sub-type

Using generic Organization when Corporation, EducationalOrganization, LocalBusiness/Restaurant, etc. would be correct. Specific sub-types provide more disambiguation signal. The Organization vs LocalBusiness deep-dive covers this trade-off.

Bug 4: Data mismatch between schema and visible page

Schema says price is €100; visible page shows €120. Google treats this as deceptive and pulls the rich result. Worse: AI assistants may surface stale schema-declared prices to users.

Bug 5: aggregateRating without real reviews

Schema declares 4.8 stars from 247 reviews; the site has no actual review system. Manual penalty risk — and AI assistants increasingly weight verifiable reviews vs unverifiable claims.

Bug 6: Inconsistent @id across pages

The same entity declared with different @id URLs on different pages. Graph fragments instead of consolidates.

Bug 7: FAQ schema where the Q&A isn’t visible

Schema FAQs that don’t appear on the visible page. Google now penalizes this pattern; the FAQ rich result requires the content to be both visible AND schema-marked.

Bug 8: BreadcrumbList with wrong positions

Position 1 should be the homepage, position 2 the section, etc. Sites often skip the homepage or have incorrect ordering.

Bug 9: Stale dateModified

dateModified on articles that haven’t been updated in years still showing yesterday’s date. Some implementations auto-update dateModified on every build, which signals false freshness. dateModified should reflect actual content updates.

Bug 10: Schema validation only at launch

Schema validated once at deploy, never again. Frameworks evolve, schema spec evolves, errors creep in invisibly. Continuous validation is required.

Schema for AI search specifically

Beyond traditional rich snippets, three schema features matter most for AI search citation:

Feature 1: Comprehensive Organization sameAs

The single biggest AI-search lever. Your Organization entity should sameAs to Wikidata, Wikipedia (if eligible), LinkedIn, GitHub (if applicable), Crunchbase, and any other authoritative third-party identifiers. AI assistants triangulate entity identity through this graph.

Feature 2: FAQPage on priority pages

FAQ schema is one of the most heavily-weighted formats in AI extraction. When a page has FAQPage schema with substantive Q&A, AI assistants frequently quote the answers verbatim. Our AI search optimization complete guide covers FAQ as a citation lever.

Feature 3: DefinedTerm for glossary entries

Glossary content marked with DefinedTerm schema gets cited disproportionately in AI definitional answers. Our glossary uses DefinedTerm extensively, which is part of why our terms appear in AI Overviews and ChatGPT answers for SEO terminology.

What doesn’t matter (much) for AI search

• Recipe / HowTo schema (for non-recipe sites)
• Event schema (unless events are the business)
• Product schema for service businesses

Optimize for the schema types that match your business model; don’t add schema for schema’s sake.

90-day implementation roadmap

How Klara sequences a fresh schema engagement:

Days 1-14: Audit and gap analysis

• Crawl entire site with Screaming Frog (custom extraction for JSON-LD blocks)
• Per-page-type inventory: which pages have which schema, which are missing
• Validation pass: which existing schema fails Rich Results Test
• Competitor benchmark: which schema types our top 3 competitors ship
• Wikidata audit: does our brand have a Q-entity? Is it complete?

Days 15-30: Foundation

• Organization (or LocalBusiness) schema rebuilt with full property set + stable @id
• WebSite schema with SearchAction
• Wikidata entry created or claimed
• sameAs graph completed (LinkedIn, Twitter, GitHub, Wikidata, Wikipedia)
• BreadcrumbList shipped on all non-root pages

Days 31-60: Content layer

• BlogPosting / Article on all blog content (with author Person + publisher @id)
• Service on all service pages
• FAQPage on priority pages
• Person schema for team members
• Validation pass on each new schema type

Days 61-90: Deep + maintenance

• DefinedTerm on glossary entries
• Review / aggregateRating only if a verifiable system exists
• ImageObject, VideoObject where applicable
• CI/CD pipeline integration: schema validation runs on every build
• Search Console enhancement reports reviewed weekly
• Monthly cadence handoff: who watches schema for regressions

Beyond day 90, the program is mostly maintenance: catching regressions from framework updates, adding schema to new page types as they ship, refreshing Wikidata as the brand evolves.

FAQ

Do I need ALL 12 schema types?

No. The 12 are the comprehensive catalog. Most sites need 5-8 of them. Pick by page types you have. The mandatory minimum: Organization, WebSite, BreadcrumbList, BlogPosting (if you blog), Service or Product (depending on business), FAQPage (where Q&A exists).

What if I have multiple business locations?

Use LocalBusiness sub-type per location, with each LocalBusiness having its own @id, sub-organization of your master Organization @id. Each location page declares its own LocalBusiness with full geo + hours. See our Local SEO Complete Guide for the multi-location pattern.

How does this affect AI Overviews specifically?

AI Overviews surface content from pages that have clear schema disambiguation. Pages with weak schema get summarized but not cited; pages with strong schema get cited by name. The schema layer determines whether your brand or a competitor appears in the Overview when both are relevant.

Can I use schema generators / plugins?

Yes, with caveats. Yoast SEO, Rank Math, SchemaPro all generate decent baseline schema. None of them ship the @id graph or comprehensive sameAs without customization. Use them for the basics; customize for the depth that matters.

Does Resocial offer schema as a standalone service?

Yes — typically packaged with technical SEO services but available as a focused 30-day schema overhaul if that’s the gap. Klara leads the work; Petros handles deploy-time integration.

How often does the schema.org spec update?

The schema.org spec evolves continuously. Major updates roughly twice yearly. Most updates add new types or properties; few deprecate existing ones. Validation tools flag deprecated properties.

Should I worry about schema for image search / Google Discover?

For image search, ImageObject with proper attribution + license helps. For Google Discover (the mobile feed), Article schema with high-quality images and proper publisher attribution helps eligibility. Both are nice-to-have, not foundational.

---

What to do next

If your site has basic schema (Organization, BlogPosting) but nothing deeper, the 60-minute first action is to build out your sameAs graph. Add LinkedIn, Twitter, GitHub, Crunchbase, Wikidata to your Organization schema. Audit Wikidata for your brand; create or complete the entry if needed. That single change typically moves AI citation rate 10-20% within 90 days, faster than any other schema investment.

If you’d like Klara and Petros to run the full 90-day schema overhaul — gap analysis, implementation, Wikidata integration, AI search citation tracking — explore our SEO services or book a consultation.

Schema is no longer optional polish. It’s the entity-disambiguation layer that determines whether AI assistants cite your brand confidently — or guess. The brands that invest properly compound through 2026 and beyond.