Google Merchant Center: como configurar o feed e diagnosticar rejeições

A escolha do método de feed do Google Merchant Center se resolve com uma pergunta: quantas vezes por dia seu preço e seu estoque mudam. Essa frequência decide o resto do setup, e ignorá-la é a origem da maioria das rejeições que travam o catálogo.

Antes de comparar métodos, uma ressalva que economiza semanas de retrabalho: feed nenhum conserta dado ruim na origem. O feed é um espelho do seu banco de produtos. Se o preço na página está errado, se falta GTIN no cadastro, se a disponibilidade não reflete o estoque real, nenhum método de envio resolve. Escolher a integração mais sofisticada com uma base de produtos suja só faz o Google reprovar mais rápido. Arrume a origem primeiro, depois decida o transporte.

Feito esse aviso, existem três formas de levar seus produtos para o Merchant Center. Cada uma vence em um contexto específico de frequência de mudança.

Opção A: planilha com busca agendada

O que é: um feed manual via Google Sheets ou um arquivo hospedado em formato XML ou texto que o Merchant Center busca em horário fixo, o chamado fetch agendado, por padrão uma vez ao dia.

Quando vence: catálogo pequeno, até algumas centenas de SKUs, com preço e estoque estáveis, e sem integração de plataforma disponível. Custo de ferramenta zero, custo de manutenção manual alto.

O problema aparece na frequência. Se o preço de um produto muda três vezes ao dia e o fetch roda uma vez, o anúncio exibe o valor antigo por horas. Preço divergente entre feed e página é um dos motivos de reprovação mais comuns, e a planilha com busca diária o produz por construção. A especificação de dados do produto do Google define os atributos obrigatórios (id, title, price, availability, link, image_link), mas não muda a cadência: quem atualiza no intervalo do fetch é você.

Opção B: integração nativa ou Content API

O que é: a plataforma de loja, como Shopify, VTEX ou WooCommerce com aplicativo oficial, empurra os produtos direto para o Merchant Center, ou você usa a Content API for Shopping para sincronização perto do tempo real.

Quando vence: preço e estoque mudam várias vezes ao dia, você roda promoções relâmpago, ou o catálogo passa de mil SKUs. Custo de desenvolvimento ou de aplicativo pago, compensado pela eliminação da divergência de preço.

A vantagem é mecânica, não de conveniência. Quando preço e disponibilidade sincronizam quase em tempo real, as duas rejeições que mais derrubam e-commerce desaparecem: "preço não corresponde ao valor no site" e "disponibilidade divergente". Você para de brigar com o sintoma porque removeu a causa, que era o atraso entre a mudança na loja e a atualização no feed.

Opção C: feed principal mais feed suplementar

O que é: um feed principal com os dados base e um feed suplementar que sobrescreve ou completa atributos específicos por SKU, usando a coluna id como chave, sem tocar na origem.

Quando vence: o feed principal está travado porque a plataforma é engessada, mas você precisa corrigir GTIN faltando, ajustar título, adicionar categoria do Google ou criar rótulo personalizado para segmentar campanha. Custo baixo. O que ele não resolve é preço ou estoque dinâmico, isso continua sendo trabalho da Opção B.

O suplementar é a ferramenta certa para consertar atributo em massa sem reprocessar a base inteira. Falta GTIN em duzentos produtos? Um suplementar com id e GTIN preenche sem que você mexa no cadastro original.

Matriz de decisão por contexto

Diagnóstico de rejeições, passo a passo

Escolhido o método, o trabalho vira manutenção. É aqui que a maioria perde dinheiro sem perceber, porque produto reprovado não aparece no leilão e não gera venda.

Onde clicar: no Merchant Center, abra a aba de produtos e o painel de diagnóstico, filtre por status "Reprovado". Ordene por número de produtos afetados, do maior para o menor, e ataque o motivo do topo primeiro. O gatilho de decisão mais útil é este: se um único motivo cobre mais de 30% do catálogo, o problema é de template ou de origem, não de item isolado, e você conserta na fonte, não produto a produto.

Os motivos que concentram quase todas as reprovações em e-commerce:

• Preço divergente. O valor no feed não bate com o da página. Verifique os microdados da página de produto e a cadência de sincronização. Se atinge muitos SKUs de uma vez, é atraso de feed, e a saída é migrar para Content API ou integração nativa.
• Disponibilidade divergente. O feed diz em estoque, a página diz esgotado. Corrija a fonte de estoque, nunca force o atributo no feed para enganar a validação, porque o Google recompara com a página.
• GTIN inválido ou ausente. Quando o produto tem código de barras, o Google espera o GTIN correto. Preencha via feed suplementar em vez de reeditar cadastro por cadastro.
• Imagem não suportada. O link precisa apontar para um formato aceito (JPEG, PNG, WebP, BMP, TIFF ou GIF), com no mínimo 500 por 500 pixels e sem marca d'água promocional.
• Informações enganosas (misrepresentation) e violação de política. Página sem política de devolução clara, sem dados de contato, ou com preço que não confere. É a reprovação mais grave, porque escala de item reprovado para suspensão de conta. As políticas de Shopping ads do Google tratam isso como prática proibida, não como erro de dado.

O que medir na prática: acompanhe a proporção de SKUs ativos sobre o total enviado. Se você sobe mil produtos e só seiscentos ficam ativos, tem 40% de catálogo invisível, e cada ponto recuperado é receita que já estava paga em mídia mas não rodava.

O que a Moyker recomenda para e-commerce de R$50k a R$500k

Para a maioria das lojas nessa faixa, em Shopify ou VTEX, a combinação que resolve é integração nativa da plataforma mais um feed suplementar para GTIN e rótulos. Isso cobre a sincronização de preço e estoque e ainda deixa espaço para corrigir atributos sem depender de dev. Planilha com fetch agendado só faz sentido com catálogo pequeno e parado, e mesmo assim como estágio inicial, não como destino.

O feed é metade do problema. O Google Merchant Center decide se o produto entra no leilão, mas ele não te diz o que converteu depois do clique. Sem GA4 com enhanced ecommerce configurado e sem CAPI alimentando a atribuição pelo servidor, você aprova o produto, gasta em mídia e ainda fica sem saber qual SKU pagou a conta. Feed, mensuração e atribuição são a mesma peça, e a visão completa disso está no setup de tracking para e-commerce em 2026.

Quantos por cento do seu catálogo estão reprovados agora, e você sabe dizer sem abrir o painel?