Skip to main content
Guide Search & discovery (SEO, GEO, AEO)

Structured data and how engines use it

Structured data gets pitched as an SEO trick: add the right tags, get a shinier search result. That is backwards. Structured data is a labeling system, a way of telling any machine reading your page what its content actually means, not just what it looks like. Search engines are one consumer of that label, and a useful one, but the relationship between "I added schema" and "I got a rich result" is looser than most guides admit. This one covers what structured data is, how engines actually use it, the types worth knowing, a real example, how to check your work, and the honest limits, including a type of rich result Google quietly turned off in 2026.

Reference12 min readLast verified August 2026

What you’ll learn

  • Explain what structured data is: a labeling system built on the schema.org vocabulary, almost always written as JSON-LD.
  • Distinguish the two separate jobs structured data does for a search engine: entity understanding and rich-result eligibility.
  • Recognize which common types (Article, BreadcrumbList, Product, Organization, LocalBusiness) still enable a Google rich result, and which do not.
  • Read and explain a real Article JSON-LD block, including how types like Organization nest inside another type.
  • Validate markup with the Rich Results Test and the Schema Markup Validator, and know what each one actually checks.
  • State the honest limits: structured data is not a ranking signal, it must match visible content, and eligibility never guarantees display.

What structured data actually is

A web page is built for two very different readers. A person sees layout, color, and typography, the stuff CSS controls. A machine reading the same page, a search crawler, a browser extension, an AI model doing retrieval, sees none of that. It sees markup. Structured data is a standardized way of adding a second, explicit layer of meaning to that markup, a label that says "this block of text is a recipe" or "this number is a price" or "this person is the author," using a shared vocabulary instead of a description you invent yourself. Google's own definition is blunt about the purpose: "Structured data is a standardized format for providing information about a page and classifying the page content."1

That shared vocabulary comes from schema.org, a project run as "a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond."3 It was founded jointly by Google, Microsoft, Yahoo, and Yandex, and it has stayed a shared, cross-engine standard since, which matters: schema.org types are not a Google feature, they are read by multiple search engines and, increasingly, by AI systems doing retrieval.

