O schema Product descreve o produto como entidade: nome, descrição, marca, imagem e nota média. O schema Offer, aninhado dentro dele, descreve os termos da venda: preço, moeda e disponibilidade. Juntos, os dois blocos dão à IA os atributos que ela precisa para comparar o seu produto com o de um concorrente e decidir se recomenda ou não numa resposta.
Sem esse par, a IA ainda pode citar o produto a partir do texto solto da página, mas sem a certeza estrutural de preço, disponibilidade e identidade que os dados estruturados oferecem. Cada campo carrega um propósito específico, e a diferença entre Product e Offer é o primeiro ponto que costuma confundir quem implementa essa marcação pela primeira vez.
Qual a diferença entre Product e Offer no schema?
Product descreve o produto como entidade fixa: o que ele é, independente de quem vende ou por quanto. Offer descreve a transação: quem vende, por qual preço e se há unidades disponíveis agora. A separação existe porque um mesmo produto pode ter mais de uma oferta, de lojas ou condições diferentes, enquanto a identidade do produto permanece a mesma.
No JSON-LD essa relação aparece como aninhamento: o bloco Offer vive dentro da propriedade offers do bloco Product. A especificação do schema.org define offers como o tipo Offer ou AggregateOffer, esse segundo usado quando existem várias variações ou vendedores para o mesmo produto. Para a página de um produto único, que é o foco deste tutorial, um Offer aninhado já cobre o que a IA precisa.
Pense assim: se alguém pergunta à IA "qual o preço da cadeira X", a resposta vem do Offer. Se pergunta "o que é a cadeira X", a resposta vem do Product. Perguntas de comparação misturam os dois: "qual cadeira ergonômica mais barata com boa avaliação" puxa nome e marca do Product, preço do Offer e nota do aggregateRating ao mesmo tempo. Para entender como esse cruzamento acontece entre marcas diferentes, veja como a IA compara produtos antes de recomendar. Quanto mais completos os dois blocos, maior a chance de o produto entrar nessa resposta, o que se reflete direto na taxa de citação da página.
Como marcar um produto com schema Product?
O bloco Product tem um punhado de campos que fazem o trabalho pesado. A tabela resume os principais, na ordem que costuma aparecer numa implementação:
| Campo | O que informa | Exemplo |
|---|---|---|
name | Nome exato do produto, igual ao que aparece na página | "Cadeira Ergonômica Alfa 200" |
description | O que o produto é e resolve, sem linguagem de propaganda | "Cadeira de escritório com apoio lombar ajustável e base giratória" |
brand | Marca ou fabricante, como bloco Organization ou Brand | {"@type": "Brand", "name": "Alfa Móveis"} |
image | URL da foto real do produto, de preferência mais de uma | "https://loja.com.br/img/cadeira-alfa-200.jpg" |
aggregateRating | Nota média agregada, com ratingValue e reviewCount | {"ratingValue": "4.6", "reviewCount": "132"} |
name e description parecem óbvios, mas o erro comum é copiar a title tag inteira da página, com marca e categoria emendadas, em vez de usar o nome limpo do produto. brand conecta o produto à entidade da empresa, o mesmo princípio explicado em Schema Organization passo a passo: se a marca já tem um bloco Organization consolidado no site, use o mesmo nome aqui.
aggregateRating é o campo que mais gera dúvida. A especificação pede pelo menos ratingValue (a nota) e reviewCount ou ratingCount (quantas avaliações sustentam essa nota). Declarar uma nota sem o número de avaliações por trás é um sinal fraco: a IA não tem como saber se 4,6 vem de três avaliações ou de trezentas.
Preciso marcar preço e disponibilidade para a IA citar meu produto?
Precisa, se o objetivo é aparecer em respostas que envolvem preço ou comparação de custo. Sem o bloco Offer, o produto ainda pode ser citado pela descrição, mas fica fora de qualquer resposta que peça quanto custa ou onde comprar mais barato. Isso importa cada vez mais: 53% dos compradores online brasileiros usaram IA na decisão de compra mais recente (PYMNTS/Visa, Global Digital Shopping Index 2026, jun/2026). Comparação de preço é exatamente o tipo de pergunta que depende do Offer.
O Offer aninha três campos centrais dentro do Product:
price: o valor numérico da oferta, sem o símbolo da moeda.priceCurrency: o código de três letras da moeda, no padrão ISO 4217. Para o mercado brasileiro, o valor éBRL. O Google Search Central trata esse formato como recomendado para snippets de produto.availability: o status do estoque, escolhido entre os valores fechados do tipo ItemAvailability do schema.org, comohttps://schema.org/InStock,https://schema.org/OutOfStock,https://schema.org/PreOrderouhttps://schema.org/LimitedAvailability.
availability não aceita texto livre como "em estoque" ou "disponível": precisa ser exatamente uma dessas URLs. É um detalhe pequeno que quebra a leitura do bloco inteiro quando sai errado, porque validadores tratam um valor fora da lista como campo inválido, não como aviso.
sku, gtin e avaliação: os identificadores que reforçam a confiança
Depois dos campos centrais, dois identificadores aumentam a precisão com que a IA reconhece o produto entre fontes diferentes. sku é o código interno da loja, útil para rastrear o item no seu próprio sistema, mas sem significado fora dele. gtin é o identificador global do produto, o padrão que engloba EAN e UPC; no Brasil, o formato mais comum é o EAN-13, declarado como gtin13 no schema.
O gtin importa mais do que parece para GEO. Quando duas lojas diferentes marcam o mesmo produto físico com o mesmo gtin, a IA tem uma base mais forte para tratá-los como o mesmo item em contextos diferentes, o que ajuda em respostas de comparação de preço entre lojas. Produtos de revenda ou distribuição se beneficiam desse campo mais do que produtos exclusivos de uma marca própria.
A nota do aggregateRating, já citada na marcação do Product, funciona como reforço de confiança quando os números batem com o que existe em outras fontes: avaliações no próprio site, no Google Meu Negócio, em marketplaces. Uma nota alta isolada, sem essas fontes visíveis, pesa menos na decisão do modelo do que uma nota moderada respaldada por avaliações reais.
Os erros mais comuns ao marcar produtos com schema
Três erros aparecem com mais frequência. Os três têm a mesma raiz: o schema descreve algo que a página não confirma.
Preço desatualizado. O price no JSON-LD fica parado na data em que alguém editou o código, enquanto o preço visível na página muda por promoção, reajuste ou integração com o estoque. Quando os dois valores divergem, ferramentas de validação e a própria IA tratam o schema como não confiável, mesmo que o restante do bloco esteja correto.
Disponibilidade fixa. É comum configurar availability como InStock na criação da página e nunca mais tocar no campo. Meses depois o produto esgota, mas o schema segue dizendo que está disponível. O ideal é que esse valor venha do mesmo sistema que controla o estoque, não de uma edição manual isolada.
Marcação que não bate com o conteúdo visível. Duas variações comuns: declarar aggregateRating com nota e contagem que não aparecem em lugar nenhum da página ou usar um brand diferente do que está no cabeçalho do site. As duas criam uma divergência que reduz a confiança no bloco inteiro. O princípio é o mesmo do sameAs na identidade de marca: o schema confirma o que já está na página, não inventa um dado que só existe no código.
Como fica o bloco completo e onde validar?
Um bloco completo de Product com Offer aninhado, para a página de um produto único, fica assim:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Cadeira Ergonômica Alfa 200",
"description": "Cadeira de escritório com apoio lombar ajustável, base giratória e estrutura reforçada para uso de oito horas por dia.",
"image": [
"https://www.suaempresa.com.br/img/cadeira-alfa-200-frente.jpg",
"https://www.suaempresa.com.br/img/cadeira-alfa-200-lateral.jpg"
],
"sku": "ALF-200-PT",
"gtin13": "7891234567895",
"brand": {
"@type": "Brand",
"name": "Alfa Móveis"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "132"
},
"offers": {
"@type": "Offer",
"url": "https://www.suaempresa.com.br/cadeira-alfa-200",
"priceCurrency": "BRL",
"price": "1299.90",
"availability": "https://schema.org/InStock"
}
}
Esse bloco vai dentro de uma tag <script type="application/ld+json">, na página do produto específico, não na home nem numa página de categoria. O artigo sobre como implementar JSON-LD passo a passo cobre a mecânica de inserir esse script no HTML; aqui o ponto é o conteúdo do bloco em si.
Antes de publicar, valide no Schema Markup Validator (validator.schema.org) ou no Rich Results Test do Google (search.google.com/test/rich-results). Os dois apontam erro de sintaxe, tipo de campo errado e propriedade obrigatória ausente. Depois, confirme manualmente que cada valor do JSON aparece de algum jeito na página visível: essa é a checagem que o validador automático não faz.
Marcar um produto é o passo unitário. Quando o catálogo tem dezenas ou centenas de itens, a pergunta muda de quais campos preencher para como manter isso atualizado em escala, o assunto do artigo sobre dados estruturados para ecommerce. Antes de escalar, vale confirmar se o site já resolveu a camada básica: o guia sobre dados estruturados como a vitória mais barata do GEO técnico explica por onde começar. Se ainda resta dúvida sobre qual tipo priorizar depois do Product, o artigo sobre quais tipos de schema usar em GEO ajuda a decidir, e o hub de GEO técnico organiza o conjunto inteiro por ordem de prioridade.
A auditoria de site da Promptis verifica se as páginas de produto têm Product e Offer implementados, se os campos batem com o conteúdo visível e onde faltam identificadores como gtin e aggregateRating. A primeira análise é gratuita e não pede cartão.
