Strukturierte Daten Produktmaße: die vergessenen Felder

Strukturierte Daten Produktmaße sind der Teil Ihres Listings, den nichts mit Augen jemals liest – und inzwischen genau der Teil, der entscheidet, ob Ihr Produkt in einer Antwort überhaupt auftaucht. Sie schreiben 600 × 320 × 720 mm auf das Maßbild. Ein Käufer liest es. Ein Crawler, ein Shopping-Feed und ein Assistent, der auf „Welche Wandschränke sind weniger als 350 mm tief?“ antwortet, lesen nichts, weil diese Zahl nur als Pixel existiert.

Strukturierte Daten Produktmaße bezeichnen die maschinenlesbare Angabe der physischen Größe eines Produkts: benannte Felder mit numerischen Werten und expliziten Einheiten, veröffentlicht entweder als JSON-LD auf der Produktseite oder als Spalten in einem Händler-Feed. Drei getrennte Spezifikationen definieren diese Felder inzwischen, sie sind sich bei den Namen nicht einig, und die meisten Kataloge füllen keines davon aus.

Hier ist der komplette Block, Feld für Feld, mit der Version zum Kopieren am Ende.

Strukturierte Daten Produktmaße: die drei Specs, die Ihre Größe lesen

Lesen Sie die letzte Zeile zweimal, denn dort steckt die Falle, in die fast jeder Katalog tappt.

Googles Maßfelder beschreiben Ihren Karton, nicht Ihr Produkt

shipping_length, shipping_width und shipping_height sind optional, akzeptieren Zentimeter oder Zoll und sind auf 1–400 cm bzw. 1–150 Zoll begrenzt. Google ist bei ihrer Aufgabe eindeutig: Sie existieren, um bei einer vom Carrier berechneten Versandmethode die Versandkosten zu ermitteln. Alle drei müssen gemeinsam und in derselben Einheit geliefert werden, sonst sind die Daten überhaupt nicht verwertbar.

Sie beschreiben also den Karton. Für die Maße des fertigen Produkts selbst gibt es kein Merchant-Center-Attribut.

Diese Lücke ist der Grund, warum product_detail für Sie wichtiger ist als jedes andere Feld auf dieser Seite. Es trägt technische Spezifikationen, die kein anderes Attribut abdeckt, in einem dreiteiligen Format, getrennt durch genau zwei Doppelpunkte:

section_name : attribute_name : attribute_value

section_name ist optional, aber empfohlen; attribute_name und attribute_value sind Pflicht. Googles eigene Beispiele folgen dem Muster Display:Size:13 inch und Battery:Capacity:12.5 hours. Der richtige Ort für die tatsächliche Größe eines Produkts in einem Google-Feed sieht damit so aus:

Zwei Regeln halten das sauber. Schreiben Sie die Einheit in attribute_value – das Feld ist Freitext, und eine nackte „600“ ist unbrauchbar. Und wiederholen Sie nie etwas, das schon ein eigenes Attribut hat: Google verlangt, keine Informationen zu duplizieren, die anderswo abgedeckt sind, und Preis- oder Lieferzeitangaben sind hier ausdrücklich unzulässig.

schema.org: die vier Felder und das eine, das niemand nutzt

Auf der Seite selbst gibt schema.org dem Product direkte Maß-Eigenschaften, jede akzeptiert einen Distance oder einen QuantitativeValue:

• width – „die Breite des Artikels“.
• height – „die Höhe des Artikels“.
• depth – „die Tiefe des Artikels“.
• weight – ein Mass oder ein QuantitativeValue.

Dann gibt es size, ein Feld anderer Art, das regelmäßig falsch verwendet wird. Seine Definition erlaubt einen einfachen Text wie XL oder 32Wx34L, einen QuantitativeValue mit unitCode oder eine vollständige SizeSpecification – und sie sagt unmissverständlich, dass dort, wo das nicht passt, „die Eigenschaften width, height, depth und weight passender sein können“. Übersetzt für alle, die etwas anderes als Bekleidung verkaufen: size für Konfektionsgrößensysteme, die vier Maß-Eigenschaften für physische Waren – und 600x320x720 gehört nicht als Zeichenkette in size.

