Structured data, feeds e o catálogo machine-readable

Pergunte ao ChatGPT por “melhor cafeteira italiana até 300 reais” e observe o que ele cita. Em três de cada quatro respostas, a página citada carrega structured data — 71% delas, para ser exato, e 65% quando a vitrine é o Google AI Mode. Não é coincidência. A IA não lê a sua página do jeito que um humano lê; ela extrai. E só extrai com confiança o que está marcado de forma inequívoca. O catálogo que parece bonito para o olho humano, mas é opaco para a máquina, simplesmente não entra na resposta.

A tese aqui contraria o instinto de muita equipe de e-commerce: structured data parou de ser tarefa de SEO técnico e virou infraestrutura de distribuição. O catálogo não serve mais apenas à página de produto. Ele é a fonte de verdade que abastece, ao mesmo tempo, o resultado de busca, a resposta da IA, o comparador de preço e o agente que compra em nome do usuário. Tratar isso como um campo de schema esquecido no rodapé do template é abrir mão de receita que está migrando, neste momento, para quem trata o catálogo como API.

O que precisa estar no JSON-LD de um produto, de verdade?

O conjunto mínimo que torna a oferta legível e citável. JSON-LD é o formato preferido porque vive separado da marcação visual, é fácil de parsear e não quebra quando o designer mexe no layout. Mas formato sem conteúdo completo não resolve nada.

O Product carrega nome, marca, descrição e — crítico — o GTIN, o identificador universal que permite cruzar a sua oferta com avaliações e comparadores. O Offer aninhado traz preço, moeda e, sobretudo, a disponibilidade. O AggregateRating informa a média e o volume de avaliações, sinal forte para a IA decidir o que recomendar. O FAQPage na própria página de produto responde perguntas que a IA tende a fazer. E o ImageObject descreve a mídia de forma que a máquina saiba o que está vendo.

Tipo de schema	O que carrega	Por que a IA precisa
Product	Nome, marca, descrição, GTIN	Identificar o item sem ambiguidade
Offer	Preço, moeda, disponibilidade	Responder “quanto custa” e “tem em estoque”
AggregateRating	Nota média, volume de reviews	Ranquear recomendação por confiança social
FAQPage	Perguntas e respostas do produto	Alimentar respostas diretas sem inferir
ImageObject	URL, dimensões, descrição da mídia	Exibir a imagem certa em vitrines visuais

Por que preço e disponibilidade precisam ser em tempo real?

Porque dado de oferta desatualizado destrói confiança — e a IA pune a desconfiança com ausência. Se o JSON-LD diz “em estoque, R$ 289” e o usuário chega na página e encontra “esgotado, R$ 349”, o estrago é duplo: frustra a pessoa e ensina o mecanismo a desconfiar da sua marca dali em diante.

Preço e disponibilidade são os dois atributos com a menor tolerância a atraso de todo o catálogo. Um título de produto pode ficar uma semana defasado sem grande dano. Um preço errado no schema é uma promessa quebrada na frente de quem comprou a sua recomendação.

O mecanismo correto é puxar preço e estoque da mesma fonte que serve o checkout, não de um cache regenerado uma vez por dia. Isso significa que o JSON-LD precisa ser gerado dinâmica e frequentemente, com a oferta saindo do mesmo backend que conhece o estoque real. Passaportes Digitais de Produto (DPP), que avançam como exigência regulatória e como padrão de transparência, empurram na mesma direção: a expectativa é que o dado da oferta seja vivo e auditável, não uma foto antiga.

Como taxonomia e facetas ajudam um agente a comparar?

Dando à máquina uma estrutura estável para raciocinar. Quando um agente de compra avalia “notebook leve para viagem com boa bateria”, ele precisa filtrar por peso e autonomia. Se a sua taxonomia chama isso de “portabilidade” numa categoria e “mobilidade” em outra, e se o atributo de bateria às vezes é “autonomia” e às vezes “duração”, o agente não consegue comparar de forma confiável. Inconsistência de taxonomia é ruído que empurra a IA para o concorrente mais organizado.

Facetas bem definidas são, ao mesmo tempo, o filtro da busca interna e o atributo que vai para o feed e para o schema. Essa é a economia da base de oferta única: o mesmo trabalho de padronizar taxonomia rende em busca, em SEO, em feed e em GEO simultaneamente. Padronizar uma vez, na origem, custa muito menos do que remendar em cada canal — e é a única forma de manter coerência quando o catálogo cresce.

Onde o Merchant Center e os feeds entram nessa arquitetura?

São a ponte entre a sua base de oferta e os destinos que não leem o seu site diretamente. O Merchant Center é implacável: atributo faltante, GTIN errado ou preço divergente derrubam o item, e o produto rejeitado some do Shopping, dos anúncios e, cada vez mais, das superfícies de IA que se apoiam nesse dado. Plataformas de gestão de feed como Feedonomics existem justamente para traduzir o catálogo da origem em algo que cada destino aceite sem rejeição, corrigindo formatos e mapeando atributos.

O ponto que poucas equipes internalizam: o feed limpo e o JSON-LD da página são manifestações do mesmo dado de origem. Não são dois projetos. Quando a base de oferta — governada por PIM, com mídia em DAM e dados-mestre em MDM — está correta, o feed sai limpo e o schema sai completo pela mesma razão. Quando ela está furada, os dois falham juntos, e você corre atrás dos sintomas em vez da causa.

O que é uma Machine-Readable Commerce Layer e por que ela protege a marca?

É expor o catálogo como API consultável, não apenas como página renderizada. A página HTML, mesmo com JSON-LD impecável, ainda exige que a máquina visite e extraia. Uma camada de comércio legível por máquina vai além: oferece um endpoint estruturado onde o agente consulta produto, preço, estoque, política de troca e atributos diretamente, com a mesma fidelidade que o seu app teria.

O ganho mais subestimado dessa camada é defensivo. Quando a IA tem que inferir um atributo que você não forneceu, ela alucina — preenche a lacuna com o palpite mais provável, que pode ser o errado. “Esse tênis é à prova d’água?” Se o dado não está explícito, a IA chuta, e o chute vira a sua promessa na cabeça do consumidor. Fornecer o atributo de forma estruturada e verificável remove a lacuna que convida à invenção. Política de troca, prazo de entrega, composição, compatibilidade — tudo que a IA precisaria adivinhar deve estar legível por máquina, no schema e, idealmente, na API.

Brand safety, na era dos agentes, deixou de ser sobre onde o seu anúncio aparece e passou a ser sobre o que a IA afirma do seu produto. A única forma de controlar essa narrativa é não deixar lacuna para ela preencher.

A decisão e o próximo passo

A decisão executiva é parar de tratar structured data como um item da lista técnica de SEO e começar a tratá-lo como o canal de distribuição que ele virou. O catálogo machine-readable é, hoje, tão estratégico quanto a vitrine que o cliente vê — porque metade da descoberta acontece em superfícies que o cliente nunca enxerga renderizadas.

O próximo passo cabe num sprint. Escolha os seus 50 produtos de maior receita. Audite o JSON-LD de cada um contra a tabela deste guia: Product com GTIN, Offer com preço e disponibilidade vivos, AggregateRating, FAQPage, ImageObject. Cruze com o status desses itens no Merchant Center e com o que o ChatGPT e o Google AI Mode respondem quando perguntados pelo produto. Onde a IA inventar ou ignorar, você terá encontrado exatamente a lacuna de dado que está custando a citação — e o roteiro de correção, atributo por atributo, já estará escrito.