Données structurées dimensions produit : les champs oubliés

Les données structurées dimensions produit sont la partie de votre fiche que rien de doté d'yeux ne lit jamais — et c'est désormais celle qui décide si votre produit apparaît, ou non, dans une réponse. Vous mettez 600 × 320 × 720 mm sur l'image technique. Un acheteur la lit. Un crawler, un flux shopping et un assistant qui répond à « quels caissons muraux font moins de 350 mm de profondeur ? » ne lisent rien, parce que ce nombre n'existe que sous forme de pixels.

Les données structurées dimensions produit désignent la déclaration lisible par machine de la taille physique d'un produit : des champs nommés portant des valeurs numériques et des unités explicites, publiés soit en JSON-LD sur la page produit, soit sous forme de colonnes dans un flux marchand. Trois spécifications distinctes définissent aujourd'hui ces champs, elles ne s'accordent pas sur les noms, et la plupart des catalogues n'en remplissent aucun.

Voici le bloc entier, champ par champ, avec la version à copier-coller à la fin.

Données structurées dimensions produit : les trois specs qui lisent votre taille

Relisez deux fois la dernière ligne : elle contient le piège dans lequel tombent presque tous les catalogues.

Les champs de dimensions de Google décrivent votre carton, pas votre produit

shipping_length, shipping_width et shipping_height sont optionnels, acceptent les centimètres ou les pouces, et sont bornés à 1–400 cm ou 1–150 pouces. Google est explicite sur leur rôle : ils existent pour aider à déterminer le coût d'expédition lorsque vous utilisez une méthode calculée par le transporteur. Les trois doivent être fournis ensemble dans la même unité, sinon la donnée est tout simplement inutilisable.

Ils décrivent donc le carton. Il n'existe aucun attribut Merchant Center pour les dimensions propres du produit fini.

C'est ce trou qui fait de product_detail le champ le plus important de cette page pour vous. Il transporte les spécifications techniques que les autres attributs ne couvrent pas, dans un format en trois parties séparées par exactement deux deux-points :

section_name : attribute_name : attribute_value

section_name est optionnel mais recommandé ; attribute_name et attribute_value sont obligatoires. Les exemples fournis par Google suivent la forme Display:Size:13 inch et Battery:Capacity:12.5 hours. Autrement dit, le bon emplacement pour la taille réelle d'un produit dans un flux Google ressemble à ceci :

Deux règles pour garder tout cela propre. Mettez l'unité à l'intérieur de attribute_value — le champ est du texte libre, et un « 600 » nu est inexploitable. Et ne répétez jamais une information qui possède déjà son propre attribut : Google vous demande de ne pas dupliquer ce qui est couvert ailleurs, et les données de prix ou de délai de livraison sont explicitement exclues ici.

schema.org : les quatre champs, plus celui que personne n'utilise

Sur la page elle-même, schema.org donne à Product des propriétés de dimension directes, chacune acceptant un Distance ou un QuantitativeValue :

• width — « la largeur de l'article ».
• height — « la hauteur de l'article ».
• depth — « la profondeur de l'article ».
• weight — un Mass ou un QuantitativeValue.

Vient ensuite size, un champ de nature différente et régulièrement mal employé. Sa définition autorise une simple chaîne de texte comme XL ou 32Wx34L, un QuantitativeValue avec un unitCode, ou une SizeSpecification complète — et elle précise noir sur blanc que, là où ces formes ne conviennent pas, « les propriétés width, height, depth et weight peuvent être plus appropriées ». Traduction pour quiconque vend autre chose que du textile : utilisez size pour les systèmes de tailles vestimentaires, utilisez les quatre propriétés de dimension pour les biens physiques, et ne mettez pas 600x320x720 dans size sous forme de chaîne.

Le champ que personne n'utilise, c'est hasMeasurement, un QuantitativeValue sur Product prévu pour les mesures de l'article — les exemples donnés par schema.org sont l'entrejambe d'un pantalon, la taille de roue d'un vélo, le pas d'une vis. Il accepte un tableau : c'est donc là que doit aller chaque dimension secondaire, largeur intérieure d'étagère, hauteur d'assise, entraxes de fixation, ouverture, pas de filetage. Ce sont précisément les nombres pour lesquels un acheteur vous écrit, et il existe pour eux un champ standard qui reste vide dans presque tous les catalogues.

