Como marcar preço e estoque da loja virtual para agentes de IA não errarem na compra

Cada vez mais um agente de IA lê a página do produto antes do cliente. Se a marcação de preço, estoque e condição estiver errada ou desatualizada, quem responde pelo erro é a loja, não o algoritmo.

A vitrine agora tem um leitor que não é gente

Até pouco tempo, a página de produto existia para dois públicos: o cliente que navegava e o robô do Google que indexava texto para posicionar no ranking de busca. Hoje existe um terceiro leitor, que não rola a página nem olha a foto: o agente de IA que varre o HTML em busca de dados estruturados, resume o que encontrou e entrega a resposta pronta para quem perguntou "onde compro X mais barato" ou "esse produto tem na minha cor".

A documentação do Google Search Central sobre dados estruturados de produto (developers.google.com/search/docs/appearance/structured-data/product) é a referência técnica por trás disso. Ela descreve o padrão de marcação que faz preço, disponibilidade e avaliação aparecerem direto no resultado de busca, nas imagens do Google e no painel de conhecimento de compras.

A documentação não trata especificamente de agentes de IA ou assistentes conversacionais, mas o raciocínio técnico é o mesmo: o Schema.org Product é um padrão aberto, pensado para ser lido por máquina, e qualquer sistema automatizado que precise responder com dados de produto, seja o Google, seja um agente de IA de terceiros, tende a buscar primeiro esse tipo de marcação antes de tentar interpretar texto solto na página.

O ponto prático para quem administra catálogo: se o dado estruturado está errado, desatualizado ou simplesmente ausente, o agente de IA não vai parar para confirmar. Ele responde com o que encontrou, certo ou errado, e quem carrega a consequência comercial e legal é a loja.

Dois jeitos de marcar, dependendo do que a página vende

A documentação do Google separa a marcação de produto em duas categorias, e a escolha entre elas depende de uma pergunta simples: o cliente consegue comprar direto nessa página?

As duas se sobrepõem bastante: quem preenche as propriedades exigidas pelo merchant listing geralmente já cobre o que o product snippet pede. Por isso o conselho da própria documentação do Google é preencher o máximo de propriedades possível, sem se preocupar em adivinhar qual formato de resultado vai aparecer. Quanto mais completa a marcação, mais formatos de exibição a página fica apta a receber, e isso vale tanto para a busca quanto para um agente conversacional.

As quatro propriedades que decidem se o cliente é bem informado

Na prática, quatro campos da marcação Schema.org Product concentram o risco de erro que chega até o cliente final:

1. price: o valor atual, sem taxa escondida. Precisa bater exatamente com o que aparece no carrinho.
2. availability: no padrão Schema.org, costuma usar valores como InStock, OutOfStock ou PreOrder. Um produto esgotado marcado como InStock é a origem mais comum de reclamação por venda de item indisponível.
3. shippingDetails: custo e prazo de frete, para o cliente (e o agente que responde por ele) enxergar o custo total antes de decidir.
4. hasMerchantReturnPolicy: a política de troca e devolução da loja, declarada de forma estruturada e não só em texto corrido no rodapé do site.

Um exemplo de marcação mínima, no formato JSON-LD que o Google recomenda, mostra como essas propriedades se encaixam:

{
 "@context": "https://schema.org/",
 "@type": "Product",
 "name": "Tênis de corrida modelo X",
 "offers": {
 "@type": "Offer",
 "price": "349.90",
 "priceCurrency": "BRL",
 "availability": "https://schema.org/InStock",
 "hasMerchantReturnPolicy": {
 "@type": "MerchantReturnPolicy",
 "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
 "merchantReturnDays": 7
 }
 }
}

Esse bloco entra no <head> ou no corpo do HTML da página de produto, dentro de uma tag <script type="application/ld+json">. Ele não aparece visualmente para o cliente que navega, mas é exatamente o que um agente de IA lê primeiro, antes de tentar interpretar texto solto na página.

