A Google desligou a Content API for Shopping a 18 de agosto de 2026. Desde então, cada chamada aos antigos endpoints v2.1 volta como HTTP 410 Gone, e qualquer integração ainda apontada para eles deixou de enviar produtos, preços e stock para o Google Merchant Center. A boa notícia, que a maioria das publicações em pânico ignorou, é que uma grande parte das lojas WooCommerce não teve nada a fazer. Se a sua está nesse grupo, o feed continua a correr; se não está, aqui fica como confirmar e o que fazer agora.
A versão honesta desta história continua a ser uma triagem, não um pânico. Na WPPoland construímos e mantemos integrações WooCommerce para comerciantes que vendem em toda a UE, por isso aqui fica quem foi realmente afetado, o que deixou de funcionar para quem falhou a data e porque é que a mesma migração é, discretamente, a porta para o comércio conduzido por agentes.
Quando foi desligada a Content API for Shopping
A Content API for Shopping é a antiga superfície programática da Google para gerir tudo o que uma loja envia para o Merchant Center: dados de produtos, stock, preços e definições de conta. Foi substituída pela Merchant API, que cobre o mesmo terreno, mas está dividida em sub-APIs focadas (Products, Inventories, Accounts, Reports) em vez de um endpoint monolítico.
A data que importou foi 18 de agosto de 2026. Desde aí, a antiga Content API devolve 410 Gone e não volta. Houve também uma data anterior: a v1beta da Merchant API foi descontinuada a 28 de fevereiro de 2026, por isso qualquer código escrito contra a beta já tinha de estar na v1 estável antes do corte principal.
Que lojas WooCommerce têm de migrar para a Merchant API
Esta é a pergunta que decide se pode fechar este separador. Uma loja WooCommerce costuma falar com o Merchant Center de três formas.
- O plugin oficial Google for WooCommerce. Se a sincronização de produtos corre através do plugin oficial (antigo Google Listings and Ads), está protegida. A passagem para a Merchant API foi entregue dentro de uma versão do plugin, por isso quem foi atualizando atravessou a data sem tempo de inatividade e sem código. Confirme na mesma que está numa versão recente e que a última sincronização de produtos é posterior a 18 de agosto.
- Um plugin de feed ou de marketing de terceiros. Alguns destes chamavam a Content API diretamente. Confirme com o fornecedor que a atualização para a Merchant API já saiu, que a tem instalada e que o feed voltou a atualizar depois de 18 de agosto.
- Uma integração própria. Conectores à medida, exportadores de feed próprios, configurações headless que enviam para o Merchant Center a partir do seu próprio código e ferramentas internas escritas contra a Content API. É este o grupo com trabalho real, e se esse código nunca mudou de API está agora a receber 410 Gone a cada tentativa.
No mercado português junta-se aqui um caso típico: uma loja que, com um único exportador próprio, alimenta ao mesmo tempo o Google Merchant Center e o KuantoKusta. A Google é então apenas um de vários canais nesse script, por isso a migração desse único ramo para a Merchant API tem de acontecer sem mexer nos restantes feeds, que continuam a funcionar como antes.
Se está no primeiro grupo, pare por aqui. Se está no terceiro, continue a ler.
Feed do Merchant Center não atualiza após o corte
Nada se degradou com suavidade. Desde 19 de agosto de 2026 as chamadas simplesmente falham com 410 Gone, e os efeitos alastram em cascata:
- As listagens ficam desatualizadas. Os produtos novos deixam de aparecer, e os removidos podem ficar pendurados. O seu catálogo no Merchant Center afasta-se do seu catálogo real do WooCommerce.
- Preços e stock deixam de atualizar. Este é o perigoso. O Merchant Center continua a mostrar o último preço e a última disponibilidade que recebeu, por isso pode acabar a anunciar um preço que já não pratica ou um produto que já não tem em stock, o que arrisca reprovações e perda de confiança da conta.
- As campanhas Shopping e Performance Max passam fome. As campanhas do Google Ads alimentam-se dos dados de produtos do Merchant Center. Quando o feed congela, as campanhas correm sobre stock desatualizado até começarem, discretamente, a ter mau desempenho.
Como falha tudo de uma vez em vez de o avisar, um feed parado pode passar dias despercebido. Se não sabe ao certo em que grupo está, verifique agora: no Merchant Center veja a data do último processamento do feed, e do lado da loja veja o registo de erros da integração. Uma resposta 410 nesses registos fecha a questão.
A Google refere na ajuda do Merchant Center que as atualizações automáticas não substituem as atualizações regulares dos dados dos produtos. Servem apenas para corrigir problemas esporádicos de preço, disponibilidade e estado. Se espera que o preço, a disponibilidade e o estado dos produtos mudem com frequência, a Google indica que deve usar a Merchant API. Numa loja com stock de rotação rápida, isto significa enviar as alterações pela integração, em vez de esperar que a Google corrija os dados a partir das páginas.
Como migrar uma integração WooCommerce para a Merchant API
O trabalho é metódico, não difícil, e é engenharia WooCommerce comum do lado do servidor.
- Confirme primeiro que a causa é mesmo a Content API. Procure nos registos da loja as respostas 410 e o domínio
shoppingcontent.googleapis.com. Se aparecer, a integração continua a chamar a superfície antiga e é essa a origem do feed congelado. - Inventarie as suas chamadas da Content API. Liste cada endpoint que a integração toca e o evento WooCommerce que o dispara (gravação de produto, alteração de stock, sincronização completa agendada).
- Mapeie cada chamada para a respetiva sub-API da Merchant API. Products, Inventories, Accounts e Reports assumem, cada uma, parte do que a Content API fazia num só sítio.
- Volte a autenticar-se. A Merchant API usa OAuth 2.0 ou uma conta de serviço. Confirme que as suas credenciais e âmbitos transitam.
- Verifique as etiquetas do feed após a mudança. A configuração das etiquetas nem sempre sobrevive à passagem, e as etiquetas comandam a estrutura das campanhas, por isso verifique-as em vez de assumir.
- Obtenha os motivos de reprovação agregados a partir da sub-API Reports assim que a nova integração estiver a funcionar, para apanhar tudo o que a mudança alterou antes de os algoritmos da Google o fazerem.
Merchant API e MCP para agentes de compras com IA
Encarar a migração como uma tarefa maçadora falha o essencial. A passagem para a Merchant API abre também o Merchant API MCP Access Service, uma ponte alpha que expõe os dados do Merchant Center a LLMs e agentes de IA através do Model Context Protocol, por agora apenas leitura mais algumas ferramentas de escrita de baixo risco. Em linguagem simples: a mesma plataforma onde o seu feed de produtos agora vive é aquela a partir da qual os assistentes de compras de IA vão ler quando decidirem que produtos mostrar.
Isto liga o corte à mudança maior sobre a qual temos escrito: as lojas passam de serem navegadas por pessoas a serem consultadas por agentes. A migração que já não pode adiar é, ao mesmo tempo, a rampa de acesso para ser encontrável e comprável por esses agentes, que é toda a tese do nosso guia de preparação para o comércio de IA.
Atributos conversacionais, atualização de 23 de outubro de 2026: desde o Google Marketing Live de maio de 2026, a especificação de dados de produto do Merchant Center tem seis campos opcionais pensados para o Modo IA e superfícies de IA semelhantes. A página de ajuda da Google sobre atributos conversacionais enumera-os: question_and_answer (perguntas e respostas sobre o produto, até 1000 caracteres cada), document_link (manuais em PDF, guias de utilização, instruções de montagem), related_product (acessórios, peças necessárias, produtos substitutos), item_group_title e variant_option (um título comum para uma família de produtos e as características que distinguem as variantes) e popularity_rank (um número de 0 a 100 que posiciona o produto face ao resto do seu inventário). A Google recomenda enviá-los por uma fonte de dados suplementar, garante que não alteram o estado de aprovação dos produtos existentes e pede que não se repita o que já consta de description, product_highlight ou product_detail. As colunas são as mesmas, seja qual for a origem do feed: um plugin WooCommerce, uma app de feed numa loja Shopify ou uma exportação própria. A fonte mais barata é o conteúdo que já tem, como as perguntas frequentes do produto e os manuais em PDF ligados nas fichas de produto.
Porque é que a Google mostra um preço de promoção que não está no feed do WooCommerce
Uma sincronização com a Merchant API a funcionar diz à Google o que a loja envia hoje. A Google guarda, no entanto, o seu próprio registo do que viu antes. Emina Demiri-Watson descreveu a 5 de outubro de 2026, no Search Engine Journal, uma loja britânica em que a Google mostrava no Shopping Was £474, now £355 com um selo de promoção. A loja não tinha promoção nenhuma e nunca enviou o atributo sale_price, nem no feed atual nem nos anteriores. Três sinais somaram-se no selo:
- o feed enviava £355 como preço sem IVA, enquanto o último rastreio da página leu £426, o mesmo preço com IVA,
- a marcação Product era um AggregateOffer com dois níveis de
priceSpecification,List pricea £395 eSale pricea £355, e £395 sem IVA são £474 com IVA, - o HTML da página escrevia
Nowjunto ao preço, e uma exportação do feed de 15 de abril ainda tinha £474 no campo do preço.
Nenhum destes sinais pedia um selo sozinho. A autora resume em duas frases: “As pessoas esquecem. Os sistemas não” (Emina Demiri-Watson, Search Engine Journal, tradução própria).
Os selos que a loja pede através de sale_price têm condições próprias. A Google verifica se o desconto fica entre 5% e 90% e se o preço base foi enviado durante um período mínimo, no Reino Unido “pelo menos 30 dias nos últimos 200 dias” (Emina Demiri-Watson, Search Engine Journal, tradução própria). As anotações de descida de preço nem precisam de envio: a Google compara o preço atual com a média que ela própria registou nos últimos 60 dias. A dimensão desta memória, segundo o mesmo artigo: o Shopping Graph contém “mais de 50 mil milhões de listagens de produtos, das quais mais de 2 mil milhões são atualizadas a cada hora” (Emina Demiri-Watson, Search Engine Journal, tradução própria).
Numa loja portuguesa só muda o número. Para um produto à taxa normal do continente, 23%, o preço rastreado fica 23% acima do preço do feed quando o feed envia o preço sem IVA e a página o mostra com IVA. A taxa normal é de 22% na Madeira e de 16% nos Açores, e as taxas intermédia e reduzida dão outras diferenças, por isso uma loja que fatura com taxas regionais ou com produtos a taxa reduzida não vê uma diferença única em todo o catálogo.
Como comparar o preço do feed com o preço do schema Product no WooCommerce
- Comece pelo que a Google viu. No Merchant Center, abra o produto em
Products > All products(nomes da interface em inglês) e desça até ao fim do separadorProduct details. A secçãoInformation found on your sitemostra o preço que a Google leu da página da última vez, com a data. Se a diferença for igual à taxa de IVA, o feed envia sem IVA e a página mostra com IVA. - Verifique
WooCommerce > Settings > Tax. A opção de introduzir preços com imposto decide o que significa o preço guardado, e a opção de mostrar preços na loja decide se o cliente o vê com ou sem IVA. Compare com o que o exportador do feed envia. Se a página mostra com IVA e o feed sem IVA, a Google tem de deduzir o imposto sozinha. - Leia o JSON-LD que sai na página, não o ecrã de definições. Abra o código-fonte de uma página de produto e procure cada bloco
application/ld+jsoncom um Product. O WooCommerce gera a sua própria marcação Product, e um plugin de SEO pode juntar uma segunda que não coincide. Procure um segundo preço e nomes empriceSpecificationcomSaleouList. - Procure palavras de promoção no HTML. O WooCommerce coloca o preço normal em
<del>e o preço promocional em<ins>quando o produto tem preço promocional, e os temas juntam muitas vezes etiquetas como “Antes” e “Agora”. Se um produto sem promoção mostra alguma delas, mude a etiqueta. A autora aconselha o mesmo. - Guarde exportações datadas do feed. O caso britânico só se resolveu porque havia, por acaso, uma exportação de abril guardada. Uma exportação por mês transforma a próxima investigação numa comparação entre dois ficheiros, também para o feed do KuantoKusta, se sair do mesmo exportador.
O que fazer às imagens de produtos descontinuados no WooCommerce
A Google mantém o seu próprio índice de imagens de produto, independente do image_link no feed e do schema. Enquanto um URL antigo de imagem continuar a responder, a Google pode continuar a usar essa imagem em anúncios e listagens gratuitas, mesmo depois de a loja a ter trocado. O artigo refere o WooCommerce diretamente: “os carregamentos do WooCommerce ficam na biblioteca multimédia normal do WordPress e raramente são limpos quando os produtos saem de venda” (Emina Demiri-Watson, Search Engine Journal, tradução própria).
- Apagar um produto não apaga as imagens. Quando retirar um produto ou trocar uma fotografia, apague o anexo antigo em
Media > LibrarycomDelete permanently. O WordPress remove o ficheiro e os tamanhos gerados, e o URL antigo passa a devolver 404, o sinal limpo que o artigo recomenda. Confirme antes que nenhum outro produto ou página usa essa imagem. - Um nome de ficheiro novo deixa o antigo online. Uma fotografia carregada com outro nome dá à Google dois URL de imagem para um produto, e a Google nem sempre escolhe o atual.
- Confirme o 404 no próprio URL. Abra o endereço antigo da imagem depois de a apagar. Uma CDN ou a cache da página podem continuar a servir o ficheiro depois de o WordPress o ter removido.
- Pesquise o nome antigo do ficheiro no Google Imagens. Uma cópia num marketplace ou numa página alheia esquecida pode ser a origem da imagem errada, e essa cópia tem de ser removida onde está.
O que fazer se o feed Google do WooCommerce parou
Se usa o plugin oficial, confirme que está numa versão recente e que o feed atualizou depois de 18 de agosto, e siga com o seu dia. Se tem uma integração própria ou de terceiros e o feed parou, descubra de que sub-APIs depende e faça a migração já, testando primeiro contra uma conta não produtiva, porque é exatamente isso que a Google recomenda antes de encaminhar tráfego de produção para as novas ferramentas.
Tratamos destas migrações no âmbito do nosso trabalho de desenvolvimento WooCommerce, a par do lado analítico das encomendas conduzidas por agentes, que abordamos em o que acontece quando um agente de IA finaliza a compra, e do servidor MCP para WooCommerce apenas de leitura, que mostra como os agentes leem um catálogo, para começar.
Última atualização: 11 de outubro de 2026.
