Dados estruturados para e-commerce: schema de produto

Para que uma IA como o ChatGPT, o Gemini ou o Perplexity cite um produto com nome, preço, disponibilidade e avaliação de forma precisa, a página precisa combinar três tipos do schema.org: Product, Offer e AggregateRating. Esse tripé é o mínimo técnico de um e-commerce que quer aparecer em respostas geradas por IA, seja numa recomendação direta ("qual tênis de corrida você indica?") ou numa comparação entre marcas concorrentes. Sem os três tipos presentes e corretos, a IA ou ignora o produto ou o cita com dados incompletos.

Os três tipos funcionam em conjunto: Product descreve o que o item é (nome, marca, imagem, descrição), Offer descreve as condições comerciais (preço, moeda, disponibilidade) e AggregateRating entrega a prova social (nota média, número de avaliações). Uma página com Product mas sem Offer dá à IA o nome do produto, mas não o preço. Uma página sem AggregateRating perde o detalhe "avaliado com 4,8 por 312 compradores" que costuma definir qual produto a IA cita entre dois concorrentes com especificações parecidas. Entenda o papel dos dados estruturados como a linguagem que a IA usa para construir uma entidade clara para cada produto no seu site.

O que compõe o schema de produto?

O tipo Product no schema.org representa um item à venda. No contexto de GEO (Generative Engine Optimization, a disciplina de otimização para IAs generativas), os campos mais relevantes são os que permitem à IA construir uma representação precisa: saber que "Tênis Runner Pro" é fabricado pela marca X, tem imagem associada, um código SKU específico e uma descrição que o diferencia de outros produtos parecidos no catálogo.

Os campos essenciais do Product são:

• name: o nome exato do produto como aparece na loja.
• description: um parágrafo descritivo funcional do que o produto faz, não a tagline de marketing.
• image: URL da imagem principal, de preferência com resolução alta.
• sku: o código interno do produto, útil para eliminar ambiguidade em catálogos grandes.
• brand: o fabricante ou marca, estruturado como @type: Brand com um campo name dentro.

A tabela abaixo reúne os campos centrais dos três tipos e o papel de cada um para a citação por IA:

O campo availability usa URIs do schema.org: https://schema.org/InStock para produto disponível, https://schema.org/OutOfStock para esgotado. Strings como "disponível" ou "em estoque" não são reconhecidas corretamente pelos parsers das IAs nem pelo Google. O mesmo vale para priceCurrency: use a sigla ISO 4217 (BRL para real brasileiro), não o símbolo R$.

Para um panorama de quais outros tipos de schema priorizar no seu site além do Product, consulte quais tipos de schema usar para GEO. Para a estratégia mais ampla de visibilidade em IAs no contexto de e-commerce, veja GEO para e-commerce.

Por que preço desatualizado é pior do que não ter schema?

O campo price dentro do Offer precisa refletir o preço real no momento da visita. Se a sua loja tem uma promoção que começa na segunda-feira e o schema continua com o preço cheio até a sexta, a IA pode citar "a partir de R$ 89,90" enquanto a página já mostra R$ 149,90.

Para o cliente que chegou pela recomendação da IA, isso é uma quebra de confiança antes da primeira interação com a sua marca. E do ponto de vista técnico, o Google cruza os dados do schema com o conteúdo visível da página. Inconsistências são marcadas como informação não confiável, o que reduz a credibilidade do schema inteiro, inclusive os campos que estão corretos.

A solução certa é gerar o campo price dinamicamente pelo sistema de e-commerce, não escrever o valor à mão no template. Plataformas como VTEX, Nuvemshop e WooCommerce têm plugins e configurações nativas que sincronizam preço e disponibilidade automaticamente. Se a plataforma não suporta essa sincronização para determinados produtos, como itens com preço negociado caso a caso, deixe o schema fora dessas páginas. Preço ausente no schema é neutro; preço errado é ativo negativo para a percepção da sua marca pelas IAs.

O campo priceValidUntil pode complementar a configuração sinalizando a data de encerramento de um preço promocional, mas não substitui a atualização dinâmica do campo price. Trate-o como recurso adicional para promoções com data certa de término.

Um detalhe técnico que passa despercebido: o valor de price no JSON-LD deve ser uma string numérica com ponto como separador decimal ("249.90"), independente do padrão local brasileiro com vírgula. Parsers que seguem a especificação JSON-LD não aceitam "249,90" como número válido.

Como incluir o AggregateRating sem fabricar dados

O AggregateRating é o campo que mais gera dúvidas, e com razão. Colocar nota 5,0 com mil avaliações quando você tem 12 avaliações reais com média 3,8 é fraude técnica. Os parsers do Google cruzam o schema com os dados visíveis na página, e inconsistências resultam em remoção dos rich results.

A regra é direta: use os dados reais das avaliações que você já tem. Se você tem 47 avaliações com média 4,3, esses são os números que entram no schema. Se não tem nenhuma avaliação ainda, simplesmente não inclua o bloco AggregateRating no JSON-LD. A ausência do bloco não prejudica os outros campos do schema. O bloco com dados fabricados compromete o schema inteiro.

Os campos do AggregateRating são:

• ratingValue: a nota média em número decimal com ponto (ex.: "4.3").
• reviewCount: o número total de avaliações em número inteiro (ex.: "47").
• bestRating e worstRating: a escala utilizada (normalmente "5" e "1"). São opcionais na spec do schema.org, mas recomendados para eliminar ambiguidade quando a escala não é a padrão de 5 pontos.

