Schema.org strukturierte Daten: die Umsetzung

Ist das Prinzip der strukturierten Daten einmal verstanden, bleibt die praktische Frage: Welche Schema.org-Typen zuerst implementieren, wie das entsprechende JSON-LD schreiben und wie prüfen, ob das Markup gültig ist.

Die prioritären Typen

Fünf Typen decken den Großteil der Anforderungen einer Website ab:

Organization: die Identität des Unternehmens (Name, Logo, Social-Media-Profile, Kontaktdaten) — in der Regel einmal auf der Startseite oder global festgelegt.
Product: eine Produktseite mit Preis, Verfügbarkeit und Bewertungen.
FAQPage: eine Liste von Fragen und Antworten, besonders nützlich, um direkt in einer generativen KI-Antwort aufgegriffen zu werden.
Article: redaktioneller Inhalt (Blog, News, Ratgeber) mit Autor, Veröffentlichungs- und Aktualisierungsdatum.
BreadcrumbList: die Breadcrumb-Navigation, die die Position einer Seite in der Website-Hierarchie explizit macht.

Weitere Typen existieren für spezifischere Anforderungen: Event für eine Veranstaltung mit Datum und Ort, LocalBusiness für ein Unternehmen mit physischer Adresse und Öffnungszeiten, Review für eine einzelne Bewertung, getrennt von einer aggregierten Bewertung, oder HowTo für in Schritte gegliederten Inhalt. Es ist sinnvoller, die fünf prioritären Typen korrekt zu implementieren, bevor man das Markup auf spezialisiertere Typen ausweitet, deren Nutzen stark von der Branche abhängt.

Kommentiertes JSON-LD-Beispiel

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Produktname",
  "description": "Kurze, sachliche Produktbeschreibung.",
  "brand": {
    "@type": "Brand",
    "name": "Markenname"
  },
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

Jede Eigenschaft sollte eine tatsächlich vorhandene und auf der Seite überprüfbare Information widerspiegeln: Der angezeigte Preis muss dem ausgezeichneten Preis entsprechen, die Durchschnittsbewertung muss echten, einsehbaren Bewertungen entsprechen.

Für eine Seite mit häufig gestellten Fragen:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Wie lange dauert die Einrichtung?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Die Einrichtung dauert je nach Projektkomplexität in der Regel 2 bis 5 Werktage."
      }
    }
  ]
}
</script>

Wo der Code platziert wird

JSON-LD wird in der Regel im <head> oder direkt vor dem schließenden </body>-Tag eingefügt, ohne jede Abhängigkeit vom visuellen Layout der Seite — anders als semantisches HTML5-Markup, das eng an die visuelle Struktur des Dokuments gebunden bleibt. Das ist einer der Vorteile von JSON-LD gegenüber alternativen Syntaxen (Microdata, RDFa), die eine direkte Annotation der sichtbaren HTML-Tags erfordern. Diese Unabhängigkeit vom visuellen Rendering ermöglicht es auch, das Markup dynamisch aus einer Datenbank zu generieren (Produktkatalog, Content-Management-System) — ohne manuellen Eingriff auf jeder einzelnen Seite. Das macht es besonders geeignet für Websites mit einer großen Zahl ähnlicher Seiten.

Validierungstools

Vor der Veröffentlichung sind zwei Prüfungen unerlässlich: die syntaktische Validierung (ist das JSON wohlgeformt, ohne überflüssiges Komma oder fehlendes Anführungszeichen) und die semantische Validierung (existieren die verwendeten Typen und Eigenschaften im Schema.org-Vokabular, und sind sie untereinander konsistent). Die Rich-Results-Testtools von Google und die Schema.org-Validatoren der Community helfen dabei, beide Fehlerkategorien vor dem Livegang zu erkennen und zu prüfen, dass keine für den verwendeten Typ erforderliche Eigenschaft fehlt.

Diese Prüfung sollte nach jeder Änderung des Templates, das das Markup generiert, wiederholt werden, nicht nur bei der ursprünglichen Implementierung: Ein CMS-Update, eine Änderung der Datenbankstruktur oder ein Theme-Update können einen dynamisch generierten JSON-LD-Block stillschweigend zerstören, ohne dass dies auf der Seite visuell erkennbar wäre.

Mehrere Typen auf derselben Seite kombinieren

Eine Seite kann legitim mehrere Schema.org-Blöcke gleichzeitig tragen: Eine Produktseite kann Product für den Eintrag selbst, BreadcrumbList für die Breadcrumb-Navigation und Organization für die Identität der verkaufenden Marke kombinieren. Diese Blöcke können separat in mehreren <script>-Tags deklariert oder über die Eigenschaft @graph in einem einzigen Block zusammengefasst werden, mit der sich mehrere Entitäten innerhalb eines einzigen JSON-LD-Dokuments explizit miteinander verknüpfen lassen. Dieser zweite Ansatz wird vorzuziehen, sobald Entitäten sich gegenseitig referenzieren müssen (der Autor eines Artikels, die Marke eines Produkts), da er die Duplizierung von Informationen über mehrere unabhängige Blöcke hinweg vermeidet.

Häufige Fehler

Doppeltes oder widersprüchliches Markup zwischen mehreren JSON-LD-Blöcken auf derselben Seite.
Ausgezeichnete Daten, die nach einer Aktualisierung nicht mehr mit dem sichtbaren Inhalt übereinstimmen (Preis auf der Seite geändert, aber nicht im JSON-LD).
Verwendung eines Schema.org-Typs, der nicht wirklich zum Inhalt passt (eine Blogseite als Product auszeichnen).
Fehlerhaftes JSON, das den gesamten Block stillschweigend ungültig macht.
Sekundäre Typen vervielfachen, bevor die prioritären Typen korrekt implementiert und validiert wurden.

Diese Lektion schließt den Teil des Moduls zum technischen Markup ab. Die anschließende vollständige technische Checkliste fasst alle bisher behandelten Punkte in einer umsetzbaren Liste zusammen, bevor es zu den eigentlichen Grundlagen von GEO übergeht.