Strukturierte Produktdaten heißt: Jede Produkteigenschaft steckt in einem typisierten Attribut mit E…
Strukturierte Produktdaten: So zeigen sie sich in der Storefront
Strukturierte Produktdaten heißt: Jede Produkteigenschaft steckt in einem typisierten Attribut mit Einheit, stabiler Kennung und klarer Position in der Variantenhierarchie, nicht im Beschreibungstext. Das Datenmodell selbst sieht im Shop niemand, seine Folgen schon, und zwar an fünf Stellen: Filter, Vergleichstabellen, Variantenauswahl, Schema.org-Markup und Feeds. Ist das Modell schwach, muss jede dieser Komponenten raten, und das merken Kundinnen und Kunden.
Was "strukturiert" im Produktkatalog praktisch heißt
"Wir haben ein PIM" und "unsere Produktdaten sind strukturiert" sind zwei verschiedene Aussagen. Struktur entsteht durch die Modellierungsentscheidungen, die du im PIM triffst:
- Attributmodell: Jedes Attribut hat einen Typ (Text aus einer Werteliste, Zahl, Ja/Nein, Bereich) statt Freitext. "Weiß", "weiß " und "ws" sind drei Filterwerte, ein Wert aus einer Liste ist einer.
- Einheiten: Zahl und Einheit werden getrennt gespeichert. "ca. 60 cm" im Textfeld wird nie ein Schieberegler, 60 mit der Einheit cm schon.
- Klassifikation: In technischen B2B-Sortimenten nehmen dir Standards wie ETIM und ECLASS diese Regeln ab. ETIM beschreibt Produkte über Klassen und Merkmale in vier Typen (alphanumerisch, logisch, numerisch, Bereich), numerische Merkmale und Bereichsmerkmale brauchen eine Einheit, außer Zählmerkmale wie Anzahl Pole. ECLASS vergibt jeder Eigenschaft eine weltweit eindeutige Kennung (IRDI) und kennt Wertelisten und umrechenbare Einheiten.
- Varianten: Ein Elternprodukt trägt die gemeinsamen Informationen, jede kaufbare Variante eigene SKU, GTIN, Preis und Bestand, und die Variantenachsen (Größe, Farbe, Spannung) sind explizit.
- Mehrsprachigkeit: Kennungen bleiben sprachunabhängig, übersetzt werden nur Bezeichnungen und Werte.
- Medien-Zuordnung: Bilder hängen an der Variante oder Option, die sie zeigen, nicht nur lose in einer Galerie.
Filter und Facetten: Hier zeigen sich Lücken zuerst
Eine Facette ist nur so gut wie das Attribut dahinter. In Laioutr definiert Orchestr einen Filter-Vertrag für Listing-Seiten: Listenfilter, Ja/Nein-Schalter, stufenlose Bereiche und vorab gebildete Intervalle. Bereichsgrenzen können Zahlen, Geldbeträge oder Messwerte mit Einheit sein. Die Verbindung zu deinem Datenmodell ist direkt: Eine Breite als Zahl plus Einheit wird ein Schieberegler, eine Breite als Text im besten Fall eine lange, unsortierte Checkbox-Liste.
Facettenwerte und Trefferzahlen liefern dein Backend oder dein Suchanbieter; Komponenten wie die Filterleiste und das Off-Canvas-Filtermenü zeigen an, was Orchestr zurückgibt. Wenn du darüber semantische Suche und Filter willst, die sich an die Treffermenge anpassen, deckt das AI Search & Discovery als Add-on ab. Die Basis deiner Facetten bleibt dein Attributmodell.
Filter sind auch fürs Crawling relevant: Googles Leitfaden zur facettierten Navigation empfiehlt, Filter-URLs vom Crawling auszuschließen, wenn sie nicht indexiert werden müssen. Sollen sie indexiert werden, gehören eine konsistente Parameter-Reihenfolge und ein 404 für leere Kombinationen dazu. Wie oft Kundinnen und Kunden mit einem Filter statt mit der Suche einsteigen, zeigt unsere Analyse zu KI-Suche, Kategorie-Navigation und Facettenfiltern.
Datenblätter und Vergleichstabellen: Warum gemeinsame Kennungen zählen
Im kanonischen Produktmodell von Laioutr sind Spezifikationen geordnete Zeilen: ein Anzeigename, ein typisierter Wert (Text, Zahl, Wahrheitswert, Messwert oder Geldbetrag) und optional ein Abschnitt wie "Maße" oder "Technik". Die Spezifikationstabelle formatiert jeden Wert passend zur Locale und gruppiert die Zeilen in Abschnitte. Wer in Deutschland einkauft, sieht "1,5 kg", wer in den USA einkauft, "1.5 kg", aus denselben Daten.
Eine Vergleichstabelle stellt diese Zeilen für mehrere Produkte nebeneinander, und das funktioniert nur, wenn die Zeilen dieselben Kennungen tragen. Heißt es bei einem Produkt "Gewicht" und beim nächsten "Nettogewicht (kg)", hat die Tabelle Löcher, und eine Ansicht "nur Unterschiede" vergleicht am Ende Beschriftungen statt Werte. Standardisierte Eigenschaftsnamen gibt es genau dafür: Zeilen aus unterschiedlichen Konnektoren passen zusammen.
Sind die Zeilen konsistent, ist das Platzieren der Spezifikationstabelle auf der Produktdetailseite Layout-Arbeit und kein Datenprojekt, erledigt von der Redaktion in Studio, dem visuellen Editor von Laioutr. Eine Produktvergleichsansicht, falls dein Projekt eine baut, liest dieselben Zeilen.
Variantenauswahl: Achsen, Verfügbarkeit und Bilder
Im kanonischen Modell hält ein Produkt seine Optionsgruppen (zum Beispiel Größe mit S, M, L und Farbe mit Rot und Blau), und jede Variante trägt ihre gewählten Optionen, SKU, optional GTIN, Verfügbarkeit und Preise inklusive Grundpreis.
Drei typische Fehlerbilder tauchen hier auf:
- Farben als eigene Produkte modelliert. Die Auswahl kann sie nicht anbieten, also springen Kundinnen und Kunden zwischen Produktseiten.
- Verfügbarkeit nur pro Wert. "XL" ausgrauen klappt pro Achsenwert, "Rot in XL" ist aber eine Kombination und braucht Bestand auf Variantenebene.
- Bilder nur am Elternprodukt. Wer Blau wählt, sieht einen neuen Preis, aber das alte Foto.
Alle drei behebst du im Datenmodell, nicht in der Komponente.
Schema.org und Feeds: dieselbe Struktur, von Maschinen gelesen
Suchmaschinen und KI-Antwortsysteme lesen dieselben Fakten wie deine Filter. Mit Schema.org kann ein Product zusätzliche Eigenschaften als PropertyValue-Paare tragen: propertyID nimmt einen Standardcode für das Merkmal auf, dort passt eine ETIM- oder ECLASS-Kennung hin, und unitCode einen UN/CEFACT-Einheitencode. Für Varianten dokumentiert Google eine ProductGroup mit productGroupID, den Merkmalen, nach denen sie variiert, und verschachtelten Varianten.
In einem Laioutr-Frontend kannst du JSON-LD mit dem Nuxt-Schema.org-Modul aus der Entität erzeugen, die eine Sektion rendert, statt aus separat gepflegten SEO-Feldern. So haben Markup und sichtbare Seite eine Quelle, mehr dazu unter SEO und GEO.
Feeds folgen denselben Regeln. Google Merchant Center erwartet über alle Varianten einer Gruppe dieselbe Item-Group-ID und unterschiedliche Werte für Farbe, Größe, Material oder Muster. Warum aus vierzig Kanälen vierzig Wahrheiten werden, beschreibt unser Beitrag zur Konsistenz von Produktdaten über Kanäle hinweg. Für Kanal-Exporte direkt aus dem Frontend-Layer gibt es Distributr als Add-on: 0 Importe, die Daten sind schon da, 1 Richtung, raus. Ein PIM ist es nicht.
Ein Datenmodell über alle Backends mit Orchestr
Produktdaten liegen selten in einem System: Das PIM verantwortet Attribute und Medien, das ERP Preise und Bestand, ein Suchanbieter die Facetten. Orchestr bildet diese Quellen auf ein kanonisches Modell aus Produkten, Varianten, Spezifikationen und Filtern ab, sodass Komponenten dieselbe Form bekommen, egal woher ein Feld stammt. Es bündelt mehrere sequenzielle API-Aufrufe in einem Request und nutzt dreistufiges Caching. Laioutr verbindet sich mit 50+ Backends über 300+ Integrationen; weitere Quellen lassen sich über eine Orchestr-Integration anbinden. Mehr zur Architektur: Composability und Orchestrierung.
So startest du:
- Prüfe die 20 Attribute, die deine wichtigsten Kategoriefilter nutzen: Typ, Einheit, Werteliste.
- Lege die Variantenachsen im PIM fest, bevor das nächste Frontend-Release ansteht.
- Ordne Attributkennungen gemeinsamen Namen zu, damit Vergleichszeilen zusammenpassen.
- Erzeuge strukturierte Daten aus der gerenderten Entität und prüfe deine Feeds dagegen.
FAQ
Brauchen wir ETIM oder ECLASS?
Nur wenn euer Markt sie erwartet, typischerweise im technischen Großhandel, in der Elektro- und Gebäudetechnik oder im industriellen Einkauf. Für Mode oder Konsumgüter reicht meist ein sauberes eigenes Attributmodell mit typisierten Werten und Einheiten.
Ersetzt Laioutr unser PIM?
Nein. Das PIM bleibt das führende System für Produktdaten. Laioutr ist die Frontend-Ebene: Es liest die Daten über Orchestr, rendert sie in Komponenten und hält die Storefront über Backends hinweg konsistent.
Wer pflegt Filter und Datenblätter, Entwicklung oder Marketing?
Beide, mit klarer Aufteilung. Die Entwicklung definiert Komponenten und Datenanbindung einmal. Produkt- und Marketing-Teams platzieren und konfigurieren sie in Studio, ohne Ticket für jede Kategorieseite.
Nächste Schritte
Du willst sehen, wie sich dein Attributmodell in Filtern, Datenblättern und Variantenauswahl verhält? Buch dir eine Demo und bring eine Beispielkategorie mit. Wir schauen sie uns gemeinsam auf einem Composable Headless Frontend an.