Pour les unités, unitCode prend un code commun UN/CEFACT à 3 caractères — MMT millimètre, CMT centimètre, INH pouce, KGM kilogramme, LBR livre. En cas de doute sur un code, unitText avec une chaîne simple reste valide et vaut mieux qu'un code erroné.

Balisage schema dimensions produit : le bloc JSON-LD à copier-coller

Insérez ceci dans votre nœud Product existant. Il est valide, il est complet, et il sépare volontairement la taille du produit de celle du carton.

{
  "@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" }
  ]
}

Le flux ChatGPT veut les mêmes nombres sous d'autres noms

La spécification du flux produit Agentic Commerce — le fichier que les marchands poussent vers les surfaces shopping de ChatGPT — accepte les dimensions de deux façons, et les règles de dépendance sont strictes :

La spécification indique que les caractéristiques physiques et la classification aident à la catégorisation, au filtrage et à la pertinence de recherche — ce qui revient à dire, en clair, qu'un produit sans dimensions est un produit qu'on ne peut pas filtrer dans un jeu de résultats. Si un acheteur demande un caisson de moins de 350 mm de profondeur et que votre champ de profondeur est vide, vous n'êtes pas mal classé. Vous êtes absent.

Un manque, en toute honnêteté : la spécification ne définit aucun champ distinct pour les dimensions de l'emballage, et ne dit pas si dimensions désigne le produit ou son carton. Précisez lequel des deux vous voulez dire, à un endroit qu'un humain comme un modèle peuvent lire, et restez cohérent sur l'ensemble de votre catalogue.

Pourquoi remplir ces champs même si Google ne les affichera pas

Voici la partie qui ressemble à une contradiction. La documentation de Google sur les données structurées Product, celle qui liste ce qui vous donne droit à un résultat enrichi, n'inclut pas width, height, depth, weight ni hasMeasurement. Sa liste des propriétés prises en charge s'arrête au prix, à la disponibilité, aux notes d'avis, à la livraison, à la politique de retour, aux tailles textile, aux identifiants et aux avantages et inconvénients.

Le balisage des dimensions ne vous dessinera donc pas un extrait plus grand. Cela n'a jamais été prévu.

Ce qui a changé, c'est le consommateur de la donnée. Google indique que product_detail fournit des données structurées qui l'aident à comprendre et à afficher les produits sur ses différentes surfaces, y compris les fonctionnalités pilotées par l'IA comme AI Mode dans la recherche ; le flux Agentic Commerce, lui, existe pour rendre les produits trouvables et filtrables à l'intérieur d'une conversation. Ces systèmes n'ont pas besoin d'un modèle d'affichage pour se déclencher — ils ont besoin d'un attribut qu'ils peuvent comparer à une contrainte. Un champ de dimension n'est plus un ornement sur un résultat de recherche. C'est ce qui vous qualifie pour être récupéré.

Ce qui recadre la priorité : remplissez ces champs pour les moteurs qui répondent aux questions, pas pour ceux qui dessinent des cadres.

La règle qui casse tout : un nombre, deux endroits

Tous les modes de défaillance que j'ai vus avec les données structurées dimensions produit partent de la même racine — le flux dit une chose et l'image en dit une autre.

Cela arrive innocemment. Quelqu'un saisit la taille du carton dans shipping_width, quelqu'un d'autre mesure le meuble monté pour le schéma technique, une troisième personne arrondit 564 mm à 56 cm dans product_detail. Résultat : un assistant annonce avec assurance à un acheteur que le caisson fait 640 mm de large, l'acheteur regarde votre image qui indique 600, et vous venez de fabriquer un problème de confiance, plus un retour. Pire encore : le nombre lu par la machine est celui qui sera cité, parce que c'est celui qui était lisible.

Le correctif relève du processus, pas du balisage : mesurez une fois, puis publiez cette même mesure dans le champ et sur l'image. Concrètement —

1. Mesurez l'article fini, pas le plan et pas le carton, et notez à quoi se rapporte chaque chiffre.
2. Posez chaque chiffre sur l'image, contre l'élément qu'il décrit — accroché au bord réel du produit, pas flottant à côté — et exportez à la taille de schéma technique de chaque plateforme. Un logiciel conçu pour l'annotation de dimensions le fait de façon déterministe, et c'est toute la différence avec un éditeur photo généraliste où vous placez les flèches à la main, ou avec un générateur d'images, qui affichera volontiers une cote qu'il n'a jamais mesurée, parce que « plausible » est ce qu'il optimise.
3. Recopiez les mêmes chiffres dans width/height/depth, dans product_detail et dans les champs de dimension du flux. Même source, même arrondi, mêmes unités.
4. Quand un chiffre change, changez-le des deux côtés dans le même commit. Une paire désynchronisée est pire qu'une donnée manquante.

