Does your JSON-LD still parse after Google's single-unescape change? 79 of 443 pages AI engines cite carry entity text Google says it will no longer unroll, Ahrefs, HubSpot, TechRadar and Google's own docs among them

What Google changed

The announcement is a LinkedIn post from Google Search Central, dated 2026-08-21 09:04 UTC, in full: "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. Practically speaking, this means that double-escaped entities (like `&`+`amp;` or `&`+`#10004;`) will no longer be unrolled. 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`)." Gary Illyes added eight minutes later that proper escaping "is very, very well defined in RFC 8259, specifically section 7." Search Engine Roundtable reported it the same morning. There is no entry on the Search Central documentation changelog as of this run; the LinkedIn post is the primary.

(Entity sequences are written here as `&`+`amp;` because, fittingly, our own publishing pipeline refuses to ship one inside a content string: `ops/verify/entity_sweep.mjs` reds the build on any entity in a registry value or in live JSON-LD. It has since 2026-08-21, the day this change landed.)

Why it matters before the numbers

Until last week Google's parser was forgiving: a title serialised as `Tom &`+`amp; Jerry` inside a JSON string was decoded back to `Tom & Jerry`, sometimes through several passes. That forgiveness hid a very common bug, where a templating engine HTML-escapes a value that is then placed inside JSON, which has its own escaping. The new behaviour means the string Google stores is the string your parser would give you: a `headline` with `&`+`#8217;` in it is now a headline containing seven characters of entity text, and a block that is not valid JSON is not structured data at all. For the FAQPage, Article, Product and LocalBusiness markup that AI-visibility advice routinely recommends, that is the difference between markup that works and markup that ships a typo into the index.

What we measured

Our weekly self-audit asks 12 buyer questions ("Which tools show how ChatGPT recommends businesses?", "How do I audit my brand's AI visibility?" and ten more) of four engines, three samples each, and stores every URL each engine returned in its citation channel. The 2026-08-17 run produced 144 answers. We excluded our own domain (7 entries) and Gemini's bare-hostname citations (382 entries, which carry no path), leaving 572 unique URLs on 385 hosts: the pages the engines are actually citing on these questions. We fetched each once with a browser user-agent and no JavaScript, 20-second budget. 527 returned readable HTML; 30 refused with 403 (g2.com, capterra.com, wikipedia and other bot-walled hosts), 10 returned other 4xx or 5xx, 1 was non-HTML, 4 timed out.

For every `<script type="application/ld+json">` block on the 527 readable pages we recorded two things. Strict: does Node's `JSON.parse`, which implements RFC 8259, accept the block as served? Entity: after parsing, does any string value anywhere in the object contain an HTML entity sequence (named, decimal or hex, the same regex our own sweep uses)? A page is affected if any block fails either test. 443 of the 527 pages (84.1%) carry at least one block, 1,113 blocks in total.

The read

By entity kind, counted per block: the ampersand entity 57, the curly-apostrophe numeric form (`#8217`) 12, the straight-apostrophe forms (`#39`, `#039`) 18, `hellip` 5, the WordPress ampersand form (`#038`) 4, `rsquo` 3, `quot` 2, and one each of `lt`, `gt`, `nbsp`, the dollar sign (`#36`) and the en-dash (`#8211`). The six strict failures are all different bugs: two elfsight.com posts with a second object pasted after the closing brace, a bigeyeagency.com block whose `headline` and `description` are unrendered template placeholders (`{{… | json}}`), a sidehustlenation.com block with a JavaScript-style `//` comment inside the JSON, a webfx.com block with a raw control character inside a string, and an iqdigitalai.com `Person` block whose entire JSON was HTML-escaped, so it opens with `{&`+`quot;@context&`+`quot;`.

Who is on the list

