Zum Inhalt springen
Potenzial-Analyse

Insights · · 17 Min. Lesezeit · HYPED

Schema Markup für E-Commerce: Die wichtigsten Typen und Felder

Setzen Sie Product und Offer als JSON-LD direkt in die initiale HTML-Antwort, mit den Pflichtfeldern price, priceCurrency, availability und condition. Für Varianten nutzen Sie ProductGroup statt einzelner unabhängiger Produktseiten. Validieren Sie jedes Snippet vor dem Livegang mit validator.schema.org, erst danach folgt der Rich Results Test.

Kurz gesagt:

  • Für Produktseiten sind die wichtigsten Schema-Typen Product, Offer, ProductGroup, BreadcrumbList sowie Review und AggregateRating, da sie die Sichtbarkeit in Suchergebnissen erheblich verbessern.
  • Die Implementierung muss serverseitig erfolgen, strikt nach Schema-Vorgaben, um gültiges Markup mit korrekten Werten zu erzeugen, und regelmäßig automatisiert geprüft werden.
  • Variationen wie Größen oder Farben sollten stets als ProductGroup modelliert werden, um Duplikate und unklare Zuordnungen zu vermeiden.
  • Für große Kataloge mit häufigen Änderungen ist eine automatisierte, datengeführte Generierung des Markups unverzichtbar, Cache-Invaliderungen sind dabei essenziell.
  • Ergänzende Typen wie OfferShippingDetails und WarrantyPromise erweitern das Markup, erfordern jedoch eine konsequente Pflege und genaue Abgleichung mit realen Daten.
Hyped
hyped.de
Mehr Sichtbarkeit für Ihren Onlineshop
HYPED unterstützt E-Commerce-Unternehmen mit SEO, GEO-Maßnahmen und Monitoring für bessere Auffindbarkeit bei Google und in KI-Antworten.

Sichtbarkeit verbessern

Inhaltsverzeichnis

Welche Schema-Typen brauchen Online-Shops wirklich?

Nicht jeder Schema-Typ lohnt den Aufwand. Für einen Shop zählen vor allem fünf Entitäten, der Rest ist Kür.

Product ist der Kern jeder Produktseite. Google verlangt neben name, description und image mindestens eine eindeutige Kennung wie sku oder gtin, ohne die eine Zuordnung zum Merchant-Feed schwierig wird, wie die Google-Dokumentation zu Produkt-Strukturdaten beschreibt.

Offer gehört als verschachteltes Objekt in jedes Product. Pflicht sind price, priceCurrency und availability, bei zeitlich begrenzten Aktionen kommen priceValidUntil und gegebenenfalls priceType hinzu, etwa um einen Sale-Preis vom regulären Preis zu unterscheiden.

ProductGroup kommt immer dann ins Spiel, wenn ein Artikel in mehreren Ausprägungen existiert, also Größe, Farbe oder Material. Die Eigenschaften hasVariant, variesBy und productGroupID bilden die Struktur ab, wie Google Search Central zu Produktvarianten erläutert.

BreadcrumbList bildet die Navigationshierarchie ab. Jedes ListItem braucht eine position, die laufende Nummer in der Kette von Startseite bis Produktseite, so wie es die Schema zeigt.

Review und AggregateRating zeigen Sternebewertungen in den Suchergebnissen, allerdings nur, wenn echte Nutzerbewertungen vorliegen und die Werte mit dem sichtbaren Inhalt übereinstimmen.

  • Product ohne eindeutige sku oder gtin wird vom Feed-Abgleich oft nicht erkannt.
  • Offer ohne priceCurrency gilt als unvollständig und kann ignoriert werden.
  • ProductGroup ersetzt niemals einzelne Product-Einträge, sondern bündelt sie.
  • BreadcrumbList ohne korrekte Position-Reihenfolge wird falsch interpretiert.

Von der Datenquelle zum fertigen JSON-LD: der Implementierungsweg