A maioria das plataformas de e-commerce gera esses números automaticamente a partir do sistema de avaliações nativo. Verifique nas configurações do plugin de schema se o AggregateRating está conectado à base de avaliações real, não a um valor fixo no template HTML. Um número de avaliações real e baixo (como 12 avaliações com 4,1) é mais confiável para as IAs do que um número inflado sem correspondência na página.

Exemplo completo: Product + Offer + AggregateRating

O bloco abaixo mostra o JSON-LD completo para um produto hipotético. Salve-o dentro de uma tag <script type="application/ld+json"> no <head> da página do produto, de preferência no HTML gerado pelo servidor, não via JavaScript assíncrono:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Tênis Runner Pro Masculino",
  "description": "Tênis de corrida com solado de borracha e cabedal em mesh respirável. Indicado para treinos em asfalto e pista.",
  "image": "https://www.exemplo.com.br/imagens/tenis-runner-pro.jpg",
  "sku": "TRP-M-42-AZL",
  "brand": {
    "@type": "Brand",
    "name": "Runner Pro"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.exemplo.com.br/tenis-runner-pro-masculino",
    "priceCurrency": "BRL",
    "price": "249.90",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.3",
    "reviewCount": "47",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Três pontos do exemplo merecem atenção. O campo url dentro do Offer aponta para a URL canônica da página do produto: isso ajuda quando o mesmo produto aparece em várias categorias e o Google precisa saber qual URL representa o produto de forma definitiva. O itemCondition com NewCondition sinaliza produto novo, diferenciando a sua loja de revendedores de segunda mão ou marketplaces mistos. E price como string com ponto decimal é um requisito da spec JSON-LD, não uma preferência: o validador rejeita formato com vírgula.

Para o passo a passo de como inserir esse bloco no código do site e conectá-lo ao CMS ou à plataforma de e-commerce, veja como implementar JSON-LD passo a passo.

Como escalar o schema para um catálogo grande?

Com centenas de produtos, escrever JSON-LD à mão é inviável. A abordagem correta é gerar o bloco dinamicamente a partir dos dados do produto no banco de dados da loja, tratando o JSON-LD como mais uma saída do sistema de renderização, ao lado do HTML e das imagens.

As principais plataformas usadas no Brasil têm suporte para isso:

• WooCommerce (WordPress): plugins como Yoast SEO e Rank Math geram o JSON-LD a partir dos campos nativos de produto, incluindo preço e avaliações em tempo real.
• VTEX: tem suporte nativo a structured data; verifique se o AggregateRating está ativado nas configurações da vitrine, pois costuma vir desativado por padrão.
• Nuvemshop: a maioria dos temas gera o Product automaticamente; confirme se o Offer inclui availability e price dinâmico, não um valor fixo.
• Shopify: usa JSON-LD via Liquid templates; a maioria dos temas pagos inclui por padrão, mas vale confirmar com o Rich Results Test após qualquer atualização de tema.

Para lojas com desenvolvimento próprio, crie um template de JSON-LD que recebe os dados do produto como variáveis (nome, preço, SKU, avaliações) e renderiza o bloco no <head> de cada página individualmente. Não compartilhe um mesmo schema entre várias páginas de produto, mesmo que os produtos sejam similares.

A taxa de citação de uma loja nas IAs cresce quando o schema cobre uma parte expressiva do catálogo, não apenas os produtos em destaque. Uma IA que processa 500 páginas com schema correto tem muito mais material para citar com precisão do que uma que lê 20 páginas bem otimizadas num catálogo de 2.000. O efeito de escala é real, especialmente para produtos de nicho onde a IA pode ser a principal fonte de descoberta antes de o cliente buscar diretamente no Google.

Para o contexto estratégico de como o schema de produto se encaixa numa estratégia maior de GEO, leia dados estruturados: a vitória mais barata do GEO e explore o hub de conteúdo do GEO técnico.

Como testar se o schema está funcionando?

A ferramenta oficial é o Rich Results Test do Google. Cole a URL da página do produto ou o HTML diretamente, e a ferramenta mostra se o schema foi detectado, quais campos estão presentes, erros de validação (como price ausente ou em formato incorreto) e avisos sobre campos recomendados que não foram encontrados.

O erro mais comum em schemas de produto é a ausência do campo price dentro do Offer. A ferramenta exibe "Item precisa de um campo 'price'" e o rich result não é ativado. Outros erros frequentes: availability como string livre ("disponível") em vez da URI completa, e price com vírgula como separador decimal em vez de ponto.

Para uma validação mais técnica, o Schema Markup Validator da própria schema.org é complementar ao Rich Results Test: valida a estrutura contra a especificação do schema.org sem o filtro adicional dos requisitos do Google. Use os dois em conjunto. O Rich Results Test diz se o Google vai reconhecer e exibir rich results; o Schema Markup Validator diz se a estrutura está correta segundo o padrão, o que também é o que as IAs consomem diretamente.

Revalide periodicamente, especialmente após atualizações de plataforma, mudanças de tema ou migrações de sistema. Não é raro um update de plugin desfazer configurações de schema sem nenhum aviso. Uma auditoria semestral no Rich Results Test é suficiente para manter o schema saudável na maioria dos catálogos.

A auditoria de site da Promptis verifica se o schema de produto das suas páginas está válido, completo e legível para as IAs. Você vê campo a campo o que está correto e o que precisa corrigir antes de uma IA citar, ou deixar de citar, os seus produtos. A primeira análise é gratuita, sem cartão.