JSON-LD, llms.txt und Feeds in Shopware: Was wirklich Sichtbarkeit bringt

Mit strukturierten Daten, llms.txt und maschinenlesbaren Feeds geben Sie Suchmaschinen und KI-Systemen die wichtigsten Informationen Ihres Shops in lesbarer Form. Dieser Beitrag zeigt, welche JSON-LD Rich Snippets in Shopware tatsächlich etwas bringen, wie Sie Produkt-, Kategorie-, Organisations- und FAQ-Daten zentral ausspielen und welche Voraussetzungen dafür gelten.

Sie bekommen konkrete Einsatzfälle, die Grenzen der Lösung sowie Hinweise zur Kompatibilität (Shopware 6.5 bis 6.7) und zum Nutzen, den Sie realistisch erwarten können.

Woran erkennen Sie, dass fehlende strukturierte Daten ein konkretes Shopproblem sind?

Wenn Ihre Suchergebnisse keine Preis-, Verfügbarkeits- oder Bewertungsinfos anzeigen und Kategorieseiten in den SERPs wenig Kontext haben, sind strukturierte Daten eine mögliche Ursache.

Für die Diagnose beginnen Sie mit einem Blick in die Suchergebnisse und in KI-Antworten und arbeiten dann systematisch weiter. Öffnen Sie einige Produkt- und Kategorieseiten und suchen Sie im Seitenquelltext nach <script type="application/ld+json">. Fehlt ein JSON-LD-Block komplett, ist der Befund klar. Ist ein Block vorhanden, prüfen Sie, ob die wichtigsten Felder (Offer mit price und priceCurrency, availability, aggregateRating oder Review-Informationen) tatsächlich gefüllt sind oder nur leere Platzhalter enthalten.

Weitere sinnvolle Prüfungen:

• Rich-Results- und Schema-Validatoren: Die offiziellen Tools melden Fehler und zeigen fehlende Property-Zuweisungen.
• Search Console: In den Berichten zu Verbesserungen und strukturierten Daten stehen fehlende oder fehlerhafte Elemente oft schon aufgelistet.
• Server-Logs und Bot-Zugriffe: Prüfen Sie, ob Crawler die JSON-LD-Ressourcen fehlerfrei abrufen. Manche Bots sehen eine vereinfachte, gecachte oder anders ausgegebene Version.
• KI-Testabfragen: Stellen Sie produktbezogene Fragen an eine KI oder an interne Retrieval-Systeme. Geben die Antworten Preise, Verfügbarkeit oder Varianten nicht korrekt wieder, fehlt oft maschinenlesbarer Input oder er liegt nicht in standardisierter Form vor.

Typische Fehlerbilder: Sichtbare Inhalte widersprechen dem JSON-LD (der Preis im Frontend ändert sich, das JSON-LD bleibt alt), eine Seite enthält doppelte oder widersprüchliche JSON-LD-Blöcke, auf Variantenseiten fehlen Kennungen wie GTIN oder MPN, oder das JSON-LD wird nur clientseitig per JavaScript eingefügt, sodass manche Indexer es nicht zuverlässig sehen.

Betrifft das Problem einzelne, unwichtige Seiten, reicht eine punktuelle Korrektur. Tritt es systematisch auf, etwa bei vielen Produktseiten, bei allen Kategorieseiten oder bei typischen Nutzerfragen an eine KI, ist eine zentrale Lösung sinnvoller als viele einzelne Quickfixes.

Wie unterscheidet sich der Aufwand: manuelle Markup-Pflege oder zentrale JSON-LD-Ausspielung?

Strukturierte Daten pro Template oder Artikel von Hand zu pflegen, skaliert schlecht und führt zu Inkonsistenzen.

Die Unterschiede in Aufwand und Risiko:

