Ultimate Guide to Schema Markup (2026)

Schema markup is the layer of code that tells search engines what the words on a page actually mean: that a string of digits is a price, that a name is an author, and that a business is the same business mentioned on Wikipedia. This guide walks JSON-LD from first tag to rich result, pairing every schema type worth your time with a copy-paste block, a live validation check, and a Search Console step you can run before and after deploy. What sets it apart is the verification workflow: most guides stop at the code, while this one shows you how to confirm your markup is valid, eligible, and still intact a month after you shipped it.

Schema Markup in 2026: What It Still Does and What It Never Did

Schema markup still does one thing extremely well: it removes ambiguity. When Google reads a page, it sees text, and text is famously bad at distinguishing a person named Paris from a city named Paris, or a product price from a phone number. Structured data hands Google a typed, labeled description of the entity on the page, which is why Google's own documentation describes structured data as a way to help Google understand the page and present it more usefully in search. The mechanism is real, it is well documented, and it still powers a meaningful list of rich results in 2026.

What schema markup never did matters just as much. It is not a ranking factor, and Google has said so directly: structured data helps Google understand and present content but is not a guaranteed ranking boost, because eligibility and display depend on many additional signals, per Google's structured data introduction (2025). It is also not a license to decorate a page with facts that are not visible to users. Google's structured data policies (2025) require markup to be accurate, non-deceptive, and to describe content that actually appears on the page, which means hidden or spammy markup is a violation, not a shortcut.

The practical 2026 position is this: schema is worth doing because it controls the extra real estate you can win in search results, the knowledge panels you can help consolidate, and the clarity you hand to every system that reads your pages, from Googlebot to an AI assistant. How assistants actually use that clarity when they cite sources is the subject of the AI search visibility guide. But you should implement it with the correct expectations, which means understanding both the vocabulary and the workflow. If you are not sure what markup a page is already sending, extract it with the schema checker before you add anything, so you know whether you are fixing a gap or duplicating an existing block.

How Structured Data Works: Entities, Triples, and How Search Engines Read JSON-LD

Structured data is built on two ideas: entities and triples. An entity is a thing with a stable identity, such as a company, a person, a product, an article, or a place. A triple is a statement about an entity in three parts: a subject, a predicate, and an object. The sentence "Example Corp is located in Berlin" is a triple, where Example Corp is the subject, is located in is the predicate, and Berlin is the object. Structured data turns prose into these machine-readable triples so a crawler does not have to guess.

Entities, not strings

The shift from strings to entities is the whole point. A search engine that indexes the word "Berlin" as a string knows nothing except that the characters appear. A search engine that indexes Berlin as an entity of type City knows its population, its coordinates, and its relation to other entities. schema.org encodes this by giving every entity a type and a set of properties. When you declare a thing as an Organization with a name, a logo, and a sameAs link to its Wikipedia page, you are telling the crawler which entity you mean and how it connects to the rest of the graph. This is the layer that the technical SEO guide sets up at the crawl level and that schema carries forward at the meaning level.

Triples and properties

Every schema type is really a template of triples waiting to be filled. A Product has a name property, an image property, and an offers property. A Recipe has a recipeIngredient property and a cookTime property. Each property value is either a literal, such as a number or a date, or a reference to another entity, such as an Offer or a Person. The nesting you see in JSON-LD, where an Organization contains an ImageObject which contains a url, is just triples pointing at other triples. Understanding this is what makes the difference between markup that parses and markup that actually describes the page.

How search engines read JSON-LD

JSON-LD travels as a small script tag that lives directly in the page HTML. Google's documentation examples place a <script type="application/ld+json"> block in the page rather than relying on client-side JavaScript injection, per Google's structured data introduction (2025). A crawler downloads the HTML, finds the block, parses the JSON inside it, and links the resulting triples to the entity graph it maintains for your domain. Because the block is plain JSON in a script tag, it is trivial for a human to read and for a CMS to generate, which is exactly why JSON-LD won the format war.

