Glossary
What is Structured Data Markup (Schema.org)?
Definition
Structured data markup is machine-readable code added to a page that labels what the content is: a product, an author, a price, a definition. Schema.org is the shared vocabulary those labels come from. Unlike the visible copy, which a system has to interpret, structured data states the facts outright.
At a glance
- CategoriesTechnical
- Related fieldsSEO, Technical
- DifficultyIntermediate
At a glance
- Structured data is usually written as JSON-LD inside a script tag, separate from the visible HTML.
- Schema.org supplies the vocabulary. Google documents which types affect search results.
- The markup must match what the page shows. A price the page never displays is a policy breach.
- Marking something up guarantees no visual treatment. It makes the fact unambiguous.
A second, literal copy of the page
Structured data sits in a application/ld+json script block. Nothing renders. A parser reads it and gets your facts with no interpretation needed.
A product page might state name, brand, SKU, price, currency and availability. An article states headline, author and both dates. A glossary entry can use DefinedTerm to declare that the page defines a term and which set it belongs to.
What each consumer does with a type is up to them. Google publishes which types affect search results. The AI labs have published far less, so anyone telling you how an assistant weights your schema is guessing.
One rule holds everywhere. The markup has to match what a person sees. A rating nobody left, or a price the page never displays, breaks search engine policy and gives any machine reading you a reason to distrust the rest.
What markup buys you now that rich results have narrowed
Structured data used to be a straight trade: add markup, collect a star rating. Google has since narrowed which types earn a visual treatment, and plenty of teams concluded the work stopped paying.
The payoff changed rather than vanished. Markup is now the cheapest way to make a fact unambiguous to a machine.
An assistant reading your product page has to work out which number is the price, whether a review score belongs to this product or the category above it, and who wrote the guide it is about to quote. Prose makes it infer all of that. JSON-LD tells it.
That matters most where being wrong is expensive: pricing, availability, authorship, safety or legal wording. A stale price repeated inside an answer becomes a support ticket and a lost sale.
Markup will not make a weak page worth citing. It stops a good page being misread, and it raises extractability, because the facts already sit apart from the prose.
Mark up the types you can keep accurate
The usual failure is marking up everything once, then letting it drift.
- Start with Organization on your homepage. Legal name, logo, sameAs links to your official profiles. This is the base for how machines resolve your brand in a knowledge graph.
- Add Product on product templates, with price, currency and availability read from the same source the page renders from. Never hand-typed.
- Add Article with a named author to anything editorial, including the modified date. Authorship is one of the few credibility signals you can state outright.
- Use FAQPage only where the page genuinely answers questions. Do not rewrite body copy as fake questions to qualify.
- Emit it server-side and validate after every template change. JSON-LD injected by a script can be invisible to clients that do not render, so server-side rendering applies here too.
Structured data is generated, not authored. If someone is typing JSON-LD into a CMS field by hand, it will be wrong within a quarter.
Which types are worth the effort
| Type | What it settles | Worth it for |
|---|---|---|
| Organization | Who the brand is, and its official profiles | Every site, once |
| Product | Price, availability, identifiers | Ecommerce, always |
| Article | Author, published and updated dates | Anything editorial |
| FAQPage | Which text is a question and its answer | Pages that really are Q and A |
| BreadcrumbList | Where the page sits in the site | Deep catalogs |
Frequently asked questions
-
Does structured data make an AI assistant cite me?
No lab has said so, and anyone claiming a direct link is ahead of the evidence. What markup reliably does is remove ambiguity, so a system reading your page gets the price, the author and the date right rather than inferring them. Being quoted accurately is worth having on its own.
-
Is schema markup the same as meta tags?
No. Meta tags carry a handful of fixed fields such as title and description, aimed at how a result is displayed. Schema.org is an extensible vocabulary describing what the content actually is. They coexist and do different jobs.
-
Do I still need FAQ schema?
Only if the page is genuinely a set of questions and answers. The visual result most brands added it for is no longer widely available, so adding it for that reason is wasted work. Keeping it on real FAQ content is still worth doing, because it labels each answer cleanly.
-
Does more markup mean better results?
No, and over-marking creates work without return. Five accurate types beat twenty nobody maintains, and a contradictory block is worse than none. Mark up what you can keep true, validate it in your build, and stop there.