Praktischer Guide für strukturierte Daten

JSON-LD Schema Markup Guide für praktische SEO-Arbeit

JSON-LD hilft Suchmaschinen zu verstehen, worum es auf einer Seite geht, wer sie veröffentlicht hat, wie sie in deine Website passt und welche Fakten für unterstützte Suchfunktionen relevant sind.

Das Ziel ist nicht, jeden möglichen Schema-Typ einzubauen. Sinnvoll sind genaue strukturierte Daten, die zur sichtbaren Seite passen, sauber validieren und bei Inhaltsänderungen aktuell bleiben.

Die kurze, nützliche Version

Nutze JSON-LD, wenn du eine Seite mit ehrlichen, sichtbaren Fakten beschreiben kannst: Titel, Beschreibung, Autor, Veröffentlichungsdatum, Breadcrumbs, Produktdetails, Videodaten oder klare Fragen und Antworten. Füge kein Schema ein, nur um Funktionen zu versprechen, die Google nicht mehr anzeigt, oder Inhalte auszuzeichnen, die Nutzer nicht sehen.

Bestes erstes Schema Article, WebPage und BreadcrumbList für die meisten Guide-Seiten.
Bester Workflow Erzeuge Schema aus denselben Metadaten, die auch Title, Description, Canonical und Open Graph steuern.
Bester Realitätscheck FAQPage- und WebSite-Markup können Inhalte weiterhin beschreiben. Baue deine Strategie aber nicht auf Google-Anzeigen, die abgeschafft oder stark eingeschränkt wurden.

Was JSON-LD wirklich macht

JSON-LD ist ein maschinenlesbarer Block strukturierter Daten. Er steht meist in einem Script-Tag im Head oder Body der Seite und beschreibt Entitäten mit dem Vokabular von schema.org. Suchmaschinen nutzen ihn als zusätzliche Klarheitsschicht über dem sichtbaren Inhalt.

Klarheit für Parser

Bedeutung

Es macht aus Seitenfakten benannte Entitäten und Eigenschaften, zum Beispiel Article, author, datePublished, BreadcrumbList oder SoftwareApplication.

Suchfunktion

Eignung

Es kann eine Seite für unterstützte Rich Results qualifizieren. Google entscheidet aber weiterhin anhand von Qualität, Richtlinien, Suchanfrage und Funktionsverfügbarkeit, was angezeigt wird.

Website-Graph

Konsistenz

Es gibt deinem CMS oder deiner Blazor-App einen strukturierten Ort, an dem dieselbe Canonical-URL, Sprache, Titel, Daten, Bilder und Publisher-Daten wiederverwendet werden.

Keine Abkürzung

Grenze

Es repariert keine schwachen Inhalte, Fake-Bewertungen, versteckte FAQ-Antworten, veraltete Daten oder Seiten, die nicht zu den strukturierten Daten passen.

Wichtig: Strukturierte Daten sollen die Seite unterstützen, nicht gute Inhalte ersetzen. Wenn die sichtbare Seite dünn, verwirrend, veraltet oder irreführend ist, macht Schema-Markup daraus kein starkes Suchergebnis.

Schema nach Aufgabe der Seite wählen

Am einfachsten vermeidest du spammy oder doppelte strukturierte Daten, indem du fragst, welche Aufgabe die Seite erfüllt. Füge nur das kleinste Schema-Set hinzu, das diese Aufgabe genau beschreibt.

Inhalte

Article / BlogPosting

Geeignet für
Guides, Tutorials, Reviews, newsähnliche Beiträge und ausführliche Erklärartikel.
Einbauen, wenn
Die Seite hat eine klare Überschrift, Autor oder Publisher, Veröffentlichungsdatum, Änderungsdatum, Canonical-URL und Bild.
Weglassen, wenn
Die Seite ist vor allem eine Tool-Oberfläche, Produktliste, Kategorieseite oder dünne Landingpage.

Navigation

BreadcrumbList

Geeignet für
Fast jede Seite unterhalb der Startseite.
Einbauen, wenn
Nutzer können erkennen, wo die Seite in der Website-Struktur liegt.
Weglassen, wenn
Der Breadcrumb-Pfad widerspricht internen Links, Canonical-URLs oder der sichtbaren Navigation.

Website-Identität

WebPage / WebSite / Organization

