Purpose unfolding now.

A blockchain for the world's information.

What Is Schema schema.org · w3c · json-ld
schema-1.png

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.

The Origin Story 2011 · four search engines · one vocabulary
schema-2.png

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.

827Schema.org types — every entity category on the web
1,528Properties — the vocabulary machines use to understand your entity
53.2%Of websites use JSON-LD — binary presence only, depth unmeasured
2011Year schema.org launched — the web has had 14 years to implement it
What the Data Actually Shows w3techs · march 2026 · cited

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 Graph36.0%46.1%60.1%65.5%69.8%70.3%
Twitter/X Cards19.3%29.8%46.7%50.1%55.3%56.0%
JSON-LD18.1%28.2%41.3%46.5%52.5%53.2%
Generic RDFa13.1%13.5%32.4%38.9%39.4%39.0%
Microdata13.1%15.3%21.5%24.7%23.1%22.7%
None55.1%44.3%30.3%25.1%21.7%21.4%
◈ What this data cannot tell you

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.

Source: W3Techs — w3techs.com/technologies/details/da-jsonld — Verified March 29, 2026 W3Techs Source →
The Three Formats microdata · rdfa · json-ld

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.

Format Comparison — Same Data, Three Syntaxes schema.org · LocalBusiness
/* ── MICRODATA — embedded in HTML tags ── */ <div itemscope itemtype="https://schema.org/LocalBusiness"> <span itemprop="name">Example Business</span> </div> /* ── RDFa — also embedded in HTML ── */ <div vocab="https://schema.org/" typeof="LocalBusiness"> <span property="name">Example Business</span> </div> /* ── JSON-LD — completely separate from HTML ✓ RECOMMENDED ── */ <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Example Business" } </script>
W3C Recommendation · JSON-LD 1.1 · Published 2020 W3C Spec →
How AI Changed the Stakes from ranking to reasoning

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.

Without Schema — What the AI Receives unstructured · inference required · hallucination risk
/* AI crawler arrives at your page and finds: */ <div class="header">Welcome to Our Business</div> <p>We serve great customers in a great location.</p> <p>Call us or visit us today!</p> /* AI must now infer: */ ? What type of business is this ? Where exactly is it located ? What does it offer ? Is it still open ? Who runs it ? What is it related to /* Result: guesses, pattern-matching, plausible-sounding hallucination */
Unstructured HTML — Maximum Inference Required
With Schema — What the AI Receives structured · declared · zero inference required
/* AI crawler arrives at your page and finds: */ { "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Example Business", "description": "What this business actually does, clearly declared", "address": { "@type": "PostalAddress", "streetAddress": "123 Main St" }, "openingHours": "Mo-Fr 09:00-17:00", "sameAs": ["https://maps.google.com/...", "https://yelp.com/..."] } /* AI now knows with certainty: */ Type: declared Location: verified Hours: confirmed Identity confirmed across multiple sources /* Result: accurate citations, correct recommendations, zero hallucination */
Structured JSON-LD — Zero Inference Required · Hallucination Eliminated schema.org/LocalBusiness →
What Most Implementations Get Wrong the coverage problem

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.

◈ Thin Schema

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.

◈ Static Schema

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.

◈ Isolated Schema

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.

Thin Schema vs Rich Schema — Same Entity Type LocalBusiness · coverage comparison
/* ── THIN — what most sites have ── */ { "@context": "https://schema.org", "@type": "Dentist", "name": "Example Dental", "telephone": "+1-555-000-0000" } /* 3 fields. Skeleton. Coverage: ~8% of available vocabulary. */ /* ── RICH — what Telosima generates ── */ { "@context": "https://schema.org", "@type": "Dentist", "@id": "https://exampledental.com/#organization", "name": "Example Dental", "description": "Family and cosmetic dentistry — full declared description", "telephone": "+1-555-000-0000", "foundingDate": "2008", "address": { /* full PostalAddress */ }, "geo": { "@type": "GeoCoordinates", "latitude": 00.0000, "longitude": -000.0000 }, "openingHoursSpecification": [ /* full spec per day */ ], "hasOfferCatalog": { /* services declared */ }, "aggregateRating": { /* rating + review count */ }, "sameAs": [ /* verified external profiles */ ], "areaServed": [ /* geographic service area */ ], "knowsAbout": [ /* Telosima edge injection: regulations, industry cluster */ ] } /* 30+ fields. Full entity. Coverage: 85%+ of available vocabulary. */ /* Plus: edges baked in from Telosima's eternal braid. */
Rich JSON-LD + Telosima Edges — Full Entity · Graph-Connected schema.org/Dentist →
The Telosima Difference edges baked in · eternal braid · machine readable

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.

