---
title: "Schema Markup Validation Is Not Enough: Monitoring JSON-LD"
date: 2026-05-12
description: Schema validators only check syntax on demand. A plugin update or CMS change can silently wipe your JSON-LD. Learn how to monitor structured data on live pages.
excerpt: A plugin update or CMS change can wipe JSON-LD from your live pages without the validator complaining. Schema markup needs ongoing monitoring, not just one-off validation.
author: Rudi Kraeher
categories: [Guides]
---
import BlogCTA from "../../components/post/BlogCTA.astro";
import Callout from "../../components/post/Callout.astro";
In November 2023, the SEO manager of five live music venues updated [The Events Calendar](https://wordpress.org/plugins/the-events-calendar/) — a widely used [WordPress](/blog/monitor-wordpress-website/) event management plugin — and silently lost more than 100 event rich results across all five sites.
The markup was valid and from his perspective the sites looked fine in the browser.
What neither he nor the validator knew was that logged-out visitors — Googlebot included — were being served pages with no event schema at all.
The first sign came from Search Console, days later. By then, the weekend's shows were already gone from Google's event results. [By his own estimate](https://wordpress.org/support/topic/event-schema-is-not-showing-using-yoast-integration/), a plugin update had cost him tens of thousands of dollars across venues doing hundreds of thousands in weekend ticket sales.
Every guide on schema markup covers the same four steps — audit, choose types, implement, validate — and stops there.
What happens to the markup after it goes live gets almost no coverage.
This post is about what breaks after deployment and how monitoring catches it.
## Structured data, schema markup, and JSON-LD
Structured data is machine-readable metadata embedded directly in a page's HTML — descriptions that tell search engines not just that a page exists but what it contains: a product with a price or an event with a date.
When that structured data uses the schema.org vocabulary, it becomes schema markup. Search engines use it to build rich results in SERPs, populate knowledge panels, and answer queries without a click.
| Term | Definition | Example |
| --- | --- | --- |
| Structured data | Any machine-readable data describing entities and their relationships | A row in a database, an RDF triple, a JSON document |
| Schema markup | Structured data using a defined vocabulary — usually [schema.org](https://schema.org/) — to describe entities for search engines | A `Product` block describing a page's main offer |
| JSON-LD | A serialization format for embedding structured data in HTML, using `` |
Every entity in this model has a **type** (Person, Product, Event), a set of **properties** (name, price, startDate), and **relationships** to other entities — an Article links to its author; a page links to a BreadcrumbList.
JSON-LD is [Google's recommended format](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) because it decouples the markup from the HTML around it.
You can add or update it without touching templates, generate it through a CMS plugin or Google Tag Manager, and nest related entities cleanly.
The two older alternatives — Microdata and RDFa — attach attributes directly to HTML elements, which works but gets unwieldy outside tightly controlled templates.
## JSON-LD types that appear in search results
When it comes to JSON-LD for SEO, a handful of types covers most of what actually shows up in search results.
| Type | What it enables in search |
| --- | --- |
| `Organization` / `LocalBusiness` | Knowledge panel: name, logo, contact info, social profiles |
| `Product` / `ProductGroup` | Product snippets and shopping knowledge panels showing price, availability, and ratings |
| `Event` | Event rich results with date, location, and ticket info |
| `BreadcrumbList` | The breadcrumb trail rendered above the SERP snippet |
| `AggregateRating` | Star ratings and review snippets alongside listings |
| `Article` / `BlogPosting` / `NewsArticle` | Date and headline information shown in search results via `datePublished` and `dateModified` |
| `FAQPage` | FAQ rich results — deprecated May 2026, no longer shown in search |
Google is [deprecating](https://searchengineland.com/google-to-no-longer-support-faq-rich-results-476957) `FAQPage` rich results in phases: gone from search as of May 7, 2026; removed from the Rich Results Test in June 2026; Search Console API support ending August 2026. The `FAQPage` schema type itself is still supported — Google and other search engines can still use it to understand your page content.
Each type also has required and recommended properties.
Many errors originate here: a required property is missing, the value doesn't match what's visible on the page, or the type doesn't fit the content.
Validators solve for any syntactical issues during initial implementation, but mismatches in visible content or incorrect type usage can go through without any warnings or errors.
## The schema markup lifecycle
Schema markup work breaks into five stages:
1. **Audit content** — figure out which pages have which entities worth marking up
2. **Choose types** — match each entity to a schema.org type
3. **Implement** — generate or hand-write the JSON-LD blocks
4. **Validate** — confirm the markup is syntactically correct and schema.org-compliant
5. **Monitor** — keep watching, because the markup that worked on Tuesday may not be there on Wednesday
Almost every schema guide treats stage 4 as the end.
Stage 5 barely gets mentioned,
and the tools available for stages 1–4 are part of why — there are solid options for each.
Where it gets thin is the continuous side.
## Schema markup tools
The main schema markup tools that most SEOs reach for each cover different aspects of the problem.
- **[Schema.org Validator](https://validator.schema.org/)** — validates against the schema.org vocabulary, independent of Google's eligibility rules. On-demand, no monitoring.
- **[Google's Rich Results Test](https://search.google.com/test/rich-results)** — one-off check on a URL or pasted markup; tells you whether it's eligible for specific rich results. Syntactic and eligibility-focused only.
- **[Google Search Console](https://search.google.com/search-console/)** — the only one that reflects what Google actually parsed from your pages, but the data is delayed and only updates when Googlebot recrawls.
- **Crawlers (Screaming Frog, Sitebulb, Ahrefs, Semrush)** — comprehensive coverage at audit time, useful for scheduled crawls, but not designed for continuous monitoring of individual pages.
None of the tools above can tell you whether the markup on your live page still says what it should, right now, unless you manually pass page URLs or individual JSON-LD blocks to the validators.
As far as we can tell, no other monitoring tool offers automated, property-level JSON-LD checks on a schedule that notifies you when anything breaks.
## How JSON-LD breaks after validation
Schema markup reaches a page through a pipeline — a CMS plugin, a template, a build step, a GTM container — and any change to that pipeline can alter or remove the output without triggering any error. None of the validation tools run continuously; they catch what's wrong at the moment you test, not what breaks the next day.
Here are two documented, real-world examples of how things can break:
### 1. A plugin update wipes schema for anonymous visitors
A [plugin update](https://wordpress.org/support/topic/event-schema-is-not-showing-using-yoast-integration/) suppressed the JSON-LD for unauthenticated visitors only.
The site manager, browsing while logged in, saw nothing wrong.
Googlebot, which always crawls unauthenticated, saw pages with no event schema.
The signal eventually came from Search Console — but only after Google had recrawled enough pages to register the drop.
### 2. Dynamic content and schema disagree
WooCommerce has a [long-standing core bug](https://adtribes.io/woocommerce-structured-data-bug/) in variable products: the JSON-LD always emits the cheapest variation price, regardless of which variant the page is actually showing.
The markup is valid but the price in the JSON-LD is wrong.
Google [compares structured data prices](https://support.google.com/merchants/answer/6098334) against what's visible on the page — when they don't match, it disapproves the product listing, removing it from Shopping results.
### Other failure modes worth watching
| Failure | Cause |
| --- | --- |
| JSON-LD blocks disappear entirely | Deploy or template change |
| Plugin emits stale `Organization` values | Plugin caching or settings not synced after a rebrand |
| Schema doesn't match visible page content | A/B testing serving different markup to Googlebot |
| `dateModified` not updating | Plugin or build step not reading the content change date |
Testomato catches all of these. A check on the right property value, running every five minutes, alerts you before Google does.
### Why GSC isn't enough
Google Search Console is the most authoritative structured data signal most SEOs have access to, but it reflects crawl data, not the live state of the page.
Google's [own documentation](https://support.google.com/webmasters/answer/13300208) is explicit about the lag: "Validation can take two weeks or more, depending on crawl frequency."
In practice, the window between a deploy that breaks schema and the damage becoming fully visible in Search Console can stretch to four to six weeks.
GSC has also had extended reporting freezes of its own — one [incident in late 2025](https://searchengineland.com/google-search-console-performance-reports-delays-fixed-466290) left performance data stuck for weeks.
## Monitoring JSON-LD with Testomato
The JSON-LD checker came directly from a customer request — an SEO consultant who needed to know the moment structured data values changed on pages they managed.
It monitors individual property values inside any JSON-LD block, checking every five minutes against the live page.
When a check fails, Testomato sends an alert through your [configured alert channel](/instant-alerts/): Email, Slack, PagerDuty, or any other supported integration you select.
### Rule syntax
Rules use a `json-ld:` prefix followed by a dot-notation path through the JSON.
An unscoped path like `json-ld:name` matches that property in any block on the page.
A type-scoped path like `json-ld:Organization.name` narrows the match to blocks where `@type` is `Organization`.
Type scoping matters on pages that carry multiple blocks. Testomato's homepage, for example, carries both a `WebSite` and an `Organization` block — each with its own `name` property:
```json
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Testomato",
"url": "https://testomato.com/"
}
// ...
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Testomato s.r.o.",
"url": "https://testomato.com/"
}
```
A bare `json-ld:name` rule passes as long as any block on the page matches. Use `json-ld:Organization.name` when you need to assert something specifically about the `Organization` block.
The full rule syntax, all operators, and failure modes are in the [help doc](https://help.testomato.com/checks/json-ld).
Presets cover the most common schema fields and type+property combinations.
### What to monitor first
A practical starting set:
- **`Product` name** and **`offers.price`** on ecommerce pages — exactly the surface that breaks in the WooCommerce scenario
- **`Organization` name** on pages with an `Organization` block — catches CMS updates and rebrands before they cause damage
- **`BreadcrumbList` itemListElement** — catches template regressions that wipe breadcrumbs from SERPs
- **`AggregateRating` ratingValue** — best monitored with the `matches pattern` regex operator, since the value changes over time but should always look like a number
Testomato also keeps a full incident history — each failure logged with its exact message, timing, and response details, up to 30 days back.
If a rich result drops after a deploy, you can see exactly when the JSON-LD check started failing and what it found.
Schema markup isn't visible in the rendered page, so you'll never know there is a problem unless you are manually checking and see that the rich results have disappeared or after the Search Console report arrives.
An effective implementation of JSON-LD begins with the validator passing, but everything after that – the next site deployment, plugin update, or CMS migration – needs ongoing monitoring.
Start monitoring your JSON-LD with Testomato