Das Feld, das niemand nutzt, ist hasMeasurement, ein QuantitativeValue am Product, gedacht für Maße des Artikels – schema.orgs eigene Beispiele sind die Schrittlänge einer Hose, die Radgröße eines Fahrrads, die Gewindegröße einer Schraube. Es akzeptiert ein Array und ist damit der Ort für jedes sekundäre Maß: nutzbare Innenbreite, Sitzhöhe, Befestigungsabstand, Öffnungsmaß, Gewindesteigung. Genau nach diesen Zahlen fragen Käufer per E-Mail – und in fast jedem Katalog steht das dafür vorgesehene Standardfeld leer.

Bei den Einheiten nimmt unitCode einen dreistelligen UN/CEFACT Common Code – MMT Millimeter, CMT Zentimeter, INH Zoll, KGM Kilogramm, LBR Pfund. Wenn Sie sich bei einem Code unsicher sind, ist unitText mit einer einfachen Zeichenkette gültig und besser als ein falscher Code.

Schema Markup Produktabmessungen: der JSON-LD-Block zum Kopieren

Setzen Sie das in Ihren bestehenden Product-Knoten. Es validiert, es ist vollständig, und es trennt Produktmaß und Kartonmaß bewusst.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wall cabinet, 2-door, 600 mm",
  "sku": "WC-600-2D",
  "material": "Birch plywood, white melamine",
  "width":  { "@type": "QuantitativeValue", "value": 600, "unitCode": "MMT" },
  "height": { "@type": "QuantitativeValue", "value": 720, "unitCode": "MMT" },
  "depth":  { "@type": "QuantitativeValue", "value": 320, "unitCode": "MMT" },
  "weight": { "@type": "QuantitativeValue", "value": 14.2, "unitCode": "KGM" },
  "hasMeasurement": [
    { "@type": "QuantitativeValue", "name": "Internal shelf width",
      "value": 564, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Wall fixing centres",
      "value": 512, "unitCode": "MMT" },
    { "@type": "QuantitativeValue", "name": "Carton, longest side",
      "value": 760, "unitCode": "MMT" }
  ]
}

Der ChatGPT-Feed will dieselben Zahlen unter anderen Namen

Die Spezifikation des Agentic-Commerce-Produktfeeds – die Datei, die Händler für die Shopping-Oberflächen von ChatGPT ausliefern – nimmt Maße auf zwei Wegen auf, und die Abhängigkeitsregeln sind streng:

Die Spezifikation stellt fest, dass physische Merkmale und Klassifizierung bei Kategorisierung, Filterung und Suchrelevanz helfen – was schlicht heißt: Ein Produkt ohne Maße ist ein Produkt, das sich nicht in eine Ergebnismenge filtern lässt. Wenn ein Käufer nach einem Schrank mit weniger als 350 mm Tiefe fragt und Ihr Tiefenfeld leer ist, ranken Sie nicht schlecht. Sie fehlen.

Eine ehrliche Lücke: Die Spezifikation definiert kein eigenes Feld für Verpackungsmaße und sagt nicht, ob dimensions das Produkt oder seinen Karton meint. Legen Sie an einer Stelle fest, die Mensch und Modell lesen können, was davon gemeint ist – und bleiben Sie im gesamten Katalog konsistent.

Warum sich diese Felder lohnen, obwohl Google sie nicht anzeigt

Hier kommt der Teil, der wie ein Widerspruch klingt. Googles eigene Dokumentation zu strukturierten Daten für Product, die auflistet, was ein Rich-Ergebnis verdient, enthält width, height, depth, weight und hasMeasurement nicht. Die Liste der unterstützten Eigenschaften reicht von Preis, Verfügbarkeit, Bewertungen, Versand, Rückgabebedingungen und Konfektionsgrößen bis zu Kennungen sowie Vor- und Nachteilen.

