Schema.org Grundlagen: Strukturierte Daten richtig nutzen

1. Was Schema.org ist und warum strukturierte Daten für Rich Results zählen

Schema.org ist ein gemeinsam von Google, Microsoft, Yahoo und Yandex getragenes Vokabular, das Webinhalten eine maschinenlesbare Bedeutung gibt. Statt nur Fließtext zu crawlen, kann eine Suchmaschine mit strukturierten Daten exakt erkennen: Dies ist ein Produkt, es kostet 49,90 Euro, ist auf Lager und hat 128 Bewertungen mit einem Schnitt von 4,7 Sternen. Diese Eindeutigkeit ist die Grundlage für Rich Results, also erweiterte Suchergebnisse mit Sternen, Preisen, Breadcrumbs oder FAQ-Aufklappern direkt in der SERP.

Der Effekt ist messbar: Rich Results beanspruchen mehr Fläche im Suchergebnis, erhöhen das Vertrauen durch sichtbare Bewertungen und verbessern die Klickrate spürbar gegenüber einem reinen Text-Snippet. Wichtig ist die Unterscheidung: Strukturierte Daten selbst sind kein direkter Rankingfaktor, Google bestätigt das ausdrücklich. Sie sind aber die Voraussetzung dafür, dass Google ein Ergebnis überhaupt als Kandidat für ein Rich Result in Betracht zieht. Ohne korrektes Markup bleibt selbst die beste Produktseite ein einfacher blauer Link.

2. Vokabular-Basics: Types, Properties und die Schema.org-Hierarchie

Schema.org organisiert sich in Types (Entitätstypen wie Product, Article oder Organization) und Properties (Eigenschaften dieser Typen wie name, price oder author). Die Types sind hierarchisch als Baum organisiert: Product erbt von Thing, genau wie LocalBusiness von Organization erbt, die wiederum von Thing erbt. Diese Vererbung bedeutet praktisch, dass jeder Type automatisch alle Properties seiner Eltern-Types mitbringt, etwa name, description und image, die auf der Basisebene Thing definiert sind.

Manche Properties erwarten einfache Werte wie Text oder Zahlen, andere erwarten ein verschachteltes Objekt eines anderen Types, sogenannte Nested Types. Ein Product hat zum Beispiel eine offers-Property, die selbst ein Offer-Objekt mit eigenen Properties wie price und availability erwartet. Diese Verschachtelung bildet reale Datenstrukturen ab, verlangt aber auch Präzision: Ein falsch platziertes Feld, etwa price direkt am Product statt im verschachtelten Offer, wird von Validatoren als Fehler markiert, selbst wenn der Wert selbst korrekt aussieht.

3. JSON-LD vs. Microdata vs. RDFa: warum JSON-LD der De-facto-Standard ist

Schema.org lässt sich in drei Syntaxen einbetten: JSON-LD, Microdata und RDFa. Microdata und RDFa verweben strukturierte Daten direkt als Attribute in den sichtbaren HTML-Code, etwa mit itemscope, itemprop und itemtype. Das funktioniert, koppelt Markup und Layout aber eng aneinander: Jede Änderung am HTML-Template riskiert, das strukturierte Datenmodell versehentlich zu zerstören, weil Attribute an spezifischen DOM-Knoten hängen.

JSON-LD löst dieses Problem, indem es strukturierte Daten als eigenständigen <script type="application/ld+json">-Block einbettet, unabhängig vom sichtbaren HTML. Das erlaubt es, Markup zentral in einem einzigen Block zu pflegen, ohne das Template aufzubrechen, und macht es einfach, komplexe verschachtelte Strukturen sauber zu formatieren. Google empfiehlt JSON-LD offiziell als bevorzugte Methode, und in der Praxis ist es inzwischen der De-facto-Standard: Es lässt sich per JavaScript dynamisch generieren, serverseitig einfach in phtml-Templates injizieren und unabhängig vom restlichen Markup validieren, ohne dass CSS-Änderungen am Frontend das Datenmodell beeinflussen.

{
  // JSON-LD: eigenstaendiger Block, unabhaengig vom sichtbaren HTML
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Beispielprodukt",
  "sku": "MS-1234",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "price": "49.90",
    "availability": "https://schema.org/InStock"
  }
}

4. JSON-LD in Magento/Hyvä implementieren

In einem Hyvä-Theme wird JSON-LD am saubersten über ein eigenes phtml-Template mit zugehörigem ViewModel ausgeliefert, das per Layout-XML in page.head.additional oder direkt vor dem schließenden </body>-Tag eingehängt wird. Das ViewModel liefert die reinen Daten (Produktname, Preis, Verfügbarkeit), das Template kümmert sich ausschließlich um die JSON-Serialisierung mit json_encode() und den sauberen Escape der Ausgabe. Wichtig ist, niemals Rohdaten ungeprüft in den JSON-LD-Block zu interpolieren, da fehlerhaftes Escaping sowohl das JSON bricht als auch ein XSS-Risiko öffnet.