Not only small sites. Ahrefs serialises its site description as `Link Building Strategies \u0026amp; SEO Tips`: the ampersand was HTML-escaped first and then correctly JSON-escaped, which is exactly the double escape Google's post describes, and the value that comes out of any JSON parser is the five-character entity. HubSpot's AI-search-optimization post carries the ampersand entity in its `WebPage` name, its `Article` headline and its breadcrumb. TechRadar ships `brand&`+`#039;s` in the Article `name`, `headline` and all four image captions. Search Engine Land's Organization description reads `(SEO) &`+`amp; Pay-Per-Click (PPC)`. And the BreadcrumbList on Google's own Succeeding in AI search post on developers.google.com names its third crumb `Google&`+`#39;s AI experiences on Search`. We re-fetched the Google, Ahrefs and TechRadar pages with plain curl after the sweep and found the same bytes.

Twelve of the 63 hosts share one defect byte-for-byte: a `Person` image `@id` ending `?s=96&`+`amp;d=mm&`+`amp;r=g`, a WordPress avatar URL escaped for HTML before it was placed in the Yoast-style `@graph`. That is a plugin-level fix, and those twelve sites will get it when the plugin does; the 56 pages with entity text in a headline, name or description are mostly hand-written or theme-level and will not.

Two readings of the rule, two numbers

Google's post is short and does not say where the single pass is applied. We report both readings. Reading A, the literal one ("double-escaped entities like the ampersand entity will no longer be unrolled"): an entity inside a JSON-LD string value now reaches the index as that entity. That is the 79-page, 17.8% figure above, and it is the reading our own detector enforces. Reading B, the conservative one: one HTML-unescape pass runs over the raw script text before the JSON parse, so a plain `&`+`amp;` in the source is still decoded and only survives when it was JSON-escaped (Ahrefs' `\u0026amp;`) or written twice. Under reading B the count is 11 pages (2.5%): the 5 syntax failures that no unescape fixes, 4 pages whose entity survives the pass (two Ahrefs posts, a TechRadar review page, nicklafferty.com), and 2 pages the pass breaks: cited.so and firstlinesoftware.com carry `quot` entities inside FAQ answer text, and decoding them mid-string produces an unterminated JSON string. The iqdigitalai.com fully-escaped block is the one case reading B repairs.

Either way the floor is nonzero on a population of pages that are, by construction, the pages AI engines already trust enough to cite. And under either reading the fix is the same one Google wrote: escape for JSON, not for HTML, and if your stack has to escape for HTML, do it after the JSON is built.

What to check on your own site

• View source, find every `application/ld+json` block, and paste each into a strict validator (Node's `JSON.parse` or `python -m json.tool`). A validator that tolerates what a strict parser rejects is no longer telling you what Google will store; a strict parser is the honest test now.
• Search the parsed values, not the raw HTML, for `&`+`amp;`, `&`+`#39;`, `&`+`#8217;` and `&`+`quot;`. The Ahrefs case shows why: the raw text reads `\u0026amp;` and a grep for the entity finds nothing.
• Look hardest at `headline`, `name`, `description` and FAQ `acceptedAnswer.text`: those are the fields answer engines quote, and 56 of the 79 affected pages have the defect there.
• If you run WordPress with an SEO plugin, check the `Person` image `@id` in your `@graph`; the `?s=96` avatar URL pattern was on 12 of the 63 affected hosts.

Limits

One fetch per URL, no JavaScript: markup injected client-side is not counted, and 30 bot-walled pages (g2, capterra, wikipedia among them) are outside the read. The population is the citation set of 12 AI-visibility buyer questions, not the web; it over-represents SEO and GEO vendors, which cuts both ways for a structured-data story. Node's `JSON.parse` is the strictness bar; Google's parser may differ at the margin (a leading BOM, for instance). We have not observed the effect in Google's index for any page on the list and make no claim about rich-result loss: the read is what the markup says, not what Google did with it.

Our own pages: 0 of the site's JSON-LD blocks carry an entity or fail a strict parse, checked on every healthcheck since 2026-08-21. The one defect we ever had, a pasted `&`+`lt;vertical&`+`gt;` inside a news post, is what built the sweep. A page that wants to be cited by an answer engine needs its visible text and its structured data to say the same thing; the answer engine optimization guide covers the rest of that list.