Maß-Markup zeichnet Ihnen also kein größeres Snippet. Das war auch nie zu erwarten.

Geändert hat sich der Abnehmer der Daten. Google schreibt, product_detail liefere strukturierte Daten, die beim Verstehen und Darstellen von Produkten über verschiedene Oberflächen hinweg helfen – einschließlich KI-getriebener Funktionen wie AI Mode in der Suche; der Agentic-Commerce-Feed existiert, um Produkte innerhalb eines Chats findbar und filterbar zu machen. Diese Systeme brauchen keine visuelle Vorlage, um auszulösen – sie brauchen ein Attribut, das sie gegen eine Bedingung prüfen können. Ein Maßfeld ist keine Dekoration an einem Suchergebnis mehr. Es ist das, was Sie überhaupt für den Abruf qualifiziert.

Das verschiebt die Priorität: Füllen Sie diese Felder für die Engines, die Fragen beantworten, nicht für die, die Kästen zeichnen.

Die Regel, die alles bricht: eine Zahl, zwei Orte

Jeder Fehlerfall, den ich bei strukturierten Daten zu Produktmaßen gesehen habe, hat dieselbe Wurzel – der Feed sagt das eine, das Bild das andere.

Das passiert ganz harmlos. Jemand tippt das Kartonmaß in shipping_width, jemand anderes vermisst das montierte Möbel für die Maßzeichnung, eine dritte Person rundet 564 mm in product_detail auf 56 cm. Jetzt erklärt ein Assistent einem Käufer überzeugt, der Schrank sei 640 mm breit, der Käufer sieht auf Ihrem Bild 600 – und Sie haben ein Vertrauensproblem plus eine Rücksendung produziert. Schlimmer noch: Zitiert wird die maschinengelesene Zahl, weil sie die lesbare war.

Die Lösung ist Prozess, nicht Markup: einmal messen, dann dasselbe Maß in das Feld und auf das Bild veröffentlichen. Konkret –

1. Messen Sie den fertigen Artikel, nicht die Zeichnung und nicht den Karton, und notieren Sie, worauf sich jede Zahl bezieht.
2. Setzen Sie jede Zahl im Bild an das Merkmal, das sie beschreibt – an die echte Produktkante gesnappt, nicht daneben schwebend – und exportieren Sie in der Maßzeichnungsgröße der jeweiligen Plattform. Software, die für Maßannotation gebaut ist, macht das deterministisch, und genau darin liegt der Unterschied zu einem allgemeinen Bildeditor, in dem Sie Pfeile von Hand platzieren, oder zu einem Bildgenerator, der ein Maß bereitwillig rendert, das er nie gemessen hat – weil er auf Plausibilität optimiert.
3. Übertragen Sie dieselben Zahlen in width/height/depth, in product_detail und in die Maßfelder des Feeds. Gleiche Quelle, gleiche Rundung, gleiche Einheiten.
4. Ändert sich eine Zahl, ändern Sie sie im selben Commit an beiden Stellen. Ein auseinandergelaufenes Paar ist schlimmer als ein fehlendes.

Ein durchgerechnetes Beispiel für die Bildhälfte dieses Paars steht in dieser Fallstudie zu Größenangaben am Produktbild, und die Einheitenfrage, über die die Hälfte aller Exporteure stolpert, behandelt Produktmaße in cm oder Zoll.

Checkliste vor der Veröffentlichung

