Se a sua loja envia produtos para o Google Merchant Center, vale a pena perceber quem trata da ligação e como confirmar que continua a funcionar. Migrar da Content API para a Merchant API pode exigir trabalho de desenvolvimento, uma atualização do conector ou uma confirmação junto da plataforma que utiliza.
O caminho depende da sua instalação. Neste guia, ajudamos você a identificar o responsável, distinguir a fonte de dados da API e verificar produtos, sincronização e campanhas sem fazer alterações desnecessárias.
Neste artigo
Porque é necessário migrar da Content API para a Merchant API
Uma API é uma forma de comunicação entre sistemas. Neste contexto, pode permitir que uma integração envie e atualize informações do catálogo da loja no Google Merchant Center. Se quiser rever o conceito antes de avançar, explicamos noutro artigo o papel das APIs na ligação entre aplicações.
A Content API for Shopping é a interface anterior; a Merchant API é a interface para a qual as integrações abrangidas devem transitar. Para o responsável pela loja, a questão prática não é apenas mudar uma designação: é garantir que o caminho entre os dados de origem e o Merchant Center continua a funcionar.
Segundo o calendário de descontinuação do Google, a Content API atingiu a data de descontinuação em 18 de agosto de 2026. A partir de 1 de setembro de 2026, os pedidos de projetos sem extensão ativa começaram a poder falhar intermitentemente com o erro HTTP 410. O encerramento integral está previsto para o início de 2027, mas o calendário pode ser revisto.
Estas datas não significam que todos os pedidos deixem de funcionar no mesmo instante. Também não tornam seguro esperar até ao último dia: falhas intermitentes podem deixar alterações de preço ou disponibilidade por atualizar antes de existir uma interrupção total.
O que está, e o que não está, confirmado
A documentação geral não permite concluir se a sua loja já migrou. Sem conhecer a plataforma, a versão do conector, eventuais integrações próprias e o estado da conta, qualquer confirmação seria uma suposição. O objetivo deste roteiro é ajudá-lo a recolher essas informações e a decidir quem deve atuar.
Também é importante distinguir a migração técnica de problemas que já existiam no catálogo. Um produto pode estar reprovado devido a uma imagem, uma política ou uma divergência de preço, independentemente da API. Registar o estado inicial ajuda a não atribuir todos os avisos à atualização.
Identifique como a loja envia os produtos
Antes de alterar definições, desenhe o percurso real dos dados. Uma loja pode enviar produtos através de um plugin, de uma plataforma alojada, de um ficheiro ou de um desenvolvimento próprio. Também pode combinar vários métodos para diferentes partes do catálogo.
Comece por identificar a plataforma da loja, o nome exato de cada extensão que comunica com o Google e a versão instalada. Anote ainda quem administra a conta Merchant Center, quem gere o Google Ads e se existe uma agência ou equipa técnica com acesso ao projeto.
Perguntas para descobrir o responsável
- Existe um plugin ou uma aplicação que sincroniza produtos? Quem é o fornecedor e qual é a versão instalada?
- Há scripts, tarefas automáticas ou uma integração desenvolvida à medida que fazem chamadas à Content API?
- Existe mais de uma fonte de dados ou mais de um sistema a atualizar os mesmos produtos?
- Quem pode consultar registos de erros, atualizar o conector e validar o catálogo depois da alteração?
Se a ligação for assegurada por uma plataforma de comércio eletrónico, o Google indica que o parceiro da plataforma gere a migração da sua integração. Isso não dispensa o comerciante de confirmar o estado da sua instalação: pode ser necessário atualizar uma aplicação, seguir instruções do fornecedor ou resolver um erro de ligação.
Se houver código próprio, a responsabilidade pelas chamadas é de quem mantém esse código. Numa situação mista, pode ser necessário envolver ambos. Por exemplo, um plugin pode enviar os produtos principais enquanto um script interno atualiza outros dados; confirmar apenas o plugin deixaria uma parte do percurso por verificar.
Peça uma resposta que possa ser verificada
Uma pergunta útil ao fornecedor é: «A versão instalada nesta loja comunica com a Merchant API e que passos faltam para concluir a transição?» Peça também a forma recomendada de confirmar a resposta, eventuais requisitos e limitações. Uma declaração genérica de que a plataforma é compatível não prova, por si só, que a instalação concreta foi atualizada.
Guarde o contacto, a data da confirmação e as ações pendentes num documento partilhado. Assim, a equipa comercial, o apoio técnico e quem acompanha as campanhas têm a mesma referência.
Fonte de dados e API: não são a mesma coisa
No Merchant Center, a fonte de dados identifica a origem ou o mecanismo através do qual os dados dos produtos são fornecidos. A API é a interface usada por uma integração para comunicar com os serviços do Google. Os dois conceitos estão relacionados, mas não são intercambiáveis.
Em particular, um nome visível que contenha «Content API» não prova, por si só, que o conector continua a fazer pedidos à API antiga. O nome pode não refletir diretamente o cliente usado no momento. Da mesma forma, alterar uma etiqueta ou renomear algo na interface não equivale a migrar o código.
O caminho mais seguro é juntar várias evidências: versão do conector, documentação do fornecedor, registos técnicos quando disponíveis e confirmação de que as atualizações de produtos chegam ao destino. Cada uma responde a uma pergunta diferente. Uma sincronização bem-sucedida mostra que certos dados chegaram; isoladamente, pode não demonstrar que todas as chamadas antigas foram substituídas.
Faça um inventário antes de apagar ou recriar
Registe as fontes existentes, os produtos ou conjuntos de produtos a que se aplicam e os sistemas responsáveis por as atualizar. Se existirem fontes adicionais que completam ou modificam atributos, inclua-as no mapa. A documentação do Google sobre a compatibilidade das fontes de dados é uma referência para a equipa técnica verificar as diferenças aplicáveis.
Imagine que a loja tem uma fonte principal para o catálogo e outra que acrescenta informação comercial. Se a equipa recriar uma delas sem compreender a relação entre ambas, pode perder atributos, criar duplicações ou dificultar a manutenção. Isto é um risco possível, não uma consequência inevitável da migração.
Antes de eliminar uma fonte, pergunte quem a utiliza, que dados fornece e como será reposta se algo correr mal. Guarde as definições relevantes e confirme as instruções do fornecedor. Evite fazer alterações de estrutura apenas porque o nome apresentado parece antigo.
O que verificar quando usa um plugin ou conector
Quando a loja depende de um conector de terceiros, a primeira medida é consultar a documentação oficial desse conector e confirmar a versão instalada. Não assuma que as instruções para uma plataforma, ou até para uma extensão com nome semelhante, se aplicam à sua loja.
No caso específico da extensão Google for WooCommerce, a documentação recomenda a versão 3.8.1 ou posterior para a transição. Recomenda também uma cópia de segurança antes da atualização e a consulta dos registos de depuração para confirmar a utilização do cliente Merchant API.
Este exemplo é útil para perceber o tipo de evidência a procurar, mas não substitui as instruções de outros plugins ou plataformas. Para esses casos, confirme a compatibilidade, a versão necessária, os passos de atualização e a forma de verificar o resultado junto do respetivo fornecedor.
Prepare uma atualização controlada
- Registe a versão atual do conector e o estado da ligação ao Merchant Center.
- Faça uma cópia de segurança adequada à loja e confirme como restaurá-la.
- Verifique requisitos e compatibilidades documentados antes de atualizar.
- Quando possível, teste primeiro numa cópia de desenvolvimento, evitando que um teste envie dados inesperados para a conta de produção.
- Atualize na janela acordada e consulte os registos e avisos disponíveis.
- Confirme produtos e alterações recentes no Merchant Center.
Uma cópia de segurança não resolve automaticamente uma falha externa nem garante que uma reversão seja inofensiva. Por exemplo, voltar a uma versão antiga pode repor uma dependência da Content API. O plano de recuperação deve considerar tanto a loja como as consequências para a sincronização.
Se não tiver acesso aos registos ou não souber interpretá-los, peça ao responsável técnico uma confirmação escrita do que foi observado. A resposta deve indicar a loja e a versão verificadas, não apenas reproduzir uma nota geral do fornecedor.
Como preparar uma integração desenvolvida à medida
Uma integração própria exige uma análise mais profunda. O trabalho não se resume a substituir o endereço de um pedido: é necessário identificar as operações utilizadas, consultar as diferenças aplicáveis e validar que os dados continuam a ser tratados como esperado.
O guia do Google para iniciar a migração recomenda mapear os métodos e as sub-APIs, testar os resultados e implementar a mudança de forma gradual. A equipa responsável deve usar a documentação atual para cada operação, em vez de presumir que existe uma correspondência simples para todas as chamadas.
Registo e acesso ao projeto
O Google exige um registo único para cada projeto Google Cloud utilizado diretamente com a Merchant API, associado à conta principal do Merchant Center. Identifique os projetos usados nos diferentes ambientes e confirme com a equipa técnica como esse requisito se aplica à arquitetura existente.
Reveja também as permissões e a gestão das credenciais. Não partilhe chaves ou dados de acesso por canais informais. O objetivo é assegurar que a integração autorizada consegue operar, mantendo acesso limitado às pessoas e serviços que dele precisam.
Teste os comportamentos relevantes
Crie uma lista das operações efetivamente usadas: inserir ou atualizar produtos, consultar informação, processar respostas e quaisquer outras funções presentes na integração. Para cada uma, identifique o equivalente documentado, os dados necessários e a forma como os erros são tratados.
Teste, por exemplo, uma atualização de preço, uma alteração de disponibilidade e um produto com variantes. Compare o resultado com o esperado na loja e no Merchant Center. A documentação de compatibilidade dos produtos ajuda a equipa a identificar aspetos técnicos a rever.
Antes de passar a produção, defina quem acompanha os registos, como detetar pedidos falhados e quando interromper a implementação. Uma passagem gradual pode reduzir a dimensão de um problema, mas só é útil se houver critérios de validação e pessoas responsáveis por agir.
Valide os produtos, não apenas a ligação
Uma migração tecnicamente concluída precisa de uma verificação comercial: os produtos certos devem apresentar os dados certos. O número total de itens é um ponto de partida, mas não basta. Um catálogo pode ter uma contagem semelhante e, ainda assim, conter variantes duplicadas ou atributos incorretos.
Registe, antes da alteração, o estado geral do catálogo e uma amostra de produtos. Depois, compare os mesmos itens. Inclua produtos simples, variantes, artigos em promoção, produtos sem stock e itens importantes para a atividade da loja.
Campos que merecem atenção
- Identificador: confirme que o produto ou a variante mantém a identificação esperada e não surge duplicado.
- Preço e moeda: compare o valor enviado com o apresentado na página de destino, incluindo promoções quando aplicáveis.
- Disponibilidade: verifique se um produto esgotado ou novamente disponível é atualizado.
- Ligação e imagem: confirme que o endereço abre o produto correto e que a imagem corresponde à variante.
- Atributos e etiquetas: compare os dados usados para categorizar produtos ou organizar campanhas.
- Estado e avisos: consulte os diagnósticos e distinga erros novos de problemas anteriores.
Os identificadores são especialmente importantes porque permitem relacionar produtos entre sistemas e processos. Uma alteração involuntária pode fazer com que um artigo seja tratado como diferente do anterior ou dificultar a comparação. Não altere identificadores em massa apenas para facilitar a transição sem compreender os efeitos.
Para um teste concreto, escolha uma t-shirt com várias cores e tamanhos. Altere um dado numa variante de teste apropriada, aguarde o processamento e confirme que a mudança aparece na variante correta, sem modificar as restantes. Repita a análise para um produto simples e para um artigo com preço promocional.
A atualização pode não ser visível de imediato. Registe quando fez a alteração, consulte o estado e respeite os tempos de processamento indicados pelas ferramentas. Se o dado não chegar, investigue os registos do conector e os avisos antes de repetir alterações em massa.
Confirme o impacto nas campanhas e na informação comercial
O catálogo alimenta mais do que uma lista de produtos: os seus atributos podem ser usados em anúncios, listagens e regras de organização. Por isso, uma verificação após a migração deve envolver quem conhece os produtos e quem acompanha as campanhas.
Comece pelos artigos prioritários. Confirme se continuam disponíveis para os destinos relevantes na conta e se os avisos existentes têm resolução atribuída. Um produto presente no Merchant Center não está necessariamente elegível para todos os destinos; consulte o estado concreto em vez de assumir que a presença equivale a aprovação.
Etiquetas, grupos e promoções
Se utiliza etiquetas personalizadas para separar margens, categorias ou campanhas sazonais, verifique se continuam preenchidas como previsto. Uma etiqueta ausente ou diferente pode afetar a forma como os produtos são agrupados, mesmo quando o título e o preço parecem corretos.
Para produtos em promoção, compare o preço e o período anunciado com as condições reais da loja. A consistência também interessa fora do envio por API: o nosso guia sobre dados estruturados para preços promocionais explica como comunicar a duração de uma promoção na página.
Reveja igualmente as informações de envio e devolução relevantes para os mercados em que vende. Uma alteração de API não corrige políticas desatualizadas. Se também gere essas informações no Search Console, veja o guia para configurar envios e devoluções e confirme que refletem as condições efetivamente praticadas.
Evite recriar campanhas ou modificar regras apenas porque ocorreu a migração. Primeiro, identifique uma diferença concreta, avalie a causa e decida a correção. Uma mudança simultânea em demasiados pontos torna mais difícil perceber o que provocou um problema.
Acompanhe a sincronização depois da migração
Depois da atualização, acompanhe os dados durante um período ajustado à frequência com que o catálogo muda. Uma loja que altera preços ou stock várias vezes por dia precisa de uma observação diferente da de uma loja com um catálogo estável. O importante é cobrir alterações reais, não apenas verificar uma vez que a ligação aparece ativa.
Uma rotina simples de acompanhamento
- Consulte os registos da integração e os avisos do Merchant Center após a mudança.
- Compare a contagem e o estado dos produtos com o registo inicial, investigando diferenças relevantes.
- Verifique se alterações posteriores de preço, stock e produtos chegam ao destino.
- Confirme com a pessoa responsável pelo Google Ads se os agrupamentos essenciais continuam coerentes.
- Registe incidentes, causa identificada, correção e responsável.
Se encontrar erros, preserve a mensagem, a hora e o contexto, sem expor credenciais. Uma falha HTTP 410 numa chamada à Content API pode ser um sinal relevante no contexto do calendário de descontinuação, mas a equipa deve confirmar qual o pedido afetado e se o projeto tinha uma extensão ativa.
Se os produtos deixarem de atualizar, avalie a dimensão do problema antes de efetuar alterações em massa. Pode ser uma falha do conector, uma permissão, uma configuração da fonte ou outro problema. Contacte o fornecedor quando a integração for de terceiros; envolva quem mantém o código quando a chamada for própria.
Defina quando o trabalho está concluído
Uma conclusão responsável combina evidência técnica e funcional: o fornecedor ou a equipa confirma a utilização da Merchant API onde aplicável; os testes previstos foram concluídos; as atualizações chegam; e os avisos relevantes têm um responsável. Problemas antigos que permaneçam abertos devem ficar registados separadamente.
Não existe uma lista universal que prove a saúde de todas as lojas. Use este roteiro como base e acrescente verificações para os seus mercados, sistemas e regras comerciais. Guarde a documentação final num local acessível para facilitar futuras atualizações ou mudanças de equipa.
Perguntas frequentes
Se a fonte de dados se chamar Content API, a loja ainda usa a API antiga?
Não necessariamente. O nome apresentado na fonte de dados, por si só, não confirma qual é a API utilizada pelo conector. Verifique a versão e os registos da integração ou peça ao fornecedor uma confirmação específica para a sua instalação.
Tenho de criar um projeto Google Cloud para atualizar um plugin?
Não necessariamente. Quando utiliza um conector de terceiros, siga as instruções do respetivo fornecedor. O registo do projeto aplica-se aos projetos Google Cloud usados diretamente com a Merchant API; não se deve presumir que todos os comerciantes precisam de criar um projeto próprio.
A migração altera automaticamente as campanhas do Google Ads?
A mudança de API não significa, por si só, que todas as campanhas tenham de ser refeitas. Ainda assim, alterações nos identificadores, atributos, etiquetas ou na disponibilidade dos produtos podem afetar a sua utilização nas campanhas. Confirme o catálogo e os grupos de produtos depois da transição.
O que levar desta leitura
Migrar da Content API para a Merchant API é uma tarefa técnica com consequências práticas para a informação que chega aos canais do Google. A prioridade é conhecer o percurso dos dados, atribuir a responsabilidade certa e confirmar o comportamento de produtos reais depois da mudança.
Não tome o nome de uma fonte de dados como prova definitiva, nem confunda uma ligação ativa com um catálogo validado. Se precisar de apoio para analisar a integração da sua loja e organizar as verificações, pode falar com a UniversoWeb.
