Schema markup is a vocabulary of structured data tags that tells search engines — and AI systems like Google’s AI Overviews, ChatGPT, and Perplexity — exactly what your content means, not just what it says. If you have ever stared at a piece of JSON-LD and wondered what @context actually does, or why Google’s documentation mentions both “entity” and “thing” without explaining the difference, this glossary is built for you. Every term is defined the way a working SEO needs it — precise enough to use, plain enough to remember.
At Salterra, we reference this kind of foundational vocabulary constantly when auditing client sites or building out structured data strategies from scratch. The terminology trips up even experienced marketers because schema sits at the intersection of web development, semantic search, and information science. Clear definitions make implementation faster and debugging far less painful.
Core Formats: JSON-LD, Microdata, and RDFa
JSON-LD
JSON-LD stands for JavaScript Object Notation for Linked Data. It is the format Google recommends for adding structured data to web pages, and for good reason: the markup lives entirely inside a <script type=”application/ld+json”> tag, completely separate from your visible HTML. You can add, update, or remove it without touching the visual layout of a page. For CMS-heavy sites and dynamic environments, this separation makes schema implementation dramatically simpler to manage and audit.
Microdata
Microdata is an HTML5 specification that embeds structured data directly into your visible page elements using attributes like itemscope, itemtype, and itemprop. Instead of a separate script block, the markup wraps the actual content in the DOM. Microdata is valid and supported by Google, but it creates tight coupling between your HTML structure and your schema — changing a layout element can inadvertently break your structured data. Most practitioners migrating off legacy setups move from microdata to JSON-LD as part of technical SEO cleanup work.
RDFa
RDFa (Resource Description Framework in Attributes) is an older W3C standard that, like microdata, annotates inline HTML. It uses attributes such as typeof, property, and vocab to express semantic relationships. RDFa is still valid and appears frequently in Drupal ecosystems and older enterprise sites. It has the same maintainability drawbacks as microdata: schema is intertwined with presentation markup. For new implementations, JSON-LD is almost always the right choice.
The Schema.org Vocabulary
Schema.org
Schema.org is the shared vocabulary — a giant, collaboratively maintained dictionary of types and properties — that powers structured data across all major search engines. Founded by Google, Microsoft, Yahoo, and Yandex, it defines what a “Product” is, what properties an “Event” has, and how to describe a “Person.” When you write schema markup, you are expressing your content in the terms that schema.org has standardized. The vocabulary is open, regularly updated, and the authoritative reference for any schema implementation.
Type
A type (written as @type in JSON-LD) is the category or class your entity belongs to. Common types include Article, Product, FAQPage, LocalBusiness, Person, BreadcrumbList, and Recipe. Every schema block must declare a type — it tells the parser what kind of thing you are describing and which properties are valid. Types form a hierarchy: LocalBusiness is a subtype of Organization, which is a subtype of Thing. Properties from parent types are always inherited.
Property
A property is a specific attribute that describes something about your type. For a Product, properties include name, description, sku, offers, and aggregateRating. Properties have expected value types — some accept plain text, some expect a number, some expect a nested schema object. Getting the value type right matters: Google’s validators will flag a property that expects a URL but receives a string of text.
Thing
Thing is the root type in the schema.org hierarchy — every other type is a subtype of Thing. Thing itself has four basic properties that apply to everything: name, description, url, and image. When documentation says a property accepts a “Thing,” it means any schema.org type is valid there. Understanding Thing as the universal parent helps make sense of why properties like name appear across dozens of different schema types.
Identifiers and Linked Data Concepts
@context
The @context field declares the vocabulary being used. In practically every real-world schema block, this is set to “https://schema.org”. It tells the parser that the properties and types in this block should be interpreted according to the schema.org specification. You can technically define custom vocabularies or mix vocabularies using @context, but for SEO purposes, pointing to schema.org is always the correct move.
@id
@id is a unique identifier for an entity — almost always expressed as a URL. It allows the same entity to be referenced across multiple schema blocks, either on the same page or across different pages. For example, your organization might have a @id of https://example.com/#organization, and multiple schema blocks (Article, WebSite, BreadcrumbList) can all point back to that same identifier. This is how you build a coherent entity graph rather than a collection of disconnected schema snippets. Google’s documentation explicitly recommends using @id to link related entities.
sameAs
sameAs is a property that points to external URLs that definitively represent the same entity — most often Wikipedia, Wikidata, official social profiles, and authoritative directory listings. For a business, a sameAs array might include the Google Business Profile URL, LinkedIn company page, and the business’s Wikidata item. For a person, it typically includes a Wikipedia page and social profiles. sameAs is one of the most powerful tools for entity disambiguation: it tells knowledge engines “this entity in my markup is the same entity as this well-known, verified record.” It directly supports E-E-A-T signals and knowledge graph inclusion.
Entity
An entity is any distinct, identifiable thing in the real world or conceptual space — a person, a business, a location, a product, a concept. Search engines increasingly organize their understanding of the web around entities rather than keywords. When Google processes your schema markup, it is trying to resolve the entities you describe and match them against what it already knows. An entity with a clear @id, accurate sameAs links, and consistent NAP (name, address, phone) data across the web is far easier for Google to confidently represent in search results and AI answers.
Knowledge Graph
Google’s Knowledge Graph is the massive database of real-world entities — people, places, organizations, creative works — and the relationships between them. When you see a Knowledge Panel on the right side of Google search results, that information is pulled from the Knowledge Graph. Schema markup, especially with correct sameAs references and consistent entity signals, is one of the primary ways websites contribute information that can influence how an entity is represented in the Knowledge Graph. AI Overviews draw heavily on Knowledge Graph data, making entity clarity more important than ever.
Rich Results and Search Enhancements
Rich Result
A rich result (sometimes called a rich snippet) is a search result that displays additional visual or informational elements beyond the standard blue-link title and meta description. Star ratings, product prices, recipe cook times, FAQ dropdowns, event dates, and job posting details are all examples of rich results. They are powered entirely by structured data. Rich results consistently achieve higher click-through rates than standard results — the enhanced appearance signals authority and gives searchers more reason to choose your result before they even click.
Featured Snippet
A featured snippet is the boxed answer that appears above organic results for certain queries. While featured snippets are not directly controlled by schema markup, structured data can increase your eligibility. Content that is clearly organized (tight question/answer structure, well-defined definitions, step-by-step lists) tends to win snippets — and those same structural qualities align with schema best practices. FAQ schema, in particular, creates machine-readable Q&A pairs that AI systems, including Google’s AI Overviews, can extract and surface directly.
Knowledge Panel
A Knowledge Panel is the information card that appears on the right side of Google search results for entities with established Knowledge Graph entries. It displays the entity’s name, description, images, key facts, and links to authoritative sources. Schema markup contributes to Knowledge Panel accuracy — particularly sameAs links, description properties, and consistent entity signals across the web. For businesses and individuals building an authoritative online presence, schema that reinforces entity identity is foundational to Knowledge Panel eligibility.
Rich Results Test
The Rich Results Test is Google’s official tool (available at search.google.com/test/rich-results) for validating structured data markup. Paste a URL or code snippet, and it tells you which rich result types your markup is eligible for, flags any errors that would prevent a rich result, and lists warnings about optional but recommended improvements. Running every schema implementation through this tool before deployment is a non-negotiable step in any structured data workflow. It catches type mismatches, missing required properties, and formatting issues that validators alone might miss.
Structured Data Relationships and Advanced Terms
Structured Data
Structured data is any data organized in a predefined, machine-readable format. In SEO, the term specifically refers to markup that communicates meaning to search engines using a shared vocabulary — most commonly schema.org expressed via JSON-LD. Unstructured data is everything else: plain prose, images, video. The shift toward AI-driven search has made structured data more valuable, not less — language models and knowledge engines prefer data they can parse and cite with confidence over prose they must interpret heuristically.
Nested Schema
Nested schema refers to schema objects embedded inside other schema objects. A Product type, for example, contains a nested Offer object (with price, availability, and seller details) and may also contain a nested AggregateRating object. Proper nesting is how you express real-world complexity — a job posting has a hiring organization, which has its own name and location; a recipe has a nutrition object with its own properties. Flattening nested relationships into a single level almost always results in incomplete or invalid schema.
itemListElement
itemListElement is the property used within a BreadcrumbList or ItemList schema to define the ordered members of the list. In breadcrumb schema, each itemListElement is a ListItem with a position number and an item object containing the page name and URL. Google uses breadcrumb schema to display the site’s hierarchy in search results — replacing the raw URL with a clean category path. Correct position ordering is mandatory; out-of-order positions trigger validation errors.
@graph
@graph is a JSON-LD array that lets you declare multiple schema entities in a single script block. Rather than adding separate <script> tags for WebSite, Organization, WebPage, and BreadcrumbList, you put all four inside one @graph array. This is not just cleaner — it enables cross-referencing between entities using @id, which creates a richer, more interconnected entity graph on the page. Most modern schema implementations follow this pattern, and it is the approach recommended by technical SEO practitioners at Salterra when building out comprehensive page-level schema architectures.
Validation, Errors, and Common Pitfalls
Required vs. Recommended Properties
Google’s documentation distinguishes between required properties (without which your markup will not generate a rich result) and recommended properties (which improve the quality and richness of the result but are not mandatory). A Product schema requires name and valid offers data to be eligible for product rich results. Recommended properties like image, description, and brand increase the completeness of the result. Common mistake: stopping at required-only and wondering why results look minimal. Always implement recommended properties when the data exists on the page.
Markup Mismatch
A markup mismatch occurs when schema markup describes content that is not actually visible on the page. Google’s guidelines are explicit: structured data must reflect content a user can see. Marking up a five-star rating that does not appear on the page, or adding product pricing that differs from what’s displayed, is a violation that can result in manual actions and the removal of rich results eligibility. At Salterra, every schema audit includes a cross-check between marked-up values and rendered page content — it catches mismatch issues before they become algorithmic or manual penalties.
Speakable
Speakable schema is a property that marks specific sections of a page as particularly appropriate for audio playback via voice assistants. It was introduced as smart speakers became common search surfaces. While speakable has limited current adoption in mainstream SEO, it is a signal of the broader trajectory: search is becoming multi-modal, and schema is the mechanism that helps engines understand which content is suited to which surfaces. Keeping up with emerging schema types is part of a forward-looking structured data practice.
Schema in the AI Search Era
AI Overviews, ChatGPT browsing, and Perplexity all rely on structured signals to determine whether a source is authoritative and citable. Schema markup contributes to that determination in several ways. sameAs links connect your site’s entities to verified external records. Author Person schema with credentials and publisher links supports E-E-A-T signals. Article schema with datePublished and dateModified helps AI systems evaluate freshness. And FAQ schema creates discrete Q&A pairs that language models can extract directly, rather than having to parse prose to find the answer.
The practical implication is that schema markup is no longer just a rich result play — it is an entity-clarity and AI-citation play. Sites that implement schema correctly, completely, and consistently across their content are giving search engines and AI systems everything they need to confidently surface that content in new answer formats. Sites that ignore schema are leaving that interpretation entirely to machine inference, which is inherently less reliable. The vocabulary is the same; the stakes have grown.
Frequently Asked Questions
What is the difference between schema markup and structured data?
Structured data is the broad concept — any data organized in a machine-readable format. Schema markup is the specific implementation: structured data written using the schema.org vocabulary, typically in JSON-LD format, and added to a web page so search engines can parse it. All schema markup is structured data, but not all structured data is schema markup.
Does schema markup directly improve rankings?
Schema markup does not directly boost rankings as a ranking signal, but it creates real competitive advantages: rich results increase click-through rates, entity clarity strengthens E-E-A-T signals, and AI-era search surfaces favor well-structured content. The indirect ranking benefits — more clicks, stronger entity signals, better crawl understanding — are well-documented in practitioner experience, even if Google has not confirmed schema as a direct ranking factor.
What is sameAs and why does it matter for SEO?
sameAs is a schema.org property that links your entity to authoritative external records — Wikipedia, Wikidata, social profiles, and official directories. It matters because it tells knowledge engines that your entity is the same as an already-verified, well-understood record. This disambiguation is how brands and people get correctly represented in the Knowledge Graph and cited accurately by AI systems like Google's AI Overviews.
Is JSON-LD better than microdata or RDFa?
For most implementations, yes. Google recommends JSON-LD because it lives in a separate script block, decoupled from your visible HTML. This makes it easier to add, update, and audit without touching page layouts. Microdata and RDFa are still valid and supported, but they interweave markup with presentation code, which creates maintenance challenges — especially on sites with templated layouts or frequent design changes.
How do I test my schema markup?
Use Google's Rich Results Test (search.google.com/test/rich-results) as your primary validation tool — it confirms rich result eligibility and surfaces errors and warnings. For broader validation and a full view of all detected structured data, also run the page through Schema.org's validator at validator.schema.org. Both tools together give you compliance from Google's perspective and standards compliance from the schema.org vocabulary perspective.
What is @graph and should I use it?
@graph is a JSON-LD array that lets you define multiple schema entities in a single script block, with cross-references between them via @id. You should use it when a page has more than one entity to describe — for example, a WebPage, an Article, an Organization, and a BreadcrumbList all in one block. Using @graph with linked @id values produces a richer, more connected entity graph that modern schema best practices strongly recommend over separate, disconnected script blocks.
Terry has 30+ years in software and SEO. He’s the founder of Salterra Digital Services and SEO Spring Training, host of the Roundtable SEO Mastermind, and lead instructor at SEO University — teaching the exact tactics his team uses on client work.
Continue learning
Ready to master this?
This guide is one lesson from the Advanced Schema course. Get every lesson, framework and checklist — plus the full 38-course catalog — inside SEO University.
Practitioner-focused training across the full digital marketing stack — from technical SEO to conversion optimization and the AI search era. By Salterra Digital Services, since 2011.