Da Hyvä konsequent auf Content Security Policy (CSP) setzt, muss jeder Inline-Script-Block, auch JSON-LD, über den hyvaCsp-ViewModel-Helper registriert werden, damit der Browser ihn nicht als Verstoß gegen die CSP-Richtlinie blockiert. Für Organization- und WebSite-Schema, die auf jeder Seite identisch sind, lohnt sich ein globaler Block im Default-Layout, während produktbezogenes Product-Schema nur auf der Produktdetailseite gerendert werden sollte, um keine falschen Daten auf Kategorie- oder CMS-Seiten auszuliefern.

<?php
/**
 * @var \Magento\Framework\View\Element\Template $block
 * @var \Mironsoft\SeoSuite\ViewModel\SchemaOrganization $viewModel
 * @var \Hyva\Theme\ViewModel\HyvaCsp $hyvaCsp
 */
$viewModel = $block->getViewModel();
$hyvaCsp = $viewModel->getHyvaCsp();
?>
<script type="application/ld+json">
<?= /* @noEscape */ json_encode([
    '@context' => 'https://schema.org',
    '@type' => 'Organization',
    'name' => $viewModel->getOrganizationName(),
    'url' => $viewModel->getBaseUrl(),
    'logo' => $viewModel->getLogoUrl(),
], JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) ?>
</script>
<?php $hyvaCsp->registerInlineScript() ?>

5. Von strukturierten Daten zu Rich Results: welche Typen was bringen

Nicht jeder Schema-Type führt zu einem sichtbaren Rich Result, Google unterhält eine begrenzte, dokumentierte Liste unterstützter Typen. Product-Schema ermöglicht Preis-, Verfügbarkeits- und Bewertungssterne direkt im Suchergebnis. BreadcrumbList ersetzt die reine URL-Anzeige durch eine lesbare Navigationspfad-Anzeige. FAQPage blendet aufklappbare Frage-Antwort-Paare direkt unter dem Snippet ein und beansprucht damit deutlich mehr vertikalen Platz in der SERP.

Review und AggregateRating erzeugen die bekannten gelben Sterne, allerdings nur, wenn die Bewertungen tatsächlich von echten Nutzern stammen und öffentlich sichtbar sind, selbst erstellte oder unvollständige Bewertungsdaten werden von Google als Spam gewertet und können zu manuellen Maßnahmen führen. Organization- und WebSite-Schema wirken sich seltener auf Rich Snippets im klassischen Sinn aus, liefern aber die Grundlage für das Knowledge-Panel und die Sitelinks-Suchbox bei Markennamen-Suchen.

{
  // FAQPage: acceptedAnswer.text muss der sichtbaren Antwort auf der Seite entsprechen
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was kostet der Versand?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Der Versand innerhalb Deutschlands ist ab einem Bestellwert von 50 Euro kostenlos."
      }
    }
  ]
}

6. Validierung: Rich Results Test, Search Console, Schema Markup Validator

Der Google Rich Results Test ist das wichtigste Validierungswerkzeug, weil er nicht nur Syntaxfehler im JSON-LD aufdeckt, sondern konkret zeigt, ob der eingegebene Code für ein von Google unterstütztes Rich Result qualifiziert. Er unterscheidet klar zwischen Fehlern, die eine Anzeige verhindern, und Warnungen zu optionalen Feldern, die die Darstellung verbessern würden, aber nicht zwingend nötig sind. Für die laufende Überwachung nach dem Launch ist die Google Search Console unter „Verbesserungen“ entscheidend, da sie zeigt, wie viele indexierte Seiten mit einem bestimmten Schema-Typ tatsächlich fehlerfrei erfasst wurden.

Der Schema Markup Validator von Schema.org selbst prüft dagegen ausschließlich die syntaktische Korrektheit gegen die offizielle Vokabular-Spezifikation, unabhängig davon, ob Google den jeweiligen Type überhaupt für Rich Results unterstützt. Beide Tools ergänzen sich: Der Schema Markup Validator bestätigt, dass das Markup dem Standard entspricht, der Rich Results Test bestätigt, dass Google daraus tatsächlich etwas Sichtbares macht. Für Magento-Shops empfiehlt sich, die Validierung in jede Staging-Deployment-Pipeline einzubauen, statt sie nur manuell nach dem Go-Live durchzuführen.

7. Häufige Anfängerfehler bei strukturierten Daten

Der häufigste Fehler ist eine Diskrepanz zwischen Markup und sichtbarem Inhalt: Ein Preis im JSON-LD, der nicht mit dem tatsächlich angezeigten Preis übereinstimmt, oder eine Bewertung im Schema, die auf der Seite nirgends sichtbar ist. Google wertet das als irreführend und kann die Rich-Snippet-Berechtigung für die gesamte Domain entziehen, nicht nur für die betroffene Seite. Ein zweiter häufiger Fehler ist die Verwendung erfundener oder veralteter Types, die im offiziellen Vokabular nicht mehr existieren, meist Kopien aus veralteten Tutorials.