• Skalierung und Drift: Bei manueller Pflege müssen Sie für jedes Template, jedes Theme-Update und jede neue Produktseite die Markup-Felder anpassen. Das bedeutet mehr Tests bei Releases und mehr Inkonsistenzen, etwa wenn Entwickler unterschiedliche Namenskonventionen verwenden.
• Eine Datenquelle: Eine zentrale JSON-LD-Generierung aus dem Produktstamm (PIM oder Shop-Datenbank) braucht nur eine Mapping-Logik. Produktdaten, Preise, Versandprofile und Rückgaberegeln werden einmal zusammengeführt und von dort an das Frontend, an Feeds und an llms.txt ausgegeben.
• Deployment und Tests: Zentral erzeugte Schemas lassen sich leichter per Unit-Test prüfen als JSON-Fragmente, die über viele Templates verteilt sind. Sinnvoll sind automatische Snapshot-Tests für die Schema-Generierung und eine Validierung in der CI-Pipeline.
• Performance und Invalidierung: Zentral heißt auch, dass Sie das Caching planen. Preise und Verfügbarkeiten ändern sich häufig, deshalb brauchen Sie ein sinnvolles Invalidierungsverfahren (zum Beispiel Cache-Keys an die Preis- oder Bestandsversion koppeln oder ereignisbasiert invalidieren). Ohne zentrale Steuerung ist das fehleranfälliger.

Gängige Umsetzungsmuster:

• Serverseitige Generierung: Das JSON-LD wird beim Rendern eingefügt. Das ist für Suchmaschinen und externe Crawler am zuverlässigsten.
• Service-Layer: Ein eigener Microservice oder Endpoint liefert die strukturierte Darstellung als API, die Frontend und Feeds abrufen.
• Template-Helper: Ein zentraler Renderer als Bibliothek, den die Templates aufrufen, damit das Ausgabeformat überall gleich bleibt.

Typische Fallen bei der Zentralisierung sind unvollständige Feldzuordnungen zwischen PIM und Shop-Datenbank, Vertrauen auf zentrale Logs ohne echte End-to-End-Prüfung und zu große JSON-LD-Blöcke mit unnötigen internen Metadaten. Eine zentrale Ausspielung verbessert Qualität und Konsistenz, sie garantiert aber keine Rich Results oder KI-Erwähnungen. Darüber entscheiden die Indexer.

Wie funktioniert die zentrale Ausspielung von Produkt-, Kategorie-, FAQ- und Organisationsdaten praktisch?

Das Plugin erzeugt Google-konforme JSON-LD-Snippets für Produkte, Kategorien, Organisation und FAQ und stellt sie zentral bereit.

Architektur und Mapping im Detail:

• Datenquelle: Die Stammdaten kommen aus dem PIM oder dem Shop-Backend (Produktkennungen, Preise, Versandprofile, Rückgaberegeln, Bewertungen). Die Pflegefelder sollten klar definiert sein, zum Beispiel was wirklich eine GTIN ist und auf welcher Ebene (Hauptprodukt oder Variante) sie steht.
• Schemaaufbau: Erzeugen Sie getrennte Blöcke für Product, Offer, AggregateRating/Review, BreadcrumbList, ItemList, Organization und FAQPage. Verwenden Sie @id für Entitäten, damit sich Schemata auf verschiedenen Seiten eindeutig verknüpfen lassen.
• OfferShippingDetails und MerchantReturnPolicy: Diese Angaben sollten aus den Versandprofilen und Rückgabe-Einstellungen kommen. Deklarative Felder statt Freitext sorgen dafür, dass Maschinen die Angaben verarbeiten können.
• Kategoriestruktur: Auf Kategorieseiten gehört eine ItemList mit ListItem-Einträgen, die auf die @id der Produkte verweisen. Achten Sie bei der Paginierung darauf, keine widersprüchlichen itemListElement-Positionen auszugeben, und setzen Sie canonical sowie rel-next/rel-prev korrekt, damit die Liste als zusammenhängend lesbar bleibt.
• Varianten und Identifikation: Geben Sie GTIN oder MPN nur dort aus, wo sie eindeutig zu einer Variante gehören. Hauptprodukte bekommen eine klare Kennzeichnung, die genaue Identifikation liefern die Variantenseiten.
• FAQ-Integration: Die FAQ-Daten sollten exakt die Fragen und Antworten enthalten, die Nutzer auch sehen. Synchronisieren Sie das Akkordeon im Frontend mit dem FAQPage-Schema, damit keine Abweichung entsteht.

Technische Hinweise und Fehlerquellen:

