Structured data (schema.org)
Structured data is content markup using the schema.org vocabulary, usually in JSON-LD. It tells machines what a page holds: that this is a service, that a product, here a question with an answer, and this a company with an address and a founding year. Search engines build rich results from it, and language models take brand facts from it.
In short
| What it is | A machine-readable description of page content using the schema.org vocabulary |
| Most common types | Organization, FAQPage, Article, Product, Service, BreadcrumbList, DefinedTerm |
| What it delivers | Rich results in search and a more accurate understanding of the brand by language models |
| What it cannot do | Replace content. Schema with no good answer in the text has nothing to describe |
How structured data works
What sits in the code
Structured data sits on the page as a separate JSON-LD block inside a script tag, independent of the visible HTML. The block declares the vocabulary (@context: schema.org), the entity type (@type: Product, Organization, Article) and its properties. Entities nest: Product holds an Offer with price, currency and availability; Organization holds an address and sameAs links to profiles; Article holds an author of type Person. Through @id one entity can be referenced from several pages, so the article's author and the person on the About page are one thing to a machine, not two records sharing a name.
What the search engine does with it
- The crawler fetches and renders the page. A block injected by JavaScript is picked up later and less reliably than one served in the HTML.
- The JSON-LD is parsed and checked against supported types: if a required property is missing, for example the price in an Offer, the item is not eligible for a rich result.
- The marked-up content is compared with what is visible on the page: the price in the schema has to match the text, and the number of questions has to match the visible FAQ.
- The page becomes eligible for a rich result. Eligibility is not a guarantee: the engine decides per query whether to show it.
- Search Console's enhancement reports show the status: valid items, items with warnings, items with errors.
For e-shops, Product schema has one more role: Merchant Center reads price and availability from the landing page and automatically corrects items that disagree with the feed.
What language models read and what it means for the site
A language model and an AI search engine read the same block as a set of statements: subject, property, value. Company X, founded, year. Product Y, price, amount. The statements are unambiguous, whereas the same fact in marketing copy first has to be interpreted. So from a site with consistent Organization and Article schema, a model takes the name, industry, author and date more accurately than from text alone.
An e-shop benefits mainly on product and category pages: Product with Offer, AggregateRating and BreadcrumbList, plus a uniform product identifier (GTIN, brand). A B2B site benefits mainly on service pages and in content: Service describing the offer, Article with a real author and Organization as the shared node that both tie into through @id.
Worked example: an e-shop has 5,000 product pages on one template. Search Console reports 4,600 valid items and 400 with the error "missing price", because the template prints no price for out-of-stock products. So 8% of the catalog is not competing for a rich result although the pages otherwise work. After the fix, the count of valid items rises only at the next crawl, not immediately.
Why it matters more than before
As long as structured data mainly served rich results, it was a CTR optimization. AI answers added a second role: a language model takes the company's identity from the Organization schema, ready-made answers from FAQPage, and the author and date from Article. When the data is missing or contradictory, the model fills the facts in from elsewhere, usually not in your favor.
From our own practice: FAQPage wherever there is a visible FAQ
The rule we keep: FAQPage belongs on every page with a visible FAQ section, and the question counts in the schema have to match what is visible on the page. Schema promising questions that are not on the page is a risk, not an advantage. Service belongs on service pages, and articles need Article with a real author plus Person schema.
The practical lesson from audits: structured data tends to be deployed only partially, usually a basic Organization block and nothing else. It is not a hygiene standard everyone already has. Thorough deployment is still a competitive advantage, not a duty.
Common mistakes
- Schema without visible content. Marking up an FAQ that does not exist on the page is a route to a penalty, not to results.
- Contradictions between schema and page. Different numbers in Organization than in the site copy undermine both versions.
- Deploy and forget. Schema changes with the content. Stale values keep spreading from it.
- Expecting citations from schema alone. It aids comprehension, but without a good answer in the text it cannot earn the citation.
Related terms
See also entity SEO, Knowledge Graph, AEO, GEO and llms.txt.
Frequently asked questions
Which types should go first?
Organization site-wide, FAQPage wherever a visible FAQ exists, Article on posts and Service on service pages. The rest depends on the business.
Is JSON-LD better than microdata?
Yes. It is Google's recommended format and it separates data from HTML, which makes it easier to maintain.
How do I verify the schema works?
With a rich results validator and an anonymous fetch of the page. A logged-in administrator often sees different output than bots do.
How we can help
We deploy structured data as part of AI visibility work. Details on the AI visibility agency page.