Dados estruturados de dimensões do produto: campos vazios

Dados estruturados de dimensões do produto são a parte do seu anúncio que nada com olhos chega a ler, e hoje são justamente a parte que decide se o seu produto aparece ou não em uma resposta. Você colocou 600 × 320 × 720 mm na imagem de especificações. Um comprador lê. Um rastreador, um feed de compras e um assistente respondendo "quais armários de parede têm menos de 350 mm de profundidade?" não leem nada, porque esse número existe apenas como pixels.

Dados estruturados de dimensões do produto são a declaração legível por máquina do tamanho físico de um produto: campos com nome carregando valores numéricos e unidades explícitas, publicados como JSON-LD na página do produto ou como colunas em um feed de vendas. Hoje três especificações distintas definem esses campos, elas discordam quanto aos nomes, e a maioria dos catálogos não preenche nenhum deles.

Aqui está o bloco inteiro, campo por campo, com a versão para copiar e colar no final.

Dados estruturados de dimensões do produto: as três especificações que leem seu tamanho

Leia a última linha duas vezes, porque é ali que está a armadilha em que quase todo catálogo cai.

Os campos de dimensão do Google descrevem sua caixa, não seu produto

shipping_length, shipping_width e shipping_height são opcionais, aceitam centímetros ou polegadas e ficam limitados a 1–400 cm ou 1–150 inches. O Google é explícito sobre a função deles: existem para ajudar a determinar o custo de frete quando você usa um método com tarifa calculada pela transportadora. Os três precisam ser enviados juntos, na mesma unidade, ou o dado simplesmente não pode ser usado.

Ou seja, eles descrevem a caixa de papelão. Não existe atributo no Merchant Center para as dimensões do produto acabado.

É essa lacuna que faz product_detail importar mais para você do que qualquer outro campo desta página. Ele carrega especificações técnicas não cobertas por outros atributos, em um formato de três partes separadas por exatamente dois sinais de dois-pontos:

section_name : attribute_name : attribute_value

section_name é opcional, mas recomendado; attribute_name e attribute_value são obrigatórios. Os próprios exemplos do Google seguem o formato Display:Size:13 inch e Battery:Capacity:12.5 hours. O que significa que o lugar certo para o tamanho real de um produto em um feed do Google fica assim:

Duas regras para isso não virar bagunça. Coloque a unidade dentro de attribute_value: o campo é texto livre e um "600" solto é inutilizável. E nunca repita algo que já tem atributo próprio: o Google orienta a não duplicar informação coberta em outro lugar, e dados de preço ou de prazo de entrega estão explicitamente fora de escopo aqui.

schema.org: os quatro campos mais aquele que ninguém usa

Na própria página, o schema.org dá ao Product propriedades de dimensão diretas, cada uma aceitando um Distance ou um QuantitativeValue:

• width — "a largura do item".
• height — "a altura do item".
• depth — "a profundidade do item".
• weight — um Mass ou um QuantitativeValue.

Aí existe o size, que é um campo de outra natureza e é mal usado rotineiramente. A definição dele aceita uma string de texto simples como XL ou 32Wx34L, um QuantitativeValue com unitCode, ou um SizeSpecification completo, e diz sem rodeios que, quando nada disso serve, "as propriedades width, height, depth e weight podem ser mais adequadas". Traduzindo para quem vende qualquer coisa que não seja roupa: use size para sistemas de numeração de vestuário, use as quatro propriedades de dimensão para bens físicos, e não coloque 600x320x720 como string em size.

O campo que ninguém usa é o hasMeasurement, um QuantitativeValue no Product feito para medições do item. Os exemplos do próprio schema.org são a altura interna da perna de uma calça, o aro de uma bicicleta, a bitola de um parafuso. Ele aceita um array, então é ali que mora cada dimensão secundária: largura interna da prateleira, altura do assento, centros de fixação, vão livre, passo da rosca. São exatamente os números pelos quais o comprador te manda e-mail, e existe um campo padrão para eles vazio em quase todo catálogo.