Geeignet für
Startseite, Hubs, Über-uns-Seiten und Seiten, bei denen die Publisher-Identität wichtig ist.
Einbauen, wenn
Du möchtest einen stabilen Entitätsgraphen, der Seite, Website, Publisher und Sprache verbindet.
Weglassen, wenn
Du fügst WebSite-Markup nur hinzu, um der alten Sitelinks-Suchbox-Anzeige hinterherzulaufen.

Produkt oder App

Product / SoftwareApplication

Geeignet für
Tools, Apps, SaaS-Seiten, Erweiterungen, herunterladbare Software oder echte Produktseiten.
Einbauen, wenn
Der sichtbare Seiteninhalt enthält Name, Beschreibung, Betriebssystem oder Kategorie, Preis, Angebote und Bewertungen, wenn du diese auszeichnest.
Weglassen, wenn
Bewertungen, Preis, Verfügbarkeit oder Reviews sind für Nutzer auf der Seite nicht sichtbar.

Fragen

FAQPage

Geeignet für
Sichtbare Fragen-und-Antworten-Bereiche, die Nutzern wirklich helfen, das Thema zu verstehen.
Einbauen, wenn
Der Q&A-Inhalt ist auf der Seite nützlich, auch wenn Google keine FAQ Rich Results anzeigt.
Weglassen, wenn
Du fügst generische Q&A nur ein, um Suchfläche zu belegen oder dieselbe Antwort auf vielen Seiten zu wiederholen.

Medien

VideoObject / ImageObject

Geeignet für
Seiten mit einem wichtigen eingebetteten Video, Tutorial-Video oder crawlbaren Bild-Asset.
Einbauen, wenn
Das Medium ist zentral für die Seite und hat Titel, Beschreibung, Thumbnail, Upload-Datum und eine stabile URL.
Weglassen, wenn
Das Medium ist dekorativ, versteckt, blockiert oder für den Hauptzweck der Seite nicht relevant.

Umsetzungs-Checkliste gegen die meisten Fehler

Gutes JSON-LD ist auf die beste Art langweilig: konsistent, aus verlässlichen Feldern erzeugt, leicht zu prüfen und schwer zu vergessen, wenn sich eine Seite ändert.

01

Eine Hauptentität wählen

Entscheide, ob die Seite hauptsächlich ein Artikel, Produkt, eine App, ein Video, eine FAQ, Sammlung oder allgemeine Webseite ist. Sekundäres Schema sollte diese Hauptentität unterstützen.

02

Sichtbaren Inhalt abgleichen

Jede ausgezeichnete Aussage sollte auf der Seite sichtbar oder klar ableitbar sein: Titel, Autor, Daten, Preis, Bewertung, Q&A, Breadcrumbs und Bilder.

03

Stabile @id-Werte nutzen

Gib wichtigen Entitäten stabile IDs, zum Beispiel die Canonical-URL plus #article, #webpage, #organization oder #faq. Das hilft Parsern, Graph-Teile zu verbinden.

04

Aus gemeinsamen Metadaten erzeugen

Nutze dieselben Quellfelder, aus denen Title-Tags, Meta-Descriptions, Canonical-URLs, Open-Graph-Bilder, Sprach-Tags und Änderungsdaten entstehen.

05

Daten ehrlich halten

Ändere dateModified nur, wenn sich relevante Seiteninhalte geändert haben. Aktualisiere Daten nicht automatisch, nur damit Suchergebnisse neuer wirken.

06

Bilder crawlbar machen

Nutze absolute Bild-URLs, passende Abmessungen und Dateien, die nicht durch robots, Authentifizierung oder reines Lazy-Loading blockiert sind.

07

Früh rendern

In Blazor und anderen JavaScript-Apps solltest du prerendered oder servergerendertes JSON-LD bevorzugen, damit Crawler es schon in der ersten HTML-Antwort sehen.

08

Prüfen und beobachten

Führe vor der Veröffentlichung den Rich Results Test aus, prüfe die Syntax im Schema Markup Validator und beobachte die Search Console nach der Indexierung.

Ein sauberes JSON-LD-Muster für Blazor-Seiten

Für Blazor ist das sicherste Muster: Schema während Initialisierung oder Prerendering aus den Seitenmetadaten bauen, einmal serialisieren und das application/ld+json-Script so ausgeben, dass Crawler es schon im initialen HTML sehen.

