Datos estructurados de dimensiones de producto: campos vacíos

Los datos estructurados de dimensiones de producto son la parte de tu ficha que nada con ojos llega a leer nunca, y hoy son la parte que decide si tu producto aparece o no en una respuesta. Pusiste 600 × 320 × 720 mm en la imagen de especificaciones. Un comprador lo lee. Un rastreador, un feed de compras y un asistente que responde "¿qué gabinetes de pared tienen menos de 350 mm de profundidad?" no leen nada, porque ese número solo existe como píxeles.

Datos estructurados de dimensiones de producto significa la declaración legible por máquinas del tamaño físico de un producto: campos con nombre que llevan valores numéricos y unidades explícitas, publicados como JSON-LD en la página del producto o como columnas en un feed de comercio. Hoy hay tres especificaciones distintas que definen esos campos, no se ponen de acuerdo en los nombres, y la mayoría de los catálogos no llena ninguno.

Aquí está el bloque completo, campo por campo, con la versión para copiar y pegar al final.

Datos estructurados de dimensiones de producto: las tres especificaciones que leen tu tamaño

Lee dos veces la última fila, porque ahí está la trampa en la que cae casi todo catálogo.

Los campos de dimensiones de Google describen tu caja, no tu producto

shipping_length, shipping_width y shipping_height son opcionales, aceptan centímetros o pulgadas y están acotados a 1–400 cm o 1–150 inches. Google es explícito sobre su función: existen para ayudar a determinar el costo de envío cuando usas un método con tarifas calculadas por el transportista. Los tres deben enviarse juntos y en la misma unidad, o el dato no se puede usar en absoluto.

Es decir, describen el cartón. No hay ningún atributo de Merchant Center para las dimensiones del producto terminado.

Ese vacío es la razón por la que product_detail te importa más que cualquier otro campo de esta página. Lleva especificaciones técnicas que no cubren otros atributos, en un formato de tres partes separadas por exactamente dos signos de dos puntos:

section_name : attribute_name : attribute_value

section_name es opcional pero recomendado; attribute_name y attribute_value son obligatorios. Los ejemplos de Google siguen la forma Display:Size:13 inch y Battery:Capacity:12.5 hours. Lo que significa que el lugar correcto para el tamaño real de un producto en un feed de Google se ve así:

Dos reglas para que esto se mantenga limpio. Pon la unidad dentro de attribute_value: el campo es texto libre y un "600" pelado no sirve de nada. Y nunca repitas algo que ya tiene su propio atributo: Google te pide no duplicar información cubierta en otro lugar, y los datos de precio o de plazos de entrega están explícitamente prohibidos aquí.

schema.org: los cuatro campos más el que nadie usa

En la página misma, schema.org le da a Product propiedades de dimensión directas, y cada una acepta un Distance o un QuantitativeValue:

• width — "el ancho del artículo".
• height — "el alto del artículo".
• depth — "la profundidad del artículo".
• weight — un Mass o un QuantitativeValue.

Después está size, que es un campo de otra naturaleza y se usa mal de forma rutinaria. Su definición admite una cadena de texto simple como XL o 32Wx34L, un QuantitativeValue con unitCode, o un SizeSpecification completo, y dice sin rodeos que cuando eso no encaja "las propiedades width, height, depth y weight pueden ser más apropiadas". Traducción para quien vende algo que no es ropa: usa size para sistemas de tallas de indumentaria, usa las cuatro propiedades de dimensión para bienes físicos, y no metas 600x320x720 como cadena en size.

El campo que nadie usa es hasMeasurement, un QuantitativeValue sobre Product pensado para mediciones del artículo. Los ejemplos de schema.org son el tiro interno de un pantalón, el rodado de una bicicleta, el calibre de un tornillo. Acepta un arreglo, así que ahí es donde va cada dimensión secundaria: ancho interior de estante, altura de asiento, centros de fijación, luz de paso, paso de rosca. Son los números por los que un comprador te escribe un correo, y existe un campo estándar para ellos que está vacío en casi todos los catálogos.