Para unidades, unitCode recebe um código comum UN/CEFACT de 3 caracteres: MMT milímetro, CMT centímetro, INH polegada, KGM quilograma, LBR libra. Se você não tem certeza do código, unitText com uma string simples é válido e melhor do que um código errado.

Para copiar e colar: o bloco de dimensões em JSON-LD

Coloque isto dentro do seu nó Product existente. Ele valida, está completo e separa de propósito o tamanho do produto do tamanho da caixa.

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

O feed do ChatGPT quer os mesmos números com outros nomes

A especificação do feed de produtos do Agentic Commerce, o arquivo que os lojistas enviam para as superfícies de compra do ChatGPT, aceita dimensões de duas formas, e as regras de dependência são rígidas:

A especificação afirma que características físicas e classificação ajudam na categorização, na filtragem e na relevância de busca, o que é a forma direta de dizer que um produto sem dimensões é um produto que não pode ser filtrado para dentro de um conjunto de resultados. Se um comprador pede um armário com menos de 350 mm de profundidade e seu campo depth está vazio, você não fica mal ranqueado. Você fica ausente.

Uma lacuna que vale admitir: a especificação não define um campo separado para dimensões da embalagem e não diz se dimensions se refere ao produto ou à caixa. Declare qual dos dois você quer dizer em algum lugar que uma pessoa e um modelo consigam ler, e mantenha isso consistente em todo o catálogo.

Por que vale preencher esses campos mesmo que o Google não os mostre

Agora vem a parte que soa como contradição. A documentação de dados estruturados de Product do próprio Google, aquela que lista o que rende um resultado rico, não inclui width, height, depth, weight nem hasMeasurement. A lista de propriedades suportadas vai até preço, disponibilidade, notas de avaliação, frete, política de devolução, numeração de vestuário, identificadores e prós e contras.

Então marcação de dimensão não vai te desenhar um snippet maior. Nunca ia mesmo.

O que mudou foi quem consome. O Google diz que product_detail fornece dados estruturados que ajudam a entender e exibir produtos em várias superfícies, incluindo recursos com IA como o Modo IA na Busca; o feed do Agentic Commerce existe para tornar produtos encontráveis e filtráveis dentro de um chat. Esses sistemas não precisam de um template visual para disparar: precisam de um atributo que possam comparar com uma restrição. Um campo de dimensão já não é enfeite no resultado de busca. É o que qualifica você para ser recuperado.

O que reordena a prioridade: preencha esses campos para os motores que respondem perguntas, não para os que desenham caixas.

A regra que quebra tudo: um número, dois lugares

Todo modo de falha que já vi com dados estruturados de dimensões do produto vem da mesma raiz: o feed diz uma coisa e a imagem diz outra.

E acontece sem má intenção. Alguém digita o tamanho da caixa em shipping_width, outra pessoa mede a unidade montada para o desenho técnico, e uma terceira arredonda 564 mm para 56 cm no product_detail. Agora um assistente diz com toda a confiança ao comprador que o armário tem 640 mm de largura, o comprador olha sua imagem que diz 600, e você acabou de fabricar um problema de confiança mais uma devolução. Pior: o número citado é o que a máquina leu, porque era o legível.

A correção é processo, não marcação: meça uma vez e publique essa mesma medida tanto no campo quanto na imagem. Concretamente:

1. Meça o item acabado, não o desenho nem a caixa, e registre a qual dos dois cada número se refere.
2. Coloque cada número na imagem junto ao elemento que ele descreve, encostado na borda real do produto e não flutuando por perto, e exporte no tamanho de desenho técnico de cada plataforma. Software feito para anotação de dimensões faz isso de forma determinística, e é aí que está toda a diferença em relação a um editor de fotos genérico, no qual você posiciona as setas à mão, ou a um gerador de imagens, que renderiza sem cerimônia uma dimensão que nunca mediu, porque o que ele otimiza é a plausibilidade.
3. Copie os mesmos números para width/height/depth, para product_detail e para os campos de dimensão do feed. Mesma fonte, mesmo arredondamento, mesmas unidades.
4. Quando um número muda, mude nos dois lugares no mesmo commit. Um par desalinhado é pior do que um valor faltando.