HTMLArticle-JSON-LD-Beispiel
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/en/json-ld-schema-guide/#article",
  "headline": "JSON-LD Schema Markup Guide for Practical SEO",
  "description": "A practical guide to choosing, generating, and validating structured data.",
  "image": "https://example.com/images/json-ld-guide.png",
  "datePublished": "2026-03-28T10:00:00+00:00",
  "dateModified": "2026-05-31T10:00:00+00:00",
  "author": {
    "@type": "Organization",
    "name": "Example Publisher"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publisher",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/en/json-ld-schema-guide/"
  }
}
</script>
C#C#-Helper-Muster
private MarkupString BuildJsonLd(PageMetaData meta)
{
    var pageUrl = BuildPageUrl(meta);

    var schema = new Dictionary<string, object?>
    {
        ["@context"] = "https://schema.org",
        ["@type"] = "Article",
        ["@id"] = $"{pageUrl}#article",
        ["headline"] = meta.Title,
        ["description"] = meta.Description,
        ["url"] = pageUrl,
        ["datePublished"] = meta.Published?.ToString("O"),
        ["dateModified"] = meta.Modified?.ToString("O"),
        ["inLanguage"] = CS.Culture
    };

    var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
    {
        DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
    });

    return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}
Praktische Regel: Nutze stabile URLs für url und @id. Verwende überall dieselbe Canonical-URL. Wenn dieselbe Seite unter mehreren Sprach-URLs erscheint, erzeugst du sprachspezifische Metadaten und hältst hreflang und Canonical konsistent.

JSON-LD prüfen, bevor du dich darauf verlässt

Validierung hat zwei Aufgaben. Der Schema Markup Validator prüft, ob Vokabular und JSON-LD-Syntax verständlich sind. Googles Rich Results Test prüft, ob Google die Seite für unterstützte Rich-Result-Typen erkennt.

Google-Eignung

Test für erweiterte Suchergebnisse

Prüft, ob Google die Seite lesen kann und ob erkannte strukturierte Daten für unterstützte Rich-Result-Typen geeignet sind.

Rich Results Test öffnen

Vokabular

Schema-Markup-Validator

Prüft die allgemeine schema.org-Struktur und JSON-LD-Syntax, einschließlich Typen, Eigenschaften, verschachtelter Entitäten und fehlerhaftem JSON.

Schema Markup Validator öffnen

Nach der Veröffentlichung

Search Console

Nutze URL-Prüfung und Enhancement-Berichte, um Crawl-, Indexierungs- und Structured-Data-Probleme zu erkennen, nachdem Google die Seite verarbeitet hat.

Google-Doku zu strukturierten Daten lesen

JSON-LD-Fehler, die Vertrauen kosten

Die meisten Schema-Probleme sind keine komplizierten technischen Fehler. Es sind Widersprüche zwischen dem Markup und dem, was Nutzer oder Crawler auf der Seite prüfen können.

Versteckte oder fehlende Inhalte auszeichnen

Wenn Nutzer eine Antwort, Bewertung, ein Angebot, Bild oder eine Autorenaussage nicht sehen können, gehört es nicht in strukturierte Daten. So verliert man am schnellsten Vertrauen.

FAQPage überall einbauen

FAQ-Schema kann sichtbare Q&A weiterhin beschreiben, sollte aber kein Copy-Paste-Block auf jedem Artikel sein. Nutze es nur, wenn die Q&A die Seite wirklich verbessern.

Widersprüchliche doppelte Scripts

Mehrere Article-Blöcke mit unterschiedlichen Überschriften, Daten oder URLs machen die Seite schwerer verständlich. Ein klarer Graph ist besser als drei halbe.

Falsche Canonical-URL oder @id

Schema-URLs sollten zur Canonical-Seite, Sprach-URL und hreflang-Konfiguration passen. Gemischte Sprach-URLs erzeugen Duplicate-Content- und Entitätsverwirrung.

Künstliche Aktualität

Erhöhe dateModified nicht für Template-Anpassungen, Tracking-Änderungen oder reine Schema-Updates. Nutze das Datum für echte Inhaltsänderungen.

Spätes Client-only-Rendering

Wenn JSON-LD erst nach einem verzögerten Client-Render erscheint, können Crawler es übersehen. Für wichtige Seiten sind Server Rendering oder Prerendering besser.

Praktische Schema-Rezepte nach Seitentyp

Du brauchst selten einen riesigen Graphen. Diese Kombinationen decken die Seiten ab, die kleine Websites, Blogs, Tools und Review-Projekte wirklich veröffentlichen.

