Structured Data und JSON-LD: Praktischer SEO-Implementierungsleitfaden

前端工程

Structured Data hilft Suchmaschinen zu verstehen, worum es auf einer Seite geht. JSON-LD ist die häufigste Methode, weil maschinenlesbare Daten getrennt vom sichtbaren HTML bleiben.

Structured Data kann eine Seite für erweiterte Suchfunktionen qualifizieren, garantiert aber keine Rich Results. Google und andere Suchmaschinen entscheiden anhand von Seitenqualität, Suchintention, Eligibility-Regeln und vielen weiteren Signalen, was angezeigt wird.

Nützliche Referenzen:

Was Structured Data leistet

Structured Data gibt Seiteninhalten explizite Bedeutung. Statt nur Text zu sehen, kann eine Suchmaschine verstehen, dass eine Seite ein Artikel, Produkt, Software-Anwendung, Breadcrumb Trail, FAQ-Bereich oder ein anderer erkannter Entity-Typ ist.

Gute Structured Data sollte:

  • Mit dem sichtbaren Seiteninhalt übereinstimmen.
  • Den spezifischsten passenden Schema.org-Typ verwenden.
  • Erforderliche und empfohlene Properties enthalten.
  • Genau bleiben, wenn sich Inhalte ändern.
  • Vor dem Deployment validiert werden.

Verwenden Sie Structured Data nicht für Inhalte, die Nutzer nicht sehen können. Das ist ein häufiges Qualitätsproblem und kann Markup unzulässig machen.

Warum JSON-LD meist das beste Format ist

Es gibt mehrere Structured-Data-Formate, aber JSON-LD ist meist am einfachsten zu warten.

Format Einbindung Wartung
JSON-LD Ein <script type="application/ld+json">-Block Sauber und getrennt von HTML
Microdata Attribute in HTML-Elementen Kann bei Template-Änderungen leicht brechen
RDFa Attribute in HTML-Elementen Leistungsfähig, aber komplexer

Mit JSON-LD kann sich das Frontend-Markup ändern, ohne jedes Structured-Data-Attribut neu zu schreiben.

Grundmuster für JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data and JSON-LD: Practical SEO Implementation Guide",
  "description": "Learn how to add JSON-LD structured data safely.",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

Die Kernfelder sind:

  • @context: normalerweise https://schema.org.
  • @type: der Schema.org-Typ, etwa Article.
  • Properties: Felder, die die Entity beschreiben, etwa headline, author oder datePublished.

Article Markup

Verwenden Sie Article, BlogPosting oder NewsArticle für redaktionelle Inhalte. Wählen Sie den Typ, der am besten zur Seite passt. Für normale Blogposts ist BlogPosting oft passend.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Split a PDF Safely",
  "description": "A practical guide to extracting and splitting PDF pages.",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

Bleiben Sie bei Datumsangaben ehrlich. Aktualisieren Sie dateModified nicht nur, um Inhalte frischer aussehen zu lassen, wenn sich die Seite nicht tatsächlich geändert hat.

Breadcrumb Structured Data hilft Suchmaschinen, die Seitenhierarchie zu verstehen.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

Der Breadcrumb Trail in JSON-LD sollte zur Navigation passen, die Nutzer auf der Seite nachvollziehen können.

FAQPage Markup

Fügen Sie FAQPage-Markup nur hinzu, wenn die Seite tatsächlich sichtbare Fragen und Antworten enthält. Erfinden Sie keine FAQs nur für Rich Results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does structured data guarantee rich results?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Structured data can make a page eligible, but search engines decide whether to show enhanced results."
      }
    },
    {
      "@type": "Question",
      "name": "Should JSON-LD match visible page content?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Markup should describe content that users can also see on the page."
      }
    }
  ]
}
</script>

FAQ-Markup ist keine Abkürzung zu mehr Suchfläche. Nutzen Sie es nur, wenn es die Klarheit für Nutzer verbessert.

SoftwareApplication Markup

Für Online-Tools, Apps oder herunterladbare Software kann SoftwareApplication beschreiben, was die Seite anbietet.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

