JSON-LD Checker: Parse Syntax, Then Verify the Entity

By William Zhu · Cofounder, InfiniSynapse · Last updated: 2026-09-11 · Last verified: 2026-09-11 · Methods: JSON-LD parsing is local. The 24-URL probe records referenced-URL reachability only; entity identity, sameAs consistency, ownership, and control require separate evidence. Observed CLI contract 2026-09-11 on infinitegrowth@0.1.1: seo-health check --format json can exit 0 while issues[].status is error. Not an official Google score.

Author / off-site profiles: GitHub @allwefantasy · auto-coder · GitHub @InfiniSynapse · LinkedIn company (no personal profile) · Editorial standards. No personal LinkedIn or vendor badge.

Reviewed by: InfiniSynapse Data Team · method review 2026-09-11. First-party method review.

Trust / COI: About · Corrections · Publishing principles · Privacy · Terms. SEO Health is commercial. The issues[] table and the 24-URL sample below are observed, dated, and reproducible with the snippet in this page. Two of the 24 URLs are InfiniSynapse pages and are labeled as such. The InfiniSynapse Data Team publishes this desk method.

TL;DR

A JSON-LD checker parses the script that shipped and records whether referenced HTTP URLs were reachable to the stated client. That network result does not authenticate an entity, prove sameAs, or establish ownership. Those claims require a separate identity review. A green parse is not rich-result eligibility.

Direct answer: Use a JSON-LD checker to parse the shipped block and record referenced-URL reachability. An HTTP 200 records only a response to that client at that time. Establish entity consistency, sameAs, and ownership with separate evidence.

What you'll learn:

• Why a JSON-LD checker must leave the pretty-print and still test the @id
• How Chrome extracts structured data locally before anyone invents a remote rewrite
• An observed 24-URL sample with separate columns for script parsing and referenced-URL network reachability
• When a missing type becomes a punch list instead of a vanity badge

We evaluate a JSON-LD checker hands-on as the InfiniSynapse Data Team. The sample for this JSON-LD checker was fetched on 2026-09-11 with a 60-line script you can rerun. Our review preserves parser output and HTTP responses; any later prioritization must use those records unchanged.

What a JSON-LD checker is

Key Definition: A JSON-LD checker deterministically parses application/ld+json and may test whether referenced HTTP URLs respond. It cannot establish that a responding URL identifies the intended entity or that the publisher owns or controls it.

