O Google começou nesta terça-feira, 1º de setembro de 2026, a provocar falhas intermitentes em chamadas feitas à antiga Content API for Shopping. A medida atinge projetos sem extensão ativa e pode interromper parte da sincronização de produtos, preços, disponibilidade e outros dados enviados automaticamente ao Merchant Center.

A documentação oficial, atualizada hoje, informa que as requisições selecionadas passam a receber o erro HTTP 410 Gone. A empresa já havia encerrado oficialmente a API em 18 de agosto, mas agora adicionou uma etapa de degradação progressiva antes da desativação total, prevista para o início de 2027.

Isso não significa que todo e-commerce terá o catálogo derrubado. O alerta é dirigido a empresas, agências, plataformas e desenvolvedores que ainda mantêm integrações próprias ou conectores legados baseados na Content API for Shopping v2.1. Quem usa uma integração nativa deve primeiro confirmar com o fornecedor qual API está por trás da sincronização.

Para a PME, o risco mais traiçoeiro não é uma tela inteira fora do ar. É a operação continuar parecendo normal enquanto algumas atualizações de preço, estoque ou produto deixam de chegar ao Google.

O que mudou em 1º de setembro

Segundo o cronograma oficial, chamadas à Content API for Shopping feitas por projetos sem extensão começaram a falhar de forma intermitente em 1º de setembro. Quando uma requisição é selecionada para a degradação, a API devolve o status 410 Gone.

A expressão "intermitente" merece atenção. Uma integração pode funcionar em uma execução e falhar na seguinte. Isso dificulta perceber o problema quando o sistema não tem alertas, repetição automática ou alguém acompanhando os registros de erro.

O Google orienta a migração para a Merchant API, substituta da tecnologia antiga. A desativação completa de todos os endpoints está prevista para o início de 2027, embora a empresa ressalte que o calendário pode ser revisto conforme o avanço da migração do ecossistema.

Projetos que precisam de mais tempo podem solicitar uma extensão temporária. Quando aprovada, ela protege o projeto das falhas programadas durante a janela concedida, mas não ultrapassa a desativação definitiva.

Quem pode ser afetado

A mudança interessa principalmente a negócios que automatizam o Merchant Center por meio de software próprio ou de uma integração antiga. Alguns sinais de exposição são:

  • a empresa contratou um desenvolvedor para enviar o catálogo ao Google;
  • uma agência mantém scripts para atualizar preço, estoque ou promoções;
  • o ERP, hub ou conector registra chamadas para shoppingcontent.googleapis.com;
  • os registros técnicos mencionam content/v2.1;
  • a integração começou a apresentar respostas 410 Gone;
  • ninguém sabe informar se o conector já usa a Merchant API.

Lojas que cadastram produtos manualmente, enviam arquivos ou usam feeds por outros meios não estão necessariamente expostas a esta API. O mesmo vale para integrações nativas que já tenham sido atualizadas pelo fornecedor.

A pergunta correta, portanto, não é "uso Google Shopping?". É "qual tecnologia envia meus dados ao Merchant Center e quem responde por ela?".

O que pode acontecer com o catálogo

A Content API for Shopping era usada para automatizar tarefas como gestão de contas, produtos, inventário e relatórios. A Merchant API cobre esses fluxos na nova arquitetura, mas o Google avisa que não há garantia de compatibilidade total entre recursos semelhantes.

Se uma chamada antiga falhar e o sistema não tratar o erro, o efeito depende da função daquela requisição. Entre os cenários possíveis estão:

  • um produto novo demorar a aparecer no Merchant Center;
  • uma atualização de preço não ser processada;
  • o estoque exibido no Google ficar diferente do estoque da loja;
  • uma promoção não ser atualizada como esperado;
  • diagnósticos e relatórios internos ficarem incompletos;
  • rotinas de conta ou inventário apresentarem falhas parciais.

Nem toda falha produz imediatamente um anúncio reprovado ou um catálogo vazio. Justamente por isso, a conferência precisa comparar a fonte da loja com os dados efetivamente recebidos pelo Merchant Center.

Preço e disponibilidade inconsistentes podem prejudicar a experiência do consumidor e gerar problemas de qualidade dos dados. Para quem anuncia, também podem desperdiçar tráfego ao levar uma pessoa a uma oferta diferente da que ela viu.

Como descobrir se a loja ainda usa a API antiga

O dono da PME não precisa dominar programação para conduzir a primeira verificação. Ele precisa chegar ao responsável certo com perguntas objetivas.

1. Identifique o responsável pela integração

Descubra quem configurou e mantém a conexão: equipe interna, agência, desenvolvedor, ERP, plataforma de e-commerce ou hub de marketplaces.

Se ninguém tem essa responsabilidade definida, o risco operacional já existe independentemente da mudança do Google.

2. Peça uma confirmação por escrito

Envie três perguntas ao fornecedor:

  • a integração com o Google Merchant Center ainda usa a Content API for Shopping v2.1?
  • o projeto já foi migrado para a Merchant API?
  • houve erros HTTP 410 Gone desde 1º de setembro?

Uma resposta como "a integração está funcionando" não é suficiente. Como as falhas são intermitentes, o teste precisa incluir registros recentes e chamadas de escrita, não apenas uma consulta superficial.

3. Compare produtos críticos

Escolha uma amostra pequena, mas relevante: itens com maior venda, promoções ativas, produtos com estoque baixo e lançamentos recentes.

Compare preço, disponibilidade e atualização na plataforma de origem com o que aparece no Merchant Center. Faça a checagem novamente depois de uma alteração controlada.

