Mit Release 6.7.9.0 stellt Shopware die Storefront vom alten Microdata-Format auf modernes JSON-LD um (Shopware Release Notes). Für Händler ist das mehr als ein technisches Detail: JSON-LD steht inzwischen auf rund 41% aller Seiten, Microdata nur noch auf rund 26% (Web Almanac/HTTP Archive). Wer JSON-LD sauber implementiert, macht Rich Results, Merchant Listings und die maschinelle Auswertung durch generative Suchmaschinen überhaupt erst möglich. Dieser Guide zeigt, was sich in Shopware 6.7.9.0 konkret ändert, welche neuen Schema-Typen jetzt automatisch ausgespielt werden und wie Sie ohne SEO-Risiko von Microdata auf JSON-LD migrieren – inklusive Pflichtfeldern, Template-Overrides und Validierungs-Workflow für Ihren SEO-Auftritt.
Was Shopware 6.7.9.0 für Schema ändert
Bislang setzte die Shopware-Storefront auf Microdata – Schema-Attribute wurden direkt in HTML-Tags geschrieben (itemprop, itemtype, itemscope). Mit Version 6.7.9.0 wechselt Shopware auf JSON-LD: Strukturierte Daten werden als separater <script type="application/ld+json">-Block im <head> der Seite ausgegeben (Shopware Release Notes 6.7.9.0). Damit folgt Shopware dem Standard, den Google empfiehlt und den der Großteil der modernen Web-Plattformen längst nutzt.
Die Umstellung wirkt zunächst rein technisch, hat aber konkrete Folgen für die SEO-Sichtbarkeit. Fehlerhaftes Markup fällt im Rich Results Test oft erst spät auf. Microdata-basierte Markups in komplexen Twig-Templates sind besonders anfällig für ungültige Strukturen, weil Tags und Attribute über mehrere Dateien verteilt sind. JSON-LD entkoppelt die strukturierten Daten vom Layout-Markup und ist damit deutlich besser wartbar und validierbar.
Ein direkter Ranking-Vorteil für JSON-LD gegenüber Microdata ist nicht belegt – Google verarbeitet beide Formate. Der Vorteil liegt in Validität, Wartbarkeit und Erweiterbarkeit: Neue Schema-Typen wie WebSite/SearchAction oder VideoObject lassen sich in JSON-LD sauber als zusätzliche Script-Blöcke ergänzen, ohne den HTML-Code anzufassen.
| Aspekt | Microdata (alt) | JSON-LD (ab 6.7.9.0) |
|---|---|---|
| Position im DOM | über HTML verteilt | im <head> gebündelt |
| Lesbarkeit für Entwickler | schwer nachvollziehbar | ein Block, ein Datensatz |
| Validierung | Tag-für-Tag prüfen | kompletter Block in Rich Results Test |
| Wartbarkeit | Layout-gekoppelt | vom Layout entkoppelt |
| Google-Empfehlung | akzeptiert | bevorzugt |
| Adoption | ca. 26% aller Seiten (Web Almanac) | ca. 41% aller Seiten (Web Almanac) |
| Storefront-Status | deprecated, Entfernung mit 6.8.0 | neuer Standard |
Das alte Microdata-Markup ist ab 6.7.9.0 als deprecated markiert und wird laut Shopware Forum mit Version 6.8.0 vollständig entfernt. Wer eigene Templates mit itemprop-Attributen erweitert hat, sollte diese rechtzeitig auf JSON-LD-Overrides umstellen, bevor das Major-Update kommt.
Feature-Flag JSON_LD_DATA aktivieren
Damit bestehende Shops bei der Migration nicht plötzlich doppeltes Schema-Markup ausliefern, hat Shopware das Feature hinter einem Feature-Flag versteckt: JSON_LD_DATA. Solange das Flag deaktiviert ist, rendert die Storefront weiterhin Microdata. Wird das Flag aktiviert, werden Microdata-Attribute aus den HTML-Tags entfernt und stattdessen die neuen JSON-LD-Blöcke ausgespielt (Shopware GitHub).
# Feature-Flag für JSON-LD aktivieren
FEATURE_JSON_LD_DATA=1
# Cache leeren, damit das Flag greift
bin/console cache:clear
bin/console feature:dumpAlternativ kann das Flag in der config/packages/shopware.yaml gesetzt werden, was bei mehreren Stages (Staging, Produktion) übersichtlicher ist. Für die Migration empfiehlt sich folgender Ablauf: zuerst auf einer Staging-Umgebung aktivieren, das gerenderte HTML mit dem Rich Results Test prüfen, eigene Template-Overrides anpassen und erst dann produktiv schalten.
shopware:
feature:
flags:
- name: JSON_LD_DATA
default: true
major: false
description: 'Storefront emits JSON-LD instead of Microdata'Das Flag ist als Migrations-Schalter gedacht, nicht als Dauerlösung. Es kennt zwei Zustände: aus (Microdata wie bisher) oder an (nur JSON-LD). Eine parallele Ausgabe beider Formate ist bewusst nicht vorgesehen, weil sie zu Duplicate-Schema-Warnungen im Rich Results Test führen würde.
Neue Schema-Typen im Detail
Die Umstellung auf JSON-LD ist nicht nur ein Format-Wechsel – Shopware ergänzt mit 6.7.9.0 auch neue Schema-Typen, die bisher nicht oder nur in eigenen Plugins ausgeliefert wurden (Shopware Release Notes 6.7.9.0). Damit deckt die Storefront ab Werk deutlich mehr Rich-Results-Szenarien ab und verbessert die Sichtbarkeit in Generative Engine Optimization.
WebSite mit SearchAction
Auf der Startseite wird ein WebSite-Objekt mit eingebettetem SearchAction ausgegeben. Damit kann Google die Sitelinks Searchbox anzeigen – ein Suchfeld direkt unter Ihrem SERP-Eintrag, das auf Ihre interne Suche verweist.
Organization mit Logo
Organization-Markup mit name, url und logo ermöglicht das Knowledge-Panel-Logo in Google. Wichtig: Das Logo muss laut Google mindestens 112x112 Pixel, quadratisch und in der robots.txt nicht blockiert sein.
ItemList für Kategorien & Suche
Kategorie- und Suchergebnisseiten erhalten ein ItemList-Schema, das die enthaltenen Produkte als geordnete Liste beschreibt. Das hilft Google, die Seite als Listing statt als einzelne Produktseite einzustufen.
VideoObject in Produkten
Sind Produktvideos hinterlegt, wird automatisch ein VideoObject mit name, description, thumbnailUrl und uploadDate mitgeliefert. Voraussetzung für Video-Rich-Results in der Google-Suche.
Zusätzlich bleiben die bekannten Typen erhalten: Product, Offer, AggregateRating, Review, BreadcrumbList und FAQPage. Sie werden nun nicht mehr als Microdata, sondern als separate JSON-LD-Blöcke ausgegeben – jeweils einer pro Typ, was die Validierung deutlich erleichtert.
Product-Schema: Pflichtfelder für Rich Results
Damit Google Product-Markup als Rich Result anerkennt, müssen mindestens name und image gesetzt sein – plus eines aus offers, review oder aggregateRating. Shopware liefert diese Felder out-of-the-box, sofern die Stammdaten im Produkt gepflegt sind. Fehlt eines der Pflichtfelder, verwirft Google den gesamten Block – nicht nur das fehlende Attribut.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Bio Espresso 1kg",
"image": "https://shop.example.com/media/espresso-1kg.jpg",
"description": "Sortenreiner Bio-Espresso aus Hochlandanbau, schonend geröstet.",
"sku": "ESP-BIO-1000",
"gtin13": "4015834012345",
"brand": {
"@type": "Brand",
"name": "Beispielrösterei"
},
"offers": {
"@type": "Offer",
"price": "89.90",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"url": "https://shop.example.com/espresso/bio-1kg"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"ratingCount": "184"
}
}- name (Pflicht): Produktbezeichnung, ohne Marketing-Floskeln
- image (Pflicht): mindestens 500x500 Pixel ab 2026 für Google Merchant (Google Merchant Update)
- description: zusammenhängender Text, keine Bullet-Listen
- sku: interne Artikelnummer für eindeutige Identifikation
- gtin/gtin13: EAN/GTIN für Google Shopping und Merchant Listings
- brand: Marke als
Brand-Objekt, nicht als Plain-String - offers: mindestens
priceundpriceCurrency, sonst keine Rich Results - aggregateRating oder review: mindestens eines, für Sterne-Bewertungen im SERP
Fehlt eines der Pflichtfelder, validiert der Rich Results Test zwar erfolgreich, Google zeigt das Produkt aber nicht als Rich Result an – das Schema landet im Index, generiert aber keinen sichtbaren Mehrwert. Der häufigste Fehler in der Praxis: leere gtin-Felder in den Stammdaten oder brand als reiner Textstring statt als Objekt.
Offer & Merchant Listings
Für Google Merchant Listings (organische Shopping-Einträge) reichen die minimalen Offer-Felder nicht aus. Google verlangt zusätzlich priceCurrency, availability und itemCondition als URL-Werte aus dem schema.org-Vokabular. Fehlt einer dieser Werte, erscheint das Produkt zwar im Index, aber nicht in den Shopping-Einträgen.
{
"@type": "Offer",
"price": "89.90",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"priceValidUntil": "2026-12-31",
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingRate": {
"@type": "MonetaryAmount",
"value": "4.90",
"currency": "EUR"
},
"shippingDestination": {
"@type": "DefinedRegion",
"addressCountry": "DE"
}
},
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"applicableCountry": "DE"
}
}Shopware liefert shippingDetails und hasMerchantReturnPolicy ab 6.7.9.0 nur dann automatisch mit, wenn entsprechende Stammdaten in den Versand- und Rückgabe-Einstellungen gepflegt sind. Wer hier Lücken hat, sollte sie vor der Migration füllen oder über ein eigenes Template-Override ergänzen – sonst sind die Merchant-Listings aus den Rich-Result-Pools ausgeschlossen. Mehr zur sauberen Datenpflege in unserem Beitrag zur Synchronisation von Lagerbeständen über mehrere Kanäle.
AggregateRating und Reviews
Sterne-Bewertungen im SERP sind ein sichtbarer CTR-Hebel: Sie heben den Treffer optisch von den Nachbareinträgen ab. Shopware unterstützt sowohl aggregateRating (Durchschnittswerte) als auch einzelne Review-Objekte. Damit das Markup als gültig erkannt wird, müssen ratingValue zwingend mit ratingCount oder reviewCount kombiniert werden – nicht nur ein einzelner Wert.
{
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"ratingCount": "184",
"bestRating": "5",
"worstRating": "1"
},
"review": [
{
"@type": "Review",
"author": {
"@type": "Person",
"name": "M. Schmidt"
},
"datePublished": "2026-04-12",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5"
},
"reviewBody": "Sehr aromatischer Espresso, schnelle Lieferung."
}
]
}Google akzeptiert keine Bewertungen, die ein Shop über sich selbst als Markup ausspielt (z.B. „4,9 Sterne basierend auf 1.200 Bewertungen unseres Shops"). Bewertungs-Schema darf sich ausschließlich auf das konkrete Produkt beziehen, das auf der Seite dargestellt wird. Verstoßen Shops dagegen, werden Sterne-Snippets nachträglich entfernt – ohne Vorwarnung.
BreadcrumbList für SERP-Pfade
Statt der nüchternen URL zeigt Google im SERP gerne den Kategoriepfad an – vorausgesetzt, eine BreadcrumbList ist im Schema hinterlegt. Das hilft Nutzern, den Kontext der Seite schon vor dem Klick zu erfassen. Shopware generiert die Breadcrumb automatisch aus der Kategoriestruktur.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Startseite",
"item": "https://shop.example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Espresso",
"item": "https://shop.example.com/espresso/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Bio Espresso 1kg"
}
]
}Pflichtfelder sind position, name und – außer beim letzten Element – item mit absoluter URL. Das letzte Element zeigt auf die aktuelle Seite und benötigt deshalb keinen item-Wert. Wichtig: Die Breadcrumb-Reihenfolge muss exakt der Navigation auf der Seite entsprechen, sonst verwirft Google das Markup als irreführend.
FAQ und HowTo-Schema
FAQ-Schema gehört zu den effektivsten Bausteinen für AI Overviews und LLM-Citations: Strukturierte Frage-Antwort-Paare werden von generativen Suchmaschinen besonders gerne aufgegriffen. Die Datenlage ist allerdings differenziert: Eine kontrollierte Analyse von 1.885 Seiten, die JSON-LD ergänzten, fand gegenüber Kontrollseiten ohne Schema keinen messbaren Citation-Vorteil durch Schema allein – weder in Google AI Overviews/AI Mode noch in ChatGPT (Search Engine Journal). Schema wirkt damit eher als Beschleuniger gut strukturierter Inhalte als als Garant. Shopware spielt FAQ-Markup ab 6.7.9.0 für CMS-Blöcke vom Typ „Akkordeon" automatisch aus, sofern der entsprechende CMS-Block dafür konfiguriert ist.
Wichtig zu wissen: Google hat 2023 die Anzeige von FAQ-Rich-Results in den klassischen blauen Links für die meisten Branchen reduziert. Das Markup wird aber weiterhin indexiert und ist relevant für AI Overviews, Bing Chat und LLM-Antworten in Tools wie Google AI Mode oder Perplexity. Mehr dazu in unserer Analyse zu Google AI Mode und Generative Engine Optimization.
FAQs sollten eine Frage mit einer fokussierten Antwort kombinieren – maximal 2-3 Sätze. Lange Marketing-Texte werden von LLMs schlechter zitiert als prägnante Antworten. Entscheidend ist, dass das FAQ-Markup zur Suchintention der Seite passt – sonst wird es zwar validiert, aber nicht ausgespielt.
Templates überschreiben: storefront/layout/structured-data/
Shopware legt die JSON-LD-Templates unter storefront/layout/structured-data/ ab – pro Schema-Typ ein eigenes Twig-File. Das macht Overrides deutlich übersichtlicher als beim alten Microdata, das tief in den Produkt- und Kategorie-Templates verteilt war. Eigene Anpassungen können in einem Plugin oder Theme via Standard-Twig-Inheritance erfolgen.
{% sw_extends '@Storefront/storefront/layout/structured-data/product.html.twig' %}
{% block layout_structured_data_product %}
{{ parent() }}
{# Eigene Erweiterung: GTIN aus Custom Field #}
{% if product.customFields.custom_gtin %}
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "{{ product.translated.name|json_encode|raw }}",
"gtin13": "{{ product.customFields.custom_gtin }}"
}
</script>
{% endif %}
{% endblock %}Wer komplexere Anpassungen braucht – etwa zusätzliche Offer-Varianten für Staffelpreise oder ein eigenes VideoObject aus einem Custom Field – sollte den passenden Block überschreiben statt das komplette Template zu kopieren. Das vermeidet Konflikte bei zukünftigen Shopware-Updates. Bei umfangreicheren Migrationen empfiehlt sich eine begleitende Code-Review durch unsere Programmierer, um Performance-Auswirkungen frühzeitig zu erkennen, etwa im Zusammenspiel mit PHP 8.5.
Validierung mit Rich Results Test
Vor dem Live-Schalten muss jeder Seitentyp validiert werden – Produktdetail, Kategorie, Startseite, Suchergebnis und CMS-Seiten. Es reicht nicht, nur eine Beispiel-Produktseite zu prüfen. Ein Großteil aller Schema-Implementierungen besteht den Rich Results Test nicht sauber – die Fehler fallen meist erst auf, wenn die Sichtbarkeit einbricht.
- Rich Results Test (Google): Prüft, ob Google das Markup als Rich Result anerkennt – nicht nur, ob es valide ist.
- Schema Markup Validator (schema.org): Prüft die Konformität gegenüber dem schema.org-Vokabular, unabhängig von Google.
- Search Console / Erweiterungsbereich: Zeigt nach 1-2 Wochen, welche Markups Google live indexiert hat und welche Fehler bestehen.
- Eigene CI-Pipeline: Headless-Browser-Test mit Schnappschuss der gerenderten JSON-LD-Blöcke pro Seitentyp – verhindert Regressionen bei zukünftigen Updates.
Wichtig: Weil AI Overviews und Rich Snippets einen wachsenden Teil der Ergebnisseite belegen, wird die korrekte Schema-Implementierung zur Pflicht-Ressource für E-Commerce-Sichtbarkeit, nicht zum Nice-to-have. Wer Klassik-CTR verliert, muss diese über erweiterte SERP-Features kompensieren.
Migration: Von Microdata zu JSON-LD
Eine saubere Migration läuft in fünf nachvollziehbaren Schritten – idealerweise auf einer Staging-Umgebung, mit aktivem Monitoring der Search Console nach dem Go-Live.
- Bestandsaufnahme: Aktuelle Microdata-Implementierung dokumentieren – welche Schema-Typen werden ausgespielt, welche Custom-Erweiterungen gibt es, welche Plugins greifen ins Schema-Markup ein? Eine Audit-Checkliste verhindert, dass beim Umstieg Markup-Lücken entstehen.
- Update auf 6.7.9.0: Shopware Core auf die neue Version aktualisieren, Composer-Dependencies prüfen, alle Plugins auf Kompatibilität testen. Auf Staging zuerst, nicht direkt produktiv.
- Feature-Flag aktivieren:
JSON_LD_DATA=1in der Staging-Konfiguration setzen, Cache leeren, alle Seitentypen rendern und das DOM auf vorhandene Microdata-Reste prüfen. - Templates anpassen: Eigene Microdata-Erweiterungen in JSON-LD-Overrides unter
storefront/layout/structured-data/umschreiben. Custom Fields und Plugin-Daten dabei mitnehmen. - Validierung & Go-Live: Jeden Seitentyp im Rich Results Test prüfen, ggf. Fehler beheben, dann produktiv schalten und in der Search Console mindestens 4 Wochen beobachten – falls AI-Overview-Visibility oder Sterne-Snippets einbrechen, gezielt nachbessern.
Wer parallel weitere große Umstellungen plant – etwa eine Migration von WooCommerce auf Shopware, die Lighthouse-Optimierung auf Score 100 oder die Einführung von Subscription-Modellen – sollte die JSON-LD-Migration isolieren: Erst Schema sauber umstellen, dann nächste Baustelle. So lassen sich Sichtbarkeitsverluste klar zuordnen.
JSON-LD ist die Pflicht-Basis für Sichtbarkeit
Mit Shopware 6.7.9.0 wird JSON-LD vom optionalen Add-on zum Storefront-Standard. Microdata bleibt auf Altbestände beschränkt – JSON-LD ist das Format, auf das Google, Bing und LLM-basierte Suchmaschinen optimieren. Wer die Migration sauber macht, sichert sich Rich Results, AI-Citations und einen klaren Vorsprung gegenüber den vielen Shops mit fehlerhaftem Markup. Mehr zu strukturierten Daten in unserem Grundlagen-Beitrag Structured Data für Online-Shops und in der Analyse Produktdaten mit KI optimieren. Verbindung zu Google Shopping und Merchant Center: über unser Modul Google Merchant Center. Rohdaten-Pflege und Schema-Anreicherung übernimmt unsere KI-gestützte Data Enrichment.
Dieser Artikel basiert auf Daten und Veröffentlichungen von: Web Almanac/HTTP Archive, Search Engine Journal sowie Shopware Release Notes 6.7.9.0. Die genannten Zahlen sind Momentaufnahmen und können je nach Branche und Erhebungszeitpunkt abweichen.
Ein sofortiges Update ist erfahrungsgemäß nicht zwingend, aber zu empfehlen. Microdata wird laut Shopware Forum mit 6.8.0 entfernt – wer früh migriert, hat mehr Zeit für die Anpassung eigener Templates und kann das Feature-Flag in Ruhe auf Staging testen. Der Wechsel auf 6.7.9.0 ist ein Patch-Release und in der Regel rückwärtskompatibel.
Ein direkter Ranking-Verlust durch den Format-Wechsel ist nicht belegt – Google verarbeitet beide Formate. Risiken entstehen typischerweise nur, wenn beim Umstieg eigene Schema-Erweiterungen nicht mit migriert werden und dadurch Markup-Lücken entstehen. Eine begleitende Validierung mit dem Rich Results Test reduziert dieses Risiko.
In der Regel sind Product, Offer, AggregateRating und BreadcrumbList die umsatzkritischen Typen, weil sie direkt zu Sterne-Snippets, Preis-Anzeige und Kategoriepfad im SERP führen. Ergänzend WebSite/SearchAction für die Sitelinks Searchbox, Organization für das Knowledge-Panel-Logo und FAQPage für AI-Overview-Citations.
Für Standard-Shops mit gepflegten Stammdaten reicht das Feature-Flag in der Regel aus. Anpassungen sind typischerweise dann nötig, wenn Sie eigene Custom Fields (z.B. zusätzliche GTINs, Hersteller-Angaben, Videos) im Schema mit ausspielen wollen oder bestehende Microdata-Erweiterungen in eigenen Plugins haben. In diesen Fällen ist ein Template-Override unter storefront/layout/structured-data/ erfahrungsgemäß der sauberste Weg.
Die Dauer hängt von der Komplexität ab. Standard-Shops ohne eigene Schema-Erweiterungen lassen sich in der Regel innerhalb weniger Tage migrieren – inklusive Staging-Test, Validierung und Go-Live. Bei Shops mit individuellen Plugins, Custom Fields und mehrsprachigen Storefronts ist erfahrungsgemäß ein Aufwand von ein bis drei Wochen realistisch.
Eine kontrollierte Analyse fand keinen messbaren Citation-Vorteil durch Schema allein (Search Engine Journal). Strukturierte Daten ersetzen also keine gute Inhaltsstruktur – sie machen die vorhandene Struktur maschinell auswertbar, und genau das bleibt die Voraussetzung dafür, dass generative Systeme eine Seite sauber erfassen.