What it means
A page may describe a product in ordinary prose while also labeling its name, offer, or organization in structured data. JSON-LD is one format for those labels, commonly stored in a dedicated script block. It helps supported systems interpret declared information without relying entirely on the page's visual layout.
The declaration should describe the actual page. Useful implementation starts with information you maintain accurately, rather than adding as many types and properties as possible. Google supports several structured-data formats and has separate requirements for particular search features; this checker concentrates on JSON-LD detection.
Hypothetical example: a product page with a stale price
Imagine a fictional desk lamp page displaying a price of 45 currency units. Its JSON-LD still declares 39 because a template update changed only the visible price. BLURSOR can report structured data detected even though this disagreement needs correcting.
If JSON-LD is absent from the initial response but present in the browser snapshot, a script may have added it. That difference tells you where it was observed. It does not establish whether a particular service processed or accepted it.
| Observation | What it establishes | What still needs checking |
|---|---|---|
| JSON-LD detected | A recognized script block was captured | Valid syntax and relevant properties |
| Product type detected | A type name was found | Whether it accurately describes this page |
| Browser only | Detected in the browser representation | How the intended consuming service handles it |
How BLURSOR measures it
In the report: Structured data before JavaScript · Structured data after JavaScript
BLURSOR looks for script blocks with type application/ld+json in each available HTML representation. It can collect simple string-valued @type entries from those blocks. This is a lightweight detection step, not a JSON parser or a structured-data validator.
The comparison reports detected or not detected for each usable capture. Type names appear where they were recorded; a detected block with no listed type is not necessarily missing all types. If a capture is unavailable, the checker cannot turn that uncertainty into an absence finding.
What to do next
- Check that declared names, prices, availability, dates, and relationships agree with information customers can read.
- Use Google's Rich Results Test when checking a supported Google search feature, alongside its feature-specific requirements.
- Ask whoever maintains the website to update visible content and structured data together, then verify the published response.
What it cannot tell you
- Not detected means no recognized JSON-LD block was found in that capture. Other formats, including Microdata and RDFa, are outside this measurement.
- Presence does not prove valid markup, rich-result eligibility, factual correctness, indexing, or AI citation.
Sources and further reading
The definitions below describe the underlying concepts. The measurement section describes BLURSOR’s own checks.