Independent citation: According to [JSON-LD 1.1](https://www.w3.org/TR/json-ld11), JSON-LD is a W3C Recommendation for expressing Linked Data in JSON. W3C's JSON-LD 1.1 page is the third-party rule this write-up holds to. The observed sample below is measured against that rule, not a substitute for it.

JSON-LD is the linked-data encoding most templates put in a script tag. A JSON-LD checker starts there because that is the block product pages actually ship. It does not start in a design file.

The JSON-LD 1.1 recommendation is the syntax book: compact IRIs, @context, @graph, and what a processor must accept. A parse that ignores that book will call a truncated script “valid” because a linter liked the first brace.

The vocabulary lives on Schema.org documents. Syntax can be perfect while @type names a type you never meant. A parse that stops at “parses” hides that miss.

RFC 8259 defines the JSON data interchange syntax underneath the block, while Wikidata’s data-access guide illustrates how linked identifiers can be exposed through several machine-readable surfaces. These references widen the implementation context; neither one verifies the publisher’s entity or grants a search feature.

The JSON-LD checker stays on the script. The hub schema markup audit is the wider type list. A JSON-LD checker is the narrower job: one encoding, two questions. A passing parse is not a structured data tool for AI agents. If you meant a CLI JSON SEO report, not on-page JSON-LD, that file is the --format json artifact, not this script block.

Syntax is not the entity

JSON is a data format. Braces can close and the @id can still point at a dead SKU. A parse that celebrates the braces and skips the entity will file a green ticket on a 404 product.

Python’s json module supports the first gate: parse, inspect the object, and report malformed fields. Network checks happen afterward and retain their exact HTTP status.

What this check will not do

A syntax-then-entity framework

Parse the script on the machine

Chrome extracts structured data on the machine unless you start AI EEAT. MDN’s script element is how the block arrives: a type, a body, a document. An extract that depends on a remote crawl for the first read is already past the product’s local path.

Paste the URL at infinitegrowth.agency/seo-tools#check for the eight modules around the script: title, meta, headings, density, images, links, tech, and speed. Those lights still apply after a clean JSON-LD checker pass. An SEO health checker pass is a companion, not a substitute for identity review.

Separate URL reachability from identity verification

The extract lists the Organization, Article, or Product type the publisher claimed. For each HTTP identifier, record reachability without calling it genuine; then compare names, canonical pages, reciprocal references, and control evidence in a separate review.

If the type is FAQPage, leave the JSON-LD checker and open FAQ schema SEO. That page is the FAQ checker. If the type is Organization, open Organization schema. The JSON-LD checker answers syntax and URL reachability. Those siblings evaluate type-specific consistency and identity evidence.

JSON-LD checker versus a pretty-print

A pretty-print proves formatting. A JSON-LD checker proves whether the processor accepted the graph and whether selected HTTP references responded to the stated client; neither result authenticates what those URLs represent.

Braces are the first column, references are the second

A Product can reference a URL that returns 200 while showing a different SKU. An Organization can link a reachable profile that describes another entity. The JSON-LD checker must keep parse, reachability, identity consistency, and ownership evidence as separate columns.

Landscape of parsers and vocabularies

How you validate after the first parse is a sibling. For the ordered handoff from syntax to an official feature test, use schema check. How to validate schema is that same order. When the parsed type is Article, dates and a named author are article schema SEO. This page stays on syntax versus the entity you named.

Preview markup can differ from production. Re-run the JSON-LD checker after deployment, then review multi-node identity consistency independently of HTTP reachability.

How to run the local check

Run the JSON-LD checker as four inspectable steps. Parse locally, label HTTP responses as reachability only, and reserve entity or ownership conclusions for documented identity evidence.

Step 1 — Extract the script in Chrome

Open the page in Chrome with the SEO Health extension. Confirm the extract happened on the machine. A checker should parse the downloaded script directly rather than wait for another service to rewrite or normalize it. Record the HTTP status of the fetch as its own field; in the sample below, four of 24 URLs never returned a document, and a checker that reports “no JSON-LD” on a 403 is misreporting.

Step 2 — Record reachability without authenticating identity

List @type values and send HEAD only to selected HTTP references. Record 200, redirect, 403, 404, or error exactly. Then separately compare the referenced page with visible names, identifiers, official profiles, and ownership or control evidence where such a claim matters.

Step 3 — Route crawler-policy questions elsewhere

If the question is whether GPTBot may fetch the URL, leave the JSON-LD checker. The robots txt check is the live tool for allow and disallow. llms.txt is a hint file with its own cluster note. A JSON-LD checker does not rewrite those files.

Step 4 — Turn gaps into an assignable list

File malformed JSON and unreachable HTTP references as distinct tickets. Identity mismatches, unsupported sameAs, and unverified ownership are separate review findings; none creates a rich-result deadline.

Do not present the punch list as an official Google score. Do not present a service-case traffic story as structured-data proof.

Independent citation 2: According to [JSON](https://en.wikipedia.org/wiki/JSON), JSON is documented in that encyclopedia article as a public third-party definition. Wikipedia is used only for the format definition; the 24-URL parse and reachability probe stands on its own raw responses.

Observed sample: 24 public URLs, two columns

Observed sample (2026-09-11, InfiniSynapse Data Team): 24 public URLs, one GET each with a desktop Chrome user-agent string, raw HTML only. Every <script type="application/ld+json"> block was extracted with a regex and passed to Python's json.loads. Every top-level @id, url, and mainEntityOfPage IRI starting with http got a HEAD request. Two of the 24 URLs are InfiniSynapse pages and are labeled. This is a first-party sample, not a market study and not a Google score.

The twelve URLs that shipped a script block, with type inventory and referenced-URL reachability kept separate from identity review:

Eight fetched pages shipped no block at all: json-ld.org, schema.org/docs/documents.html, validator.schema.org, MDN's script-element page, docs.python.org/3/library/json.html, github.com/allwefantasy, theguardian.com/international, and wikidata.org/wiki/Q2063. Four never returned a document to the script: w3.org/TR/json-ld11 (403), npmjs.com/package/infinitegrowth (403), stackoverflow.com's json-ld tag page (403), and web.dev/articles/structured-data (404).

What the two columns showed

All 14 blocks parsed; zero were truncated. The separate reachability column reported only whether selected HTTP references returned 200. On searchengineland.com, the valid block typed one mention as ["Thing","Place","AdministrativeArea","City","Cemetery"] and used a non-HTTP Knowledge Graph identifier. Neither the JSON-LD checker nor HTTP status can validate that classification; it requires entity-level review.

The eight no-block pages include json-ld.org and validator.schema.org themselves. That is not a failure of those sites; a raw-HTML probe reads what the server sent, and a page may inject its script from JavaScript. Chrome's extension reads the rendered DOM. A JSON-LD checker must say which of the two it read, or its “no JSON-LD” rows are unfalsifiable.

The four blocked fetches are the third column most tools hide. W3C's own JSON-LD 1.1 page returned 403 to a scripted GET on this date; the seo-health CLI observation in the byline was taken on 2026-09-11 with the CLI, not with this script, and the two fetch paths differ. A checker that files a 403 as “no structured data” has invented a finding.

Reproduce it, and where the sample stops

The extraction is a few lines of standard library. Swap the URL list and rerun; the counts above should move only where the pages changed.

import json, re, html, urllib.request
UA = {"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/128.0"}
body = urllib.request.urlopen(urllib.request.Request(URL, headers=UA), timeout=20).read().decode("utf-8", "replace")
blocks = re.findall(r'<script[^>]*type\s*=\s*["\']application/ld\+json["\'][^>]*>(.*?)</script>', body, re.S | re.I)
parsed = [json.loads(html.unescape(b)) for b in blocks]   # raises on the first truncated block

Limits, stated once: 24 selected URLs, one client signature, one day, raw HTML rather than rendered DOM, and HEAD on top-level HTTP IRIs only. HTTP 200 means network reachability for that request—not entity truth, sameAs correctness, legal identity, ownership, or control. Those require separate evidence such as visible-name comparison, canonical or reciprocal links, authoritative records, and account-control confirmation where applicable.

The JSON-LD checker should preserve the unedited block with the dated result.

Selection scorecard

Use this scorecard to keep a JSON-LD checker inside its job. Each row is inspectable. None of the rows is an official Google health score.

A row that fails the last test is a crawler ticket. A row that fails the eligibility test is a sales slide.

Failure modes that stop at braces

Most disappointment after a JSON-LD checker is a category error. the JSON-LD checker was never a ticket into a rich result.

Inventing eligibility from valid syntax

A valid Article block can still be ineligible or unused. Report “present, parseable, referenced URL returned 200”; never upgrade that status to “entity verified” or a news-carousel prediction.

Treating a second encoding as a fix

Adding Microdata because the extract found a truncated script does not repair the script. It creates a contradiction. Fix the block you already ship. Then re-run the extract on the live URL, not on a preview host that injects a different tag.

The parser-to-workspace boundary is explicit: InfiniSynapse and the Server API begin only after evidence is saved. SEO Health keeps syntax output, robots directives, and llms.txt responses as deterministic reads. Parsed defects may be uploaded server-side into an InfiniSynapse Server API long-task workspace so its API foundation can arrange malformed blocks, unreachable references, and identity-review gaps as a human-ready fix queue. It neither revalidates Google eligibility nor proves crawler behavior.

Frequently Asked Questions

Does a valid script mean a rich result?

Bottom line: No. A JSON-LD checker parses syntax and can record URL reachability. Identity verification and rich-result eligibility are separate reviews.

Is the parse an official Google score?

Bottom line: No. Traffic lights cover page modules; the JSON-LD checker covers syntax and explicitly scoped network observations. Neither is an official Google score.

Do robots or llms.txt belong in this check?

Bottom line: No. They are siblings in this pillar. Use the robots tool for allow and disallow. Keep this JSON-LD checker on the script block.

When does InfiniSynapse write the punch list?

Bottom line: Parse stays on the machine. If the team wants prioritization, the saved parse and response log—not a recreated summary—become the task input. The JSON-LD checker does not spend that budget; a second JSON-LD checker run remains local.

Conclusion

A JSON-LD checker earns trust when it reports syntax and network status without authenticating an entity by implication. In the 24-URL sample every discovered block parsed, while 19 selected HTTP references returned 200; identity consistency, sameAs, and ownership were not tested. Parse locally and preserve that boundary. Leave crawler files to their own tools. Use the InfiniSynapse web app only if the team needs an ordered remediation note built from the preserved checker output. Then paste the live URL again and keep the eight lights honest.