JSON-LD vs Microdata vs RDFa: Why Google Recommends JSON-LD

Three syntaxes can express the same schema.org triples, and they are not equal in practice. JSON-LD is a standalone JSON block. Microdata sprinkles itemscope, itemtype, and itemprop attributes through your HTML tags. RDFa does the same job with a different attribute vocabulary. All three are valid ways to carry structured data, but Google recommends JSON-LD and writes its documentation examples in JSON-LD, while Microdata and RDFa remain supported but no longer featured, per Google's structured data introduction (2025).

JSON-LD also has the strongest standards pedigree. JSON-LD 1.1 reached W3C Recommendation status on 16 July 2020, and JSON-LD 1.0 had already reached Recommendation status in January 2014, per the W3C JSON-LD 1.1 specification (2020). That matters because a W3C Recommendation is a stable, reviewed standard rather than a vendor convention, which is why JSON-LD is also the format of choice for non-search consumers of structured data, including AI crawlers and content management systems.

The maintenance argument decides it for most teams. Microdata and RDFa bind your structured data to your markup, so a redesign that changes a div to a section can silently break your schema. JSON-LD lives in a single block that your template can print without touching the rest of the layout. When you need to change a price or a review count, you edit one JSON object. That is why nearly every modern stack, from WordPress to Next.js, generates JSON-LD by default, and why the rest of this guide is written in JSON-LD.

Reading the schema.org Vocabulary: Types, Properties, and the Release History

schema.org is a shared vocabulary for structured data created collaboratively by Google, Microsoft, Yahoo, and Yandex, per schema.org (2025). It is the single source of truth for the types and properties you are allowed to use, and it is organized as a hierarchy. Everything descends from Thing, the root type, and below it sit broad classes such as CreativeWork, Organization, Person, Place, Product, Event, and Intangible. Each type lists its own properties plus everything it inherits from its parents, so an Article is a CreativeWork is a Thing, and it carries properties from all three levels.

Types and expected values

Each property declares the type of value it expects. Some expect text, some expect a number, some expect a URL, and some expect another typed entity. The offers property of a Product expects an Offer, and the author property of an Article expects a Person or an Organization. Getting the expected type right is the difference between markup that validates and markup that fails, and the Rich Results Test is unforgiving about wrong types. When in doubt, open the schema.org page for the type and read the property table rather than guessing from memory.

The release history and scale

The vocabulary is not frozen. schema.org releases new versions on a regular cadence, adds pending types before they are finalized, and maintains a public mailing list where the maintainers discuss changes. The scale of adoption is enormous: WebDataCommons released 74 billion RDF quads of Microdata, embedded JSON-LD, RDFa, and Microformat data extracted from 16.5 million websites, per the WebDataCommons announcement (2025). That number is useful for one reason: structured data is ubiquitous enough that having none makes you an outlier, while having broken or spammy markup is a liability you can measure. This guide returns to versioning and pending types later, because tracking them is what separates a practitioner who maintains schema from one who set it and forgot it.

Which Rich Results Still Exist in 2026 (and Which Google Killed in 2023)

The biggest mistake most 2026 guides still make is teaching FAQPage and HowTo markup as if they earn rich results. They do not, and they have not since 2023. In August 2023, Google limited FAQ rich results to well-known, authoritative government and health websites, and limited HowTo rich results to desktop search only, per Google's HowTo and FAQ announcement (2023). The HowTo result was then removed entirely for standard sites in September 2023, per Search Engine Journal (2023), and FAQ rich results effectively ended for most websites, per Neil Patel (2023).

What remains is a smaller but real list. An industry roundup counted 25 currently supported rich result types in early 2026 while finding no evidence of a direct AI-search boost from structured data, per eCorpIT (2026). The table below lists the results worth caring about, the schema type that powers each one, and the tool you use to validate it. For the full tour of every feature on the 2026 results page, including the ones schema cannot buy, see the SERP features guide.