01 Score. Every entity Telosima indexes gets scored against the full schema.org vocabulary for its entity type. Coverage depth. How many of the available properties are declared. What is missing. What matters most for AI citation.
02 Enrich. A structured intake process captures what the entity actually is — in plain language. That information gets normalized and used to generate a complete, vocabulary-aligned JSON-LD block targeting maximum coverage for the entity type. Human questions. Machine output.
03 Inject edges. The entity is run against Telosima's indexed entity graph. Confirmed relationships are baked into the schema — regulatory bodies, industry clusters, geographic markets, semantic neighbors — all with provenance links. The schema does declare. It connects.
04 Mint. The entity gets a permanent receptor page at telosima.com/e/[domain] — machine-readable at a clean endpoint, with a full provenance chain, edge map, and schema score. The entity is a confirmed node in the graph. Every new entity added to the graph strengthens this one.
Score · Enrich · Inject · Mint — the Telosima pipeline Enter the Eternal Braid →
Live JSON-LD Examples copy · validate · implement

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.

Restaurant — Food & Beverageschema.org/Restaurant
{ "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://yourrestaurant.com/#organization", "name": "Your Restaurant Name", "description": "[cuisine type, atmosphere, what makes you different]", "url": "https://yourrestaurant.com", "telephone": "+1-XXX-XXX-XXXX", "priceRange": "$$", "servesCuisine": ["American", "Craft Cocktails"], "hasMenu": "https://yourrestaurant.com/menu", "acceptsReservations": true, "address": { "@type": "PostalAddress", "streetAddress": "123 Main Street", "addressLocality": "Your City", "addressRegion": "CA", "postalCode": "XXXXX", "addressCountry": "US" }, "geo": { "@type": "GeoCoordinates", "latitude": 00.0000, "longitude": -000.0000 }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday"], "opens": "11:00", "closes": "22:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Friday","Saturday"], "opens": "11:00", "closes": "02:00" } ], "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.7, "reviewCount": 284 }, "sameAs": ["https://yelp.com/biz/...", "https://maps.google.com/..."] }
schema.org/Restaurant
Law Firm — Legal Servicesschema.org/LegalService
{ "@context": "https://schema.org", "@type": "LegalService", "@id": "https://yourlawfirm.com/#organization", "name": "Your Law Firm", "description": "[practice areas, jurisdiction, years in practice]", "url": "https://yourlawfirm.com", "telephone": "+1-XXX-XXX-XXXX", "foundingDate": "YYYY", "address": { "@type": "PostalAddress", /* full address */ }, "geo": { "@type": "GeoCoordinates", "latitude": 00.0000, "longitude": -000.0000 }, "openingHours": "Mo-Fr 09:00-17:00", "knowsAbout": ["Personal Injury Law", "Civil Litigation", "California Labor Code"], "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Legal Services", "itemListElement": [{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Personal Injury Representation" } }] }, "areaServed": [{ "@type": "State", "name": "California" }], "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.9, "reviewCount": 147 }, "sameAs": ["https://avvo.com/...", "https://martindale.com/..."] }
schema.org/LegalService
Contractor — Construction & Homeschema.org/HomeAndConstructionBusiness
{ "@context": "https://schema.org", "@type": "HomeAndConstructionBusiness", "@id": "https://yourcontractor.com/#organization", "name": "Your Contracting Company", "description": "[licensed contractor — specialties, years, license number, service area]", "url": "https://yourcontractor.com", "telephone": "+1-XXX-XXX-XXXX", "foundingDate": "YYYY", "address": { "@type": "PostalAddress", /* full address */ }, "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Construction Services", "itemListElement": [{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Kitchen Remodeling" } }, { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "ADU Construction" } }] }, "areaServed": [{ "@type": "City", "name": "Your City" }], "knowsAbout": ["California Building Code", "CSLB License Requirements"], "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.8, "reviewCount": 93 }, "sameAs": ["https://houzz.com/...", "https://bbb.org/..."] }
schema.org/HomeAndConstructionBusiness
Medical Clinic — Health & Medicalschema.org/MedicalClinic
{ "@context": "https://schema.org", "@type": "MedicalClinic", "@id": "https://yourclinic.com/#organization", "name": "Your Medical Clinic", "description": "[specialties, patient demographics, what makes you different]", "url": "https://yourclinic.com", "telephone": "+1-XXX-XXX-XXXX", "medicalSpecialty": ["Family Medicine", "Preventive Medicine"], "availableService": [{ "@type": "MedicalProcedure", "name": "Annual Physical Exam" }, { "@type": "MedicalProcedure", "name": "Telehealth Visits" }], "address": { "@type": "PostalAddress", /* full address */ }, "geo": { "@type": "GeoCoordinates", "latitude": 00.0000, "longitude": -000.0000 }, "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "08:00", "closes": "18:00" }], "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.6, "reviewCount": 201 }, "sameAs": ["https://healthgrades.com/...", "https://zocdoc.com/..."] }
schema.org/MedicalClinic
Real Estate Agentschema.org/RealEstateAgent
{ "@context": "https://schema.org", "@type": "RealEstateAgent", "@id": "https://yourrealty.com/#organization", "name": "Your Realty Group", "description": "[markets served, specialties, volume, years in business]", "url": "https://yourrealty.com", "telephone": "+1-XXX-XXX-XXXX", "address": { "@type": "PostalAddress", /* full address */ }, "geo": { "@type": "GeoCoordinates", "latitude": 00.0000, "longitude": -000.0000 }, "areaServed": [{ "@type": "City", "name": "Your City" }], "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Real Estate Services", "itemListElement": [{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Buyer Representation" } }, { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Seller Representation" } }] }, "knowsAbout": ["California Real Estate Law", "1031 Exchange", "DRE License Requirements"], "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.9, "reviewCount": 178 }, "sameAs": ["https://zillow.com/...", "https://realtor.com/..."] }
schema.org/RealEstateAgent
Auto Repair — Automotiveschema.org/AutoRepair
{ "@context": "https://schema.org", "@type": "AutoRepair", "@id": "https://yourautorepair.com/#organization", "name": "Your Auto Repair Shop", "description": "[specialties, certifications, makes/models serviced]", "url": "https://yourautorepair.com", "telephone": "+1-XXX-XXX-XXXX", "openingHours": "Mo-Fr 07:30-17:30", "address": { "@type": "PostalAddress", /* full address */ }, "geo": { "@type": "GeoCoordinates", "latitude": 00.0000, "longitude": -000.0000 }, "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Auto Services", "itemListElement": [{ "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Engine Diagnostics" } }, { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Brake Service" } }, { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Oil Change" } }] }, "knowsAbout": ["ASE Certified Technicians", "California BAR Registration"], "aggregateRating": { "@type": "AggregateRating", "ratingValue": 4.7, "reviewCount": 156 }, "sameAs": ["https://yelp.com/...", "https://carfax.com/..."] }
schema.org/AutoRepair
Live examples — 6 entity types · validate before deploying Google Rich Results Test →
References and Provenance primary sources · cited · verified

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.