Die technische Umsetzung beginnt nicht im Template, sondern im Datenmodell. Wer dort schlampt, produziert Markup, das zwar valide aussieht, aber falsche Werte transportiert.

  1. Identifizieren Sie die führende Datenquelle, meist das PIM-System, das CMS oder direkt den Produktkatalog, und legen Sie fest, welches Feld im System welchem Schema-Attribut entspricht.
  2. Generieren Sie das JSON-LD serverseitig und schreiben Sie es in die initiale HTML-Antwort, denn Googlebot verarbeitet nachträglich per JavaScript eingefügtes Markup unzuverlässiger.
  3. Wenn eine JS-Lösung unumgänglich ist, etwa bei einer reinen Single-Page-Anwendung, sorgen Sie für ein Server-Side-Rendering-Fallback, das zumindest Product und Offer ohne Skriptausführung liefert.
  4. Achten Sie auf Formatregeln: price als Dezimalzahl mit Punkt statt Komma, priceCurrency als dreistelliger ISO-4217-Code wie EUR, und für availability und itemCondition ausschließlich die von schema.org definierten Enum-Werte.
  5. Bauen Sie automatisierte Tests in die Deployment-Pipeline ein, die jedes generierte JSON-LD gegen ein Schema validieren und stichprobenhaft echte Produktobjekte prüfen.

