August 21, 2026

Google's JSON-LD parser changed: what we checked

Google's JSON-LD parser changed: what we checked

At 5:04 a.m. Eastern time on August 21, 2026, Google Search Central published a LinkedIn notice about a change to Google's JSON-LD extraction. This was a Search Central technical announcement, not an announcement from the Google Search Console product.

Google now applies one pass of HTML unescaping when it extracts JSON-LD. A value that was encoded twice, such as &, will no longer be repeatedly decoded until it becomes the intended &. Google advised site owners to use standard JSON or Unicode hexadecimal escapes such as \u0026 instead of relying on repeated HTML decoding. Google Search Central announced the parser behavior directly.

What this means in plain English

JSON-LD is a JSON-based format for linked data, commonly embedded in a page inside a <script type="application/ld+json"> element. For Google Search features, Google recommends JSON-LD in most cases because it keeps machine-readable data separate from visible HTML and is easier to manage across larger sites. Google explains its supported formats and JSON-LD recommendation, while the W3C JSON-LD recommendation defines the format.

Suppose the intended organization name is Research & Development. These JSON strings preserve that text:

"name": "Research & Development"

"name": "Research \u0026 Development"

An ampersand may appear directly in a JSON string, and a Unicode escape may represent it as \u0026; JSON requires quotation marks, reverse solidus characters, and control characters to be escaped, not ampersands. Section 7 of RFC 8259 defines JSON string and Unicode escape rules.

This version is the risk Google called out:

"name": "Research &amp;amp; Development"

After one HTML-unescape pass, &amp;amp; becomes &amp;, not the intended ampersand. A site that depended on multiple decoding passes can therefore send Google the wrong text even when a browser page looks normal. Google's notice identifies double-encoded named and numeric character references as affected patterns.

What we audited today

We audited every sitemap-discoverable URL across different partner sites where we maintain or review structured data. Every URL in the audit, more than a thousand in total, returned HTTP 200; hundreds of pages contained more than a thousand JSON-LD blocks. We found zero nested HTML entities matching the cases in Google's announcement.

The check performed five steps:

  1. Read each site's public sitemap, including child sitemap files.
  2. Fetch the HTML returned for every advertised URL.
  3. Extract every application/ld+json script.
  4. Parse each block with a standards-based JSON parser.
  5. Inspect every nested string value for double-escaped named and numeric HTML entities.

Those steps test both code and content. That distinction matters on content-managed sites because a template can be correct while an editor-entered value introduces an encoding problem later. Google likewise recommends testing structured data during development and monitoring it after deployment because templating or serving issues can break it later. Google's structured-data introduction describes that development and post-deployment validation workflow.

The crawl also surfaced a small number of ordinary JSON parsing failures unrelated to nested HTML entities. We separated those into remediation work rather than describing this scan as a universal structured-data all-clear.

We also added the same check as a local, on-demand regression script. It is not a continuous GitHub Actions workflow and uses zero GitHub Actions minutes; it can be rerun after code or content changes when a structured-data release warrants a full crawl.

Examples of JSON-LD we implement

The markup has to describe the content readers can actually find on that URL. Google requires it to represent the page's main content accurately rather than introduce information hidden from readers. Google's general structured-data guidelines define those quality requirements.

Local businesses

For multi-location businesses, we have implemented location-specific LocalBusiness objects on individual location pages, using supported facts such as the canonical location URL, address, hours, geographic coordinates, and price range. Google documents these properties for local business pages and may use them in business details shown in Search or Maps; complete and accurate data remains more important than filling every optional field. Google's LocalBusiness documentation lists the supported business details.

Products, offers, and product ratings

For ecommerce pages, we have implemented Product and Offer, adding AggregateRating only when the rating is specific to that product and visible on the page. Google says product structured data can make a page eligible for richer appearances that include price, availability, review ratings, shipping information, and other product details. Google's Product documentation describes those search appearances, and Google's review guidelines require marked-up ratings to be visible and tied to a specific item.

Organizations

We have implemented Organization data using the official name, URL, logo, and verified public profile relationships rather than blank or speculative values. Google says Organization markup can help it understand and disambiguate an organization, and that properties such as logo can influence visual elements in Search results and knowledge panels. Google's Organization documentation explains those uses.

Articles and breadcrumbs

On publication and professional-services sites, we have implemented Article or BlogPosting data for the headline, author, date, and representative image, plus BreadcrumbList data for the page's position in the site hierarchy. Google says Article markup can help it understand article details and show better title, image, and date information, while breadcrumb markup helps Google categorize a page in search results. Google documents Article structured data and Breadcrumb structured data.

The benefit, without overstating it

Correct structured data can clarify a page's meaning for Google and establish eligibility for supported enhanced search features. Eligibility is not a promise that a feature will appear; if Google applies a structured-data manual action, the consequence concerns rich-result eligibility rather than the page's ordinary web-search ranking. Google states both limitations in its general structured-data guidelines.

The same restraint applies to claims about AI-generated search answers. For AI Overviews and AI Mode, Google directs site owners back to ordinary Search requirements; it does not prescribe an AI-specific Schema.org vocabulary. Structured data should still agree with the visible page. Google's guidance for AI features states those requirements directly.

Our recommendation is therefore narrow: produce valid JSON-LD from accurate, visible content; use supported types where they describe the page; and test the rendered output whenever templates or content systems can change it. Today's parser change did not require a live rewrite across the audited partner sites, but it justified a complete rendered-site check and a repeatable regression tool.

Request a JSON-LD findings report

Want a clearer picture of the JSON-LD your site is serving? Let us know. We can crawl the public URLs listed in your sitemaps, parse the JSON-LD returned in the page HTML, and share a concise report of parsing failures, encoding problems, conflicting markup, and prioritized next steps.

Thank you for your time

If you have any questions or want to connect on anything that I wrote about above, please email me or book some time on my calendar. Any and all feedback is of course so appreciated.