What is schema markup?

Schema markup gives facts machine readable labels

A human visitor can usually infer that a prominent name is a company, that a price belongs to a product, or that a date refers to an event. Software may need clearer signals. Structured data expresses the page’s subject and its details in a standardized way: a type identifies what kind of thing is being described, and properties name facts about it. For instance, an Organization can have a name and URL; a Recipe can have a name and ingredients.

This does not replace the page’s prose, design, or evidence. It adds a structured description alongside content. Google describes structured data as explicit clues about page meaning, while Schema.org provides a shared vocabulary used by websites and applications. For a wider definition, see what structured data means.

Vocabulary, types, properties, and format are separate

The terms schema markup and structured data are often used loosely, but separating the parts makes implementation decisions clearer. Schema.org is a vocabulary: it defines types such as Person, Organization, Product, and Article, plus properties such as name, author, and offers. A type describes the kind of subject; a property describes a detail or relationship. The format is the syntax used to put those labels into a page.

Schema.org’s getting started guide explains how types and properties work together. Its vocabulary is broad, and the fact that a term exists does not mean every search engine supports a special presentation for it. For Google Search, check the current Search Central guide for the specific feature. The AEO glossary hub connects this definition to related terms, including entities and knowledge graphs.

Choose markup that describes the actual page

Start by asking what the page is about and what a reader can verify there. A product detail page may describe one product and its visible price or availability; a company profile may describe an organization; an editorial explainer may describe an article. A page mentioning a company is not automatically a company profile, and adding a product type to a general category page does not make the page a product detail page.

Select the closest applicable Schema.org type, then use only properties supported by the content and the underlying source of truth. Where a Google rich result is the goal, consult Google’s feature specific requirements rather than assuming that the broad Schema.org definition is sufficient. The entity SEO guide is useful when a page must distinguish a company, service, product, person, or location clearly.

The common formats: JSON LD, Microdata, and RDFa

Google Search documents support for three formats: JSON LD, Microdata, and RDFa, unless a particular feature says otherwise. JSON LD expresses the data in a JSON script block, separate from most visible HTML text. Microdata and RDFa attach machine readable attributes to HTML elements, connecting labels more directly to the marked up content. An existing site may already emit one format through its CMS or theme. Google generally recommends JSON LD when a site can maintain it because it is often easier to manage at scale.

Teams should favor a format they can keep accurate, avoid conflicting duplicates, and test the deployed page. See the JSON LD templates guide for an implementation focused discussion.

A concrete example: describe, do not embellish

Imagine a fictional agency website with a page that visibly identifies the business as Northstar Studio and links to its official homepage. A restrained organization description could encode the type as Organization, the visible business name as name, and the linked homepage as url. If the page names its founder, represent that person separately only when the relationship is genuinely described. Do not add awards, service areas, opening hours, or customer ratings merely because a schema property exists.

Every value should be sourced and agree with what a visitor sees. A useful editorial test is to read the page and markup side by side: if the structured description would surprise a reader, be difficult to substantiate, or contradict the page, revise it.

A practical agency workflow

Treat schema work as part of page modeling and release quality control, not a last minute plugin toggle. A repeatable workflow helps strategists, editors, and developers agree on what is being described and who maintains its facts.

1. 01Inventory the page template and its primary subject. Decide whether the page describes an organization, article, product, location, or another real thing; do not begin with a list of attractive search features.
2. 02Map each proposed property to a visible fact and a reliable source field, such as an approved business profile, product record, author account, or publishing system. Mark unknown or inapplicable data as omitted, not guessed.
3. 03Choose an encoding format the site can maintain. Check whether the CMS, theme, or extensions already emit markup before adding a second implementation that may conflict.
4. 04Check the relevant Schema.org terms and, when pursuing a Google feature, its current Search Central documentation. Follow type specific requirements and access rules rather than relying on a generic example.
5. 05Test representative live pages after deployment, compare the output with visible content, and note the date, template, issues, and owner so changes can be retested later.

Validate meaning as well as syntax

A parser can catch malformed markup, but a clean syntax result does not establish that every property is true, relevant, or appropriate for a Google feature. Check the graph for the intended type, spelling, relationships, and values; then compare it with the rendered page. Look for stale CMS data, duplicate titles, mismatched bylines, or outdated prices.

Google’s general structured data policies require relevant markup that represents visible content and make clear that valid markup is no promise of display. For a practical testing sequence, use the schema validation guide; its discussion distinguishes Schema.org validation from checks for Google supported rich results.

What schema can and cannot do for AEO

Structured descriptions can make page facts and relationships more explicit, which is useful when maintaining a coherent site and helping systems interpret content. Schema is not a shortcut to answer engine visibility. Search features change, engines may use information in different ways, and Google says a valid implementation only makes eligible pages candidates for supported appearances. A test cannot guarantee that Google will show a rich result, that another answer system will retrieve the page, or that a system will cite it.

Strong AEO still depends on accessible pages, useful and accurate explanations, clear sourcing, and relevant information architecture. Schema complements those foundations; it cannot repair thin, contradictory, or unsupported content. When planning implementation, connect this glossary definition to the broader AEO implementation hub rather than treating markup as an isolated deliverable.