The practical takeaway is that the rich-result landscape shrank in 2023 and stayed shrunk. Focus your markup budget on the rows that still pay, and use the schema checker to confirm what you are already sending before you retire or add anything.

Schema's Real Role in AI Search: What the Ahrefs and SALT Data Actually Show

The loudest claim attached to schema in the last two years is that it buys visibility in AI answers, and the loudest evidence says it does not. Ahrefs tracked 1,885 pages that added schema markup and found AI citations barely moved, concluding that schema does not directly boost AI-citation frequency, per Ahrefs (2025). Separate coverage of SALT.agency data reached the same direction, arguing that new data challenges schema's value for AI search, per Search Engine Journal (2025). The eCorpIT roundup of 25 rich results reached the same conclusion on the AI side: no direct AI boost, per eCorpIT (2026).

That does not mean schema is useless for AI. It means you should sell it for what it actually does. Structured data gives an assistant a clean, typed description of an entity, which helps the assistant disambiguate your company from a similarly named one and connect your content to a stable identity. The Ahrefs finding is about citation frequency, not comprehension, and the two are easy to confuse. An assistant does not cite you more often because you added schema, but when it does read your pages, the schema makes the entity layer unambiguous. That is a hygiene win, not a visibility lever, and you should budget accordingly.

The honest framing for a stakeholder is this: schema is an instruction manual for machines, and machines that read your site for AI answers benefit from a clear manual even when the manual does not change how often you are quoted. If your goal is to track whether you appear in AI answers at all, check your domain with the AI visibility checker before you attribute any movement to schema. The tool gives you a baseline, and the baseline is the only way to separate a real effect from wishful thinking.

Your 5-Step Schema Workflow: Implement, Validate, Monitor, Iterate

Schema fails most often not because the JSON is wrong but because nobody runs a repeatable process around it. The workflow below is the one the rest of this guide applies to every worked example, and it is deliberately short enough to run for a single page or a whole site. The five steps are choose, implement, validate, monitor, and iterate.

Step 1: Choose the type and read the required fields

Start from the rich result you want, not from a schema you remember. If you want a knowledge panel, the type is Organization. If you want Top Stories, the type is Article, NewsArticle, or BlogPosting. If you want product snippets, the type is Product. Open the Google Search Central page for that type and copy the required properties exactly, because a missing required field silently disqualifies the markup. Most of the rest of the on-page SEO guide covers what goes in the visible page; schema only works when the visible page and the markup agree.

Step 2: Implement JSON-LD in the server HTML

Add one script block to the page HTML, in the head or the body. Keep it in the server-rendered HTML rather than injecting it client-side after load, because the crawler should not have to execute JavaScript to find your schema. The copy-paste library later in this guide gives you blocks for the types that matter.

Step 3: Validate before deploy

Run every block through Google's Rich Results Test and the Schema.org Validator before you ship. The Rich Results Test tells you whether the page is eligible for a specific rich result, and the Schema.org Validator tells you whether the JSON is well formed and the vocabulary is used correctly. Do both, because they answer different questions. You can extract a page's current markup with the schema checker and paste it straight into either validator.

Step 4: Monitor after deploy

Wait for Google to crawl the page, then open the Enhancements report in Search Console and confirm the type appears with no errors and no warnings. If you changed a template, check that the change did not introduce a duplicate block. Preview how the page renders in search with the SERP preview so the visible snippet and the structured data tell the same story.

Step 5: Iterate on the gap

If the Enhancements report shows valid but not eligible, the gap is usually a missing required property or a policy issue. If it shows eligible but you still do not see the rich result live, the gap is usually page quality, crawl, or relevance, not the markup. Fix the reported item, redeploy, and re-validate. Iteration is the step that turns a one-time tag into a maintained asset.

Organization Schema to Knowledge Panel to Merchant Listing (Worked Example)

Organization is the highest-leverage type on most business sites because it feeds two things at once. It can power a knowledge panel for your brand, and it is a prerequisite for Merchant listing structured data, per Google's Organization documentation (2025). This worked example walks the full validate-then-monitor cycle so you can see the process, not just the code.