4. Revise alertas e tentativas automáticas

Uma integração madura deve registrar o status das chamadas, avisar quando o erro se repete e tentar novamente apenas quando isso fizer sentido. Repetir indefinidamente uma chamada a um endpoint encerrado não resolve a migração.

Peça evidência do monitoramento: painel, log, alerta enviado ou relatório de falhas. O objetivo não é receber jargão técnico, mas saber quem será avisado e quanto tempo levará para agir.

Migrar não é apenas trocar o endereço da API

A documentação de compatibilidade mostra diferenças importantes entre as duas tecnologias. Na Merchant API, nomes de recursos, identificadores e métodos podem mudar. O formato usado para identificar um produto, por exemplo, deixa de seguir a mesma estrutura da API antiga.

O Google também informa que a Merchant API não oferece o método customBatch da Content API. Integrações que dependiam dele precisam adotar chamadas paralelas ou assíncronas. As bibliotecas clientes usam gRPC por padrão, e o projeto deve registrar a conta do Merchant Center e o projeto do Google Cloud.

Ao mesmo tempo, a nova API amplia recursos. Ela permite trabalhar com diferentes fontes de dados, incluindo inventário local e regional, promoções e avaliações, além de oferecer notificações sobre mudanças na conta e ações de diagnóstico.

Na prática, isso exige inventário das funções atuais, mapeamento dos equivalentes, testes em ambiente controlado e validação dos dados depois da mudança. Tratar a migração como uma simples substituição de URL aumenta a chance de falhas silenciosas.

O que fazer nas próximas 24 horas

Para uma PME com e-commerce ativo, o plano mais seguro é curto e verificável:

  1. confirme se existe uma integração por API com o Merchant Center;
  2. identifique a tecnologia usada e o responsável por mantê-la;
  3. procure erros 410 Gone nos registros a partir de 1º de setembro;
  4. compare preço e estoque de produtos críticos entre a loja e o Merchant Center;
  5. se a API antiga ainda estiver ativa, cobre cronograma de migração e plano de testes;
  6. avalie a extensão apenas como contingência, não como substituta da migração;
  7. monitore o catálogo até confirmar estabilidade na Merchant API.

Empresas em campanha promocional, com alta rotatividade de estoque ou grande variação de preço devem priorizar a checagem. Nesses casos, poucas horas de defasagem já podem criar oferta inconsistente ou tráfego desperdiçado.

A leitura da AgenciAR: o maior risco é confiar na tela certa com o dado errado

Mudanças em APIs costumam ser delegadas integralmente à tecnologia. Para a PME, porém, esta migração toca diretamente mídia, operação e receita. O catálogo é a ponte entre a loja e os anúncios ou listagens exibidos pelo Google.

O erro intermitente muda a natureza do problema. Uma indisponibilidade total costuma ser percebida rápido. Uma integração parcialmente funcional pode sobreviver por dias sem levantar suspeita, especialmente quando o catálogo é grande e a equipe confere apenas se a conta está acessível.

Por isso, a validação não deve terminar com "o conector abriu". Ela precisa responder se o dado certo chegou ao destino certo no tempo esperado. Preço, estoque e produto novo são indicadores de negócio, não apenas campos técnicos.

Também é importante evitar uma reação exagerada. Se o fornecedor já usa a Merchant API e apresenta evidência de sincronização, não há motivo para reconstruir a operação. O trabalho do gestor é reduzir a incerteza, definir responsabilidade e exigir teste.

A extensão temporária pode comprar tempo, mas não remove o prazo final. A decisão madura é transformar esta semana em uma auditoria rápida da cadeia de dados do catálogo. Mesmo depois da migração, esse mapa ajuda a descobrir quem monitora falhas e como a empresa reage antes que o cliente encontre uma oferta errada.

Referências oficiais consultadas

Por que esta pauta merece publicação

O fato novo é verificável e começou a produzir efeito hoje: integrações sem extensão já podem receber falhas intermitentes. O ângulo da AgenciAR traduz uma mudança técnica em risco operacional concreto para e-commerces, sem sugerir que toda loja está afetada. A matéria ajuda o gestor a identificar exposição, cobrar evidência do fornecedor e proteger preço, estoque e mídia antes de uma falha silenciosa chegar ao cliente.

Perguntas frequentes

O Google Shopping vai parar de funcionar para todas as lojas?

Não. A mudança atinge chamadas feitas à antiga Content API for Shopping por projetos sem extensão. Lojas que não usam essa API ou cujos conectores já migraram para a Merchant API não estão incluídas nesse risco específico.

O que significa o erro 410 Gone?

É a resposta usada para indicar que o recurso solicitado não está mais disponível. Na degradação programada, o Google passou a devolver esse erro intermitentemente às chamadas da API antiga.

Uma integração nativa de plataforma pode ser afetada?

Depende da tecnologia mantida pelo fornecedor. O lojista deve confirmar se a plataforma, ERP ou hub ainda usa a Content API v2.1 e pedir evidência de que a migração foi concluída.

A extensão resolve o problema definitivamente?

Não. Uma extensão aprovada evita temporariamente as falhas programadas durante a janela concedida, mas não passa da desativação total prevista para o início de 2027.

Qual é a urgência para uma PME?

Se a empresa usa integração própria ou não sabe qual API alimenta o Merchant Center, a verificação deve ser feita agora. Negócios com promoções, preços dinâmicos ou estoque volátil têm prioridade porque uma sincronização parcial pode afetar rapidamente a oferta mostrada ao consumidor.