Un exemple travaillé de la moitié « image » de cette paire se trouve dans cette étude de cas sur les étiquettes de dimensions produit, et la question des unités, qui fait trébucher la moitié des exportateurs, est traitée dans dimensions produit en cm ou en pouces.

Checklist avant publication

• width, height, depth présents sur le nœud Product, chacun en QuantitativeValue avec unitCode ou unitText
• weight présent, avec une unité
• Chaque dimension secondaire qu'un acheteur demande réellement figure dans hasMeasurement, avec un name descriptif
• size réservé aux systèmes de tailles textile — aucune chaîne du type 600x320x720
• Flux : shipping_length / shipping_width / shipping_height tous les trois présents, dans la même unité, et décrivant le carton
• Flux : dimensions du produit monté dans product_detail, unité à l'intérieur de la valeur, exactement deux deux-points par entrée
• Flux : aucune duplication d'une donnée qui possède déjà son propre attribut ; ni prix ni délai de livraison dans product_detail
• Flux agentique : soit dimensions avec son unité, soit length+width+height plus dimensions_unit
• Flux agentique : weight jamais envoyé sans item_weight_unit
• Dimensions du produit et dimensions du carton étiquetées distinctement partout où elles apparaissent
• Chaque nombre du balisage correspond au nombre imprimé sur l'image technique, au millimètre près
• Un responsable nommé pour cette correspondance, afin que personne ne modifie un seul côté

FAQ

Comment ajouter les dimensions produit dans les données structurées ?

Mettez width, height, depth et weight sur votre nœud Product en JSON-LD, chacun en QuantitativeValue avec une value numérique et un unitCode. Ajoutez toutes les autres caractéristiques mesurables comme entrées de hasMeasurement, avec un name descriptif. Dans un flux Google, la taille du produit monté appartient à product_detail, pas aux champs shipping_*.

Google utilise-t-il width, height et depth du schema Product ?

Pas pour les résultats enrichis. Les propriétés produit prises en charge par Google couvrent le prix, la disponibilité, les avis, la livraison, la politique de retour, les tailles textile, les identifiants et les avantages et inconvénients — les dimensions physiques ne figurent pas sur cette liste. Elles comptent malgré tout pour la récupération et la comparaison sur les surfaces pilotées par l'IA, ce qui est un autre travail, et désormais un plus gros.

Quelle est la différence entre shipping_length et la taille réelle du produit ?

shipping_length, shipping_width et shipping_height décrivent le colis d'expédition et existent pour permettre le calcul des tarifs transporteur. Ce ne sont pas les dimensions du produit fini et il ne faut pas les remplir avec. Merchant Center n'a aucun attribut dédié à la taille du produit monté, et c'est pour cela que product_detail en est le bon emplacement.

Quels codes d'unité utiliser pour les dimensions en JSON-LD ?

unitCode prend un code commun UN/CEFACT à 3 caractères — MMT pour le millimètre, CMT le centimètre, INH le pouce, KGM le kilogramme, LBR la livre. Si vous n'êtes pas certain du code correspondant à une unité, utilisez plutôt unitText avec une chaîne simple : un unitText lisible vaut mieux qu'un unitCode erroné.

Faut-il encore afficher les dimensions sur l'image produit si elles sont dans le flux ?

Oui, et le raisonnement est symétrique. Les machines lisent les champs et ne savent pas lire votre image ; les acheteurs lisent l'image et n'ouvriront jamais votre flux. Votre schéma de dimensions est une image, et chaque système qui décide si votre produit apparaît dans une réponse lit du texte — livrez donc les deux, et faites-les concorder au millimètre. La manière de formuler la partie image pour que les acheteurs en tiennent compte est traitée dans communiquer les dimensions produit aux acheteurs ; et si vous voulez chiffrer en euros le coût d'une erreur, le calculateur de coût des retours fait ce calcul.

Sources et références

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode et unitText
• Google Merchant Center — attributs de dimensions d'expédition et leurs limites
• Google Merchant Center — attribut product detail [product_detail]
• Google Search Central — données structurées Product et propriétés prises en charge
• Agentic Commerce — spécification du flux produit