The block

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Example Corp",
  "url": "https://www.example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://www.example.com/logo.png",
    "width": 600,
    "height": 60
  },
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Corp",
    "https://www.linkedin.com/company/example-corp"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+1-800-555-0100",
    "contactType": "customer service"
  }
}
</script>

Before: what the page sends now

The first move is not to paste this block, it is to see what the page already sends. Run the site through the schema checker and note every type it finds. Most sites discover either no Organization block, or a stray block in a footer template that half the pages inherit, or two competing blocks where the homepage declares one name and the about page declares another. Document the current state before you change anything, because the before state is what your after state will be compared against.

Validate before deploy

Paste the block into the Rich Results Test as a code snippet. It should return Organization as a detected type with no errors. Then paste it into the Schema.org Validator to confirm the JSON parses and the sameAs values are absolute URLs. Watch the @id: giving your organization a stable URI such as https://www.example.com/#organization is what lets other blocks reference it by ID instead of repeating the whole object, a technique this guide returns to in the entity consolidation section.

Monitor after deploy

Ship the block on the homepage and the about page, then open the Enhancements report in Search Console after the next crawl. Organization does not always show a dedicated enhancement card the way Product does, so the signal you watch is different: search your brand and check whether a knowledge panel consolidates around the entity you described. The sameAs links to Wikipedia and LinkedIn are the consolidation anchors, so verify those URLs resolve and point at the same business before you rely on them. If you also sell products, the same Organization entity is what you reference from Merchant listing fields, which is the moment this single block stops being a nice-to-have and becomes the spine of your merchant identity.

Article, NewsArticle, and BlogPosting Schema for Top Stories (Worked Example)

Article structured data, in its Article, NewsArticle, and BlogPosting variants, supports features such as Top Stories and helps Google understand article content and authorship, per Google's Article documentation (2025). The three subtypes differ mostly in what they signal: NewsArticle is for time-sensitive journalism, BlogPosting is for blog content, and Article is the general fallback. Use the most specific one that matches your content.

The block

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Schema Markup in 2026: What Still Earns Rich Results",
  "description": "The JSON-LD types worth implementing and the ones Google retired.",
  "image": "https://www.example.com/blog/schema-2026.jpg",
  "datePublished": "2026-08-16",
  "dateModified": "2026-08-16",
  "author": {
    "@type": "Person",
    "name": "Jane Doe"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Corp",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.example.com/blog/schema-2026"
  }
}
</script>

Required fields and the Top Stories gate

For Top Stories eligibility, Google requires an accurate, non-deceptive headline, an image, and a valid datePublished and dateModified. The headline in the markup must match the visible headline on the page, because a mismatch is exactly the kind of discrepancy the structured data policies (2025) treat as a violation. Top Stories is also gate-kept by Google News publisher eligibility, so markup alone does not put a brand-new blog into Top Stories; it makes eligible publishers legible. Do not oversell the block as a shortcut into news surfaces.

Validate and monitor

Paste the block into the Rich Results Test and confirm it detects BlogPosting or Article with no errors. The common failures are a missing image, a date in the wrong format, or an author field left empty. Fix those, redeploy, then watch two places. In Search Console, the Enhancements report should list the Article item. In the live results, check how the page's title, date, and byline render next to competitors using the SERP preview, because the visible snippet and the structured data have to agree for the result to hold. If your article is genuinely news, use NewsArticle and add a dateline; if it is evergreen editorial, BlogPosting is the honest choice, and honest typing outperforms ambitious typing every time.

Product Schema for Product Snippets: Name, Image, Offers, Reviews (Worked Example)

Product structured data requires properties such as name, image, and offers, and optionally aggregateRating and review, to be eligible for product snippets, per Google's Product documentation (2025). The required set is short, which makes Product the type where missing fields cost people the most: they add a rich block with a review and skip the offers object, and the whole thing disqualifies because offers is the part Google actually needs.

