JSON-LD Errors: How Do You Validate Structured Data?

A site can lose every one of its rich results at once without a single alert appearing in the dashboard, without a drop in indexing, and without one red line in the coverage report.

JSON-LD errors work exactly like that: the page stays live, the text stays correct, and Google keeps crawling. Only the structured data block stops being interpreted.

The practical effect is a loss of real estate on the SERP. Stars, breadcrumbs, product information, and enriched cards disappear, and the result goes back to being an ordinary blue link next to competitors that kept their markup readable.

In August 2026, that risk grew for a specific reason: Google tightened its reading standard and stopped fixing, on its own, a type of error it used to tolerate.

What are JSON-LD errors and why do they go unnoticed?

JSON-LD errors are defects in the structured data block that prevent the search engine from interpreting the markup. They can be syntactic, when the JSON is malformed, or semantic, when the property does not exist in the vocabulary or does not match the page content.

What makes this problem dangerous is its invisibility. The JSON-LD block sits inside a script tag in the source code and is never rendered for the visitor.

Nobody notices the failure while browsing the site. The layout does not break, the page loads the same way, and the content team receives no signal that anything changed.

Caption: When the structured data block breaks, the search engine discards the entire markup and the enriched result disappears from the SERP.

The search engine does not complain proactively either. When the markup is unreadable, the default behavior is simply to ignore the block, not to log an alert in every case.

The consequence is a loss that only shows up in the numbers. The rich result vanishes from the SERP, CTR falls, and the team's natural hypothesis is to attribute the drop to a core update or to a new competitor.

It is worth separating what the error does from what it does not do. Google's structured data policies documentation treats misleading markup as a violation subject to a manual action, but markup that is simply broken is not a penalty: it is an absence.

That distinction changes both the urgency and the type of fix. A penalized page needs a compliance review, while a page with broken markup needs a technical repair and a fresh validation.

What changed in Googlebot's JSON-LD extraction?

Google Search Central announced on August 21, 2026 that it now applies a single pass of HTML unescaping when extracting JSON-LD. The stated goal was to align the crawler with the JSON standard, and the side effect is that non-standard markup is no longer corrected at read time.

Before that change, the parser was tolerant. When it found HTML entities escaped more than once, it applied successive passes until it reached valid JSON, which masked generation defects.

Now the behavior is literal. The crawler unescapes once and works with whatever is left, even if the result still contains unresolved entities.

The reference standard is public. RFC 8259, which defines the JSON format, establishes in its section on strings which characters require escaping and authorizes the six-character hexadecimal notation that begins with a backslash and the letter u.

One detail matters for anyone investigating this now. According to the report of the change on Search Engine Roundtable, the notice circulated through a Search Central social channel, with no corresponding entry in the documentation changelog at that point.

That has a practical implication for diagnosis. Looking for the rule in the official documentation and not finding it does not mean the change is not in force, so verification has to happen in the tool, not in the supporting text.

The risk group is well defined: sites whose markup is assembled by a template, a plugin, or an integration rather than written by hand. That is the path where the extra escaping layer tends to get added without anyone asking for it.

Why does double escaping break JSON-LD silently?

Double escaping happens when a character already converted into an HTML entity gets converted again before reaching the final code. The ampersand becomes an entity, that entity has its own ampersand escaped again, and the result is a sequence that neither side knows how to undo on its own.

The typical path has three stages. The writer types a special character into the CMS, the text editor converts it into an entity so it displays correctly on the page, and the template converts it again when serializing the field inside the JSON-LD.

Each stage makes sense in isolation. The problem is born from the sum, because none of the layers knows the previous one already did the same job.

The outcome varies depending on where the character landed. When the broken sequence sits inside a text value, the effect is cosmetic and the property arrives dirty, with the entity code showing up inside the rich result.

When the broken sequence affects a quotation mark or a backslash, the effect is structural. The JSON stops being valid, the entire block is discarded, and every property in that markup disappears at once.

The characters that most often cause this are predictable: the ampersand in course and institution names, quotation marks in titles and testimonials, the apostrophe in proper names, and the greater-than and less-than symbols in technical text.

There is an additional trap in manual inspection. The browser may display the entity already resolved in the elements tab, so the reading has to be done in the raw source code or straight in the validation tool.

The fix is not to remove the escaping, but to escape only once, in the right standard. For special characters inside JSON strings, JSON's own hexadecimal notation solves it without relying on an HTML entity.

How do you validate structured data in the Rich Results Test?

Validating structured data takes two tools, because they answer different questions. Google's Rich Results Test tells you whether the page is eligible for any enriched feature in Search, while the Schema Markup Validator tells you whether the markup is correct according to the schema.org vocabulary.

The difference between those two answers is what confuses most teams. Markup can be perfect in the schema.org validator and still produce no rich result at all, simply because Google does not offer that feature.

The reverse also happens. Markup can pass the Rich Results Test with warnings and still carry wrong properties that hurt interpretation by systems other than Google.

Here is how each tool behaves in the face of the most common problems:

Tabela: Expected behavior of each tool when facing the most frequent JSON-LD errors.

Reading both together settles the diagnosis. Markup that disappears in the Rich Results Test and flags syntax in the validator is an escaping case, not a vocabulary one.

One methodological caution makes a difference in testing. Validating by public URL reproduces what the crawler actually receives, while pasting the template code tests the intention and can hide exactly the escaping layer added at delivery.

Which JSON-LD errors show up most on CMS-driven sites?