• Clientseitig erzeugtes JSON-LD erkennen manche Indexer schlechter. Besser ist die serverseitige Einbettung.
• Vermeiden Sie widersprüchliche Angaben: Steht im Frontend ein Preis, muss das Offer-Objekt denselben Preis enthalten. Sonst leidet das Vertrauen, und Suchmaschinen können die Daten abwerten.
• Content Security Policy: Manche Shops haben restriktive CSP-Regeln, die Inline-Scripts blockieren. Dann muss das JSON-LD extern oder über eine passende CSP-Konfiguration ausgeliefert werden.
• Sichtbarkeit: Geben Sie im JSON-LD keine Daten aus, die der Nutzer auf der Seite nicht sieht. Das kann als irreführend gewertet werden.

Wartung: Ändert sich ein Versandprofil, eine Rückgabeoption oder die URL-Struktur, sollte die zentrale Generierung das automatisch übernehmen. Tests und Monitoring helfen, Abweichungen früh zu bemerken.

Wann sind llms.txt und maschinenlesbare Feeds für KI-Suchsysteme sinnvoll?

llms.txt und maschinenlesbare Feeds lohnen sich, wenn KI-Suchsysteme gezielt strukturierte Produkt- und Kategoriedaten aus Ihrem Shop abrufen sollen.

Wozu dienen sie, und was unterscheidet sie von JSON-LD im HTML?

• llms.txt ist eine Hinweisdatei für LLM-Indexer. Sie zeigt, wo relevante Feeds oder Regeln für Crawling und Nutzung stehen. Ähnlich wie die robots.txt ist sie ein Einstiegspunkt zur Orientierung, eine Nutzung erzwingt sie nicht.
• Maschinenlesbare Feeds (JSON, CSV, XML) bieten einen einfachen Endpunkt für große, regelmäßige Abrufe. Für umfangreiche Indexierungen ist das deutlich effizienter, als jede Seite einzeln auszulesen.

Wann Sie Feeds und llms.txt in Betracht ziehen sollten:

• Wenn externe KI-Anbieter, Vergleichsportale oder interne Retrieval-Pipelines umfassend auf Ihren strukturierten Katalog zugreifen sollen.
• Wenn Ihr Katalog sehr groß ist oder sich häufig ändert und Sie ein performantes, abgestuftes Abrufverfahren brauchen (zum Beispiel Voll- und Delta-Feeds).
• Wenn Sie genau steuern wollen, welche Daten offen zugänglich sind und in welcher Granularität (etwa nur Produkt-Metadaten ohne personenbezogene Daten oder Bestellinformationen).

Im Betrieb zu beachten:

• Formatwahl: JSON ist für KI-Systeme meist am praktischsten, weil es verschachtelte Strukturen gut abbildet. CSV genügt für einfache Attribute. XML kommt in KI-Pipelines seltener vor, passt aber zu manchen Altsystemen.
• Delta- und Voll-Feed: Bieten Sie beide an, wenn häufige Aktualisierungen nötig sind. Dazu gehören klare Änderungsmetadaten (lastUpdated, changeType) und eine verlässliche Versionierung des Schemas.
• Sicherheit und Governance: Legen Sie fest, welche Daten Sie offenlegen. Für sensible Informationen eignen sich authentifizierte Feeds oder signierte URLs. Dokumentieren Sie Nutzungsbedingungen und Lizenz, damit Dritte wissen, wie sie die Daten verwenden dürfen.
• Monitoring: Beobachten Sie die Zugriffe auf Ihre Feeds, setzen Sie ein Rate-Limit und prüfen Sie, ob externe Systeme die Daten tatsächlich verarbeiten. Logs helfen, fehlerhafte Feed-Versionen und Zugriffe externer Indexer nachzuvollziehen.

Wichtig: llms.txt und Feeds erhöhen die Chance, dass KI-Systeme Ihre Daten sehen. Ob sie genutzt oder bevorzugt werden, lässt sich damit nicht erzwingen. Außerdem gelten dieselben rechtlichen Anforderungen wie bei jedem Datenzugriff, achten Sie also auf Datenschutz und Vertragsbedingungen mit Dritten. Mehr zur Sichtbarkeit in KI-Suchen lesen Sie auf unserer Seite zu GEO, AEO und LLM-Optimierung.

Welche Voraussetzungen, Einschränkungen und Einsatzszenarien gelten für die zentrale Lösung?

Die Erweiterung ist mit den Shopware-Versionen 6.5.0.0 bis 6.7.13.0 kompatibel. Während eines aktiven Abonnements sind Updates und Support durch uns als Hersteller inklusive, und es gibt einen kostenlosen Probemonat.

