Google Search Central said on LinkedIn on August 21 that it changed how it extracts JSON-LD, the structured-data format sites embed in their pages. The parser now applies a single pass of HTML unescaping, so an entity that was escaped twice is no longer unrolled. Gary Illyes of Google reshared it minutes later with a pointer to the JSON standard that defines proper escaping.
What Google’s parser does differently
Google’s own description: “To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping.” The two examples in Google’s post are the ampersand entity and the check-mark entity (✔), each escaped a second time. An entity written once, like &, still resolves to a plain character under the single pass that remains.
An entity escaped twice, like &, now stops after that pass at the literal string &, and that string is what Google reads as the value. Double-escaped entities were previously, in Google’s own word, “unrolled”; they no longer are. Google’s advice: “If you’re using JSON-LD for structured data, be sure to update your code to standard JSON escapes or Unicode hexadecimal escapes (like \u0026).”
What did Google change in JSON-LD extraction?
Google’s JSON-LD parser now applies a single pass of HTML unescaping. An entity escaped twice no longer unrolls back to its original character and instead stays literal in the parsed value. Google recommends standard JSON escapes or Unicode hexadecimal escapes such as \u0026, matching RFC 8259 section 7.
Why the RFC settles the question
Gary Illyes of Google pointed straight at the spec: “If you’re wondering what proper escaping is in JSON, I have good news for you! It’s very, very well defined in RFC 8259, specifically section 7.” That section puts JSON strings inside quotation marks and requires escaping only the quotation mark, the reverse solidus, and control characters from U+0000 through U+001F. The permitted escapes are \", \\, \/, \b, \f, \n, \r, \t, and \uXXXX.
Under that rule, a plain ampersand needs no escaping at all: & is valid JSON as it stands, and \u0026 is only the optional Unicode form. HTML entities such as &, ", or ✔ are not JSON escapes at all.
How this shows up on a live site
Nothing looks wrong in the CMS; the difference is only in what the parser reads. On a WordPress site we checked, running Yoast SEO, a title with an ampersand reached the Article JSON-LD as &: escaped once, which the remaining pass still resolves. Run that value through one more escaping layer, such as a theme filter or a headless front end, and it would no longer resolve to an ampersand. elsop’s FAQ Schema Generator already sidesteps the issue: it writes the ampersand, less-than and greater-than characters as \u0026, \u003c and \u003e, the Unicode-escape form Google’s notice names, rather than as HTML entities.
What to check now
The fix starts with the page source, not the CMS preview. Search inside every <script type="application/ld+json"> block for &, ", or &#. Where an entity appears escaped twice, fix the generator, not the page: the places to look are a CMS filter, an SEO plugin, or a headless middleware step that re-escapes an already-escaped string. Write values as plain characters or as JSON and Unicode escapes, then retest.
Commenters replying under Google’s post pointed at e-commerce themes and apps that generate JSON-LD without anyone reviewing the output.
Google named a different structured-data problem on July 24, a review-snippet guideline against fake or undisclosed incentivized reviews, covered in elsop’s report on the manual action. That one carries a defined consequence: the manual action strips the star rating from the listing and leaves rankings untouched. This week’s notice mentions no action of any kind; the parser simply reads a different string than the page intended, and the page source is where that shows.
As of this writing, the change has no entry in Google’s Search Central documentation changelog, and the structured-data policies page, last updated July 10, says nothing about it. Search Engine Roundtable covered the notice the same morning, at 7:15 am ET.
