A complete, deeply explained guide — from the history and inventors, to every type, property, and concept you need to master structured data.
Schema.org is a shared vocabulary — a dictionary — for the internet. It is a set of agreed-upon words, definitions, and structures that allows websites to communicate with search engines not just in human language (which is ambiguous), but in precise, machine-readable structured data.
Think of it like this. If you write "We are open Monday to Friday" on your website, a human understands perfectly. But a search engine sees raw text and has to guess what it means. Schema.org lets you attach an invisible, precise label saying: "These are official business hours, formatted exactly as the OpeningHoursSpecification type defines." Now the search engine understands it with 100% certainty — and can display it beautifully in search results.
Schema.org is a collaborative, community-maintained vocabulary of structured data types and properties. It is the universal language that lets webmasters describe the meaning of their content — not just the text — so machines can understand it as well as humans.
Imagine you receive a package. On the outside it just says "stuff inside." You have to open it to find out what it is. That's regular HTML — the search engine has to "open" and read everything to guess what your page is about.
Now imagine the package has a detailed label: "Contents: 1 ceramic coffee mug. Fragile. Made in Japan. For ages 18+. Price: $24.99." The delivery system, customs, the warehouse — everyone immediately knows exactly what's inside without opening it. That label is Schema markup.
A shared set of agreed words (Types and Properties) that both websites and search engines understand the same way.
Agreed upon by Google, Bing, Yahoo, and Yandex simultaneously — so one implementation works across all search engines.
It adds invisible structure to your visible content, turning words into meaningful, categorized data that machines process precisely.
Completely free to use. Maintained openly by the community via GitHub and W3C groups. No license, no cost, no registration.
Schema.org was not invented by one person or one company. It was a historic collaboration between the four biggest search engines in the world, who set aside their competition to solve a shared problem.
| Organization | Role | Joined | Their Search Engine |
|---|---|---|---|
| Co-founder & primary driver | June 2, 2011 | Google Search (dominant worldwide) | |
| Microsoft (Bing) | Co-founder | June 2, 2011 | Bing Search |
| Yahoo! | Co-founder | June 2, 2011 | Yahoo Search |
| Yandex | Co-founder (joined months later) | November 2011 | Yandex (dominant in Russia) |
Primary initiator and co-founder of Schema.org. Currently heads the Schema.org Steering Group. Previously invented RSS and worked on the Semantic Web at W3C.
Co-founder of Schema.org and Microsoft's executive sponsor. Represented Bing's technical and strategic commitment to the project.
Worked on vocabularies for many major topics. Serves on the Steering Group and handles day-to-day running of Schema.org alongside Dan Brickley.
Long-time contributor and Steering Group member. Previously co-authored FOAF (Friend of a Friend), one of Schema.org's predecessor vocabularies.
This is a fascinating question. Google, Bing, and Yahoo were fierce competitors. Yet they cooperated on Schema.org. The reason: they all shared the same painful problem. The web was growing too fast and too chaotically. Without a common vocabulary, each search engine had to independently try to guess the meaning of billions of pages — wasting enormous resources and producing poor results for users.
The logic was similar to why competing car manufacturers all agreed to use the same traffic signs and road rules. A shared standard benefits everyone more than each having their own. Google still competes with Bing on ranking algorithms, but they both benefit if websites communicate their data clearly.
Human language is deeply ambiguous. The word "Jaguar" could mean a car brand, a wild animal, an operating system, or a sports team. Search engines reading raw HTML text could not reliably tell which one a page was about.
Animal? Car? Mac OS X version? Jacksonville Jaguars NFL team? A perfume brand? Without Schema, the search engine guesses.
The fruit? Apple Inc.? Apple Records (Beatles' label)? Apple Bank? A person's nickname? Context alone is often not enough.
Is this a business hour statement? An event? An instruction? What's the opening time? Schema gives precise, unambiguous answers.
A review rating? A hotel category? A military rank? A song? Schema's AggregateRating type makes this unambiguous.
Before 2011, there were attempts at structured data, but they were fragmented and incompatible. Each search engine had its own format, so web developers had to maintain multiple implementations:
| Format | Problem | Who Used It |
|---|---|---|
| Microformats | Very limited vocabulary, CSS class names only | A small community |
| RDFa | Too complex, required academic knowledge | Government, academia |
| FOAF | Only described people, not businesses or products | Early social web |
| GoodRelations | Only covered e-commerce products and offers | Online shops |
| Google Rich Snippets | Google-only, not recognized by Bing or Yahoo | Google users only |
One unified vocabulary. One implementation. Works for Google, Bing, Yandex, and Yahoo simultaneously. Covers every topic from local businesses and recipes to medical conditions and scientific datasets. Continuously maintained and expanded by a public community.
Tim Berners-Lee (inventor of the World Wide Web) first proposes the idea of a "semantic web" — a web where data has meaning, not just display. This becomes the intellectual foundation for Schema.org two decades later.
Various groups create Microformats, FOAF, GoodRelations, RDFa, and other structured data formats. None achieve widespread adoption because no major search engine strongly backed any single standard.
Google, Bing, and Yahoo simultaneously announce Schema.org. Launched with 297 Types and 187 Properties. R.V. Guha of Google and Steve Macbeth of Microsoft are the primary co-founders. The web community is stunned that competitors cooperated.
Yandex, Russia's dominant search engine, joins Schema.org. Now the four largest search engines on Earth are all committed to this single vocabulary.
Schema.org merges with the GoodRelations e-commerce vocabulary. This massively expands product, offer, and pricing schemas — a huge win for online retail.
Google officially begins supporting and recommending JSON-LD as the preferred format for Schema markup. This makes implementation dramatically simpler — markup no longer needs to be tangled inside HTML elements.
The W3C Schema.org Community Group becomes the main forum for Schema development, making it fully open and community-governed. Anyone can propose new types and properties via GitHub.
Google formally declares JSON-LD as the strongly preferred format. Microdata and RDFa are still supported but JSON-LD becomes the de facto standard for new implementations.
New types added for healthcare, education, jobs, COVID-19 data, datasets, and more. Schema goes beyond websites — now used in email (Gmail Actions), voice assistants, and mobile app indexing.
Schema.org achieves massive scale. Over 45 million websites use it, embedding over 450 billion individual Schema objects across the web. It becomes foundational infrastructure for AI and LLM training data.
The latest version contains 827 Types, 1,528 Properties, 94 Enumerations, and 522 Enumeration Members. Schema is now critical not just for SEO but for AI training, knowledge graphs, and the AI-powered search era.
The entire Schema.org vocabulary is built from exactly five kinds of things. Understanding these five is understanding the whole system.
A Type is the thing. Properties are its attributes. Each property takes a Datatype as its value (like Text or Number), OR another Type as its value (nesting), OR a fixed Enumeration Member as its value (like "Monday" or "InStock").
A Type is the answer to the question: "What kind of thing is this?" Every piece of structured data must declare its Type first. It is the foundation of everything else.
Each Type in Schema.org is:
| Characteristic | Explanation | Example |
|---|---|---|
| A proper noun | Always starts with a capital letter (CamelCase) | LocalBusiness, FAQPage, BlogPosting |
| A URL at schema.org | Every Type has a dedicated page defining it | https://schema.org/LocalBusiness |
| Inherits properties | Child types inherit all properties of parent types | Restaurant inherits from FoodEstablishment → LocalBusiness → Organization → Thing |
| Has its own properties | May add unique properties on top of inherited ones | Restaurant adds servesCuisine, menu, acceptsReservations |
| Case-sensitive | Must be written exactly as shown — no exceptions | LocalBusiness ✅ vs localbusiness ❌ |
Every single one of the 827 Types ultimately descends from one parent Type called Thing. This means every Type in the entire vocabulary automatically inherits these basic properties from Thing:
The name of the item. Available on absolutely every Type in Schema.org.
A short explanation of the item. Inherited by every single Type.
The URL of the item's webpage. Universal across all Types.
An image of the item. Available everywhere — from people to products.
A unique identifier for the item (like an ISBN, product ID, etc.).
URL of a reference page that unambiguously identifies this item (like its Wikipedia or Wikidata page).
This is one of the most important concepts. Types are organized in a strict parent → child hierarchy. Child types inherit all properties of every ancestor all the way up to Thing, and then add their own specific properties on top.
INHERITANCE TREE ── Thing (root of everything) ├── Organization │ ├── LocalBusiness ← inherits from both Organization & Thing │ │ ├── Plumber ← inherits from LocalBusiness, Organization & Thing │ │ ├── Restaurant ← inherits from LocalBusiness, Organization & Thing │ │ ├── Hospital ← inherits from LocalBusiness, Organization & Thing │ │ └── AutoRepair ← inherits from LocalBusiness, Organization & Thing │ ├── Corporation │ └── NGO ├── Person ├── Place │ ├── CivicStructure │ └── Landform ├── CreativeWork │ ├── Article │ │ ├── BlogPosting ← inherits from Article → CreativeWork → Thing │ │ └── NewsArticle │ └── WebPage │ ├── FAQPage │ ├── AboutPage │ └── ContactPage ├── Event ├── Product ├── Action └── Intangible ├── Service ├── Rating │ └── AggregateRating └── BreadcrumbList
When you use "@type": "Plumber", you automatically get access to ALL properties defined for LocalBusiness, Organization, AND Thing — not just the ones listed under Plumber specifically. This is why name and telephone work on a Plumber type even though they're technically defined on ancestor types.
If Types are the nouns of Schema.org, then Properties are the adjectives and verbs. They are the attributes and details that describe a Type. With 1,528 properties in the vocabulary, they cover virtually every kind of factual detail about anything.
| Rule | Explanation | Example |
|---|---|---|
| Always camelCase | Start with lowercase, each new word capitalized | telephone, openingHours, priceRange, areaServed |
| Each property has an expected value type | Some expect Text, some expect a Number, some expect another Type (nested object) | name → Text; address → PostalAddress Type; ratingValue → Number |
| Can be multi-valued | Many properties accept arrays of values | "areaServed": ["Salt Lake City", "Murray", "Sandy"] |
| Optional unless stated | No property is strictly mandatory (but some are needed for Google Rich Results) | Google requires name and address for LocalBusiness rich results |
| Can be nested Types | A property's value can be a complete Type object — schemas can nest infinitely | address takes a full PostalAddress type as its value |
A plain string or number. Most common type of value. Just write the value directly.
"name": "ACME Plumbing" "telephone": "+18019308000" "ratingValue": 4.9
A value in a specific format — like ISO 8601 dates, URLs, or Boolean true/false.
"datePublished": "2025-01-15" "url": "https://example.com" "isAccessibleForFree": true
A fixed value from a predefined list — like days of the week or availability status.
"dayOfWeek": "Monday" "itemCondition": "NewCondition" "availability": "InStock"
The value is itself a full Schema Type — enabling infinitely deep nesting.
"address": {
"@type": "PostalAddress",
"city": "Salt Lake City"
}
| Property | Applies To | What It Holds |
|---|---|---|
name | Everything (from Thing) | The official name of the entity |
description | Everything (from Thing) | Short text description |
url | Everything (from Thing) | The canonical webpage URL |
image | Most types | URL of an image, or full ImageObject |
telephone | Organization, Person, Place | Phone number as text string |
address | Organization, Person, Place | PostalAddress nested type |
openingHoursSpecification | LocalBusiness | OpeningHoursSpecification nested type |
aggregateRating | Product, LocalBusiness, CreativeWork | AggregateRating nested type |
review | Product, LocalBusiness, CreativeWork | Review nested type |
author | CreativeWork, Article, BlogPosting | Person or Organization type |
datePublished | CreativeWork subtypes | ISO 8601 date string |
priceRange | LocalBusiness | Text like "$", "$$", "$$$" |
areaServed | Organization, Service | Text, City, State, Country, or GeoShape |
sameAs | Everything (from Thing) | URL to authoritative reference (Wikipedia etc.) |
Datatypes define what format a simple value should be in. There are 14 Datatypes in Schema.org:
| Datatype | What It Is | Example Value |
|---|---|---|
Text | A plain string of characters | "ACME Plumbing" |
Number | Any numeric value | 4.9 or 150 |
Integer | A whole number only | 5 or 100 |
Float | A decimal number | 24.99 or 3.14 |
Boolean | True or false only | true or false |
Date | ISO 8601 date format | "2025-12-31" |
Time | ISO 8601 time format | "09:00:00" |
DateTime | Combined date and time | "2025-12-31T09:00:00" |
Duration | ISO 8601 duration format | "PT1H30M" (1 hour 30 min) |
URL | A full web address | "https://schema.org/LocalBusiness" |
XPathType | An XPath expression | Rarely used, for XML path references |
CssSelectorType | A CSS selector string | Rarely used, for page element selectors |
PronounceableText | Text with pronunciation guidance | Used for accessibility |
Mass / Distance / Energy | Quantity types with units | Used in product and scientific schemas |
An Enumeration is a property where the value must be chosen from a fixed, predefined list. You cannot invent your own values. Think of it like a dropdown menu — you must pick one of the given options.
Fixed values: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, PublicHolidays
Fixed values: InStock, OutOfStock, PreOrder, Discontinued, LimitedAvailability, OnlineOnly
Fixed values: Cash, CreditCard, DebitCard, Invoice, ByInvoice, PayPal
Fixed values: Hardcover, Paperback, EBook, AudiobookFormat, GraphicNovel
Fixed values: FourWheelDriveConfiguration, FrontWheelDriveConfiguration, RearWheelDriveConfiguration
Fixed values: Male, Female — used on the Person type. Other genders can be expressed as Text.
The Schema.org vocabulary (the types and properties) is separate from the format (how you write it in your HTML). There are three official formats. JSON-LD is strongly recommended by Google and is what you should use.
| Format | What It Is | Recommended? | Difficulty |
|---|---|---|---|
| JSON-LD | A separate <script> block in the <head>. Schema data is completely separate from visible HTML. | ✅ Yes — Google's Top Choice | Easy |
| Microdata | Attributes added directly to HTML elements (itemscope, itemtype, itemprop) | ⚠️ Supported but not preferred | Medium |
| RDFa | Attributes added to HTML elements. Academic/government standard, more complex. | ⚠️ Supported but rarely used | Hard |
• Completely separate from HTML — easy to add/remove/edit
• Easy to copy, paste, and manage
• Works even if the visible content looks different
• Supported by every major CMS and plugin
• Can be injected via Google Tag Manager
• Nested data is very readable and logical
• No risk of breaking your page layout
• Google's officially preferred format since 2017
• Must be embedded inside visible HTML elements
• Hard to read and edit — schema tangled with content
• If you change the HTML, you might break the schema
• Cannot easily add data that isn't visible on the page
• Difficult to manage across many pages
• Hard to validate and debug
• Developers must touch layout files to change schema
• Google has de-emphasized both since 2015
JSON-LD ANATOMY // 1. The wrapper — tells the browser this is JSON-LD structured data <script type="application/ld+json"> { // 2. @context — ALWAYS "https://schema.org". Points to the vocabulary. // Never change this. It is the URL of the dictionary you're using. "@context": "https://schema.org", // 3. @type — The TYPE you are declaring. Fixed Schema.org vocabulary. // CamelCase. Exact spelling. Never invent your own. "@type": "LocalBusiness", // 4. @id — A unique URL identifier for this specific entity. // Use your page URL + "#" + a descriptor. Helps Google's Knowledge Graph. "@id": "https://acmesewerdraincleaning.com/#business", // 5. Properties — the details. Keys are fixed; values are yours. "name": "ACME Sewer & Drain Cleaning", "telephone": "+18019308000", "priceRange": "$$", // 6. Nested Type — the value of "address" is itself a full Type. // This is how schemas can describe complex, multi-level data. "address": { "@type": "PostalAddress", // ← another Type nested inside "addressLocality": "Salt Lake City", "addressRegion": "UT", "addressCountry": "US" }, // 7. Array value — multiple items for one property "areaServed": [ "Salt Lake City", "Murray", "Sandy" ] } </script>
All 827 types organize under Thing, then branch into these top-level categories. Every type has a home in this tree.
| Top-Level Branch | Approximate Types | Covers |
|---|---|---|
| Thing (root) | 1 (the parent) | The universal parent. All properties here are inherited by every type. |
| Action | ~100 types | Things people do: BuyAction, SearchAction, BookAction, ReviewAction, LikeAction, PlayAction |
| CreativeWork | ~150 types | Content: Article, BlogPosting, Book, Movie, Podcast, Recipe, SoftwareApplication, WebPage, Dataset |
| Event | ~30 types | Happenings: ChildrensEvent, ComedyEvent, Festival, MusicEvent, SportsEvent, TheaterEvent |
| Intangible | ~200 types | Concepts: Service, Offer, Rating, BreadcrumbList, JobPosting, Permit, Ticket, Language, Quantity |
| MedicalEntity | ~80 types | Healthcare: Drug, MedicalCondition, MedicalProcedure, MedicalTrial, Physician, Hospital |
| Organization | ~60 types | Entities: Corporation, EducationalOrganization, LocalBusiness (and 70+ sub-types), NGO, SportsTeam |
| Person | 1 type | Individual humans — living, dead, or fictional. Has rich properties for bio, career, family. |
| Place | ~80 types | Locations: Country, City, Airport, Hospital, LandmarksOrHistoricalBuildings, Park |
| Product | ~30 types | Items for sale: Product, ProductGroup, Vehicle, Car, IndividualProduct |
| BioChemEntity | ~10 types | Scientific: Gene, Protein, ChemicalSubstance, MolecularEntity |
Schema.org is the input. Rich Results are the visible output in Google Search. When Google reads and validates your Schema markup, it may enhance your search listing with visual features that stand out dramatically from plain blue links.
Gold stars shown under your business name in results. Requires AggregateRating schema with ratingValue and reviewCount.
Your search result expands to show questions and answers directly. Requires FAQPage schema. Can double your result's height in SERPs.
Shows the page path (Home › Services › Drain Cleaning) instead of the raw URL. Requires BreadcrumbList schema.
The info box on the right of Google results showing your business hours, phone, map, reviews. Powered by LocalBusiness schema + Google My Business.
Shows cooking time, calories, ratings, and photos directly in results. Requires Recipe schema with all required properties.
Video thumbnail and duration shown in results. Requires VideoObject schema with thumbnailUrl, uploadDate, and duration.
Shows salary, location, and company in a dedicated job listing format. Requires JobPosting schema with required properties.
Shows price, availability, and rating in search results. Requires Product schema with Offer and AggregateRating.
Adding valid Schema markup makes you eligible for rich results — but Google still decides whether to show them. Google considers content quality, page authority, correctness of markup, and other factors. Valid schema is the entry ticket, not a guarantee.
The most important Type for any physical or service business. LocalBusiness has over 70 specialized subtypes covering every kind of business. Key properties unique to LocalBusiness include openingHoursSpecification, priceRange, currenciesAccepted, paymentAccepted, and areaServed.
Plumber, Electrician, HVACBusiness, Locksmith, RoofingContractor, AutoRepair, Dentist, Optician, Pharmacy, Florist, Bakery, Restaurant, Hotel, HealthClub, LegalService, AccountingService, RealEstateAgent — and dozens more.
Covers all content that humans create. Used primarily for articles, blog posts, books, courses, and web pages. Key subtypes include Article, BlogPosting, NewsArticle, Book, Course, Movie, Recipe, Podcast, and WebPage.
Describes an individual human being. Properties include givenName, familyName, birthDate, jobTitle, worksFor, alumniOf, affiliation, and knowsLanguage. Used for author markup, team members, and biographical pages.
Describes any product for sale or display. Essential for e-commerce. Combined with Offer (for pricing), AggregateRating (for reviews), and Brand (for manufacturer). Key properties: sku, gtin, brand, material, color, weight.
Describes a happening in time and space. Properties include startDate, endDate, location, organizer, performer, eventStatus, and offers (for tickets). Subtypes include MusicEvent, SportsEvent, Festival, ExhibitionEvent.
One of the most visually rich Schema types. Properties: cookTime, prepTime, totalTime, recipeIngredient, recipeInstructions, recipeYield, nutrition, suitableForDiet. Google shows full recipe cards in search results when all required fields are present.
Structures question-and-answer content. Contains mainEntity which holds an array of Question types, each with an acceptedAnswer of type Answer. When valid, Google may show expandable FAQ dropdowns directly in search results.
Describes the hierarchical path to the current page. Contains itemListElement, an ordered array of ListItem types, each with a position (number), name (text), and item (URL). Google replaces the raw URL in your search listing with these breadcrumbs.
Review represents a single review with author, reviewRating, and reviewBody. AggregateRating represents the average of many reviews with ratingValue, reviewCount, bestRating, and worstRating. Together they power star ratings in search results.
Describes a service offered by an organization. Properties include serviceType, provider, areaServed, hasOfferCatalog, and availableChannel. Used extensively for professional service businesses alongside LocalBusiness.
WebSite represents the entire website entity. WebPage represents individual pages. These establish the basic structure of your web presence in Google's knowledge graph and can enable the Sitelinks Search Box in branded search results.
Describes a job opening. Properties: title, hiringOrganization, jobLocation, baseSalary, employmentType, datePosted, validThrough. Google has a dedicated Jobs search feature that reads this schema and displays rich job listings with salary and apply buttons.
| # | Rule | Why It Matters |
|---|---|---|
| 1 | Never invent a Type or Property name | Google will simply ignore markup it doesn't recognize. Custom types do nothing. |
| 2 | Types are CamelCase (capital first letter) | LocalBusiness ✅ — localbusiness ❌ will be ignored entirely. |
| 3 | Properties are camelCase (lowercase first) | telephone ✅ — Telephone ❌ — phone ❌ |
| 4 | The content must match the visible page | Google will penalize sites that mark up content not visible to users. Don't markup fake reviews or hours that differ from reality. |
| 5 | Include only what's true and accurate | Incorrect schema (wrong hours, fake ratings) can lead to manual penalties from Google. |
| 6 | Always validate before publishing | Use Google's Rich Results Test. One syntax error can break the entire schema block. |
| 7 | Use @id consistently | Using the same @id across multiple schemas tells Google all those blocks describe the same entity, building a unified Knowledge Graph entry. |
| 8 | Don't spam schema | Only add schema types that genuinely reflect your page's content. Adding FAQPage schema to a page with no FAQ is a guidelines violation. |
"@type": "Localbusiness" // lowercase 'b' — Google ignores entirely
"@type": "LocalBusiness" // Exact CamelCase as defined by schema.org
"phone": "+18019308000" // "phone" is NOT a schema.org property
"telephone": "+18019308000" // "telephone" is the official schema.org property
{
"@type": "LocalBusiness",
"name": "ACME"
}
// Without @context, there's no vocabulary reference
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "ACME"
}
The primary tool. Test by URL or by pasting code. Shows exactly what rich results your schema qualifies for.
search.google.com/test/rich-results
Official validator from Schema.org itself. Checks that your markup follows the vocabulary correctly, independent of what Google supports.
validator.schema.org
After publishing, shows "Enhancements" reports for each schema type. Tells you which pages have errors, warnings, or valid markup in production.
search.google.com/search-console
Here is a fully annotated, production-quality schema block — every line explained.
COMPLETE EXAMPLE <script type="application/ld+json"> { // ① ALWAYS required. Points to the schema.org vocabulary dictionary. "@context": "https://schema.org", // ② The Type. Two types at once using an array — this entity is BOTH // a LocalBusiness AND a Plumber. Gets properties from both. "@type": ["LocalBusiness", "Plumber"], // ③ @id is a unique, permanent URL identifier for this entity. // The #business "fragment" makes it a named entity, not just a page URL. "@id": "https://acmesewerdraincleaning.com/#business", // ④ Simple Text properties — keys fixed by schema.org, values are yours. "name": "ACME Sewer & Drain Cleaning", "description": "Salt Lake City's owner-operated drain and sewer specialist.", "telephone": "+18019308000", "priceRange": "$$", "url": "https://acmesewerdraincleaning.com", // ⑤ NESTED TYPE — address property takes a PostalAddress Type as its value. // This is how complex data is structured. A Type inside a Type. "address": { "@type": "PostalAddress", ← another Type nested inside "addressLocality": "Salt Lake City", "addressRegion": "UT", "addressCountry": "US" }, // ⑥ NESTED TYPE — geo property takes a GeoCoordinates Type. "geo": { "@type": "GeoCoordinates", "latitude": 40.7608, ← Number datatype (no quotes) "longitude": -111.8910 }, // ⑦ ARRAY OF NESTED TYPES — multiple opening hours specifications. "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", // ← ENUMERATION MEMBERS — values from the DayOfWeek enumeration. // You CANNOT write "mon" or "monday" — must be exactly these values. "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"], "opens": "08:00", ← Time datatype — 24hr format "closes": "18:00" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Saturday", "Sunday"], "opens": "00:00", "closes": "23:59" ← 24/7 on weekends } ], // ⑧ NESTED AggregateRating — enables gold stars in search results. "aggregateRating": { "@type": "AggregateRating", "ratingValue": 5.0, ← Number (no quotes) "bestRating": 5, "worstRating": 1, "reviewCount": 50 }, // ⑨ ARRAY of simple string values — multiple cities served. "areaServed": [ "Salt Lake City", "Murray", "Sandy", "West Jordan" ], // ⑩ sameAs — connects this entity to authoritative external references. // Helps Google's Knowledge Graph understand who you are definitively. "sameAs": [ "https://maps.app.goo.gl/uDsC4jYqTQhM11E2A" ] } </script>
Schema.org was built for search engines. But in 2024–2026, its importance has expanded far beyond traditional SEO into artificial intelligence, voice search, and the entire future of how machines understand the web.
Large Language Models (like GPT and Claude) were trained on web data. Websites with Schema markup provided cleaner, structured training data — making Schema a contributor to the quality of modern AI knowledge.
Google's AI Overviews (formerly SGE) and Bing's Copilot pull structured facts directly from Schema markup to compose AI-generated search summaries. Schema data is directly cited by AI answers.
Siri, Google Assistant, and Alexa pull business hours, phone numbers, and service info from Schema markup to answer voice queries. Without Schema, your business is invisible to voice.
Google's Knowledge Graph — the database behind the info boxes you see on the right of search results — is populated largely from Schema.org markup and Wikidata. Your @id and sameAs values connect you to it.
Gmail reads Schema.org markup in HTML emails. A confirmation email with ReservationAction schema gets a "Check In" button right in Gmail. Schema is no longer just for web pages.
Tim Berners-Lee's 1989 vision of a machine-readable web is finally becoming real — Schema.org is the primary mechanism making it happen, connecting data across billions of pages into a global knowledge network.
Schema.org is no longer just an "SEO trick." It is the foundational infrastructure of how the modern, AI-powered internet understands information. Businesses that implement it correctly are not just getting better Google rankings — they are making themselves legible to the entire machine-readable layer of the internet, including AI assistants, voice search, knowledge graphs, and the next generation of search technologies that haven't been invented yet.
| Concept | One-Line Definition |
|---|---|
| Schema.org | A shared vocabulary for structured data, created by Google/Bing/Yahoo/Yandex in 2011. |
| Type | The "what" — what kind of thing you're describing. CamelCase. Fixed vocabulary. 827 total. |
| Property | The "details" — attributes of a Type. camelCase. Fixed vocabulary. 1,528 total. |
| Datatype | The format of a simple value — Text, Number, Date, URL, Boolean, etc. 14 total. |
| Enumeration | A fixed dropdown list — the value must be one of the predefined options. 94 total. |
| Enumeration Member | A specific value from an enumeration — like "Monday" from DayOfWeek. 522 total. |
| JSON-LD | The recommended format for writing Schema — a <script> block in the <head>. |
| @context | Always "https://schema.org" — points to the vocabulary. Never change it. |
| @type | The Type declaration. Must match schema.org exactly. Never invent custom values. |
| @id | A unique URL identifier for the entity. Connects it to Google's Knowledge Graph. |
| Rich Results | The visual enhancements in Google search (stars, FAQ, breadcrumbs) enabled by valid schema. |
| Inheritance | Child types automatically get all properties of parent types, all the way up to Thing. |
| Nesting | The value of a property can itself be a complete Type object — schemas can be infinitely deep. |
| Validation | Always test at search.google.com/test/rich-results and validator.schema.org before publishing. |