Primary Sources — schema.html Reference Corpus all links verified · March 29, 2026
/* ── W3C STANDARDS ── */ [W3C-01] JSON-LD 1.1 W3C Recommendation https://www.w3.org/TR/json-ld11/ Published: 16 July 2020 · Status: W3C Recommendation /* ── SCHEMA.ORG ── */ [SCH-01] Schema.org Full Vocabulary — 827 Types · 1,528 Properties https://schema.org/docs/schemas.html [SCH-02] Schema.org Data Model Overview https://schema.org/docs/datamodel.html /* ── GOOGLE SEARCH CENTRAL ── */ [GOO-01] Introduction to Structured Data — Google Search Central https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data [GOO-02] Google Rich Results Test https://search.google.com/test/rich-results /* ── ACADEMIC / PRIMARY ── */ [ACM-01] Schema.org: Evolution of Structured Data on the Web Guha, R.V. · Brickley, Dan · Macbeth, Steve https://cacm.acm.org/practice/schema-org/ Published: ACM Communications · February 2016 [SEM-01] The Semantic Web — Berners-Lee, Hendler, Lassila Scientific American · May 2001 https://www.scientificamerican.com/article/the-semantic-web/ /* ── USAGE STATISTICS ── */ [W3T-01] JSON-LD Usage Statistics — W3Techs https://w3techs.com/technologies/details/da-jsonld Verified: March 29, 2026 · JSON-LD used by 53.2% of all websites /* ── TELOSIMA RESEARCH ── */ [TLS-01] Telosima Research — Web Science & AI Era Discoverability https://telosima.com/research Ongoing · provenance substrate · entity indexing · schema coverage analysis [TLS-02] Telosima Eternal Braid — Live Entity Provenance Log https://telosima.com/eternal-braid Continuous · every entity minted · every pass recorded · every gap preserved
All sources primary · all links verified · last updated 2026-03-29 Research Archive →
Schema & Structured Data · Telosima · Nothing is hidden. Always. Enter the Eternal Braid →
Telosima
System Status
PageSCHEMA
StandardSchema.org
FormatJSON-LD 1.1
Types827
Properties1,528
Adoption53.2%
W3C StatusRecommendation
Depth MeasuredTelosima only
SourceW3Techs 2026-03-29
Entities Minted
Machine Entry Point
entities/api/entities
braid/api/braid
graph/api/graph
lexicon/api/lexicon
content_type application/ld+json
Build: 2026-PROD Spec: receptor-v1.0 Status: OPERATIONAL
Schema. Provenance.