Structured data
Updated 2026-09-15
Structured data is markup, usually JSON-LD using schema.org types, that states explicitly what a page is about: an article, a product, a question and its answer, an organisation, a defined term. It makes facts machine-readable instead of leaving them to be inferred from prose.
What it does and does not do
Markup does two reliable things: it disambiguates entities by linking stable identifiers (an organisation node referenced from every page, a person node for the author), and it exposes structured facts — dates, authors, prices, question-answer pairs — without the parsing risk of prose. What it does not do is force inclusion in a generated answer; no engine promises that. Markup that contradicts the visible page is a violation and can remove eligibility rather than add it.
Illustrative graph (example structure)
An organisation node with a fixed @id, a website node pointing at it, a person node for the founder with worksFor referencing the same @id, and article nodes naming that person as author. Engines then see one entity described consistently rather than four pages that happen to share a brand name.
Common mistakes
- FAQ markup whose answers do not appear in the visible text.
- A different organisation @id on every page, which splits one entity into many.
- Adding aggregateRating markup without genuine reviews — a policy violation and a trust problem.
Frequently asked questions
- Does schema markup improve AI visibility directly?
- Not as a ranking lever. It improves the odds that your facts are read correctly and attributed to the right entity, which is a precondition for being quoted accurately rather than a guarantee of being quoted.
- Which types matter most for this category?
- Organization and Person for entity clarity, FAQPage where the questions are genuinely on the page, Article or TechArticle with dates and author for freshness signals, and BreadcrumbList so the site structure is legible.
