In a previous experiment, I tested how different content structures affect how models interpret product pages. The conclusions were relatively clear:
- Structure improves clarity
- Explicit context improves reasoning
- HTML alone has limited impact
After sharing those results, a colleague, Cyrus Grimes, suggested extending the experiment:
What happens if we add JSON?
Not visible content. Not formatting. Structured data embedded directly in the page.
So this follow-up experiment focuses on one question:
Does JSON change how LLMs understand product pages?
Hypotheses
This test was built around three hypotheses.
1. JSON improves extraction
Structured data should help models retrieve specifications and key attributes more accurately and consistently.
2. JSON may compensate for missing context
If key information is encoded in JSON, models may rely less on explicit natural language.
3. JSON will not replace explicit meaning
Even with structured data, models will still depend on clear relationships and context written in natural language.
Methodology
The setup builds directly on that experiment, but introduces one new variable: structured data (JSON).
Same product (WIKA A-10 pressure transmitter), prompts and evaluation framework.
The only change is the introduction of JSON, creating two additional variants
- B_html_JSON: Structured content (sections, bullet points, separated specs) + JSON
- C_html_JSON: Structured + explicit context (clear relationships and constraints) + JSON
These were tested across:
Using the same four prompts:
- Product summary
- Technical specification extraction
- Use cases and constraints
- Decision-making information
Outputs were evaluated using the same four dimensions:
- Accuracy
- Completeness
- Clarity
- Constraint awareness
All inputs and outputs are uploaded to GitHub and accessible publicly.
Key Findings
1. JSON improves structure and completeness
Adding JSON consistently improved accuracy, completeness and output organisation.
This was most visible in Version B.
Structured content + JSON often produced results closer to Version C, even without explicit wording.
JSON acts as a clean signal layer that helps models retrieve and organise information more reliably.
2. JSON partially compensates for missing context
One of the more interesting outcomes was that Version B with JSON sometimes approached the performance of Version C.
This was noticeable in product summaries and use cases and constraints (in some models)
Models can partially use structured data to recover part of the meaning that is not clearly expressed in the text.
The difference becomes clearer when comparing structured content with and without JSON.
In the JSON version (right in the image above), the model restructures the same information into more explicit relationships. Instead of listing features, it starts to connect them (for example, pressure → signal → system behaviour), adds functional framing, and introduces clearer grouping of concepts.
The underlying data is the same, but the interpretation becomes more organised and closer to a usable explanation.
3. JSON does not replace explicit context
Even when JSON improves performance, Version C remains more consistent. But this suggests that not all context needs to be forced into visible content.
This is especially clear in constraint handling, conditional behaviour and interpretation tasks.
Structured data helps surface information but it does not fully explain relationships.
Explicit meaning still matters.
4. Impact varies significantly by model
The effect of JSON is not consistent across models.
- ChatGPT was already strong, with JSON mainly improving consistency
- Google showed clearer improvements in completeness and constraint awareness
- Claude improved in structured tasks, but less consistently in summaries
More structure-sensitive models benefit more from JSON.
5. JSON has little impact on simple tasks
For specification extraction, performance was already high across all versions.
Adding JSON did not significantly change results.
When the task is straightforward, models do not need additional structure.
6. JSON helps surface constraints when they are encoded
In the previous experiment, constraints were only reliably captured in Version C.
With JSON, constraint awareness improved in some Version B variants, especially when constraints were explicitly defined in the data
This suggests that structured data can make constraints more visible. However, models do not always apply them correctly in reasoning.
A few examples make this more visible.
1. Measuring range
- B_html: Range: 0.05 bar up to 1,000+ bar
- B_html + JSON: Measuring range: 0.05 bar (min) to 1,000+ bar (max)
The information is the same, but the JSON version expresses it as clear boundaries. The model is more likely to treat this as a defined constraint.
2. Ingress protection
- B_html: IP rating: IP65 or IP67
- B_html + JSON: Ingress protection: IP65 or IP67 (depends on connection type)
The dependency becomes explicit. Instead of a fixed attribute, the model can link protection level to configuration.
3. Accuracy
- B_html: Improved non-linearity: ±0.25% of span (select configs)
- B_html + JSON: Higher accuracy option: down to ±0.25% non-linearity (select configurations)
The model is more likely to interpret this as a conditional capability, not a default specification.
7. HTML + JSON behaves differently than HTML alone
In the previous test, HTML alone had mixed results.
In this experiment HTML + JSON produced clear improvements and results were more consistent across tasks.
The difference is that HTML provides structure but JSON provides meaning.
Markup without semantic content has limited impact but structured data adds a stronger signal.
8. Structured data can trigger enrichment behaviour
One unexpected behaviour appeared again.
In some structured HTML versions with JSON, ChatGPT introduced information not present in the input. Also, Gemini is introducing external sources. A behaviour I didn’t see in the previous experiment.
This suggests that once the product becomes clearly identifiable, the model recognises it as an entity and connects it to prior knowledge.
At that point, the task shifts from summarising to enriching.
Well-structured content does not just improve interpretation. It can change how the model behaves.
Practical Implications
For ecommerce and SEO, the implications are clear.
- Structured data helps, but it is not enough on its own. JSON improves extraction and coverage, but does not replace clear content.
- Explicit relationships are still required. If constraints or dependencies matter, they need to be written clearly.
- Combining layers is the most reliable approach. Structure, explicit context, and structured data work best together.
Product pages should not only be indexable. They should be interpretable.
Limitations
This is a controlled test using a single product with a limited number of prompts, and manual evaluation.
No statistical analysis was performed, and model behaviour may vary depending on context.
The goal is to observe patterns, not define universal rules.
Conclusion
Adding JSON improves how LLMs extract and organise information. It can partially compensate for missing context, but it does not replace explicit meaning.
The strongest results come from combining structured content, clear semantic relationships and structured data
However, this experiment suggests something practical.
If key specifications and constraints are encoded in JSON, it may reduce the need to write everything explicitly in the visible content, as in Version C.
| Setup | Strength |
|---|---|
| B | Structure |
| B + JSON | Structure + extraction |
| C | Reasoning |
| C + JSON | Most robust |
This creates a more balanced approach:
- Natural, user-friendly content for humans
- Structured data to support machine interpretation
Instead of forcing content to be overly explicit or unnatural, JSON can carry part of that burden.
Product pages are evolving from documents to inputs and how information is structured, not just written, increasingly defines how it is understood.
