JSON - The Silent Data Highway (LLM Ingestion) | LinkedIn

The framing in Joseph Mas's article is a good one: JSON is the silent infrastructure of machine consumption. Humans experience the web as rendered pages, but the systems that index, retrieve, summarise and cite that web increasingly operate on structured records. His central claim, that "structured data is no longer just SEO, it's the foundation of AI visibility", overstates the evidence in one direction while pointing at something real in another. Both halves are worth unpacking, because the practical advice that falls out is genuinely useful and the risk attached to one part of it is genuinely serious.

How JSON-LD actually reaches a machine

A JSON-LD block is not read the way body copy is read. It is extracted at crawl time and normalised into entity records: a thing, its type, its attributes, and its relationships to other things. That path has properties that plain prose does not.

• No inference step. A parser reading "ratingValue": 4.5 does not have to work out from a sentence whether 4.5 is a rating, a price or a version number. Ambiguity that costs a language model tokens and accuracy costs a JSON parser nothing.
• Stable identity. @id and sameAs let you declare that the entity on your page is the same entity referenced elsewhere. This is the part most sites skip and the part that does the most work for entity resolution.
• Survives summarisation. When a retrieval system compresses a page into a chunk, prose facts can be lost or garbled. Attributes extracted from markup are already atomic.
• Cheap and deterministic. Parsing is trivial compared with running a model over a document, which matters when the operation runs across the whole web repeatedly.

Where the claim needs tightening is the leap from "machines parse this efficiently" to "this is the foundation of AI visibility". Mas describes LLM Cards as "the direct ranking factor of machine-readable truth", and that phrase should be read as advocacy rather than documentation. There is no published confirmation from any major AI search provider that structured data is a ranking factor for generated answers. Google has been consistent for years that structured data drives rich result eligibility and entity understanding rather than a generic ranking boost, and nothing in the AI era has been announced to replace that position. Our summary of how AI engines choose sources covers what is actually observable about selection.

The honest version of the argument is still strong: structured data makes your facts cheap to extract, hard to misread and easy to attribute. That is a retrieval and grounding advantage, not a ranking lever, and it is worth doing on those terms alone.

The LLM Cards proposal, and how to implement it safely

Mas's proposal separates a human facing layer, built for readability and engagement, from a machine facing layer built for ingestion. He anticipates the obvious objection and rejects it directly, arguing that LLM Cards are not "shadow pages" or cloaking but an engineering pattern of "decoupled data delivery" at the data layer.

He is right that decoupling is not inherently deceptive. Every site with a JSON-LD block already serves a machine layer alongside a human one, and nobody calls that cloaking. Content APIs, feeds and structured endpoints are ordinary architecture. The distinction that matters is not whether you emit a machine layer, it is what is in it.

Google's structured data general guidelines are explicit that markup should represent the content of the page, and that you should not mark up content that is not visible to users. Google's spam policies separately define cloaking as presenting different content to users and search engines. Put those together and the safety test is a single question: if a human read your machine layer, would it describe the page they are looking at?

If you want to implement the useful core of this idea, do it as an enrichment of the page you already have rather than as a parallel truth. Concretely:

1. Model the entity properly. Give the primary entity a stable @id, and reference it consistently across templates rather than emitting disconnected blocks per page.
2. Fill in the attributes you already display but have never marked up: specifications, dates, authorship, prices, availability, ratings, relationships to other entities.
3. Use sameAs honestly to link to profiles you actually control or that genuinely describe the entity.
4. Keep the human page complete. If a fact is important enough to encode for machines, it is important enough to show. This also happens to be the version that survives any future policy tightening.
5. Validate continuously. Run the Rich Results Test and the Schema Markup Validator in your build, and treat a mismatch between markup and rendered content as a failing test.

The implementation mechanics, including how to structure @graph blocks and avoid the duplication traps, are covered in our guide to writing structured data with JSON-LD and schema @id.

Where this sits on the risk spectrum

It is worth being direct about why this proposal attracts criticism, because the criticism is not merely conservatism. Any pattern that optimises a machine facing layer independently of the human one creates a gradient. The first version describes the page faithfully. The second adds a few attributes that are "implied but not stated". The third adds claims the page never makes because they perform well. Nobody decides to cloak; they arrive at it one reasonable increment at a time.

That is a reason to build the guardrail into the system rather than to reject the idea. Two controls do most of the work:

• Generate the machine layer from the same source as the human layer. If both render from one content model, divergence becomes a bug rather than a temptation. This is the strongest argument for the decoupled architecture Mas describes, and it is an argument he is entitled to make.
• Assert parity in CI. A test that fails when the markup contains a value not present in the rendered page turns the policy into an engineering constraint.

On the visibility side, the more reliable lever remains the structure of the visible content itself: self contained passages, clear headings, tables for comparable facts, and explicit sourcing. Retrieval systems chunk documents, and a page written in extractable units performs better whether or not you ship an entity graph. That ground is covered in content structure for AI, and the practical schema questions in our schema markup FAQ.

Read Mas's original for the full framework. Take the entity modelling discipline, which is excellent and underapplied. Hold the ranking factor language at arm's length until someone documents it. And keep the machine layer describing the page a human would see.

Frequently asked questions

The useful residue of this argument is not a new tactic. It is a reminder that the web now has two readerships, and that most sites still describe themselves properly to only one of them.

Source: https://www.linkedin.com/pulse/json-silent-data-highway-llm-ingestion-joseph-mas-kxkuc/