The block

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Runner GTX",
  "image": ["https://www.example.com/shoes/trail-runner-gtx.jpg"],
  "description": "Waterproof trail running shoe with a lugged outsole.",
  "sku": "TR-GTX-44",
  "brand": { "@type": "Brand", "name": "Example Outdoors" },
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/shoes/trail-runner-gtx",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "214"
  }
}
</script>

The required trio and the review caveat

The three fields that must be present are name, image, and offers. Inside offers, the price, priceCurrency, and availability are what let Google show a price and a stock state, so a Product block with no offers object is not eligible for a product snippet. aggregateRating and review are optional but powerful, and they come with the strictest policy in the schema world: the rating must be real, it must come from reviews you actually received, and it must be shown on the page. Fabricated review counts are one of the most common manual-action triggers, so treat the review fields as documentation of real reviews rather than a decoration.

Validate before, monitor after

Extract the page with the schema checker first, so you can see whether an old Product block already exists and whether it conflicts with the new one. Then run the new block through the Rich Results Test: it should return Product as eligible for a product snippet with no warnings. After deploy, the Enhancements report should show a Product card with a valid item count, and the price you ship should match the price a user sees on the page to the cent. A price mismatch between markup and page is a policy violation, not a small bug, so re-check whenever a promotion changes the visible price. When the visible price and the structured price drift apart, the snippet you earned can disappear faster than you earned it.

Copy-Paste JSON-LD Library: The Schemas Worth Adding for Most Sites

This section collects the types worth implementing for a typical business site, along with the required properties that decide eligibility and the rich result each one earns. It is not exhaustive; it is the shortlist that pays for the effort. The three blocks you saw above are the backbone, and the table below adds the surrounding types that most sites should layer on top.

One @graph block for the whole site

Rather than printing half a dozen separate script tags, consolidate the sitewide types into a single block using @graph. The block below declares an Organization, a WebSite, a WebPage, and an Article in one place, and it links them with @id references so the publisher is defined once and referenced everywhere else.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Example Corp",
      "url": "https://www.example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "url": "https://www.example.com/",
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://www.example.com/blog/schema-guide#webpage",
      "url": "https://www.example.com/blog/schema-guide",
      "name": "Ultimate Guide to Schema Markup",
      "isPartOf": { "@id": "https://www.example.com/#website" }
    },
    {
      "@type": "Article",
      "headline": "Ultimate Guide to Schema Markup",
      "author": { "@id": "https://www.example.com/#organization" },
      "publisher": { "@id": "https://www.example.com/#organization" },
      "mainEntityOfPage": { "@id": "https://www.example.com/blog/schema-guide#webpage" }
    }
  ]
}
</script>

The @graph wrapper is a JSON-LD feature that lists multiple top-level nodes in one object, and it is the cleanest answer to the duplicate-markup problem this guide tackles next. When every block references the same #organization ID, you never describe your company twice, which means you never describe it two different ways by accident.

Generating JSON-LD Programmatically in CMS, Headless, and Next.js Stacks

Hand-writing JSON-LD does not scale, so the real question is how your stack prints the block into the server HTML. The requirement is the same everywhere: the <script type="application/ld+json"> block must be in the initial HTML response, not injected by client JavaScript after the page loads, per Google's structured data introduction (2025). Whatever generates your HTML should also generate your schema.

WordPress and Shopify

On WordPress, a dedicated schema plugin or a small custom function attached to wp_head prints the block, and the advantage of the custom function is that it can read the actual post title, author, and publish date rather than leaving you to hand-edit JSON. On Shopify, the liquid theme can print an Organization block sitewide and a Product block per product page using the product object, which keeps price and availability in sync automatically. The pattern in both cases is the same: derive the schema from the same data the page already renders, so markup and page can never disagree.

Headless CMS and Next.js

