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 builds valid JSON-LD for common types, and the FAQ schema generator and 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 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.