Schema.org Product e Offer viram o contrato técnico que agentes de IA de compras exigem da loja

O que muda quando quem lê a vitrine é um agente de IA

Por anos, marcar um produto no vocabulário da Schema.org foi tarefa de SEO: um jeito de avisar o Google que aquele texto era preço, aquele outro era estoque, para ganhar selo de "em estoque" ou estrelas de avaliação no resultado de busca. A página oficial do tipo Product, mantida pela organização Schema.org, registra hoje mais de 10 milhões de domínios usando essa marcação, segundo levantamento do próprio Google de agosto de 2026. O vocabulário não mudou. Quem lê, sim.

Um agente de compras baseado em IA (um assistente que navega entre lojas, compara preço e condição, e em alguns casos pode fechar a compra em nome do cliente) não lê a vitrine como um humano. Ele não confia num "só restam 2 unidades!" escrito em vermelho no HTML se esse dado não estiver também declarado num formato que o código entenda sem ambiguidade. É aí que entram dois tipos da Schema.org: Product, que descreve o que é vendido, e Offer, que descreve em que condição aquilo é vendido (preço, moeda, disponibilidade, validade).

Como um robô de compras separa HTML bonito de dado confiável

A forma mais comum de publicar essa marcação é o JSON-LD, um bloco de código colocado na página ao lado do HTML normal, sem alterar o visual que o cliente vê. Esse bloco repete, em formato de dado estruturado, a mesma informação que já aparece na tela: nome do produto, marca, preço, condição. A diferença é que esse formato não depende de o agente "entender" o design da página: ele lê chave e valor.

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Tênis Runner Pro 2026",
  "brand": "NomeDaMarca",
  "sku": "TRP-2026-42",
  "gtin13": "7891234567895",
  "itemCondition": "https://schema.org/NewCondition",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "BRL",
    "price": "399.90",
    "availability": "https://schema.org/InStock",
    "url": "https://loja.exemplo.com/tenis-runner-pro"
  }
}

O vocabulário mínimo que a loja precisa publicar

A documentação do tipo Product lista dezenas de propriedades, de color a recycledContentPercentage, mas só um núcleo pequeno sustenta a decisão de um agente de compras.

Quando mais de um vendedor oferece o mesmo item, como num marketplace, entra o tipo AggregateOffer, que resume lowPrice, highPrice e o número de ofertas disponíveis. É esse resumo que permite a um agente dizer "este produto está mais barato em outra loja" sem visitar cada página uma a uma.

Onde a marcação técnica encontra o Código de Defesa do Consumidor

Declarar itemCondition errado (chamar de novo um produto recondicionado) não é só erro de dado para um agente de IA: é publicidade enganosa pelo Código de Defesa do Consumidor, no artigo 37. Se um agente de compra recomenda aquele item confiando na marcação, o erro se espalha antes de qualquer humano conferir a embalagem.

hasMerchantReturnPolicy carrega a mesma lógica. A lei garante 7 dias de arrependimento para compra feita fora da loja física, previsto no artigo 49 do CDC, e esse prazo pode ser declarado na própria marcação, no campo merchantReturnDays. Uma loja que preenche esse campo corretamente entrega a um agente de IA (e a qualquer comparador de preço) uma informação que hoje costuma ficar escondida num link de rodapé.

O que quebra quando a marcação está incompleta

Sem offers preenchido, ou com price desatualizado em relação ao valor real da página, um agente de comparação pode simplesmente descartar a oferta, listar o concorrente, ou recomendar o produto por um preço que não existe mais. Isso gera reclamação, devolução indevida e desgaste com o cliente. Marcação desatualizada é pior do que ausência de marcação, porque o agente trata o dado estruturado como fonte de verdade, não como sugestão a ser conferida.

Isso também marca um limite de prioridade. Nem toda loja precisa correr para implementar hasDigitalProductPassport ou hasEnergyConsumptionDetails, propriedades mais recentes do vocabulário, voltadas a rastreabilidade e eficiência energética, relevantes sobretudo para eletroeletrônicos sob regulação específica. Para o pequeno e médio e-commerce, o ganho imediato está no núcleo: name, sku ou gtin, offers com price, priceCurrency e availability sempre atualizados, e itemCondition sempre que a loja vende usado, seminovo ou recondicionado ao lado do novo.

O que testar na próxima atualização do feed de produtos

Antes de prometer qualquer ganho de recomendação por IA, o time de e-commerce pode auditar o que já está publicado:

1. Rodar um validador de schema (como o Rich Results Test) em cinco páginas de produto escolhidas ao acaso e conferir se offers tem price e availability preenchidos.
2. Conferir se o price do JSON-LD bate com o preço exibido na tela no mesmo instante, já que promoções com contagem regressiva costumam dessincronizar os dois.
3. Em itens recondicionados ou com avaria, confirmar que itemCondition reflete a condição real, e não o valor padrão herdado do template da loja.
4. Declarar hasMerchantReturnPolicy com o prazo real de troca, nunca um texto genérico copiado de outro template.

O número a acompanhar depois disso é a origem do tráfego e da conversão vindos de buscadores e assistentes de IA, comparando o período antes e depois da correção dos campos offers e itemCondition no feed. Sem esse acompanhamento, corrigir a marcação vira tarefa de TI sem retorno visível mostrado ao negócio.

Fonte: Schema.org — Vocabulário oficial (Product, Offer, AggregateOffer)