Direct answer: Paste JSON-LD or a full HTML block and the tool does four things locally: extracts every application/ld+json block and parses it; flattens arrays and @graph; checks required fields for 13 common @type values; and compares name/headline with the visible text you paste. It makes no requests, does not crawl, and does not promise rich results.
In our own scans, structured data is the thinnest layer: 5 of 25 analysable homepages carried JSON-LD, 1 of 13 product pages, and 0 of 20 contact pages used ContactPage. "Is it there" is only the first question. The second — "does it work once added" — has almost no tooling and is usually checked by reading source by hand.
Does it parse?
Are @graph nodes counted?
Are the required fields for this @type present?
Does the name appear on the page?
The tool: paste → check
| # | @type | Name | In visible text | Issues |
|---|
With no visible text, consistency is marked "not checked"; duplicate @id and missing recommended fields are warnings, not blockers.
In the default sample the Organization is complete and the Product is missing offers, so you see one error and a few suggestions; both names appear in the visible text, so both rows show "found". Delete the product name from the text and it flips to "not found" with a warning.
Rules
| @type | Required (error) | Recommended (warning) |
|---|---|---|
| Organization | name, url | logo, sameAs, address |
| LocalBusiness | name, address | telephone, url |
| Product | name + one of offers/review/aggregateRating | — |
| FAQPage | mainEntity (array) | question name + acceptedAnswer.text per item |
| BreadcrumbList | itemListElement | position, name/item per item |
| BlogPosting / NewsArticle / Article | headline, author, datePublished | image |
| WebSite / WebPage / ContactPage | url (WebSite also needs name) | name |
| Person | name | — |
These required sets are this tool's rule of thumb, not a schema.org validity test; other @types are still parsed and text-checked with a "no built-in rule" note.
Five common failures
- Parse failure. Trailing commas, single quotes, comments and BOMs all break
JSON.parse; the page looks fine while the whole block is dead. - @graph not flattened. Many sites wrap nodes in
@graph; reading only the top-level@typeyields zero nodes. - Duplicate @id. The same entity declared in several blocks with different fields leaves no clear source of truth.
- Missing key fields. A Product with only a name, or a FAQPage whose mainEntity is not an array: syntactically fine, but no result.
- Markup that does not match the page. Names, prices or ratings that are not visible; consistency checking is the cheapest screen.
Boundaries
- No fetching: it only analyses pasted text and does not know the live output.
- Not a full validator: schema.org inheritance is not modelled, and nested nodes (e.g. inside
publisher) are not checked. - No rich-result guarantee: passing syntax and fields is only a candidate condition; display is up to the search engine.
- Names only: price, rating and dates need more context and are left to manual review.
Tests and recalculation
The logic lives in js/jsonld-check.js (no dependencies, no network); scripts/test_jsonld_check.js covers 60 assertions: extraction, arrays and @graph, parse errors, the 13 type rules, FAQ/breadcrumb structure, duplicate @id, text normalisation and matching, unknown types, empty input and the English locale. Run:
node scripts/test_jsonld_check.js
Related: the 12 acceptance clauses (item 5 is structured data), the evidence-pack builder, the 30-site scan (JSON-LD 5/25) and the 15 product pages (JSON-LD 1/13).
Sources and definitions
- schema.org types and properties: schema.org.
- JSON syntax: RFC 8259: rfc-editor.org.
- Organisation details in the sample come from this site's public pages; the product name only demonstrates a missing field and is not a product claim.