Google JSON-LD Escaping: Test the Value That Reaches the Parser

A structured-data field can be correct in the CMS and wrong by the time Google extracts it. On August 21, 2026, Google Search Central said its JSON-LD extraction now applies one pass of HTML unescaping. Sites that depended on repeated cleanup of double-escaped entities need to fix the output.

This is a parser-correctness change, not a new ranking factor. It affects the value Google can read from a JSON-LD script. The practical job is narrow: inspect the delivered block, parse it as JSON, compare the decoded values with the approved page facts, repair the generator, and verify the live release.

Do not start by replacing every ampersand on the site. Find the serialization layer that changed the value. A manual patch can hide the bug on one page while the template continues to damage product names, URLs, offer text, addresses, or identifiers elsewhere.

The schema type can be right while the value is wrong

Structured data has several layers. The application starts with a business fact. A JSON serializer encodes it. A template or CMS places the JSON inside HTML. A crawler extracts the script. A JSON parser turns the text back into data. Google's structured-data systems then evaluate whether the markup matches a supported feature and the visible page.

An error at any handoff can change the result. The schema vocabulary may still say Organization and the required fields may still be present. But a name delivered as Research & Strategy can remain encoded after one unescape instead of becoming the intended Research & Strategy.

That is why “schema present” is not an acceptance test. The test is whether the live script is valid JSON and whether its parsed values still mean what the business approved.

What Google confirmed on August 21

Google Search Central said it changed JSON-LD extraction to apply a single pass of HTML unescaping. The post named double-escaped entities such as an encoded ampersand and numeric character reference, and advised sites to use standard JSON escapes or Unicode hexadecimal escapes such as \u0026.

RFC 8259 defines JSON strings and the characters that must be escaped: quotation marks, reverse solidus, and control characters. Other Unicode characters can appear directly or as Unicode escape sequences. HTML entity encoding is a different layer. Treating HTML entities as a substitute for JSON string escaping creates ambiguity between the HTML delivery step and the JSON value.

Google's standing documentation still applies. JSON-LD is the recommended format for many implementations, the markup should be valid and match visible content, and teams should use the Rich Results Test during development plus Search Console reporting after deployment. Valid markup can make a page eligible for a supported appearance; it does not guarantee that appearance or change normal ranking eligibility by itself.

Inspect three representations of the same field

Use one value that contains an ampersand, quotation mark, backslash, line break, accented character, or non-Latin text. Then compare it at three points:

1. Approved value: the fact stored or approved by the business, such as Research & Strategy.
2. Delivered script text: the content inside the live <script type="application/ld+json"> block.
3. Parsed value: what a standards-compliant JSON parser returns after reading that block.

The parsed value should match the approved value. If it still contains &, a numeric entity string, an extra backslash, or a broken Unicode sequence, the generator or delivery layer needs attention.

<!-- fragile: the delivered value depends on extra HTML-entity cleanup -->
{
  "@type": "Organization",
  "name": "Research &amp;amp; Strategy"
}

<!-- preferred: serialize the data as JSON -->
{
  "@type": "Organization",
  "name": "Research \u0026 Strategy"
}

The exact source representation can vary by framework. The invariant is the decoded result. Use one serializer for JSON, avoid running the serialized block through an HTML-escaping helper that changes its data, and test the final response rather than assuming the template preview matches production.

Run the test against the live response

A developer can begin with the browser console on the live page:

[...document.querySelectorAll('script[type="application/ld+json"]')]
  .map((node, index) => {
    try {
      return { index, valid: true, value: JSON.parse(node.textContent || '') };
    } catch {
      return { index, valid: false };
    }
  });

This tells you whether each current DOM block parses. It does not prove that every value is accurate or that the server response took the same path, so inspect View Source or the raw HTTP response as well. Search for suspicious entity strings inside JSON-LD, then compare the parsed name, URL, identifier, address, description, image, and offer fields with the visible page and approved fact packet.

Next, use Google's Rich Results Test for supported feature requirements. After release, use URL Inspection where appropriate and watch the relevant Search Console rich-result report. A validator can confirm syntax and feature fields; it cannot approve the business fact or promise display.

Fix the generator, then add a regression case

The repair belongs as close to the serializer as possible. Build the JSON object from typed application data, serialize it once, place it in the script without a second HTML-entity conversion, and preserve any framework-specific safety escaping needed to prevent the script from terminating early. Safety escaping and data corruption are different problems; test both.

Add a fixture that contains:

• an ampersand in a business or product name;
• a quotation mark and backslash in descriptive text;
• accented and non-Latin characters;
• a URL with a query string;
• text containing a less-than sign or a sequence that could close a script element.

The automated test should extract every JSON-LD block from the built page, parse it, and assert that the decoded values equal the fixture. That catches both invalid JSON and valid JSON carrying the wrong string.

Assign the work to the layer that owns the error

The content owner approves the business facts and visible copy. Engineering owns serialization, safe embedding, templates, and regression tests. SEO verifies feature requirements, page eligibility, visible-content alignment, and Search Console follow-up. A CMS or plugin owner checks whether an update introduced the second encoding pass.

Changing a schema type, adding more properties, or rewriting visible copy will not repair a damaged string. Likewise, engineering can make the JSON parse without knowing whether the company name, service area, price, or author is true. Both checks are required.

What MAXUOD would deliver for this issue

For a focused technical SEO review, MAXUOD would inventory the JSON-LD templates on priority pages, capture the live response, parse each block, compare important values with visible content and the approved business packet, identify the escaping layer, and give engineering a small failing fixture plus acceptance checks.

After the fix, we would verify the built and live pages, record the release date, and monitor the relevant Search Console state without calling eligibility a result. A self-service check is enough when the team can inspect the serializer and deploy safely. A scoped audit helps when several plugins, templates, locales, or commerce fields generate overlapping markup.

The stopping rule is simple

No change is needed when the live JSON-LD parses, the decoded values match the approved facts, supported feature requirements are met, and the markup reflects visible content. Monitor it through normal release tests.

Repair the generation path when a decoded value is wrong. Then stop. This parser update is a reason to improve delivery correctness, not permission to add unsupported schema, duplicate markup, or a new promise about rankings.

Technical note: Google and RFC guidance was checked on August 22, 2026. Structured-data features and parser behavior can change. Correct markup does not guarantee a rich result, ranking, click, AI citation, or enquiry.