On 25 August 2026 Gary Illyes wrote on Bluesky: “Google’s crawlers don’t parse JSON, they just download things. Parsing anything is done by, for example, indexing in case of Search.”
Someone in the replies asked the question I would have asked, which is whether that also covers schema written as JSON-LD. Illyes answered with one word: “yes”.
That is a small statement about internal architecture, and it would be easy to file it as trivia. It stops being trivia the moment you try to work out why a structured data problem left no trace anywhere in Search Console until rich results quietly stopped appearing.
Does Googlebot read my structured data?
Not in the sense most people mean. Google’s own in-depth guide to how Search works splits the job into three stages, and that split is the whole point here. Crawling downloads text, images and videos. Indexing analyses what was downloaded and stores it. Serving answers the query.
So the crawler is a fetcher. It pulls the bytes of your page, including the <script type="application/ld+json"> block sitting in the head, and it does not care whether the JSON inside that block is valid. The thing that cares is the indexer, and the indexer runs later, separately, on Google’s schedule rather than yours.
Illyes was also asked whether Merchant Center uses the same parser. His answer was hedged, and it is worth quoting as hedged: “we generally use shared infrastructure so we don’t have to reinvent the wheel all the time. I’m very certain MC uses the same parser, but I never worked with that team.” Very certain is not confirmed. I would not rebuild a feed on it, but it is a reasonable working assumption that a malformed feed value fails in the same place, at processing rather than at fetch.
Stages as described in Google's in-depth guide to how Search works. The placement of the failure follows from the 25 August statement that crawlers download and indexing parses.
Why this matters more than it sounds
Every crawl-side signal you have will tell you the page is fine, because from the crawler’s point of view it is fine. The bytes arrived. The status was 200. Nothing in the crawl stats report will ever go red because an @type was misspelled or a stray quote closed an object early.
I hit the practical version of this last week, from the other direction. When Google changed how it unescapes JSON-LD, the failure had exactly this shape: pages that served perfectly, crawled perfectly, and produced markup the indexer could no longer read. Nothing anywhere in Search Console said so.
That is why I stopped treating structured data as something to spot-check and wrote a check into this site’s build. It walks every HTML file in the built output, pulls out every application/ld+json block, and fails the build if any block is not valid JSON or carries HTML entities inside it. On today’s build that is 488 blocks across 131 files, all parsing, zero entities. It costs about a second, and it moves the check from Google’s stage two back onto my own machine, before the page exists.
What to check on your own site
Three things, in the order that catches the most.
Validate the built output, not the source. The template can be correct and the rendered page wrong: an escaping filter, a caching plugin, a minifier, or a page builder that helpfully encodes your quotes. Fetch the live URL and read the script block out of the response, not out of your editor.
Use the live test in URL Inspection. The live test fetches and processes the page on demand, so it behaves far more like the indexer than any crawl report does. If the live test sees your markup and the indexed version does not, you are probably looking at a change Google has not reprocessed yet rather than a syntax error.
Do not read a 200 as an all clear. This is the habit worth changing. A page returning 200 with clean logs tells you the crawl worked. It tells you nothing at all about whether the indexer could use what it downloaded. Those are different systems and they fail on different days, which is the same reason a page can be fetched successfully and still sit in crawled, currently not indexed for weeks.
If you want the map of which Search Console states report crawl problems and which report indexing problems, every Search Console indexing status lays them out side by side. Structured data errors appear in neither of those lists, which is more or less the point of this post.
What I am not claiming
Illyes described what the crawlers do. He did not announce a change to what they do, and I have no evidence Google altered anything this week. Read it as confirmation of an architecture, not as news you need to react to.
The Merchant Center part stays labelled as what it is: an educated guess from someone who said outright that he never worked with that team.
The adjacent claim, that valid markup is what gets you cited by AI systems, is worth the same scepticism. Does schema markup help with AI search checks the documentation of Google, OpenAI, Anthropic and Perplexity for a sentence supporting it.
Sources
- Gary Illyes on Bluesky, 25 August 2026: “Google’s crawlers don’t parse JSON, they just download things”, plus the one-word “yes” confirming it covers JSON-LD and the Merchant Center reply in the same thread.
- Google Search Central, In-depth guide to how Google Search works, for the crawling, indexing and serving split.
- Google Search Central, URL Inspection tool, for the difference between the indexed version and the live test.
- Block and file counts are from this site’s own JSON-LD build check, run on 26 August 2026.