Voraussetzungen für eine erfolgreiche Integration:

• Zugriff auf Stammdaten: Sie brauchen saubere Produktstämme (PIM oder Shop-Datenbank) mit korrekten IDs, Preisen, Verfügbarkeiten, Versand- und Rückgabeinformationen sowie Bewertungsdaten.
• Serverseitiges Rendering oder ein anderer zuverlässiger Weg, JSON-LD auszuliefern. Clientseitiges Einfügen ist bequem, aber nicht für alle Crawler robust genug.
• Die Möglichkeit, Schemata und CSP anzupassen, damit JSON-LD-Blöcke nicht blockiert werden.

Einschränkungen und Grenzen:

• Plattformbindung: Das Plugin ist auf Shopware-Versionen beschränkt. Für andere Plattformen braucht es eine Portierung oder eine andere Lösung.
• Keine Garantie für Rich Results: Strukturierte Daten erhöhen die Chance auf erweiterte Darstellungen, garantieren sie aber nicht. Was angezeigt wird, entscheiden Suchmaschinen und KI-Produkte.
• Sonderformate: Verlangen Drittanbieter ein proprietäres Datenformat, kann das Plugin nicht jede individuelle Struktur abbilden.

Wann die Lösung besonders sinnvoll ist:

• Sie betreiben einen umfangreichen Katalog und wollen konsistente, maschinenlesbare Produkt- und Kategoriedaten aus einer Quelle anbieten.
• Sie wollen externe KI-Indexer oder Vergleichsportale unterstützen und dafür kontrollierte, dokumentierte Feeds und llms.txt bereitstellen.
• Sie wollen Schemata zentral pflegen und mit CI-Tests absichern, statt Markup über viele Templates zu verteilen.

Wann die Lösung nicht passt:

• Wenn Ihr System stark individualisierte, proprietäre Datenexporte außerhalb der standardisierten Schemata braucht.
• Wenn Ihre Infrastruktur keine serverseitige Einbettung von JSON-LD erlaubt oder Ihnen die Werkzeuge für Cache-Steuerung und Invalidierung fehlen.

Strukturierte Daten sind ein technisches Hilfsmittel und ersetzen keine inhaltliche Arbeit. Produkttexte, Bildqualität, Bewertungen und Preisgestaltung müssen Sie weiter pflegen. Planen Sie die Einführung deshalb als Teil eines Gesamtprozesses aus technischer Bereitstellung, automatisierten Tests, Monitoring und laufender inhaltlicher Optimierung. Wie wir technisches SEO für Shopware angehen, steht auf der Seite Shopware SEO.

Häufige Fragen

Unterstützt das Plugin GTIN, MPN und Produktmaße?

Ja. Das Plugin unterstützt das Produkt-Schema inklusive GTIN und MPN sowie Angaben zu Maßen und Eigenschaften. Diese Angaben werden im JSON-LD ausgegeben.

Verwaltet die Erweiterung hreflang- und canonical-Tags automatisch?

Laut Funktionsbeschreibung bietet die Erweiterung Canonical- und Paginierungs-Handling sowie automatisches hreflang. Bei speziellen Multidomain-Setups sollten Sie die Kompatibilität mit Ihrer Umsetzung prüfen.

Gibt es eine Garantie, dass Google Rich Results anzeigt?

Nein. Das Plugin liefert Google-konforme JSON-LD-Snippets, über die Anzeige von Rich Results entscheidet aber die Suchmaschine. Strukturierte Daten erhöhen die Chance, eine Garantie sind sie nicht.

Kann das Plugin noindex für Account- oder Checkout-Bereiche setzen?

Ja. Die Erweiterung bietet eine noindex/nofollow-Steuerung für Account, Checkout und Merkzettel sowie für einzelne Kategorien und statische Seiten.

Fazit

Wer JSON-LD für Produkte, Kategorien, Organisation und FAQ zentral ausspielt und dazu llms.txt und maschinenlesbare Feeds bereitstellt, spart Pflegeaufwand und liefert Suchmaschinen und KI-Systemen standardisierte Signale. Prüfen Sie vorher die Shopware-Kompatibilität (6.5.0.0 bis 6.7.13.0) und Ihre Projektanforderungen.

Das Plugin finden Sie im Shopware Store: Rich Snippets JSON-LD & SEO/AI-Sichtbarkeit.