O que acontece quando a marcação e o estoque real andam dessincronizados

A documentação do Google explica que o recurso de "queda de preço" exibido na busca é calculado automaticamente a partir da variação histórica do campo price na marcação. Se a loja atualiza o preço no sistema de gestão mas esquece de atualizar a marcação estruturada da página (ou depende de um feed do Merchant Center desatualizado), o Google pode mostrar um preço antigo, inclusive sinalizando uma queda que não existe de fato.

A documentação do Google confirma esse tipo de combinação para o campo de preço: se o preço não estiver na marcação da página, o Google pode usar o dado do feed do Merchant Center. É razoável supor que uma inconsistência parecida aconteça com disponibilidade sempre que a loja mantém os dois canais (marcação na página e feed) e eles não estão sincronizados: se a página diz InStock e o feed diz esgotado, ou vice-versa, não há garantia de qual fonte vai prevalecer na resposta de quem consulta.

Isso não é um bug do sistema de IA. É um problema de sincronismo entre o catálogo da loja e o que foi publicado.

Para quem administra um e-commerce em rede, com múltiplos centros de distribuição, o risco cresce porque o availability muitas vezes é tratado como campo único por SKU, sem refletir que o item está em falta num centro de distribuição e disponível em outro. Na prática, a marcação estruturada de uma página não costuma ter variação por região dentro da mesma página: ou o time de catálogo resolve isso antes de publicar, ou o agente de IA vai repetir a inconsistência para o cliente.

O Código de Defesa do Consumidor não pergunta quem errou a marcação

Quando o preço ou a disponibilidade informados ao cliente estão errados, não importa se o erro nasceu numa planilha, num feed de dados ou numa marcação estruturada desatualizada. O artigo 30 do Código de Defesa do Consumidor trata toda informação suficientemente precisa veiculada por qualquer meio de comunicação como oferta que obriga o fornecedor. O artigo 35 dá ao cliente três caminhos quando o fornecedor recusa cumprir a oferta: exigir o cumprimento forçado, aceitar outro produto ou serviço equivalente, ou rescindir o contrato com devolução do valor pago e correção monetária, além de eventuais perdas e danos.

Em resumo: se o agente de IA mostrou um preço de R$ 349,90 porque a marcação da página estava desatualizada e o preço real é R$ 429,90, o cliente que tentar finalizar a compra por aquele valor está dentro do seu direito de exigir o cumprimento da oferta, salvo erro grosseiro e evidente, que é uma defesa estreita e difícil de sustentar judicialmente.

O mesmo raciocínio vale para condição do produto. Se a marcação diz que o item é novo e o item entregue é recondicionado, a loja enfrenta pedido de troca ou devolução integral com base no artigo 18 do CDC, que trata de vício do produto, independentemente de a origem do erro ter sido humana ou automatizada.

O que revisar antes da próxima campanha

Antes de rodar a próxima campanha de tráfego pago ou promoção sazonal, vale auditar três pontos da marcação estruturada:

• Se o campo price da marcação bate, em tempo real, com o preço mostrado no carrinho, não só no momento da publicação da página.
• Se o campo availability reflete o estoque real por canal de venda, e não um valor fixo herdado de um cadastro antigo.
• Se a política de devolução declarada em hasMerchantReturnPolicy é a mesma que o time de atendimento aplica de fato quando o cliente liga reclamando.

O número a acompanhar depois dessa auditoria não é o tráfego vindo da busca, que tende a subir com marcação mais completa. É a taxa de reclamação por "preço diferente do anunciado" e por "produto recebido diferente do descrito" no SAC ou no Reclame Aqui, comparando o período antes e depois do ajuste. Se essa taxa não cair, o problema não está na marcação, está na distância entre o que o sistema de catálogo sabe e o que a página realmente publica.

Fonte: Documentação do Google Search Central sobre dados estruturados de Produto