What did Google change about JSON-LD parsing?

Google's parser now applies a single pass of HTML unescaping to JSON-LD instead of auto-correcting text that was escaped twice. A value that was escaped twice, so that the ampersand of an entity is itself written as an entity, used to be unrolled back to a plain character. It now reaches the rich result as the five literal characters. The reference is RFC 8259 section 7, which is the JSON specification's own rule for escaping.

How do I know if my structured data is affected?

Look inside the string values of your JSON-LD for HTML entities: the named ones for ampersand and quote, and numeric ones such as the tick mark. A raw ampersand is correct and needs no change. An entity is only a problem when it sits inside a JSON string, because JSON has its own escaping and does not use HTML's.

How common is this problem?

Rarer than the coverage suggests. We fetched the homepages of 50 well known domains on 22 August 2026, reached 43, and found 36 publishing JSON-LD. One of the 36 carried an HTML entity inside it. That is a small sample of homepages rather than a survey, and template-generated pages deeper in a site are the likelier place for this to appear.

How do I fix a double-escaped value?

Write the character itself, or use the JSON Unicode escape for it, which for an ampersand is backslash u 0 0 2 6. Both are valid JSON. The usual cause is a value that was escaped for HTML on its way into a template and then never unescaped before being serialised as JSON, so the fix is normally one step in the template rather than an edit to the content.

Google stopped fixing double-escaped JSON-LD

Google's JSON-LD parser now applies a single pass of HTML unescaping and no longer corrects text that was escaped twice. If one of your structured data values contains &, it used to arrive as an ampersand. It now arrives as those five characters, printed literally.

We checked the homepages of 50 well known domains to see how widespread this is. 43 answered, 36 of those publish JSON-LD, and one of the 36 has the problem. So the honest headline is that this is real, silent, and rarer than the volume of coverage implies.

What actually changed

The rule Google is now following is RFC 8259 section 7, which is the JSON specification's own definition of how strings are escaped. JSON has an escaping scheme. HTML has a different one. A JSON-LD block is JSON that happens to live inside a <script> tag, so the JSON rules are the ones that apply to its contents.

Previously Google's parser was forgiving about this and would unroll HTML entities it found inside JSON strings. That forgiveness is what has been removed. Google's introduction to structured data markup is the page to watch for the surrounding guidance on supported formats.

Nothing about the change is dramatic. It is a parser being brought in line with the specification it was always supposed to follow. The interesting part is the failure mode.

Why nothing you run will catch it

Take this block:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Tom &amp; Jerry Ltd",
  "url": "https://example.com/?a=1&amp;b=2"
}

It is valid JSON. It parses. Every property Google's documentation asks for is present. @type is correct, the URL is absolute, nothing is missing. A validator that checks required and recommended fields, which is what most of them check, will pass it without comment.

And the rendered result will say Tom & Jerry Ltd.

That is an unusually unpleasant shape for a bug. There is no error anywhere in the pipeline. The markup is correct by every test you would think to run, and the only place the defect is visible is in the output, which is the one thing you cannot inspect directly. It is the structured data equivalent of a stale comment: everything agrees with everything else, and the agreement is the problem.

We checked 36 sites. One had it.

On 22 August 2026 we fetched the homepage of 50 domains: SEO and AI visibility vendors, large publishers, ecommerce sites, and SaaS products. 43 returned a 200. Of those, 36 publish at least one JSON-LD block on the homepage.

One of the 36 carries an HTML entity inside its JSON-LD.

Before trusting a result like that, it is worth proving the instrument can find something. The same pattern, run over the full HTML of the same pages rather than only the JSON-LD, matched on 42 of the 43. So the pages are full of HTML entities exactly where entities belong, and almost none of them leak into the structured data. The near-zero is a measurement rather than a broken regex.

Two limits worth stating. This is 36 homepages, not a survey, and homepages are the most hand-tended page on any site. The likelier place for double escaping is a template that generates thousands of pages from a database field, which is precisely where nobody looks.

The one that had it

The site is Search Engine Land, and its WebSite node describes the publication as News, Search Engine Optimization (SEO) & Pay-Per-Click (PPC).

That is not a dig, and it is close to the whole point. If an SEO publication with a serious technical audience has an entity sitting in its site description, the defect is not a competence problem. It is a visibility problem. Nothing in their stack was ever going to raise a hand about it, and the consequence is one slightly odd-looking description rather than a lost rich result.

Which is roughly the right scale for this issue in general. It is worth fixing, it is not worth panicking about, and the sites most likely to be bitten badly are the ones generating markup at scale from fields that passed through an HTML-escaping step on the way in.

How to check yours

Look inside the string values of your JSON-LD for anything of the shape &name;, Ӓ or 😀. A bare ampersand with no semicolon is fine and is what valid JSON should carry. An entity is only wrong when it sits inside a JSON string.

Our schema markup validator now reports these alongside missing fields, with the path to the value and the exact string it found. SEOBuilder is our own product, so weigh the recommendation accordingly; the check is free, needs no account, and you can equally do it by hand with a search across your rendered HTML.

It is reported as a warning rather than an error on purpose. A page whose subject is HTML entities will write them deliberately, and a rule that cannot be right about that case has no business calling a page broken. It names what it found and lets you decide.

What to actually do

Fix it where you find it, by writing the character itself or using its JSON Unicode escape, which for an ampersand is \u0026. Then look one step upstream, because a single escaped value is usually a symptom of a template that escapes for HTML and serialises to JSON without undoing it. Fixing the template fixes every page it generates.

Then move on. This is a small, quiet, cheap-to-fix problem, and the most useful thing about it is the reminder that "valid" and "correct" are different tests.