CMS-managed sites concentrate a predictable set of JSON-LD errors, because the markup is born from a template rather than written by hand. The same defect replicates across thousands of pages at once, and so does the fix: repairing the template repairs the whole site.

The first pattern is the unsanitized free-text field. A course title with an ampersand or a name with quotation marks goes straight into the property and carries the editor's escaping along with it.

The second is duplicated blocks. The SEO plugin and the site theme generate markup of the same type independently, and the page ends up declaring two competing articles or two competing organizations.

The third is orphan markup. The template injects properties that correspond to nothing visible on the page, which pushes the case toward the misleading-markup boundary described in Google's policies.

The fourth is the broken date. Publication and update fields come out in a local format instead of the international standard, and the search engine discards the information without notice.

The fifth is the most recent one. Markup that relied on the old parser's tolerance worked for years and stopped working in August 2026, without anything on the site having changed.

That fifth case carries a useful diagnostic fingerprint. If the rich result vanished with no deploy, no migration, and no content change, the escaping hypothesis comes ahead of any theory about the algorithm.

The logic of a clean structured field, by the way, is not exclusive to SEO. The same care sustains the use of structured data in customer retention, where dirty data contaminates segmentation instead of contaminating the SERP.

Which schema types still produce rich results at Google?

The list of types that produce rich results shrank in 2026, and auditing markup without accounting for that wastes effort. Google confirmed in the FAQPage documentation that FAQ rich results stopped appearing in Search on May 7, 2026, with the report and the testing tool support removed over the course of that year.

The consequence for the audit is one of prioritization. Fixing escaping in a FAQPage block returns nothing on the SERP, because the feature no longer exists to display.

That does not turn deprecated schema into garbage. The markup still describes the page for systems that consume structured data, and its value migrated from appearance to interpretation.

The priority rule becomes clear. Start with the types that still produce a visual effect, such as article, product, review, structured navigation, event, and organization, and treat the rest as semantic hygiene.

It is worth pairing that list with the strategic design of the markup. Building an SEO strategy with Schema.org defines which types make sense per page before the problem turns into a technical debate about syntax.

There is an additional layer that changes the calculation. With the expansion of AI-generated answers, markup took on a context function beyond its display function, which usually justifies keeping the schema even with no associated rich result.

That reasoning connects with a behavior already visible in many sites' numbers, where zero-click search reduces sessions even with good rankings, and the clarity of the markup becomes part of the fight for citation.

How do you build a structured data audit routine?

A structured data audit routine works better when it is short and recurring than when it is deep and annual. The goal is not to review every page, but to monitor a small set of pages representative of each template, so a systemic defect gets caught right after it appears.

The first step is choosing the sample. Take one page from each template type on the site, across the home page, a listing, an article, an offer page, and an institutional page.

The second is running both tools on each of them, always by public URL. Record the result in a simple spreadsheet with the date, the template, the schema type detected, and the status.

The third is reading the structured data report in Search Console. It covers the entire site and shows the trend, which sample checking does not.

The fourth is cross-referencing the date of any drop with the calendar of changes. Dating the variation avoids the wrong attribution, which is the origin of most useless fixes.

The fifth is defining a re-audit trigger. Every theme swap, SEO plugin update, CMS migration, or announced crawler change justifies repeating the sample.

The suggested frequency is monthly for the sample and immediate for the triggers. That rhythm is usually enough to catch a template defect before it consumes an entire traffic cycle.

Monitoring also benefits from reading the AI data. The AI report in Search Console helps you observe whether the drop in clicks is concentrated in generative surfaces or in the classic SERP.

How does this change operations at an educational institution's site?

Educational institution sites feel JSON-LD errors disproportionately, because they depend on repetitive template-generated pages. A catalog with dozens of programs uses the same structure for all of them, so an escaping defect in the model erases the markup of the entire catalog at once.

The problematic character is routine in that context. Program names with ampersands, titles with quotation marks, and long institutional designations are exactly the material double escaping ruins.

Seasonality makes the cost worse. A broken markup block in January weighs far more than the same block broken in September, because the enrollment window does not wait for the next fix cycle.

There is also an effect on authority. Organization and authorship markup is part of what sustains E-E-A-T signals in building authority, and an unreadable block removes that context from automated reading.

The same goes for top-of-funnel content. An article with broken markup loses part of the enrichment that helps the card compete in the feed, which adds to the natural volatility of Google Discover.

The operational recommendation is modest and cheap. Put one program page and one blog article in the monthly sample, because those two templates cover most of the risk on an educational site.

Frequently asked questions about JSON-LD errors

So, is it worth auditing JSON-LD errors now?

Auditing JSON-LD errors is worth it now for a reason of timing. The change in Googlebot extraction took effect in August 2026 and affects markup that had been working for years, so the defect may already be active without anything on the site having changed.

The cost of checking is low. A sample of five pages across two tools settles the initial diagnosis in under an hour of work.

The cost of not checking is asymmetric. A missing rich result sets off no alarm, appears in no error report, and shows up only as a slow erosion of clicks that usually gets credited to another cause.

The order of priority is simple as well. Start with the templates that generate the most pages, move on to the types that still produce rich results, and leave semantic hygiene for last.

If your operation does not currently have a routine that dates variations and separates technical defects from algorithm changes, that is the point that usually pays off fastest. It is exactly the kind of diagnosis that structures consistent SEO work, where the technical fix supports the content instead of competing with it.

To review your site's markup and turn this check into a routine, talk to the mkt4edu team.