Para las unidades, unitCode toma un código común UN/CEFACT de 3 caracteres: MMT milímetro, CMT centímetro, INH pulgada, KGM kilogramo, LBR libra. Si no tienes certeza del código, unitText con una cadena simple es válido y mejor que un código equivocado.

Para copiar y pegar: el bloque de dimensiones en JSON-LD

Colócalo dentro de tu nodo Product existente. Valida, está completo y separa a propósito el tamaño del producto del tamaño del cartón.

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

El feed de ChatGPT quiere los mismos números con otros nombres

La especificación del feed de productos de Agentic Commerce, el archivo que los comercios envían para las superficies de compras de ChatGPT, acepta dimensiones de dos maneras, y las reglas de dependencia son estrictas:

La especificación dice que las características físicas y la clasificación ayudan a la categorización, el filtrado y la relevancia de búsqueda, que es la manera llana de decir que un producto sin dimensiones es un producto que no se puede filtrar hacia un conjunto de resultados. Si un comprador pide un gabinete de menos de 350 mm de profundidad y tu campo depth está vacío, no quedas mal posicionado. Quedas ausente.

Un vacío que conviene admitir: la especificación no define un campo aparte para las dimensiones del embalaje, y no aclara si dimensions se refiere al producto o a su cartón. Declara a cuál te refieres en algún lugar que puedan leer tanto una persona como un modelo, y sé consistente en todo tu catálogo.

Por qué vale la pena llenar estos campos aunque Google no los muestre

Aquí viene la parte que suena a contradicción. La propia documentación de datos estructurados de Product de Google, la que enumera lo que te hace ganar un resultado enriquecido, no incluye width, height, depth, weight ni hasMeasurement. Su lista de compatibilidad llega hasta precio, disponibilidad, calificaciones de reseñas, envío, política de devoluciones, tallas de indumentaria, identificadores y pros y contras.

Así que el marcado de dimensiones no te va a dibujar un fragmento más grande. Nunca iba a hacerlo.

Lo que cambió es quien consume. Google dice que product_detail aporta datos estructurados que le ayudan a entender y mostrar productos en distintas superficies, incluidas funciones impulsadas por IA como el Modo IA en la Búsqueda; el feed de Agentic Commerce existe para que los productos se puedan encontrar y filtrar dentro de un chat. Esos sistemas no necesitan una plantilla visual que se dispare: necesitan un atributo que puedan comparar contra una restricción. Un campo de dimensión ya no es decoración de un resultado de búsqueda. Es lo que te califica para ser recuperado.

Lo cual reordena la prioridad: llena estos campos para los motores que responden preguntas, no para los que dibujan cajas.

La regla que rompe todo: un número, dos lugares

Todos los modos de falla que he visto con datos estructurados de dimensiones de producto vienen de la misma raíz: el feed dice una cosa y la imagen dice otra.

Pasa sin mala intención. Alguien escribe el tamaño del cartón en shipping_width, otra persona mide la unidad armada para el diagrama de especificaciones, y una tercera redondea 564 mm a 56 cm en product_detail. Ahora un asistente le dice con toda seguridad a un comprador que el gabinete mide 640 mm de ancho, el comprador mira tu imagen que dice 600, y acabas de fabricar un problema de confianza más una devolución. Peor: el número que se cita es el que leyó la máquina, porque es el que era legible.

La solución es proceso, no marcado: mide una vez y publica esa misma medida tanto en el campo como en la imagen. En concreto:

1. Mide el artículo terminado, no el plano ni el cartón, y registra a cuál se refiere cada cifra.
2. Pon cada cifra sobre la imagen junto a la característica que describe, anclada al borde real del producto y no flotando cerca de él, y exporta al tamaño de diagrama de especificaciones de cada plataforma. Un software hecho para anotar dimensiones hace esto de forma determinista, que es toda la diferencia frente a un editor de fotos genérico donde colocas las flechas a mano, o frente a un generador de imágenes, que renderizará sin problema una dimensión que nunca midió porque lo que optimiza es la verosimilitud.
3. Copia las mismas cifras a width/height/depth, a product_detail y a los campos de dimensión del feed. Misma fuente, mismo redondeo, mismas unidades.
4. Cuando una cifra cambia, cámbiala en los dos lugares en el mismo commit. Un par desalineado es peor que uno faltante.

