Uma oferta pode estar correta no ERP e errada no feed; correta no feed e desatualizada no site; ou correta na tela e diferente no JSON-LD. Sem separar essas camadas, você corre o risco de “corrigir” manualmente um campo que a integração sobrescreverá minutos depois.
1. Defina o sintoma antes de mexer na integração
Acesse o diagnóstico do Merchant Center e registre a mensagem exata do item: preço incompatível, disponibilidade divergente, item pendente, reprovação ou outra classificação. Essas situações não são equivalentes, e não há uma correção universal. Ao abrir o item, anote ID enviado, SKU interno, variante, URL de destino, país/moeda, canal e o horário do diagnóstico, se disponível.
O Google recomenda localizar os exemplos afetados e comparar os dados enviados com a página; problemas repetidos em itens semelhantes podem indicar um padrão [S01]. Use a mensagem do Google como ponto de partida, não como diagnóstico de causa já concluído.
2. Compare três representações do mesmo item
Uma auditoria mínima coloca lado a lado:
Três fontes: feed, página e dados estruturados
- 01
Fonte do produto enviada ao Merchant Center:
[id],[price],[sale_price]quando aplicável e[availability]. - 02
Página de destino acessível ao cliente: preço destacado, seleção da variante, disponibilidade e condições da oferta.
- 03
Dados estruturados da página:
Product/Offer, preço, moeda e disponibilidade, quando implementados.
A especificação do Merchant Center exige dados precisos e atenção a identificadores e variantes [S03]. Já a documentação de listagens do comerciante descreve como preços e disponibilidade podem ser informados na marcação de produto [S04]. O preço exibido na tela e o que está no código não devem entrar em contradição.
Para obter a terceira leitura, abra a URL da variante sem login e registre o que aparece ao comprador. Informe a mesma URL no Teste de pesquisa aprimorada do Google e, nos dados de produto detectados, procure a oferta Offer correspondente ao item: price, priceCurrency e availability. Registre URL, variante e horário do teste. Se não houver marcação detectada ou houver várias ofertas sem correspondência clara, anote essa situação e encaminhe ao responsável técnico; não preencha um valor por suposição. O teste ajuda a ler e validar a marcação, mas passar nele não comprova aprovação no Merchant Center nem conformidade de toda a oferta [S01] [S04].
Exemplo preenchido — divergência simulada de preço
Simulação fictícia, sem consulta a uma conta real. Às 14h, a loja demonstra uma camiseta azul M por R$ 129,90. O feed enviado às 13h30 tem R$ 149,90. O JSON-LD da página continua com R$ 149,90. As três leituras usam a mesma variante DEMO-CAM-AZ-M e moeda BRL.
Comparação fictícia R$ 129,90 versus R$ 149,90
| Camada | Valor observado no exemplo | Leitura |
|---|---|---|
| Vitrine, 14h | R$ 129,90 | Preço mostrado ao cliente |
| Feed, envio 13h30 | R$ 149,90 | Diverge do preço da vitrine |
| JSON-LD, 14h | R$ 149,90 | Também diverge da vitrine |
| Diagnóstico | Incompatibilidade de preço | É preciso confirmar a origem de atualização |
Esse quadro indica o que está diferente, mas ainda não prova por que. Pode haver atualização promocional iniciada depois do envio do feed, cache na página ou regra de canal. A causa só deve ser registrada depois da conferência de configuração e horários.
Exemplo preenchido — divergência simulada de estoque
A mesma variante aparece como in_stock no dado enviado e esgotada no site. Se uma venda consumiu a última unidade às 14h05, mas a atualização do feed ainda não ocorreu, o intervalo de sincronização é uma hipótese plausível. O Google menciona diferenças de horário como uma causa comum de inconsistência de disponibilidade [S02]. A ação não é editar o estoque em qualquer lugar: é descobrir qual sistema mantém o saldo e qual integração publica o status.
3. Cuidado com promoção e preço por canal
Quando houver promoção, registre preço normal, preço promocional, data de vigência e condição de compra. Uma regra de cupom aplicada somente ao carrinho não é automaticamente o mesmo que o preço público do item. Confira a representação exigida para o tipo de oferta antes de enviar [sale_price] [S01] [S03].
Faça uma comparação para a mesma região e variante, usando também uma sessão sem login. Nas ofertas do Shopping, não ajuste o preço da página por cookies, navegador ou dispositivo. Preço regional deve seguir o recurso e os requisitos de regionalização do Merchant Center, quando disponíveis para a operação. Já benefícios de associação têm condições próprias: não envie um preço de clube como se qualquer comprador pudesse obtê-lo, sem conferir as regras aplicáveis. Não assuma que o preço do seu navegador autenticado será o mesmo visto por outro comprador ou pelo Google. Consulte a regra vigente para a oferta e o país da conta [S01].
4. Investigue a origem: plataforma, ERP, conector ou feed
Depois de encontrar a discrepância, desenhe uma linha do tempo curta:
Linha do tempo para investigar origem de dados
| Pergunta | Registro necessário |
|---|---|
| Quem alterou o preço ou saldo? | Sistema, usuário/processo e horário, se disponível |
| Quem envia o dado ao Google? | Integração nativa, feed programado, API ou outra fonte |
| Quando a atualização foi publicada na loja? | Horário e evidência da página para a variante |
| Quando o Google recebeu os dados? | Histórico de processamento disponível no Merchant Center |
| Há outra fonte concorrente? | Feed adicional, regra promocional, cache ou edição manual |
Se o e-commerce usa Bling e Nuvemshop, confira nosso guia sobre responsabilidades entre ERP e loja. Ele ajuda a pensar a origem do dado, mas não substitui o diagnóstico da configuração real.
5. Corrija uma causa de cada vez e verifique a leitura nova
Uma sequência segura é: confirmar variante → corrigir na origem autorizada → verificar a página e os dados estruturados → enviar/aguardar atualização conforme o método utilizado → confirmar o novo estado no Merchant Center. As atualizações automáticas de itens do Merchant Center podem ajustar informações a partir da página; são um recurso do Google, distinto da sincronização entre ERP, loja e conector. Esse recurso não elimina a necessidade de manter a fonte correta [S01] [S02].
Não prometa aprovação imediata. O ritmo de processamento e revisão varia. Se a conta mostra ação de revisão, siga as instruções atuais do Merchant Center; um novo envio e uma revisão manual são processos distintos.
6. Como evitar que o problema volte
Faça uma amostra com perfis diferentes: item de preço regular, item promocional, item com variantes, item esgotado e produto recém-criado. Para cada um, registre o ID da oferta, valores esperados, horários e responsável pela correção. Refaça o teste após uma mudança de promoção ou integração.
Uma planilha simples pode ter colunas item_id, sku, variante, url, valor_feed, valor_pagina, valor_schema, status_feed, status_pagina, data_hora, origem_provavel, acao, reteste. Não coloque dados de cliente nem tokens de acesso nessa planilha.
A prevenção depende de governança: definir fonte de verdade, padronizar variantes, revisar as regras de promoção e acompanhar erros recorrentes. Uma operação pode precisar de ajustes técnicos; outra, apenas de uma rotina de publicação melhor.
7. Quando envolver alguém técnico
Peça apoio quando uma correção manual volta a ser sobrescrita, quando o erro envolve muitos itens, quando os dados estruturados não correspondem à vitrine ou quando você não consegue identificar qual sistema envia informações ao Google. Uma investigação útil deve começar com um caso reproduzível: item, variante, mensagem de erro, três leituras, horários e integração usada. A Guiby pode avaliar esse fluxo no escopo de organização e operação de e-commerce.
O seu catálogo apresenta erros de preço ou estoque? Converse com a Guiby sobre sua operação de e-commerce. Uma avaliação objetiva começa por um produto e pela trilha dos dados que alimentam cada canal.
Perguntas frequentes
O preço na página está certo. Por que o Merchant Center acusa divergência?
Porque o dado enviado ou a marcação estruturada pode estar diferente, ou o Google pode ter analisado outra versão e horário. Compare as três fontes e os registros de atualização antes de alterar os valores [S01].
Se eu editar o preço no Merchant Center, resolvo?
Talvez temporariamente, mas uma integração automatizada pode sobrescrever a edição. Primeiro identifique qual fonte governa a oferta. Não há regra única para todas as plataformas.
Produto esgotado deve continuar in_stock para não perder exposição?
Não. A disponibilidade enviada precisa refletir a condição real de compra. O Google exige consistência com a página [S02].
Atualizações automáticas substituem a sincronização da loja?
Não. As atualizações automáticas de itens do Merchant Center ajudam em alguns cenários, mas são distintas da sincronização da origem. O catálogo, a página e os dados enviados precisam permanecer coerentes [S01].
Fontes e limites
Fontes consultadas em 09/10/2026. Exemplos, produtos, preços e horários são simulados. Nenhuma conta Merchant Center, loja ou ERP foi operada para este artigo.
- Google Merchant Center — inconsistência entre feed e páginaRegras e causas de divergência de preço, programação e schema.
- Google Merchant Center — divergência de disponibilidadeStatus de estoque deve corresponder ao site; horários de atualização.
- Google Merchant Center — especificação de dados de produtoID, variantes, preço, atributos e requisitos da oferta.
- Google Search Central — merchant listingProduto, oferta, preço, moeda e disponibilidade estruturados.
