Main area
Agency
technisches-seo

JSON-LD and Structured Data — The Basics

Redaktion ·

A search engine sees a product page differently than you do. You instantly recognize: that’s the price, that’s the rating, that’s the availability. A crawler at first sees only text and HTML tags and has to guess what means what. Structured data is the answer: machine-readable markup that explicitly says “this is a product, this is its price, this is its rating” — using a standardized vocabulary that all major search engines understand.

That vocabulary is schema.org — a catalog of types (Product, Article, Recipe, Organization, FAQPage …) and their properties, maintained jointly by Google, Microsoft, Yahoo, and Yandex. schema.org defines the what. The how — the syntax you use to write that markup into the page — is a separate question. And here Google has a clear preference.

Why JSON-LD and not Microdata

There are three syntaxes for implementing schema.org markup: Microdata, RDFa, and JSON-LD. Microdata and RDFa weave the markup directly into the visible HTML — every <div>, every <span> gets extra attributes. That’s error-prone: if a developer changes the template, the markup easily breaks, and the HTML becomes unreadable.

JSON-LD takes the other route. The entire structured data sits as a JSON block inside a <script type="application/ld+json"> tag, decoupled from the visible HTML. Layout and data live separately. Google states it clearly (per Search Central, June 2026): JSON-LD is the recommended solution because it’s the easiest to implement and maintain at scale. Technically all three formats are valid — but if you’re starting fresh, pick JSON-LD.

How a JSON-LD block is built

A JSON-LD block is a normal JSON object with two mandatory keys and any number of properties:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "JSON-LD and Structured Data — The Basics",
  "author": {
    "@type": "Person",
    "name": "Redaktion"
  },
  "datePublished": "2026-06-06"
}

@context declares that the vocabulary comes from schema.org. @type says what the object is — here an Article. Everything else is a property of that type. The block typically goes in the <head> or at the end of the <body>. You can have several blocks per page or nest multiple objects (for instance, an Author as a Person inside the Article).

The one ground rule: only mark up what’s visible

This is the most important rule, and it’s the most frequently broken: only mark up content that is actually visible on the page. Google is explicit here — no markup for information the user doesn’t see, even if it’s accurate. No blank pages that exist only to hold structured data.

The reason isn’t bureaucracy but abuse prevention. Marking up a five-star rating when no rating appears anywhere on the page manipulates the display. Google penalizes this with a manual action — in the worst case the structured data of the entire domain drops out of search results. The visible page and the markup must match.

What structured data delivers — and what it doesn’t

The best-known benefit is rich results: enhanced search listings with stars, images, FAQ accordions, prices, or recipe cards. They increase visibility and often the click-through rate. But — and this is the key distinction — valid markup does not guarantee a rich result. It only makes the page eligible. Whether Google actually shows the enhanced display is Google’s call, based on its own quality and relevance criteria. You meet the prerequisite; the display stays Google’s decision.

Beyond rich results, structured data has a growing, less visible function: it helps machines understand entities and their relationships — who is the author, which organization do they belong to, what is the topic. This feeds into entity SEO and gains importance with AI-generated answers (AI Overviews, GEO): an AI system that wants to cite a page benefits from unambiguously marked-up facts. Structured data is therefore not just SERP decoration but infrastructure for machine understanding.

Validate every markup with the Rich Results Test and, after deployment, via the Search Console reports — broken syntax is silently ignored, and a typo in @type makes the whole block worthless. How structured data fits into the larger arc of crawling, rendering, and indexing is in the hub Technical SEO.

FAQ

Do I strictly need structured data for good rankings? No, structured data is not a direct ranking factor. A page can rank excellently without it. But it unlocks rich results and improves machine understanding — both of which act indirectly on visibility and click-through rate. For most production sites, marking up the core content is worth it.

What’s the difference between schema.org and JSON-LD? schema.org is the vocabulary — the catalog of types and properties, the what. JSON-LD is a syntax, the how you write that vocabulary into the page. schema.org markup can also be implemented in Microdata or RDFa; Google recommends JSON-LD.

Why does no rich result appear even though my markup is valid? Valid markup only makes the page eligible — it does not guarantee the enhanced display. Google decides based on quality, relevance, and its own criteria whether to show a rich result. Also check that all required properties of the type are set and that the Search Console reports no errors.

May I mark up ratings that aren’t on the page? No. Google requires that only visible content be marked up. Tagging stars or facts the user sees nowhere on the page counts as manipulation and can trigger a manual action that, in the worst case, devalues all structured data on the domain.

Where does the JSON-LD block belong in the HTML? In a <script type="application/ld+json"> tag, usually in the <head> or at the end of the <body>. Since JSON-LD is decoupled from the visible HTML, the exact position is uncritical. You can use several blocks per page or nest objects within one another.

Themenuebersicht

Technisches SEOStructured Data