Fügen Sie nur Felder hinzu, die wahr sind. Wenn Sie Ratings, Reviews, Preise oder Plattformangaben hinzufügen, müssen sie durch sichtbare Seiteninhalte und den tatsächlichen Produktzustand gestützt sein.

Mehrere JSON-LD-Blöcke

Sie können mehrere Structured-Data-Entities auf einer Seite einbinden. Ein Blogartikel kann zum Beispiel zusätzlich Breadcrumbs haben.

Entweder als getrennte Script-Blöcke:

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

Oder als Array:

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

Getrennte Blöcke sind oft einfacher aus Templates zu generieren.

Validierungs-Workflow

Nutzen Sie vor Veröffentlichung einen einfachen Ablauf:

  1. JSON-LD aus denselben Quelldaten generieren, die auch die Seite verwendet.
  2. Prüfen, dass das Markup gültiges JSON ist.
  3. URL oder Code durch den Rich Results Test laufen lassen.
  4. Nach der Indexierung Structured-Data-Berichte in der Search Console überwachen.
  5. Templates nach großen Design-, Routing- oder CMS-Änderungen erneut prüfen.

Eine bestandene Validierung bedeutet, dass Syntax und einige Eligibility-Regeln erfüllt sind. Sie garantiert weiterhin kein Rich Result.

Häufige Fehler

Markup passt nicht zum sichtbaren Inhalt

Wenn JSON-LD Reviews, FAQs, Preise oder Autorendetails angibt, sollten Nutzer diese Details auf der Seite prüfen können.

Falscher Typ

Nutzen Sie nicht für jede Tool-Seite Product, nur weil Product Rich Results attraktiv aussehen. Verwenden Sie den Typ, der zur Seite passt.

Erfundenes oder nicht belegtes Rating

Review- und Rating-Markup braucht echte sichtbare Bewertungen. Erfinden Sie keine Aggregate Ratings.

Uneinheitliche Datumsangaben

datePublished und dateModified sollten zum tatsächlichen Content-Lifecycle passen. Aktualisieren Sie Modified-Daten nur bei sinnvollen Änderungen.

Defekte URLs

Bild-, Logo-, Canonical- und Seiten-URLs sollten absolut, crawlbar und stabil sein.

Locale-Mismatch

Bei mehrsprachigen Websites sollte jede lokalisierte Seite Structured Data in derselben Sprache wie die Seite haben; korrekte Canonical- und Alternate-Links werden an anderer Stelle der Seite behandelt.

Implementierungstipps

  • Generieren Sie Structured Data aus CMS- oder Seitenmetadaten, nicht manuell auf jeder Seite.
  • Escapen Sie nutzergenerierten Text korrekt, damit JSON gültig bleibt.
  • Pflegen Sie ein wiederverwendbares Template pro Seitentyp.
  • Testen Sie repräsentative Seiten, nicht nur die Startseite.
  • Validieren Sie nach Änderungen an Routen, Slugs, Autorprofilen oder Bildgenerierung erneut.
  • Behandeln Sie Warnungen als Verbesserungsmöglichkeiten, priorisieren Sie aber Fehler zuerst.

Abschluss-Checkliste

Vor dem Ausliefern von JSON-LD prüfen Sie:

  • Das Markup beschreibt sichtbare Seiteninhalte.
  • Der Schema.org-Typ passt zur Seite.
  • Erforderliche Felder sind vorhanden.
  • URLs sind absolut und crawlbar.
  • Daten, Autoren, Titel und Beschreibungen passen zur Seite.
  • Die Seite besteht den Rich Results Test, wo anwendbar.
  • Search Console wird nach Deployment überwacht.

Structured Data ist kein Trick, um reichere Suchergebnisse zu erzwingen. Es ist eine saubere Methode, Seitenbedeutung explizit zu machen. Wenn es korrekt, gepflegt und am sichtbaren Inhalt ausgerichtet ist, erhöht es die Chance, dass Suchmaschinen den Inhalt richtig verstehen.

Probiere diese browser-lokalen Tools aus — keine Registrierung erforderlich →

#JSON-LD#结构化数据#SEO#Schema.org#富摘要