Google Just Broke JSON-LD Escaping. Check Your Schema Now.
Google has changed how its structured data parser handles HTML unescaping, and it now applies only a single pass. If your JSON-LD contains double-escaped entities, they will no longer be unrolled correctly, which means characters like & can render literally as & instead of &. In plain terms: schema that Google used to forgive may now silently fail, and the rich results tied to it can quietly disappear.
This is not a headline update with a blog post and a countdown. It is a low-level parsing change, the kind that hides inside templated CMS output and does not announce itself until your rich results are already gone. From my observation, those are the changes that hurt large sites the most, because the damage compounds across thousands of pages before anyone notices a dip.
What actually changed
Previously, Google's parser was lenient enough to unescape HTML entities more than once. So if your template accidentally double-encoded an ampersand as &, the parser would keep unrolling it until it resolved to a clean &.
That behaviour is gone. The parser now does one pass only. A double-escaped entity gets unescaped once and then stops, leaving a broken, literal string sitting inside your structured data values.
When this matters and when it does not
Correctly escaped JSON-LD is completely unaffected. If your schema was clean, nothing breaks. The risk sits entirely with double or triple escaping, which is almost always a byproduct of layered systems rather than a human mistake.
The classic pattern: a CMS escapes a value for HTML, then a plugin or template layer escapes it again for JSON output. Two systems, each doing their job, producing one broken entity. On a hand-built page you would spot it. On a templated site pushing product, article and FAQ schema at scale, you will not.
Where I would look first
| Field type | Why it is high risk |
|---|---|
| Product and offer names | Ampersands in brand names ("M&S", "Barnes & Noble") are extremely common |
| Article headlines | Often pull raw title text through multiple escaping layers |
| Breadcrumb and navigation labels | Template-generated, rarely reviewed, high volume |
| FAQ and Q&A content | User-generated punctuation and symbols pass through untouched |
Caption: The fields most likely to carry double-escaped entities on large templated sites.
How to audit it in three steps
You do not need to rebuild anything. You need to find the double escaping and unwind one layer of it.
- Validate live URLs. Run representative page templates through the Google Rich Results Test and read the parsed values, not just the pass/fail. Look for literal
&strings in output. - Trace the escaping chain. Find where your JSON-LD is generated and identify every layer that touches the string. Usually one layer is escaping something that was already escaped upstream.
- Fix at source and re-test. Remove the redundant pass so entities are escaped exactly once, then re-validate. Confirm against Google's own structured data documentation.
Why growth teams should care now
Rich results are eligibility, not entitlement. Broken schema does not throw an alarm, it just quietly removes you from the running for the enhanced listings your competitors still hold.
I think this is the sort of silent tax that erodes visibility while dashboards look calm. As search moves further into machine-read surfaces, clean structured data is the foundation of how you are understood, which is exactly why I keep pushing teams toward measuring citation share rather than just traffic. And if you are already tightening technical foundations ahead of Google's shifts, pair this with your spam update diagnostic work.
The action is simple and urgent. Audit your JSON-LD escaping this week, fix the double-encoding at source, and re-validate before the gap shows up in your rich result coverage.
Tags