Un ejemplo trabajado de la mitad visual de ese emparejamiento está en este caso de etiquetas de tamaño de producto, y la cuestión de unidades con la que tropieza la mitad de los exportadores se trata en dimensiones de producto en cm o pulgadas.

Lista de verificación antes de publicar

• width, height, depth presentes en el nodo Product, cada uno como QuantitativeValue con unitCode o unitText
• weight presente con su unidad
• Cada dimensión secundaria que un comprador realmente pregunta está en hasMeasurement con un name descriptivo
• size usado solo para sistemas de tallas de indumentaria, sin cadenas tipo 600x320x720
• Feed: shipping_length / shipping_width / shipping_height los tres presentes, en la misma unidad, y describiendo el cartón
• Feed: dimensiones del producto armado en product_detail, con la unidad dentro del valor y exactamente dos signos de dos puntos por entrada
• Feed: sin duplicar datos que ya tienen su propio atributo; sin precio ni plazos de entrega dentro de product_detail
• Feed agéntico: o dimensions con su unidad, o length+width+height más dimensions_unit
• Feed agéntico: weight nunca se envía sin item_weight_unit
• Las dimensiones del producto y las del cartón están etiquetadas de forma distinta en todos los lugares donde aparecen
• Cada número del marcado coincide con el número impreso en la imagen de especificaciones, al milímetro
• Hay una sola persona responsable de esa coincidencia, para que nadie edite un lado por su cuenta

FAQ

¿Cómo agrego las dimensiones del producto a los datos estructurados?

Pon width, height, depth y weight en tu nodo Product en JSON-LD, cada uno como un QuantitativeValue con un value numérico y un unitCode. Agrega toda otra característica medible como entradas de hasMeasurement con un name descriptivo. En un feed de Google, el tamaño armado va en product_detail, no en los campos shipping_*.

¿Google usa width, height y depth del schema de Product?

No para resultados enriquecidos. Las propiedades de producto compatibles con Google cubren precio, disponibilidad, reseñas, envío, política de devoluciones, tallas de indumentaria, identificadores y pros y contras: las dimensiones físicas no están en esa lista. Siguen importando para la recuperación y la comparación en superficies impulsadas por IA, que es un trabajo distinto y hoy más grande.

¿Cuál es la diferencia entre shipping_length y el tamaño real del producto?

shipping_length, shipping_width y shipping_height describen el paquete de envío y existen para poder calcular tarifas del transportista. No son las dimensiones terminadas del producto y no deberían llenarse con ellas. Merchant Center no tiene un atributo dedicado al tamaño armado, y por eso product_detail es el lugar correcto para ese dato.

¿Qué códigos de unidad debo usar para las dimensiones en JSON-LD?

unitCode toma un código común UN/CEFACT de 3 caracteres: MMT para milímetro, CMT centímetro, INH pulgada, KGM kilogramo, LBR libra. Si no estás seguro del código de una unidad, usa unitText con una cadena simple; un unitText legible le gana a un unitCode equivocado.

¿Sigo necesitando las dimensiones en la imagen del producto si ya están en el feed?

Sí, y el razonamiento es simétrico. Las máquinas leen los campos y no pueden leer tu imagen; los compradores leen la imagen y jamás van a abrir tu feed. Tu diagrama de dimensiones es una imagen, y todo sistema que decide si tu producto aparece en una respuesta lee texto, así que publica ambos y haz que coincidan al milímetro. Cómo redactar la mitad visual para que los compradores actúen se trata en cómo comunicar las dimensiones del producto a los compradores; si quieres el costo de equivocarse expresado en dinero, la calculadora de costo de devoluciones hace esa cuenta.

Fuentes y referencias

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode y unitText
• Google Merchant Center — atributos de dimensiones de envío y sus límites
• Google Merchant Center — atributo product detail [product_detail]
• Google Search Central — datos estructurados de Product y propiedades compatibles
• Agentic Commerce — especificación del feed de productos