---
title: "Google Stops Auto-Correcting Double-Escaped JSON-LD"
description: "Googlebot now unescapes JSON-LD once instead of repeatedly, so structured data a template escaped twice is no longer corrected for you. Check your markup."
tldr: "On 21 August 2026 Google changed how Googlebot reads structured data: it now decodes an escaped character in your JSON-LD once, where it used to keep decoding until it reached the plain character. A template that escapes a value twice is no longer corrected for you, so a brand name containing an ampersand can reach Google with raw markup inside it. Re-test templated product, review, recipe and FAQ markup in the Rich Results Test."
publishDate: 2026-08-24
author: "Liam Hayward"
---
Googlebot has stopped tidying up badly escaped structured data. Escaping means writing a character in a substitute form so it does not break the code around it: in HTML an ampersand is written `&`. In a LinkedIn post on 21 August 2026 Google said it is "now only applying a single pass" of HTML unescaping when reading JSON-LD, to bring its parser in line with the JSON standard. Google's Gary Illyes pointed to RFC 8259, which defines JSON string escaping.

Escaping twice is something a template or CMS does by accident, when it escapes a value that was already escaped upstream. `&amp;` is correct in page text but not inside a `<script>` block, which is not parsed as HTML. That markup used to come out right, because Googlebot kept decoding until it ran out of layers. Google's own two examples were an ampersand and a tick mark:

```
Your markup     "Bodger &amp;amp; Badger"
Google, before   Bodger & Badger
Google, now      Bodger &amp; Badger

Your markup     "In stock &amp;#10004;"
Google, before   In stock ✔
Google, now      In stock &#10004;
```

Nothing on your side changed, and nothing fails visibly: a property that used to populate a rich result can simply stop doing so.

One layer of escaping still decodes, though, so a single `&amp;` is not what broke. These still reach Google as intended:

```
"Bodger &amp; Badger"   →  Bodger & Badger
"In stock &#10004;"     →  In stock ✔
```

Neither is standard JSON. Both work only because Google decodes them for you, and that leniency is what is being reduced, so they are worth moving off.

Run a few templated pages through the Rich Results Test and check the extracted values read the way they should. Where they do not, the fix is upstream: find the step in your template that escapes an already-escaped value and remove it. Google's instruction is to "update your code to standard JSON escapes or Unicode hexadecimal escapes (like `\u0026`)", which means:

```
"Bodger & Badger"        plain character, no escape needed
"Bodger \u0026 Badger"   Unicode escape, same value

"In stock ✔"             plain character, no escape needed
"In stock \u2714"        Unicode escape, same value
```

The two numbers differ because HTML's `&#10004;` is decimal and a JSON escape hexadecimal; both are U+2714. Sites already emitting standards-compliant JSON-LD have nothing to do here.

## Sources

- [Google Search Central on LinkedIn: JSON-LD extraction now applies a single pass of HTML unescaping](https://www.linkedin.com/feed/update/urn:li:share:7496492350370713600/)
- [Gary Illyes on LinkedIn: proper escaping is defined in RFC 8259](https://www.linkedin.com/posts/garyillyes_if-youre-wondering-what-proper-escaping-share-7496494336604360705-8Ram/)
- [JSON-LD Extraction For Googlebot Now Does One Pass Of HTML Unescaping, Search Engine Roundtable](https://www.seroundtable.com/json-ld-extraction-googlebot-41921.html)
- [RFC 8259, section 7 (Strings)](https://datatracker.ietf.org/doc/html/rfc8259#section-7)