Ein minimales Beispiel für Product mit Offer sieht so aus:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Laufschuh Modell X",
  "sku": "LSX-42-SCHWARZ",
  "image": "https://shop.example/bilder/lsx-42.jpg",
  "offers": {
    "@type": "Offer",
    "price": "89.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

Dieses Grundgerüst lässt sich um priceValidUntil, hasMerchantReturnPolicy oder shippingDetails erweitern, ohne die Struktur zu brechen.

Profi-Tipp: Lassen Sie den Linter auch auf zufällig gezogenen Produkten aus dem Live-Katalog laufen, nicht nur auf den drei Testartikeln, die im Pull Request verwendet wurden.

Der letzte Schritt vor dem Merge gehört in die CI-Pipeline: ein Job, der jedes generierte JSON-LD-Objekt gegen die Schema-Definition prüft und bei fehlenden Pflichtfeldern den Build stoppt. Das verhindert, dass ein vergessenes priceCurrency erst Wochen später in der Search Console auffällt.

Produktvarianten korrekt mit ProductGroup abbilden

Sobald ein Artikel in mehreren Ausprägungen verkauft wird, wird die Modellierung schnell zur Fehlerquelle. Die Faustregel: Sobald zwei oder mehr Varianten denselben Grundartikel teilen, sich aber in Farbe, Größe oder Material unterscheiden, gehört ProductGroup ins Markup, wie Google Search Central zu Produktvarianten empfiehlt.

Jede Variante braucht eine eigene, eindeutige sku oder gtin, während die übergeordnete Gruppe eine productGroupID trägt, auf die jede Variante per inProductGroupWithID verweist. Die variesBy-Eigenschaft listet, welche Attribute zwischen den Varianten tatsächlich variieren, etwa Größe oder Farbe.

Bei der URL-Strategie entscheidet sich, ob Sie eine Single-Page-Architektur fahren, bei der alle Varianten über Parameter auf einer URL liegen, oder eine Multi-Page-Architektur mit einer eigenen URL pro Variante. Für Multi-Page-Setups gilt: Jede einzelne Variantenseite muss vollständige, eigenständige Markup-Daten enthalten, ein Verweis auf eine andere Seite reicht nicht aus.

  • Verwenden Sie preselected variant URLs, damit eine vorausgewählte Variante direkt verlinkbar bleibt.
  • Setzen Sie kanonische URLs konsequent, um Duplicate Content zwischen Variantenseiten zu vermeiden.
  • Vergeben Sie niemals dieselbe sku für zwei unterschiedliche Varianten, auch nicht bei geringem Preisunterschied.
  • Prüfen Sie, ob Ihre PLP (Kategorieseite) versehentlich Product-Markup für mehrere Artikel gleichzeitig ausgibt, das gehört ausschließlich auf die PDP.

Ein häufiger Fehler entsteht, wenn Entwicklerteams eine Variante lediglich als Textattribut im Namen unterbringen, etwa “Laufschuh Modell X, Größe 42”, ohne sie strukturell über ProductGroup zu verknüpfen. Suchmaschinen erkennen den Zusammenhang dann nicht und behandeln jede Variante als isoliertes, unabhängiges Produkt.

Testing und Monitoring: So bleibt das Markup fehlerfrei

Validierung ist kein einmaliger Schritt, sondern ein Prozess, der vor und nach jedem Deployment greift.

Vor dem Launch gehören drei Prüfungen in den Ablauf: Syntax-Validierung mit validator.schema.org, inhaltliche Prüfung mit dem Rich Results Test und ein Linting-Schritt, der fehlende Pflichtfelder vor dem Merge abfängt. Validator prüft, ob die Struktur der schema.org-Definition entspricht, während der Rich Results Test zusätzlich anzeigt, ob eine Seite für bestimmte Rich-Snippet-Formate qualifiziert.

In der CI-Pipeline lohnt sich ein automatisierter Test, der zufällig gezogene Produktobjekte gegen Product und Offer validiert und auf inkonsistente Preisformate prüft, etwa ein Komma statt eines Punkts in price.

Nach dem Launch verschiebt sich der Fokus auf Monitoring:

  • Prüfen Sie regelmäßig den Rich-Results-Bericht in der Search Console auf neue Fehler oder Warnungen.
  • Kontrollieren Sie die Protokolle im Merchant Center, wenn automatische Aktualisierungen aus dem Markup aktiviert sind.
  • Reagieren Sie zügig auf gemeldete Formatfehler, bevor sie sich auf den gesamten Katalog ausbreiten.
  • Vergleichen Sie bei dynamischen Preisen stichprobenhaft den im Markup hinterlegten Wert mit dem tatsächlich angezeigten Preis.

Automatische Aktualisierungen von Artikeldaten im Merchant Center stützen sich laut Google Merchant Center Hilfe zu Strukturierten Daten unter anderem auf price, Sonderpreis, availability und condition aus dem Markup. Wer diese Felder inkonsistent pflegt, riskiert veraltete oder falsche Angaben in den Shopping-Ergebnissen.

Best Practices und typische Fehler bei der Umsetzung

Die meisten Probleme entstehen nicht durch fehlendes Wissen, sondern durch Nachlässigkeit bei der Pflege.

Die wichtigste Regel: Jeder Wert im Markup muss mit dem sichtbaren Inhalt der Seite übereinstimmen. Ein Preis von 89,90 Euro im JSON-LD, während die Seite 94,90 Euro zeigt, führt zu Vertrauensproblemen gegenüber der Suchmaschine und im schlimmsten Fall zu einer Abschaltung der Rich-Snippet-Darstellung.

Bei Breadcrumbs gilt die Hierarchie-Variante als bevorzugte Praxis, nicht die reine Browserverlaufs-Navigation, wie Baumart-Forschung zu Breadcrumbs zeigt. Ein “Zurück zu den Ergebnissen”-Link gehört als separate Navigation neben die BreadcrumbList, nicht als Ersatz dafür.

Markup ergänzt den Merchant-Feed, ersetzt ihn aber nicht. Laut der Google-Dokumentation zu Produkt-Strukturdaten kombiniert Google beide Quellen, Inkonsistenzen zwischen Feed und Markup sollten aber vermieden werden, da sie zu unklaren Resultaten führen.

  • Platzieren Sie Product-Markup ausschließlich auf Seiten, die ein einzelnes Produkt oder dessen Varianten zeigen, niemals auf generischen Kategorieseiten.
  • Halten Sie Feed-Daten und Markup-Werte bei jedem Preis- oder Lagerupdate synchron.
  • Dokumentieren Sie Pflichtfelder in einem internen Leitfaden, damit neue Entwickler nicht bei null anfangen.

Profi-Tipp: Richten Sie einen wöchentlichen automatisierten Abgleich zwischen Feed-Preis und Markup-Preis ein, Abweichungen fallen so auf, bevor sie Kunden oder Google auffallen.

Welche Rolle Schema Markup in der Merchant-Center-Automatisierung spielt

Das Merchant Center kann Artikeldaten automatisch aus strukturierten Daten aktualisieren, statt ausschließlich auf den klassischen Produktfeed zu warten. Laut Google Merchant Center Hilfe fließen dabei price, ein eventueller Sonderpreis, availability und condition direkt aus dem auf der Seite hinterlegten Markup ein.

Das funktioniert jedoch nur zuverlässig, wenn das JSON-LD serverseitig generiert wird und bereits in der initialen HTML-Antwort steht. Ein Markup, das erst nach dem Laden per JavaScript nachgereicht wird, erschwert die automatische Erkennung und kann zu verzögerten oder ausbleibenden Updates führen.

Für Shops mit häufigen Preisänderungen, etwa durch Rabattaktionen oder Lagerbestandsschwankungen, ist diese Automatisierung ein praktischer Zusatz zum regulären Feed-Upload, weil sie die Zeitspanne zwischen einer Änderung im System und deren Sichtbarkeit in den Shopping-Ergebnissen verkürzen kann. Sie ersetzt den Feed aber nicht, sie ergänzt ihn.

Wichtig ist die Konsistenz zwischen beiden Quellen. Wenn der Feed einen Preis von 79 Euro meldet, das Markup aber noch den alten Preis von 89 Euro zeigt, entsteht ein Widerspruch, den Google auflösen muss, ohne dass vorhersehbar ist, welcher Wert gewinnt. Wer Feed und Markup aus derselben Datenquelle generiert, vermeidet dieses Problem von Grund auf.

Gemeinsame Datenquelle für Feed und Markup

Schema Markup für eCommerce versus allgemeine Produktseiten

Nicht jede Seite, die ein Produkt beschreibt, braucht dieselbe Markup-Tiefe. Eine Herstellerseite, die ein Gerät lediglich vorstellt, ohne es zu verkaufen, kommt mit einem einfachen Product-Objekt aus, oft ganz ohne Offer.

Ein Online-Shop dagegen verkauft aktiv, und genau das verändert die Anforderungen. Offer wird zur Pflicht, inklusive price, priceCurrency und availability, weil erst diese Angaben eine Darstellung als Shopping-Ergebnis oder Preisvergleich ermöglichen. Hinzu kommen Varianten, Versandinformationen und Rückgaberichtlinien, die auf einer reinen Informationsseite keine Rolle spielen.

Ein weiterer Unterschied liegt in der Kopplung an den Merchant-Feed. Während eine allgemeine Produktseite ihr Markup unabhängig pflegen kann, muss ein Shop Feed und Markup aufeinander abstimmen, da beide Quellen parallel in die Darstellung bei Google einfließen, wie es die Google-Dokumentation zu Produkt-Strukturdaten beschreibt.

Auch die Pflegefrequenz unterscheidet sich deutlich. Ein Hersteller aktualisiert eine Produktseite vielleicht einmal im Jahr, ein Shop ändert Preis und Verfügbarkeit mitunter mehrmals täglich. Diese Dynamik verlangt eine automatisierte, serverseitige Generierung des Markups, statt einer manuell gepflegten, statischen Datei.

Wie sich Schema Markup auf Sichtbarkeit und Kaufabschlüsse auswirkt

Strukturierte Daten verändern nicht den Inhalt einer Seite, sondern wie Suchmaschinen diesen Inhalt verstehen und darstellen. Für Online-Shops heißt das konkret: korrekt ausgezeichnete Produkte können als Rich-Snippet mit Preis, Verfügbarkeit und Bewertung erscheinen, statt als einfacher blauer Link.

Diese zusätzliche Information in den Suchergebnissen verändert, wie ein Angebot gegenüber anderen Treffern wirkt. Ein sichtbarer Preis direkt im Suchergebnis filtert Klicks vor, Nutzer mit abweichenden Preisvorstellungen klicken seltener, wer klickt, bringt tendenziell mehr Kaufinteresse mit. Dieser Effekt lässt sich plausibel begründen, eine pauschale Zahl zur Steigerung der Klickrate oder der Conversion-Rate lässt sich aus den verfügbaren Quellen jedoch nicht seriös ableiten.

Entscheidend bleibt die Eligibility für Rich Results, also die technische Voraussetzung, überhaupt für diese Darstellungsformen in Frage zu kommen. Ohne korrektes Markup bleibt diese Option von Anfang an verschlossen, unabhängig davon, wie gut Produktseite oder Angebot sonst aufgebaut sind. Markup ist damit eine Voraussetzung, keine Garantie, denn Google entscheidet pro Suchanfrage und Kontext, ob und welche Rich-Snippet-Darstellung tatsächlich ausgespielt wird.

Schema Markup in mehrsprachigen und internationalen Shops

Wer in mehreren Sprachen oder Ländern verkauft, muss das Markup pro Sprachversion eigenständig denken, nicht als einmalige Vorlage, die einfach übersetzt wird.

Jede lokalisierte Seite braucht ihr eigenes JSON-LD mit den für diesen Markt gültigen Werten. Der priceCurrency-Code ändert sich je nach Zielland, EUR für den Euroraum, andere Codes für andere Währungen, und availability kann sich unterscheiden, wenn ein Artikel in einem Land lieferbar ist und in einem anderen nicht.

Textfelder wie name und description sollten in der jeweiligen Sprache der Seite stehen, nicht nur übersetzt, sondern konsistent mit dem sichtbaren Inhalt der jeweiligen Sprachversion. Ein Markup auf Deutsch, eingebettet in eine englischsprachige Seite, erzeugt denselben Widerspruch wie ein falscher Preis.

Bei hreflang-verknüpften Sprachversionen gilt zusätzlich: Jede Version braucht ein vollständiges, eigenständiges Markup, ein Verweis auf die Hauptsprache reicht nicht. Das betrifft besonders BreadcrumbList, deren Beschriftungen ebenfalls lokalisiert sein müssen, und Offer, dessen Preis- und Verfügbarkeitsdaten pro Markt variieren können.

Eine zentrale Datenquelle, aus der alle Sprachversionen ihr Markup ableiten, reduziert den Pflegeaufwand erheblich. Wer stattdessen jede Sprachversion manuell pflegt, produziert über die Zeit fast zwangsläufig Abweichungen zwischen den Märkten.

Schema Markup bei dynamischen Produktkatalogen aktuell halten

Ein Katalog mit tausenden Artikeln und täglichen Preis- oder Bestandsänderungen stellt andere Anforderungen an die Pflege als eine handvoll statischer Landingpages.

Die Grundvoraussetzung ist eine automatisierte Generierung des Markups direkt aus der führenden Datenquelle, meist dem PIM-System oder der Produktdatenbank. Sobald sich ein Preis oder ein Lagerbestand ändert, muss das Markup beim nächsten Seitenaufruf automatisch den aktuellen Wert tragen, eine manuelle Pflege einzelner JSON-LD-Blöcke ist bei einem großen Katalog schlicht nicht praktikabel.

Caching ist dabei die häufigste Fehlerquelle. Wenn eine Seite über ein Content Delivery Network oder einen Reverse Proxy zwischengespeichert wird, kann das darin enthaltene Markup veraltete Preise oder eine falsche Verfügbarkeit zeigen, selbst wenn das zugrunde liegende System längst aktualisiert wurde. Die Cache-Invalidierung für Produktseiten sollte deshalb an dieselben Trigger gekoppelt sein, die auch den sichtbaren Preis aktualisieren.

Für saisonale Artikel oder Aktionen mit festem Enddatum lohnt sich priceValidUntil, damit ein abgelaufener Sale-Preis nicht unbegrenzt im Markup stehen bleibt. Ein regelmäßiger automatisierter Abgleich, der Markup-Werte gegen die Live-Datenbank prüft, deckt solche veralteten Einträge auf, bevor sie auffallen.

Fehlerhafte oder unvollständige Daten im Markup erkennen und beheben

Ein unvollständiges Markup ist nicht automatisch nutzlos, aber es schränkt die möglichen Darstellungsformen ein. Fehlt priceCurrency, gilt das Offer-Objekt als unvollständig, selbst wenn price korrekt gesetzt ist.

Häufige Fehlerquellen sind falsche Enum-Werte, etwa ein frei formulierter Text statt des vorgesehenen schema.org-Werts für availability oder itemCondition, sowie Formatfehler bei Zahlen, etwa ein Komma statt eines Punkts im Dick-Feld. Auch doppelt vergebene sku-Werte zwischen unterschiedlichen Varianten zählen zu den wiederkehrenden Problemen.

Die Auswirkungen reichen von der stillen Nichtberücksichtigung einzelner Felder bis zur kompletten Ablehnung eines Rich-Snippet-Formats für die betroffene Seite. Besonders kritisch wird es, wenn die Abweichung zwischen Markup und sichtbarem Inhalt groß genug ist, dass Google sie als Diskrepanz einstuft, dann kann die Darstellung für die gesamte Seite betroffen sein, nicht nur das fehlerhafte Feld.

Der praktische Umgang mit solchen Fehlern beginnt mit Priorisierung: Pflichtfelder wie price, priceCurrency und availability zuerst korrigieren, optionale Felder wie priceValidUntil können folgen. Ein Linting-Schritt in der Build-Pipeline, der fehlende Pflichtfelder vor dem Deployment abfängt, verhindert, dass fehlerhafte Daten überhaupt live gehen. Für bereits veröffentlichte Fehler hilft der Rich-Results-Bericht in der Search Console, der betroffene URLs und die konkrete Fehlerursache auflistet.

Weitere Schema-Typen, die für Shops Sinn ergeben

Über Product, Offer und BreadcrumbList hinaus gibt es zwei Typen, die für Online-Shops zunehmend relevant werden, auch wenn sie seltener im Fokus stehen.

OfferShippingDetails beschreibt Versandkosten, Versanddauer und Herkunftsland eines Angebots strukturiert. Für Käufer, die vor dem Klick wissen möchten, ob ein Artikel versandkostenfrei oder mit welcher Lieferzeit ankommt, kann diese Information direkt in den Suchergebnissen auftauchen, statt erst im Checkout sichtbar zu werden.

WarrantyPromise bildet Garantiezusagen ab, etwa die Dauer einer Herstellergarantie oder einer erweiterten Garantie, die über die gesetzliche Gewährleistung hinausgeht. Gerade bei höherpreisigen Artikeln wie Elektronik oder Möbeln kann eine sichtbare Garantieangabe ein Kaufargument direkt in der Suche sein.

Beide Typen werden als verschachtelte Objekte innerhalb von Offer eingebettet, ähnlich wie priceValidUntil. Ihre Pflege folgt denselben Prinzipien wie der Rest des Markups: Die Werte müssen aus einer verlässlichen Datenquelle stammen und mit dem sichtbaren Inhalt der Seite übereinstimmen, laut den Erweiterungen zu Produktvarianten im Google Search Central Blog gehören solche zusätzlichen Eigenschaften zu den fortlaufend erweiterten Möglichkeiten für Produktseiten. Wer bereits eine stabile Pipeline für Product und Offer hat, kann diese beiden Typen meist ohne größeren Mehraufwand ergänzen.

Warum die meisten Schema-Projekte an der falschen Stelle scheitern

Die verbreitete Vorstellung, Schema Markup sei ein einmaliges technisches Projekt, das nach dem Launch abgeschlossen ist, hält der Praxis nicht stand. Die größten Probleme entstehen nicht beim ersten Rollout, sondern Monate später, wenn sich Preise ändern, neue Varianten dazukommen oder ein Relaunch das Template austauscht, ohne das Markup mitzudenken.

Unterschätzt wird außerdem die Rolle der Datenquelle. Teams investieren viel Sorgfalt in das JSON-LD-Template, pflegen aber die zugrunde liegenden Produktdaten im PIM-System nachlässig, mit uneinheitlichen Einheiten oder fehlenden GTINs. Markup kann nur so gut sein wie die Daten, aus denen es generiert wird.

Was wirklich zählt, ist deshalb nicht die Komplexität des Markups, sondern dessen Konsistenz über Zeit: eine automatisierte Pipeline, die Preisänderungen, neue Varianten und Statuswechsel ohne manuelles Eingreifen korrekt abbildet. Wer dort zuerst investiert, spart sich später das mühsame Nachbessern einzelner Produktseiten.

— Dominic

Wie wir bei der Umsetzung von Schema Markup unterstützen

Bei einem großen Katalog mit vielen Varianten und häufigen Preisänderungen reicht ein einmaliges Setup selten aus, die Pflege braucht ein System dahinter. Genau dafür bieten wir das Organic Growth System an, zu einem monatlichen, flexibel kündbaren Preis.

Hyped

Darin enthalten sind unter anderem ein Audit, Maßnahmen zur Sichtbarkeit und ein monatlicher Report mit priorisierten Handlungsempfehlungen, die sich auch auf technische Themen wie strukturierte Daten anwenden lassen. Wie wir Sichtbarkeit und strukturierte Daten im Zusammenspiel mit KI-Suchsystemen einordnen, zeigen wir auch in unserem Beitrag zur KI-Suchmaschinenoptimierung im E-Commerce.

  • Sie behalten die volle Kontrolle über Ihre Konten.
  • Jede Empfehlung wird geprüft, bevor sie in Ihr Backlog geht.
  • Sie entscheiden, ob Ihr Team umsetzt oder wir als Sparringspartner begleiten.

Wenn Sie wissen möchten, wo Ihr Markup heute steht und was als Nächstes sinnvoll ist, fordern Sie ein Audit über unsere Service-Seite an.

FAQ

Was ist Schema-Markup?

Schema-Markup ist eine standardisierte Auszeichnung von Inhalten im Quellcode einer Seite, meist als JSON-LD, die Suchmaschinen erklärt, worum es sich bei einem Inhalt handelt, etwa um ein Produkt mit Preis und Verfügbarkeit. Die Definitionen stammen von schema.org, einem gemeinsamen Vokabular großer Suchmaschinenbetreiber.

Was ist das Markup?

Mit Markup ist in diesem Zusammenhang strukturierte Daten gemeint, also zusätzlicher Code, der neben dem sichtbaren Text einer Seite steht und deren Inhalt maschinenlesbar beschreibt. Für Shops betrifft das vor allem Product, Offer und BreadcrumbList.

Welches Format sollte ich für Schema Markup verwenden?

JSON-LD ist das von Google empfohlene Format, weil es sich klar vom übrigen HTML trennt und leicht automatisiert generieren lässt, wie die Google Merchant Center Hilfe zu Strukturierten Daten beschreibt. Es sollte direkt in der initialen HTML-Antwort stehen, nicht erst per JavaScript nachgeladen werden.

Wie teste ich, ob mein Schema Markup korrekt ist?

Prüfen Sie die Syntax zuerst mit validator.schema.org und anschließend mit dem Rich Results Test, der zusätzlich zeigt, ob eine Seite für bestimmte Rich-Snippet-Formate qualifiziert. Nach dem Launch ergänzt der Rich-Results-Bericht in der Search Console die laufende Kontrolle.

Ersetzt Schema Markup den Produktfeed im Merchant Center?

Nein, strukturierte Daten ergänzen den Feed, sie ersetzen ihn nicht, wie die Google-Dokumentation zu Produkt-Strukturdaten festhält. Beide Quellen sollten konsistente Werte liefern, damit keine Widersprüche entstehen.

Quellen

Empfehlungen

Weitere Beiträge

Alle Insights →

Kostenlos · 15 Minuten · kein Pitch

Lass uns über dein Wachstum sprechen.

Ehrlich, unverbindlich, transparent. Wenn wir nicht passen, sagen wir es – und du hast trotzdem eine Einschätzung mitgenommen.

Dominic FoerstGründer HYPED · Rheinland-Pfalz
Kostenlose Potenzial-Analyse
100 % kostenlos & unverbindlich.