• width, height, depth am Product-Knoten vorhanden, jeweils als QuantitativeValue mit unitCode oder unitText
• weight mit Einheit vorhanden
• Jedes sekundäre Maß, nach dem Käufer tatsächlich fragen, steht in hasMeasurement mit beschreibendem name
• size nur für Konfektionsgrößensysteme – keine Zeichenketten wie 600x320x720
• Feed: shipping_length / shipping_width / shipping_height alle drei vorhanden, dieselbe Einheit, und sie beschreiben den Karton
• Feed: Maße des montierten Produkts in product_detail, Einheit innerhalb des Werts, genau zwei Doppelpunkte je Eintrag
• Feed: keine Dopplung von Daten, die schon ein eigenes Attribut haben; kein Preis und keine Lieferzeit in product_detail
• Agentic-Feed: entweder dimensions mit Einheit oder length+width+height plus dimensions_unit
• Agentic-Feed: weight niemals ohne item_weight_unit senden
• Produktmaße und Kartonmaße sind überall, wo sie auftauchen, klar voneinander unterschieden bezeichnet
• Jede Zahl im Markup stimmt millimetergenau mit der Zahl auf dem Maßbild überein
• Eine namentlich benannte Person verantwortet diese Übereinstimmung, damit niemand nur eine Seite ändert

FAQ

Wie füge ich Produktmaße in strukturierte Daten ein?

Setzen Sie width, height, depth und weight als JSON-LD an Ihren Product-Knoten, jeweils als QuantitativeValue mit numerischer value und einem unitCode. Ergänzen Sie jedes weitere messbare Merkmal als Einträge in hasMeasurement mit beschreibendem name. In einem Google-Feed gehört die Größe des montierten Produkts in product_detail, nicht in die shipping_*-Felder.

Nutzt Google width, height und depth aus dem Product-Schema?

Nicht für Rich Results. Die von Google unterstützten Produkteigenschaften umfassen Preis, Verfügbarkeit, Bewertungen, Versand, Rückgabebedingungen, Konfektionsgrößen, Kennungen sowie Vor- und Nachteile – physische Maße stehen nicht auf dieser Liste. Für Abruf und Vergleich in KI-getriebenen Oberflächen zählen sie trotzdem, und das ist eine andere und inzwischen größere Aufgabe.

Was ist der Unterschied zwischen shipping_length und der echten Produktgröße?

shipping_length, shipping_width und shipping_height beschreiben das Versandpaket und existieren, damit vom Carrier berechnete Tarife ermittelt werden können. Sie sind nicht die Maße des fertigen Produkts und sollten auch nicht damit gefüllt werden. Das Merchant Center hat kein eigenes Attribut für die Größe des montierten Produkts, und genau deshalb ist product_detail dafür der richtige Ort.

Welche Einheitencodes soll ich für Maße in JSON-LD verwenden?

unitCode nimmt einen dreistelligen UN/CEFACT Common Code – MMT für Millimeter, CMT Zentimeter, INH Zoll, KGM Kilogramm, LBR Pfund. Wenn Sie sich beim Code für eine Einheit nicht sicher sind, nutzen Sie stattdessen unitText mit einer einfachen Zeichenkette: Ein lesbarer unitText ist besser als ein falscher unitCode.

Brauche ich Maße auf dem Produktbild, wenn sie schon im Feed stehen?

Ja, und die Begründung ist symmetrisch. Maschinen lesen die Felder und können Ihr Bild nicht lesen; Käufer lesen das Bild und öffnen Ihren Feed nie. Ihre Maßzeichnung ist ein Bild, und jedes System, das entscheidet, ob Ihr Produkt in einer Antwort erscheint, liest Text – liefern Sie also beides und bringen Sie es millimetergenau zur Deckung. Wie Sie die Bildhälfte formulieren, damit Käufer darauf reagieren, behandelt Produktmaße an Käufer kommunizieren; und wenn Sie die Kosten eines Fehlers in Euro sehen wollen, rechnet das der Rechner für Rücksendekosten aus.

Quellen und Verweise

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode und unitText
• Google Merchant Center — Versandmaß-Attribute und ihre Grenzwerte
• Google Merchant Center — Attribut product detail [product_detail]
• Google Search Central — strukturierte Daten für Product und unterstützte Eigenschaften
• Agentic Commerce — Spezifikation des Produktfeeds