Google Now Unescapes JSON-LD Once: Find Double-Escaped Schema

What Google changed

Google Search Central announced the parser change on August 21, 2026. Search Engine Roundtable preserved the announcement: Google now applies a single HTML-unescape pass when extracting JSON-LD and recommends standard JSON escapes or Unicode hexadecimal escapes such as \u0026.

Google’s Gary Illyes pointed developers to RFC 8259 section 7. The JSON standard defines escaping for quotation marks, reverse solidus characters, control characters, and Unicode sequences. HTML entities are not JSON string escapes.

This is a parser-behavior change, not a documented ranking-system update. Google did not say every site has bad markup or that a double-escaped value always removes a rich result.

Valid JSON can still carry the wrong value

A JSON parser can accept a string containing the literal characters &. That makes the object syntactically valid, but it may not contain the publisher’s intended organization name, product title, or description.

The exact output depends on the input and extraction layer. The audit should preserve the raw source, parsed JSON, and value shown by Google’s testing tools. Do not infer the result from a CMS editor preview.

Audit the template layer

1. Choose representative Article, Product, Review, Organization, Event, and other supported templates actually used by the site.
2. View the raw server response and extract each application/ld+json block.
3. Parse the JSON and compare important string values with the visible page and source database.
4. Search for named and numeric HTML entities, then trace where each value was escaped.
5. Run the URL through Google’s Rich Results Test and inspect the extracted fields, not only the eligibility summary.
6. Fix the serializer or escaping helper that repeats across the template. Avoid one-page content patches.
7. Add regression fixtures containing ampersands, quotation marks, Unicode symbols, and non-Latin text.

Our Google-supported schema guide helps prioritize types that can affect a current Search feature. The broader Schema.org versus Google rich-results explainer keeps vocabulary support separate from Google eligibility.

Fix the serializer, not the symptom

Generate a native data structure and let one JSON serializer produce the script value. Do not build JSON by concatenating escaped HTML strings. An ampersand can appear directly in a JSON string; \u0026 is the Unicode alternative Google cited.

After the fix, compare before and after raw source, parse both versions, and inspect the rendered structured-data values. Keep the change small enough to roll back. A serializer change can affect every page using the template.

Google’s structured-data policies still apply. Correct syntax and values make markup eligible for processing; they do not guarantee a rich result, ranking, or click.

What not to claim

Do not report that Google “stopped reading schema,” that every HTML entity breaks JSON-LD, or that the parser change caused a ranking decline. A single HTML-unescape pass still has different results from no unescaping, and properly serialized JSON remains the target.

If a rich result changes after a fix, record the affected URL, structured-data type, inspected values, recrawl timing, and Search appearance. That creates a testable observation. It still does not prove that escaping was the only ranking or display factor.

Sources, method, and limits

Sources: Google Search Central’s August 21 announcement as preserved by Search Engine Roundtable, RFC 8259, and Google’s structured-data policies.

Method: We separated syntax validity, intended value, extracted value, and Search-feature eligibility, then converted the change into a template-level test sequence.

Limits: SearchEngineAnswer has not measured a rich-result loss caused by this change. Google has not published prevalence data or a list of affected CMS plugins.