Purpose unfolding now.
A blockchain for the world's information.
Every website on the internet is written for two audiences. The human who reads it. And the machine that decides whether anyone ever finds it. For most of the web's history those two audiences have been completely misaligned — beautiful pages for humans, invisible noise for machines.
Schema is the bridge. It is a standardized vocabulary — a shared language — that lets your website declare what it is to any machine that comes looking. Your business name. Your location. Your hours. Your services. Your relationship to your industry, your city, your customers. All of it structured, labeled, and machine-readable in a format that search engines and AI systems can read, reason about, and trust.
The technical name for the format is JSON-LD — JavaScript Object Notation for Linked Data. It lives in the head of your HTML as a script block. It is invisible to your visitors. It is everything to the machines that decide whether your visitors ever find you.
This page is a complete reference. The history of where schema came from. What the data actually shows. How AI changed the stakes. What most implementations get wrong. And what Telosima does differently. If you are a business owner, a developer, or a researcher — everything you need to understand structured data at the level that actually matters is here.
In 2011 something unusual happened in the technology industry. Four competing companies — Google, Microsoft, Yahoo, and Yandex — sat down together and agreed on something. That almost never happens. They were competing for the same users, the same advertisers, the same market. And they agreed.
The problem they were solving was real and it was expensive. Each search engine had been recommending its own vocabulary for structured data. Webmasters trying to add structured markup to their sites had to pick a side — or implement everything multiple times. Most gave up. The result was that the structured web Berners-Lee imagined in 2001 was still mostly theoretical in 2010.
The three engineers who drove schema.org into existence were R.V. Guha at Google — who had previously created RSS and co-led the Cyc project — Dan Brickley, who had helped build the Semantic Web project at W3C, and Steve Macbeth at Microsoft. They launched schema.org with 297 types and 187 properties. One vocabulary. One standard. Every search engine would accept it.
The idea was brutally simple. Give webmasters a shared vocabulary so they only have to do the work once. Within four years, 31.3% of pages in the Google index had schema.org markup. Schema.org had grown from 297 types to 638 types and 965 properties. Today it contains 827 types and 1,528 properties covering every category of entity that exists on the web.
They published the standard. They gave it to the world. And then they waited for the web to catch up. Most of it still has not.
W3Techs publishes usage statistics for structured data formats across the web. Their data is updated daily and is the most widely cited source for structured data adoption. As of March 29, 2026, 53.2% of all websites use JSON-LD — up from 18.1% in January 2018. That is a genuine and significant trend. JSON-LD has become the dominant structured data format by a wide margin.
Here is what that number does does not tell you.
It measures presence. The depth. The coverage. The quality. A website with four fields of JSON-LD counts the same as a website with forty. A skeleton schema written in 2018 and never touched counts the same as a rich, relationship-dense entity record updated last week. The binary question — does JSON-LD exist on this page — is the only question the adoption statistics answer.
The question nobody has publicly answered at scale is: of the websites that have JSON-LD, what percentage of the available vocabulary for their entity type have they actually implemented? Our research across entity records indexed by Telosima indicates that the answer is strikingly low — most business websites cover a small fraction of what is available for their entity class. The gap between what exists and what is possible is where AI discoverability lives.
| Format | 2018 | 2020 | 2022 | 2024 | 2026 Jan | Mar 2026 |
|---|---|---|---|---|---|---|
| Open Graph | 36.0% | 46.1% | 60.1% | 65.5% | 69.8% | 70.3% |
| Twitter/X Cards | 19.3% | 29.8% | 46.7% | 50.1% | 55.3% | 56.0% |
| JSON-LD | 18.1% | 28.2% | 41.3% | 46.5% | 52.5% | 53.2% |
| Generic RDFa | 13.1% | 13.5% | 32.4% | 38.9% | 39.4% | 39.0% |
| Microdata | 13.1% | 15.3% | 21.5% | 24.7% | 23.1% | 22.7% |
| None | 55.1% | 44.3% | 30.3% | 25.1% | 21.7% | 21.4% |
These statistics measure binary presence — JSON-LD exists on the page or it doesn't. They do not measure coverage depth against the schema.org vocabulary. They do not measure whether the implementation is current, connected, or meaningful to an AI system building an entity model. Telosima measures the thing this data cannot: how much of the available vocabulary for a given entity type is actually declared, and how well that entity is connected to the graph of related entities that AI systems use to reason about it.
When schema.org launched in 2011 it supported three ways to implement structured data. Each one represented a different philosophy about how machines and humans should share information on the same page.
Microdata came first. It embedded structured markup directly inside HTML tags. Clean in theory. In practice it tangled the data layer and the presentation layer together — every time a developer changed the HTML they risked breaking the schema.
RDFa — Resource Description Framework in Attributes — was the academic approach. Technically more expressive. Also significantly more complex. Adoption stayed concentrated among developers who already lived in the semantic web world.
Then in 2014 Google began recommending JSON-LD — and everything changed. JSON-LD solved the fundamental problem: it completely separated the structured data from the visible HTML. Your schema lived in a script block in the head — a clean, self-contained JSON object that declared everything about your entity without touching a single line of your front-end code. Developers could update schema without touching design. Designers could update design without touching schema.
JSON-LD became the W3C Recommendation in 2020 — the highest level of endorsement the standards body issues. It is the official standard. Every major AI system reads it. It is the language your website uses to speak to machines.
Schema mattered before large language models. The adoption numbers above show real growth across fourteen years of the pre-LLM era. That growth was driven by search features, rich snippets, knowledge panels. Those were already significant reasons to implement structured data. Then AI arrived and the entire calculus shifted.
Search engines used to match keywords to pages. The job was ranking. Schema helped by providing explicit signals that improved ranking accuracy. That was the old game.
AI systems reason. They build models. When someone asks an AI about a business, a person, a concept — the system is constructing an understanding of what that entity is. What type it belongs to. What it relates to. What neighborhood of meaning surrounds it. That model was built long before the question was asked. Your schema is one of the primary inputs into that model.
The shift from ranking to reasoning changes what schema needs to do. In the old world, schema helped you rank higher. In the new world, schema determines whether you exist in the AI's model of your domain at all. A well-structured, relationship-dense entity is a fully formed node in the AI's understanding. An entity without it is a gap — something the AI has to guess about, or worse, something it hallucinates.
We have all experienced AI hallucination on real entities. Wrong addresses. Wrong phone numbers. Descriptions that fit nobody. Schema is hallucination prevention. It gives the AI system ground truth from a source it can verify — your own website, declaring its own identity, in a standardized vocabulary the system was trained to trust. Every property you declare is one fewer thing the AI has to guess. Every relationship you establish is one more accurate edge in the model.
The goal is machine readability. Discoverability is a byproduct of machine readability. This distinction matters — it means you are optimizing for an algorithm. You are making your entity legible to every machine that will ever try to understand it.
Schema.org has been publicly available since 2011. JSON-LD has been the recommended format since 2014. The W3C made it an official recommendation in 2020. And yet the most common implementation of structured data on a business website in 2026 looks like this: a plugin-generated block with a name, an address, a phone number, and nothing else. Written once. Never updated. Never connected to anything.
The adoption statistics show 53.2% of websites have JSON-LD. They do show how much of the available vocabulary those websites actually use. Our research across indexed entity records indicates the coverage gap is severe. Most business websites declare a small fraction of what is available for their entity type. The checkbox was ticked. The work was done.
The coverage problem has three specific failure modes.
The minimum required fields and nothing more. A LocalBusiness with a name and address but no description, no hours specification, no service catalog, no ratings, no geographic coordinates, no social profiles. The crawler reads it, extracts the minimum, and moves on. The entity model it builds is skeletal. Skeletal entity models produce weak citations and high hallucination risk.
Schema written once and never touched again. A business that has changed its hours, added services, won awards, moved locations — and has the exact same JSON-LD it had four years ago. AI systems that encounter contradictions between schema and other signals reduce their confidence in the source. Reduced confidence means fewer citations, more hedged language, and higher hallucination risk.
Schema that lives on one page and points nowhere. No sameAs connections. No links to related entities. No declared relationships between the business and its industry, its location, the people who run it. An entity in isolation is a page. An entity with confirmed connections to a graph of related entities is a node in a network. The difference in how AI systems treat these two things is significant and measurable.
When Telosima generates schema for an entity, we do just describe it. We connect it.
Think of it this way. Standard schema is an introduction. You stand alone in a room and say: here is my name, here is what I do, here is where I am. That is useful. But it is an introduction made in isolation. No one in the room knows you.
Telosima schema is an introduction made by someone everyone already knows and trusts. Your entity gets connected to the industry regulations that govern it, the geographic market it operates in, the entity clusters that AI systems already understand and cite — all with confirmed provenance links to where those connections came from. The machine learns about you in context. Context is what produces trust. Trust is what produces citations.
These connections — which we call edges — come from the Eternal Braid: Telosima's continuously growing graph of indexed, minted, and confirmed entities. Every entity we process adds to the graph. Every addition makes the graph denser. Every denser graph makes every entity in it more connected. This is compound intelligence. Your schema improves because the graph it connects to keeps growing.
The goal is machine readability — making your entity legible to every AI system that will ever try to understand it, with enough context and confirmed connections that the machine is confident enough to cite you, recommend you, and reason about you accurately.
The following are production-ready JSON-LD examples for six entity types. Every block targets maximum field coverage for the entity class, structured for rich result eligibility, and formatted for Telosima edge injection. Copy any block directly into the <head> of your HTML inside a <script type="application/ld+json"> tag. Replace placeholder values with your actual data. Validate using the Google Rich Results Test before deploying.
These examples represent the baseline. Telosima-minted entities get the enriched version — edges injected from the eternal braid, coverage scored against the full vocabulary, relationships confirmed across entity clusters.
Everything on this page is sourced. The history, the statistics, the technical specifications — all of it traces to primary documents that are publicly available and permanently archived. This is what Telosima means by provenance. A claim requires a source.