Ebenfalls verbreitet: fehlende required Properties. Jeder Google-unterstützte Type hat eine Liste von Pflichtfeldern, ohne die kein Rich Result generiert wird, etwa image und author bei Article. Viele Shops kopieren zudem ein einziges generisches JSON-LD-Template für alle Seiten, statt es dynamisch mit echten Produktdaten zu befüllen, was zu identischen, offensichtlich falschen Werten auf hunderten Seiten führt. Zuletzt: doppeltes Markup, wenn sowohl ein Modul als auch ein Drittanbieter-Plugin unabhängig voneinander Product-Schema ausgeben, was Validatoren als widersprüchlich zurückweisen.

// FALSCH: Preis im Markup weicht vom sichtbaren Preis ab, required Property fehlt
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Beispielprodukt",
  "offers": {
    "@type": "Offer",
    "price": "39.90"
  }
}

// RICHTIG: Preis stimmt mit der Seite ueberein, priceCurrency als Pflichtfeld ergaenzt
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Beispielprodukt",
  "image": "https://mironsoft.de/media/catalog/product/beispiel.jpg",
  "offers": {
    "@type": "Offer",
    "price": "49.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

8. Magento-spezifische Schema-Typen

Für Magento-Shops sind vier Schema-Typen mit dem größten praktischen Nutzen verbunden. Product transportiert Name, Bild, SKU, Marke, Preis und Verfügbarkeit direkt aus dem Produktkatalog und sollte bei jeder Preis- oder Bestandsänderung automatisch aktualisiert werden, idealerweise über denselben Indexer-Mechanismus, der auch den Full Page Cache invalidiert. BreadcrumbList lässt sich aus der bestehenden Kategoriepfad-Logik ableiten, die Magento intern für die sichtbare Breadcrumb-Navigation ohnehin schon berechnet, wodurch keine doppelte Datenhaltung nötig ist.

Organization gehört auf jede Seite und liefert Firmenname, Logo und Kontaktdaten für das Google-Knowledge-Panel. FAQPage eignet sich hervorragend für CMS-Landingpages und Kategorieseiten mit Beratungscharakter, etwa wenn dort ohnehin ein FAQ-Akkordeon mit Alpine.js gerendert wird, dessen Inhalte sich direkt aus derselben Datenquelle ins JSON-LD spiegeln lassen, ohne Redaktionsaufwand zu verdoppeln.

{
  // BreadcrumbList: Positionen 1-basiert, item als absolute URL
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Startseite", "item": "https://mironsoft.de/" },
    { "@type": "ListItem", "position": 2, "name": "Kategorie", "item": "https://mironsoft.de/kategorie" },
    { "@type": "ListItem", "position": 3, "name": "Beispielprodukt", "item": "https://mironsoft.de/beispielprodukt" }
  ]
}

9. JSON-LD-Typen im direkten Vergleich

Jeder Schema-Type hat eigene Pflichtfelder, typische Fehlerquellen und einen klaren SERP-Effekt. Die folgende Übersicht fasst die wichtigsten Typen für Magento-Shops zusammen.

In der Praxis lohnt es sich, mit Product, BreadcrumbList und Organization zu starten, da sie den größten SERP-Effekt bei geringstem Implementierungsrisiko bringen. AggregateRating sollte erst folgen, wenn echte, überprüfbare Bewertungsdaten vorliegen, da fehlerhafte Rating-Daten das größte Abstrafungsrisiko unter allen Schema-Typen tragen.

10. Zusammenfassung

Schema.org und JSON-LD lösen ein klares Problem: Suchmaschinen brauchen eindeutige, maschinenlesbare Signale, um ein Suchergebnis als Rich Result auszuzeichnen. JSON-LD hat sich als De-facto-Standard gegenüber Microdata und RDFa durchgesetzt, weil es Markup und HTML-Template entkoppelt und sich zentral über ViewModels und phtml-Templates pflegen lässt. In Magento- und Hyvä-Shops sind Product, BreadcrumbList, Organization und FAQPage die Typen mit dem größten Effekt bei überschaubarem Implementierungsaufwand.

Der entscheidende Erfolgsfaktor ist Konsistenz zwischen Markup und sichtbarem Inhalt: Jede Abweichung, sei es ein falscher Preis oder eine nicht sichtbare Bewertung, riskiert den Verlust der Rich-Snippet-Berechtigung für die gesamte Domain. Regelmäßige Validierung über den Rich Results Test und laufendes Monitoring in der Search Console stellen sicher, dass strukturierte Daten nicht nur beim Launch korrekt sind, sondern es auch nach künftigen Theme- oder Katalog-Änderungen bleiben.

11. FAQ: Schema.org Grundlagen