In a headless stack, the CMS holds the content fields and the frontend assembles the JSON-LD from them at build time or render time. In Next.js, place the block in the page component and render it as part of the server output, using a small helper or a typed schema library so required fields are enforced by the type system rather than by memory. The technical SEO guide covers the server-rendering side of this in more detail; the schema-specific rule is simply that the block must exist before hydration. If a user can view the page source and the script tag is missing, your schema is not in the initial HTML, and you have found the bug.

Avoiding Duplicate and Conflicting Markup: @graph vs Multiple Blocks and Nested References

Duplicate schema is a silent killer because it rarely throws an error. A page can carry an Organization block in the footer template, another one injected by a plugin, and a third hand-pasted into the CMS, and each block describes the company slightly differently. Google sees three descriptions of the same entity and has to reconcile them, which is exactly the ambiguity you added schema to remove. The structured data policies (2025) require markup to be consistent with visible content, and three conflicting blocks fail that test even when each block alone is valid.

@graph vs multiple blocks

There are two clean ways to structure multiple types, and they are not equal. The first is one @graph block that lists every node together, which is the approach the library above uses. The second is multiple script tags, each carrying one type, which works but is harder to keep consistent because nothing forces the separate blocks to agree. When you must use multiple blocks, give every shared entity a stable @id and reference it instead of redefining it, so the company is declared once and every other block points at that ID.

Nested references

Nesting and referencing are the two ways entities point at each other. Nesting puts the child entity inline, as when a Product contains an Offer. Referencing points at an entity defined elsewhere, as when an Article points at its publisher by @id. The rule of thumb: nest when the child belongs to exactly one parent, and reference when the entity is shared. Your company is shared across every page, so reference it. A product's price belongs to that product, so nest it. Getting this split right is what keeps a growing schema from turning into a pile of contradictory definitions, and it is the same idea the on-page SEO guide applies to canonical consolidation: one source of truth, referenced everywhere else.

Entity Consolidation with sameAs: Building Your Knowledge Graph

sameAs is the property that tells Google your page's entity is the same entity described somewhere else on the web, and it is the single most underused field in schema. When your Organization block links its sameAs to your Wikipedia page, your Wikidata entry, and your LinkedIn company profile, you are giving Google the explicit connections it needs to merge those sources into one entity. That merged entity is what a knowledge panel is built from, per Google's Organization documentation (2025).

How consolidation works

Consolidation works because Google does not trust any single source about an entity; it reconciles many. Your website, a Wikipedia article, a Wikidata item, and a LinkedIn page all describe your company, and they all describe it slightly differently. sameAs is the bridge that tells Google these are not four companies but one, and the closer the descriptions agree, the more confidently Google merges them. This is why the name, logo, and URL in your schema must match the name, logo, and URL everywhere else: the merge fails when the sources contradict each other.

Practical sameAs hygiene

Keep the sameAs list short and authoritative. Wikipedia and Wikidata are the strongest anchors, followed by official social profiles and a Crunchbase or LinkedIn company page. Do not pad the list with directory listings that have no editorial weight, and never point sameAs at a page that describes a different entity. Every sameAs link must resolve to a page that is unambiguously about the same company, because a wrong bridge is worse than no bridge. This is the entity layer that off-page SEO feeds from the other direction through links and mentions, and the two should agree on who you are.

schema.org Pending Types and Versioning: What Advanced Practitioners Track

schema.org does not stand still, and the practitioners who stay ahead of it track two things: the release cadence and the pending queue. The vocabulary is maintained as a public project with versioned releases and an open mailing list where new types are proposed and discussed. JSON-LD the syntax is separately standardized by the W3C, with JSON-LD 1.1 as the current Recommendation, per the W3C JSON-LD 1.1 specification (2020), which means the syntax you write today is stable even as the vocabulary you write with it keeps evolving.

Pending types

schema.org marks new and experimental types as pending before they are finalized into the core vocabulary. Pending types are visible on schema.org and usable in markup, but they carry more risk: their properties can change, they can be renamed, and Google may not consume them for any rich result. The rule is to use pending types for experimentation and internal knowledge graphs, not for the markup you rely on to earn a live rich result. Keep production rich-result markup on stable, finalized types, and treat pending types as a preview of where the vocabulary is heading.

