Structured data (JSON-LD) that search engines actually use

schema.org defines hundreds of vocabulary types, but only a small subset of them are actually consumed by search engines to produce visible rich results. Marking up a type that Google doesn't parse for rich results isn't harmful, but it also isn't worth the engineering effort if a rich-result feature is the goal.

JSON-LD is the recommended format

Structured data can be expressed as JSON-LD, Microdata, or RDFa; Google explicitly recommends JSON-LD because it's a self-contained `<script>` block that doesn't require interleaving attributes throughout your HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "Simple Tomato Soup",
  "author": { "@type": "Person", "name": "Jane Doe" },
  "prepTime": "PT15M",
  "recipeIngredient": ["4 tomatoes", "1 onion", "2 tbsp olive oil"]
}
</script>

Types with a real, documented rich-result payoff

• **`Article` / `NewsArticle`** — enables headline, image and publish-date display in some result formats.
• **`Product`** — price, availability and review ratings in shopping-related results, when the marked-up data matches what's visibly on the page.
• **`Recipe`** — cook time, ratings and image carousels in recipe-specific result formats.
• **`FAQPage`** — expandable question/answer accordions directly in search results, only when the questions and answers are genuinely visible on the page to a visitor.
• **`HowTo`** — step-by-step display for instructional content.
• **`BreadcrumbList`** — replaces the raw URL in the result snippet with a breadcrumb trail matching your site's navigation.
• **`Organization` / `WebSite`** — powers sitelinks search box and knowledge panel details at the site level, not per-page.
• **`SoftwareApplication`** — used for tool/app pages to show category, rating and pricing information.
• **`JobPosting`, `Event`, `LocalBusiness`, `VideoObject`** — each has its own dedicated rich-result format for job boards, events, local listings and video search respectively.

Types that mostly don't do anything visible

Generic types like `Thing`, `CreativeWork`, or deeply nested custom vocabularies rarely correspond to any rich-result feature. Marking up data with these doesn't hurt, but treating "we added schema.org markup" as a checkbox without checking whether that specific type has a documented rich-result feature is effort spent for no visible outcome.

The rule that actually gets enforced: markup must match visible content

Search engines' structured data guidelines are explicit that marked-up content must be visible to users on the page. Adding an `FAQPage` schema for questions that aren't rendered anywhere in the HTML, or a `Product` schema with a rating that doesn't appear on the page, is a policy violation that can result in the rich result being suppressed or, in repeated cases, a manual action against the site. The markup should describe what a visitor actually sees, not what you wish they saw.

Nesting and `@id` for connected entities

For pages with related entities — an `Article` written by an `Organization`, appearing on a `WebPage` that's part of a `WebSite` — nested objects are usually clearer than separate top-level blocks, and using `@id` lets you reference the same entity from multiple places without duplicating it:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How CSP Works",
  "author": { "@id": "https://example.com/#organization" },
  "publisher": { "@id": "https://example.com/#organization" }
}

Testing before you ship

Structured data is easy to get syntactically valid but semantically wrong (mismatched types, missing required properties for a given rich-result feature). Validate the generated JSON-LD against the actual visible page content, not just against JSON syntax, before deploying it. The [schema generator](/tools/seo/schema-generator) builds valid JSON-LD for common types, and the [FAQ schema generator](/tools/seo/faq-schema-generator) and [breadcrumb schema generator](/tools/seo/breadcrumb-schema-generator) handle two of the most commonly implemented rich-result types directly. For validating the shape of arbitrary JSON structures more generally, a [JSON schema generator](/tools/json/json-schema-generator) is a related but separate concept — schema.org vocabulary describes semantic meaning for search engines, while JSON Schema describes structural validation rules for data.

Takeaway

Pick structured data types based on which rich-result feature you actually want, verify it's a type search engines document a visible payoff for, and keep the markup honest with what's on the page — that's the entire difference between structured data that helps and structured data that's ignored or penalized.