Guide-Artikel

Article + BreadcrumbList + WebPage

  • Nutze Article für Überschrift, Autor, Publisher, Bild, Daten und Abschnittsnamen.
  • Nutze BreadcrumbList für den sichtbaren Seitenpfad.
  • Nutze WebPage oder @id-Referenzen, um Seite und Artikel-Entität zu verbinden.

Tool-Seite

SoftwareApplication + WebPage + BreadcrumbList

  • Nutze SoftwareApplication nur, wenn die Seite eine echte App oder ein echtes Tool behandelt.
  • Nimm Betriebssystem, Kategorie, Preis oder Angebotsdetails nur auf, wenn sie sichtbar sind.
  • Vermeide Review- oder Rating-Markup, wenn die Seite keine echten Bewertungsdaten zeigt.

Review-Seite

Review / Product nur, wenn die Seite es trägt

  • Zeichne getestetes Objekt, Autor, Datum und Bewertung nur aus, wenn die Seite sie klar zeigt.
  • Halte Affiliate-Links und kommerziellen Kontext transparent.
  • Nutze im Schema dieselbe Bewertung wie im sichtbaren Inhalt.

Fragen-Seite

FAQPage nur für nützliche sichtbare Q&A

  • Jede Antwort sollte für sich hilfreich sein und nicht nur eine Keyword-Variante.
  • Verstecke Antworten nicht hinter UI, auf die Crawler nicht zugreifen können.
  • Erwarte FAQ Rich Results nicht als Hauptvorteil.

Geprüfte Quellen

Die Empfehlungen oben basieren auf offizieller Dokumentation von Google Search Central und schema.org und wurden in eine praktische JSON-LD-Checkliste übersetzt.

01 Google: Einführung in strukturierte Daten developers.google.com 02 Google: Richtlinien für strukturierte Daten developers.google.com 03 Google: strukturierte Daten für Article developers.google.com 04 Google: strukturierte Daten für Breadcrumbs developers.google.com 05 Google: strukturierte Daten für FAQ developers.google.com 06 Google: Update zur Sitelinks-Suchbox developers.google.com 07 Schema.org Einstieg schema.org 08 Google Rich Results Test search.google.com 09 Schema-Markup-Validator validator.schema.org

Häufige Fragen

Ist JSON-LD Schema Markup ein Rankingfaktor?

JSON-LD selbst ist kein magischer Ranking-Schalter. Es hilft Suchmaschinen, geeignete Inhalte zu verstehen, und kann Rich-Result-Eignung unterstützen. Rankings hängen aber weiterhin von Inhaltsqualität, Relevanz, Crawlability, Links und vielen weiteren Signalen ab.

Wo sollte JSON-LD auf einer Seite stehen?

Ein Script-Tag im Head ist meist am einfachsten zu pflegen. Google kann JSON-LD aber auch im Body lesen. Wichtig ist, dass das Markup in der gerenderten Seite vorhanden ist und zum sichtbaren Inhalt passt.

Sollte ich FAQPage-Schema noch nutzen?

Nutze FAQPage nur, wenn die Seite wirklich nützliche sichtbare Fragen und Antworten hat. Verlass dich nicht auf zusätzlichen Platz in Google, denn FAQ Rich Results wurden für die meisten normalen Seiten stark eingeschränkt und de facto abgeschafft.

Kann eine Seite mehrere JSON-LD-Blöcke haben?

Ja. Eine normale Artikelseite kann Article-, BreadcrumbList- und WebPage-Daten haben. Halte die Blöcke konsistent, vermeide doppelte widersprüchliche Entitäten und nutze stabile @id-Werte, um zusammengehörige Teile zu verbinden.

Ist JSON-LD besser als Microdata?

Für die meisten modernen Seiten: ja. Google unterstützt JSON-LD, Microdata und RDFa, aber JSON-LD ist meist leichter zu pflegen, weil keine Schema-Attribute direkt in sichtbaren HTML-Templates nötig sind.

Wie oft sollte ich strukturierte Daten validieren?

Validiere immer dann, wenn du Templates, Metadatenfelder, Schema-Helper, URLs, Sprachrouting, Bilderzeugung, Review-Daten oder FAQ-Bereiche änderst. Prüfe außerdem die Search Console, nachdem wichtige Seiten indexiert wurden.