Versioning and drift

Versioning matters for a practical reason: the vocabulary changes underneath you. A property that was valid last year can be deprecated, a recommended field can be promoted to required, and a type can be retired the way FAQPage and HowTo effectively were. The scale of the ecosystem makes drift inevitable, with WebDataCommons extracting 74 billion RDF quads from 16.5 million websites, per the WebDataCommons announcement (2025). With that much markup in the wild, a lot of it is stale, and the way to avoid joining the stale pile is to re-validate on a schedule rather than assume last year's block is still correct.

Valid vs Eligible: Why Passing the Rich Results Test Is Not a Rich Result

There are three distinct statuses for structured data, and collapsing them is the most expensive misunderstanding in schema SEO. Valid means the markup is well formed and uses the vocabulary correctly. Eligible means Google's tools say the page qualifies for a specific rich result. Live means the rich result actually appears in search. Each is a gate, and passing one does not pass the next.

The Rich Results Test checks eligibility, not guarantees. Passing it only means the markup is eligible for a rich result; it does not guarantee one, which depends on page quality, crawlability, and relevance, per Search Engine Journal (2024). This is the same distinction Google draws in its own documentation: structured data helps Google understand and present content but is not a guaranteed ranking boost, and display depends on many additional signals, per Google's structured data introduction (2025).

The practical workflow is to check all three statuses in order. Confirm the JSON is valid in the Schema.org Validator, confirm the type is eligible in the Rich Results Test, then confirm in the live results whether anything actually rendered. The schema checker handles the first read of what a page sends, and the gap between eligible and live is where you should spend your debugging time, because that gap is rarely about the code.

Search Console Enhancements Report: Detecting Markup Drift Over Time

The Enhancements report in Search Console is the monitoring layer for schema, and it is where drift shows up first. It lists the structured data types Google found on your site, groups the items as valid, invalid, or eligible, and flags the specific errors that moved an item from one bucket to another. A schema change that breaks a template will not announce itself in the search results; it will announce itself here as a spike in invalid items, often before the rich result disappears.

Reading the report

Open the report and look for three things in order. First, the trend line of valid items, which should be flat or rising, never suddenly falling. Second, the error list, where each invalid item names the field that failed and the pages affected. Third, the gap between valid and eligible, because an item can be valid without being eligible when a required property is missing or a policy is violated. A sudden spike in invalid items almost always maps to a deploy, a template change, or a plugin update, and the fix is to roll back the change that introduced it.

Setting a drift cadence

Drift does not need daily attention, but it does need a schedule. Check the report after every template or CMS deploy, and set a monthly reminder to review the trend even when nothing changed, because the vocabulary and Google's requirements change independently of your code. When you spot a new error, extract the affected page with the schema checker, compare it against the copy-paste blocks in this guide, and fix the specific field the report named. Monitoring is the step that makes schema a maintained asset instead of a tag you set in 2024 and forgot.

Troubleshooting Common Schema Errors: A Symptom-by-Symptom Field Guide

Most schema failures fall into a handful of recurring patterns, and each has a specific symptom and a specific fix. The table below maps the symptoms you will actually see in the Rich Results Test, the Schema.org Validator, and Search Console to the root cause and the fix, so you can resolve a problem without reading the whole validator output line by line.

The field guide works because the symptoms are predictable. When you see a JSON error, the problem is syntax. When you see a missing-field warning, the problem is completeness. When you see eligible-but-not-live, the problem is quality or crawl, not code. And when you see FAQ or HowTo return nothing, the problem is not your markup at all; those results are gone. Distinguishing these four cases is the difference between fixing a typo and chasing a rich result that no longer exists. If you have already read the technical SEO guide, you will recognize the pattern: name the symptom, find the root cause, apply the smallest fix, and verify it in the live environment rather than in the preview.