In practice, structured data almost always shows up as a block of JSON-LD sitting inside a <script type="application/ld+json"> tag, usually in the page's <head>. JSON-LD is not the only format schema.org supports, Microdata and RDFa exist too, embedded directly in your visible HTML attributes, but Google is explicit that it prefers the separated version: "we recommend using a format that's easiest for you to implement and maintain (in most cases, that's JSON-LD)."1 A single self-contained script block is easier to generate, easier to template, and easier to keep in sync than markup woven through your visible HTML, which is exactly why it won.

New to this? You do not have to write JSON-LD from a blank file. Most frameworks let a small template or object print the script tag for you, and this guide has a full working example further down to copy and adapt. For now the idea matters more than the syntax: a JSON-LD block is just a small file of key-value pairs describing what is on the page, sitting next to the HTML that already shows it to a person.
Key idea
Structured data is a labeling system built on a shared vocabulary (schema.org), almost always written as JSON-LD in a script tag. It tells a machine what your content means, on top of what a person already sees on the page.

How search engines actually use it

Structured data does two separate jobs for a search engine, and conflating them is where most confusion starts. Google describes the first job plainly: "Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general."1 That is entity understanding. Marking a page as an Organization with a name and address does not just decorate your listing, it helps Google's systems connect that page to the entity it represents, the same way a Wikipedia infobox helps a reader (and a machine) place a topic in context.

The second job is the one everyone actually cares about: rich results, also called rich snippets, the star ratings, product prices, breadcrumb trails, and other enhanced display elements that show up on top of a plain blue link. Google is explicit that this is additive, not automatic just from having good content: "Adding structured data can enable search results that are more engaging to users," and for any given feature, "you must include all the required properties for an object to be eligible for appearance in Google Search with enhanced display."1 Note the word doing the work there: eligible. Correct markup is a ticket into the room, not a seat.

  • A crawler fetches the page and reads the JSON-LD block the same way it reads any other content on the page.
  • The markup feeds entity understanding, helping the engine place the page in its model of the web, independent of whether anything visual ever changes in search results.
  • If the page also has all the required properties for a given rich-result type, it becomes eligible for that enhanced display, on top of its normal ranking.
  • Whether that eligible page actually gets the enhanced treatment, for a given query, on a given day, is a separate decision the search engine makes on its own.

The common types worth knowing

Schema.org defines hundreds of types. Almost none of them matter to a typical site. A short list covers most real use cases, and it is worth knowing upfront that not every type still buys you something on Google, a point the table below does not paper over.

TypeWhat it can enable
ArticleEnhanced display for news, sports, or blog posts, larger images and headline treatment in eligible surfaces.<sup><a href="#source-6">6</a></sup>
BreadcrumbListA breadcrumb trail shown in place of the raw URL under a search result, reflecting the page's position in your site.<sup><a href="#source-6">6</a></sup>
ProductPrice, availability, and review-rating display in product-related search results.<sup><a href="#source-6">6</a></sup>
OrganizationKnowledge panel details: logo, legal name, address, and contact information.<sup><a href="#source-6">6</a></sup>
LocalBusinessKnowledge panel business details: hours, ratings, directions, and booking or ordering actions.<sup><a href="#source-6">6</a></sup>
FAQPageNothing on Google as of this writing. Google turned off the FAQ rich result on May 7, 2026.<sup><a href="#source-7">7</a></sup><sup><a href="#source-8">8</a></sup> The type still describes your content accurately for other consumers.
HowToNothing on Google as of this writing. Google removed the HowTo rich result in September 2023.<sup><a href="#source-8">8</a></sup> Same caveat: still valid, accurate markup, just not a Google display feature anymore.
Structured data type -> what it can enable
FAQPage and HowTo are the clearest lesson in this whole topic. Both were popular "win a rich result" tactics for years. Google removed the HowTo rich result in 2023 and the FAQ rich result on May 7, 2026, stating flatly that "the FAQ rich result feature is no longer shown in Google Search results."78 A guide that still promises "add FAQPage schema to win a rich snippet" is describing a feature that no longer exists on the search engine people usually mean by that advice. The types are still real, still describe your content correctly, and other consumers, other search engines, AI systems doing retrieval, can still use them. They just do not buy you a Google rich result anymore.

A real JSON-LD example

Here is what a minimal, valid Article block actually looks like. It sits in the page's <head>, self-contained, describing the same article that is visible in the page body below it.

Article JSON-LD, in a <script type="application/ld+json"> tag
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Choose a Database for Your First App",
  "image": "https://example.com/images/database-guide-cover.jpg",
  "author": {
    "@type": "Organization",
    "name": "Example Publishing"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publishing",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-03-04",
  "dateModified": "2026-07-19"
}
  • @context points at schema.org, the shared vocabulary this markup is written in.
  • @type names the entity, here Article, using a type schema.org defines.
  • headline, image, and datePublished are among the properties Google recommends for Article eligibility (it lists no strictly required ones), and every one of them must match something a reader can see on the page itself.
  • author and publisher nest another schema.org type (Organization) inside this one, which is normal, types compose.
Going further: a page with several distinct entities, an Article and its BreadcrumbList, say, does not need two separate script tags. Wrap them in a single @graph array under one shared @context, and give any entity referenced more than once, a publisher that appears on every article, for instance, an @id so other blocks can point at it instead of repeating the full object. It is the same nesting idea as the Organization inside this Article, taken one level further: one script tag describing a small graph of related entities instead of just one.

How to validate it

Two free tools cover almost every validation need, and they check different things, so it is worth knowing which one you are reaching for.

  • Rich Results Test (search.google.com/test/rich-results): Google's own tool, described as testing "your publicly accessible page to see which rich results can be generated by the structured data it contains."5 Use this to answer a Google-specific question: for the markup on this exact page, which Google features, if any, is it eligible for right now.
  • Schema Markup Validator (validator.schema.org): checks your JSON-LD against the schema.org specification itself, independent of any single search engine's feature list.4 Use this to confirm the markup is syntactically correct and uses real schema.org properties, even for types Google does not currently reward, like FAQPage or HowTo, or for markup aimed at a different consumer entirely.
Run both. The Rich Results Test tells you what Google will do with this markup today, a moving target, as the FAQ and HowTo cases show. The Schema Markup Validator tells you whether the markup itself is correct, which stays true regardless of which search engine's feature list changes next.

From markup to rich result

  1. 1Markup addedJSON-LD in a script tag, matching what is visible on the page
  2. 2Crawled and parsedA bot fetches the page and reads the structured data block
  3. 3Checked against requirementsRequired properties for that type are confirmed present
  4. 4Eligibility grantedThe page becomes a candidate for that feature, nothing more
  5. 5Engine decidesRanking and display systems choose whether, and how, to render it for a given query
What actually happens between adding a script tag and seeing a rich result

The honest limits

Three things are worth saying plainly, because a lot of SEO content quietly implies the opposite.

  • It is not a direct ranking boost. Google's general guidelines say a structured data problem "means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks."2 Structured data changes what your listing can look like. It is not a documented input into where that listing sits in the results.
  • It must match what is actually on the page. The same guidelines are direct: "Don't mark up content that is not visible to readers of the page," and "your structured data must be a true representation of the page content."2 Marking a page as a five-star product when the visible page shows no such rating is not a shortcut, it is the kind of mismatch that gets structured data ignored or penalized.
  • Correct markup does not guarantee a rich result. Google states this outright: "Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly."2 Eligibility is necessary, not sufficient. And, as FAQPage and HowTo show, a rich result you are eligible for today can stop existing entirely with no change on your end.
Key idea
Structured data is a shared vocabulary, usually JSON-LD, that labels what your content means. Search engines use it to understand entities and, separately, to decide rich-result eligibility, never as a direct ranking signal. Markup must match what a reader actually sees, and even accurate markup is not a promise, Google can and does turn features off (HowTo in 2023, FAQ in 2026) with no warning to individual sites.
Read next: How SEO, GEO, and AEO actually work places structured data inside the bigger picture of ranking, answer boxes, and AI citations. Technical SEO for Google and Bing covers the crawlability a page needs before any of this markup matters. The Shipping web apps course goes further into building and maintaining a real, structured site.

Sources

Verified against primary sources: August 2026.

  1. Introduction to structured data markup. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
  2. General structured data guidelines. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/sd-policies
  3. Schema.org. Schema.org (founded by Google, Microsoft, Yahoo and Yandex). https://schema.org/
  4. Understand how structured data works. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data
  5. Rich Results Test. Google. https://search.google.com/test/rich-results
  6. Structured data type gallery. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/search-gallery
  7. FAQ rich result documentation (deprecated May 7, 2026). Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/faqpage
  8. Search Central changelog. Google Search Central. https://developers.google.com/search/updates
Read nextTechnical SEO for Google and Bing
All Guides