Um exemplo trabalhado da metade visual desse par está neste estudo de caso de etiquetas de tamanho de produto, e a questão de unidade em que metade dos exportadores tropeça está em dimensões do produto em cm ou polegadas.

Checklist antes de publicar

• width, height, depth presentes no nó Product, cada um como QuantitativeValue com unitCode ou unitText
• weight presente com unidade
• Toda dimensão secundária que o comprador realmente pergunta está em hasMeasurement com um name descritivo
• size usado apenas para sistemas de numeração de vestuário, sem strings tipo 600x320x720
• Feed: shipping_length / shipping_width / shipping_height os três presentes, na mesma unidade, e descrevendo a caixa
• Feed: dimensões do produto montado em product_detail, com a unidade dentro do valor e exatamente dois sinais de dois-pontos por entrada
• Feed: sem duplicar dado que já tem atributo próprio; sem preço nem prazo de entrega dentro de product_detail
• Feed agêntico: ou dimensions com sua unidade, ou length+width+height mais dimensions_unit
• Feed agêntico: weight nunca enviado sem item_weight_unit
• Dimensões do produto e dimensões da caixa estão rotuladas de forma distinta em todo lugar em que aparecem
• Todo número da marcação bate com o número impresso na imagem de especificações, no milímetro
• Uma pessoa responsável nomeada por essa correspondência, para que ninguém edite só um dos lados

FAQ

Como adicionar as dimensões do produto aos dados estruturados?

Coloque width, height, depth e weight no seu nó Product em JSON-LD, cada um como um QuantitativeValue com value numérico e unitCode. Adicione toda outra característica mensurável como entradas em hasMeasurement, com um name descritivo. Em um feed do Google, o tamanho montado vai em product_detail, não nos campos shipping_*.

O Google usa width, height e depth do schema de Product?

Não para resultados ricos. As propriedades de produto suportadas pelo Google cobrem preço, disponibilidade, avaliações, frete, política de devolução, numeração de vestuário, identificadores e prós e contras: dimensões físicas não estão nessa lista. Elas continuam importando para recuperação e comparação nas superfícies com IA, que é um trabalho diferente e hoje maior.

Qual a diferença entre shipping_length e o tamanho real do produto?

shipping_length, shipping_width e shipping_height descrevem a embalagem de envio e existem para que a tarifa calculada pela transportadora possa ser apurada. Não são as dimensões do produto acabado e não devem ser preenchidos com elas. O Merchant Center não tem atributo dedicado ao tamanho montado, e é por isso que product_detail é o lugar correto para esse dado.

Quais códigos de unidade usar para dimensões em JSON-LD?

unitCode recebe um código comum UN/CEFACT de 3 caracteres: MMT para milímetro, CMT centímetro, INH polegada, KGM quilograma, LBR libra. Se você não tem certeza do código de uma unidade, use unitText com uma string simples; um unitText legível ganha de um unitCode errado.

Ainda preciso das dimensões na imagem do produto se elas já estão no feed?

Sim, e o raciocínio é simétrico. As máquinas leem os campos e não conseguem ler sua imagem; os compradores leem a imagem e nunca vão abrir seu feed. Seu desenho de dimensões é uma imagem, e todo sistema que decide se seu produto aparece em uma resposta lê texto, então publique os dois e faça com que batam no milímetro. Como escrever a metade visual para que o comprador aja está em como comunicar as dimensões do produto aos compradores; se você quer o custo do erro em dinheiro, a calculadora de custo de devolução faz essa conta.

Fontes e referências

• schema.org Product — width, height, depth, weight, size, hasMeasurement
• schema.org QuantitativeValue — value, unitCode e unitText
• Google Merchant Center — atributos de dimensão de envio e seus limites
• Google Merchant Center — atributo product detail [product_detail]
• Google Search Central — dados estruturados de Product e propriedades suportadas
• Agentic Commerce — especificação do feed de produtos