How Schema.org works
Schema.org is a shared vocabulary, agreed between the major search engines and maintained as an open project, that gives web pages an agreed set of words for describing things. It defines types — Product, Recipe, Event, LocalBusiness, Person — and the properties each type can carry, such as a name, an address, a start date or an author.
The types sit in a hierarchy. Everything descends from Thing, which branches into broad categories such as CreativeWork and Organization, which branch again into narrower ones. A subtype inherits its parent’s properties and adds its own, which is why a NewsArticle can use everything an Article can use and a little more besides.
The distinction that trips people up is vocabulary versus syntax. Schema.org supplies the words; JSON-LD, microdata and RDFa are three ways of writing them into a page. Choosing JSON-LD does not mean you are not using Schema.org — it means you are writing Schema.org terms in JSON-LD.
Why Schema.org matters
Without an agreed vocabulary, every site would describe its opening hours in its own words and no machine could read any of it reliably. The shared list is what lets a search engine turn a page into facts it can act on: this is a product, that is its price, this business is that one over there with the same phone number.
That matters more as answers move away from a plain list of links. Whether the destination is a rich result, a knowledge panel or an AI-generated summary, an unambiguous description of what a page is about gives the machine less to guess at. It is not a ranking factor in itself, and nobody should sell it as one — it is a comprehension aid that sometimes earns a more visible result.
Common mistakes with Schema.org
The biggest is assuming that everything in the vocabulary does something. Schema.org is far larger than the slice any search engine actually uses, and publishing an obscure type will not produce a search feature simply because the type exists. Search engines publish their own list of supported structured data features, and that list, not the vocabulary, decides what can appear.
The other common error is marking up claims the page does not make. The vocabulary lets you assert almost anything, so it is easy to describe a product, a rating or an event that no visitor can find on the page. That is a guidelines problem, not a technical one, and it is the version of the mistake that gets sites into trouble.
How to act on it
Start from the page, not from the vocabulary. Decide what the page genuinely is — a service page, an article, a shop listing, a business profile — then find the type that matches and fill in only the properties the page really supports. Leave the rest empty rather than inventing values to look complete.
Validate with the Schema Markup Validator for vocabulary correctness and the Rich Results Test for search eligibility, because the two answer different questions. Then watch the enhancement reports in Google Search Console over the following weeks, since that is where errors on live pages surface. Where the markup is doing real work — an ecommerce catalogue, a multi-location business — it is worth planning it deliberately rather than accepting whatever a plugin emits, which is the point of proper schema markup work on a site.