Ficha de produto sem dados estruturados fica de fora das respostas de compra com IA do Google

A vitrine da loja agora também é lida por um algoritmo de compra

Quando alguém pergunta ao Google algo como "tênis de corrida até 300 reais com boa avaliação", a resposta que aparece na tela não vem de um redator do Google. Vem da ficha de produto da própria loja, desde que ela esteja marcada do jeito certo. É isso que a documentação Product structured data, do Google Search Central (atualizada em 10 de dezembro de 2025), detalha: como o preço, a disponibilidade, a nota de avaliação e outros dados do produto chegam até os resultados de busca, incluindo as respostas de compra que o Google monta automaticamente.

A peça técnica por trás disso chama schema.org Product: um vocabulário padronizado que qualquer site pode usar para dizer que aquilo é um produto, custa tanto, tem tantas unidades em estoque e foi avaliado assim. Sem esse código, o Google até pode indexar a página, mas trata o texto como texto solto, sem separar preço de descrição nem disponibilidade de nome do produto. Sem essa separação, a ficha não entra nas experiências de compra mais ricas da busca, só aparece como link azul comum.

Onde a ficha aparece quando os dados estão certos

A documentação lista quatro formatos de resultado que dependem diretamente da marcação de produto:

• Product snippet: resultado de texto com nota, avaliação, preço e disponibilidade embutidos
• Popular products: apresentação visualmente rica dos produtos à venda
• Shopping knowledge panel: painel com informação detalhada e lista de vendedores do mesmo item
• Google Images: imagens de produto anotadas com dados de compra

O Google é direto ao dizer que essa lista não é fechada: a busca está sempre testando novos formatos. Quanto mais propriedades a ficha tiver preenchidas, mais chance ela tem de ser puxada por qualquer um desses formatos, inclusive os que ainda vão aparecer.

Dois tipos de marcação, dependendo de quem vende o quê

A documentação separa a marcação de produto em duas famílias, e a diferença importa para quem decide o que implementar primeiro.

Quem implementa os campos obrigatórios de merchant listing já fica elegível também para os product snippets, porque há sobreposição entre as duas. Na prática, para o time de e-commerce isso significa priorizar a marcação completa da página de produto da própria loja, não só a de blogs de conteúdo.

O que a ficha precisa ter, campo por campo

O vocabulário Product do schema.org pede um conjunto mínimo de propriedades para que o Google reconheça o item como produto de verdade. Numa ficha de e-commerce, isso normalmente aparece como um bloco JSON-LD como este, simplificado:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Tênis de corrida XYZ",
  "sku": "TXR-4521",
  "image": "https://loja.com.br/imagens/tenis-xyz.jpg",
  "offers": {
    "@type": "Offer",
    "price": "289.90",
    "priceCurrency": "BRL",
    "availability": "https://schema.org/InStock",
    "url": "https://loja.com.br/produto/tenis-xyz"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "812"
  }
}

Repare no que está ali: sku identifica o item de forma única no sistema da loja, price e priceCurrency dão o valor exato, availability diz se tem estoque, e aggregateRating resume as avaliações em nota e quantidade. Cada um desses campos é o que a documentação cita nominalmente como gatilho de enriquecimento: preço, disponibilidade, nota de avaliação, informação de frete, política de devolução.

Preço errado na ficha não é só erro de SEO, é risco de reclamação do consumidor

Aqui está o ponto que o time de e-commerce costuma subestimar. Quando o Google usa a ficha marcada para responder quanto custa direto na busca, essa informação sai do controle visual da loja e vira, para o consumidor, a referência de preço que ele recebeu antes de clicar. Se o campo price do schema diz R$ 289,90 e o carrinho cobra R$ 329,90, a divergência vira motivo de reclamação e de desconfiança, independentemente de qualquer processo judicial que o caso venha a gerar.

Isso muda a rotina de quem mantém o schema. Não basta gerar o JSON-LD uma vez na publicação do produto: price e availability precisam acompanhar o sistema de preço e estoque em tempo real, porque uma ficha desatualizada que o Google ainda está servindo numa resposta de compra é reclamação formal esperando para acontecer, não só uma métrica de clique perdido.

Avaliações com nome de cliente pedem atenção à privacidade

Quando a loja publica avaliações de produto com nome completo visível, seja em marcação estruturada ou na própria página, vale considerar a base legal para isso sob a LGPD, normalmente o consentimento dado no momento em que o cliente deixou a avaliação, com opção clara de aparecer anônimo. Anonimizar com iniciais, como em "Maria S.", resolve a maior parte dos casos sem perder o efeito de prova social que a nota traz para a busca.

Dados estruturados sozinhos não garantem nada: o feed do Merchant Center entra junto

A documentação do Google é explícita num ponto que costuma passar batido: estruturar os dados na página não é a única porta, e às vezes nem a mais confiável sozinha. O Google também aceita, e recomenda combinar com, um feed de dados enviado via Google Merchant Center. Quando as duas fontes existem, o Google usa uma para confirmar a outra e, em alguns casos, completa o que falta: um product snippet pode usar o preço do feed do Merchant Center se a página não tiver esse dado na marcação.

Para quem decide onde investir a hora de desenvolvimento primeiro, a lição prática é direta: ter só uma das duas fontes reduz a elegibilidade da loja para parte dos formatos de busca enriquecida que o Google oferece. As duas coisas resolvem problemas diferentes, e maximizar a elegibilidade pede as duas, como a própria documentação do Google recomenda.

O que testar na próxima campanha

Antes de qualquer campanha que dependa de tráfego de busca, vale rodar três checagens concretas:

1. Validar a página de produto em uma ferramenta de teste de dados estruturados, conferindo se price, availability, sku e aggregateRating aparecem sem erro de marcação
2. Acompanhar no Search Console se a página de produto está sendo reconhecida como elegível para os aprimoramentos de produto, revisando periodicamente os status reportados
3. Comparar, num período de 30 dias antes e depois da correção do schema, as impressões de busca da página de produto, para entender se a correção se traduziu em mais visibilidade

Esse terceiro número é o que mostra se a correção virou tráfego de verdade, e não só passou no validador.

Fonte: Google Search Central — Product structured data