Anúncio reprovado por site comprometido no Google Ads: como resolver

O que significa site comprometido no Google Ads?

Site comprometido é um destino cuja integridade foi afetada por uma intervenção não autorizada, como a inserção de código, conteúdo ou redirecionamentos prejudiciais. No Google Ads, essa classificação indica um problema de segurança associado à experiência que o usuário pode encontrar depois de clicar no anúncio. A página inicial pode parecer normal enquanto outras URLs, arquivos ou condições de acesso revelam o comportamento que motivou a reprovação na plataforma. Por isso, olhar apenas a aparência do site no próprio computador não basta para concluir que houve um erro de análise. O primeiro passo é tratar o aviso como um incidente técnico que exige investigação, sem presumir que toda a conta foi suspensa.

Site comprometido e software malicioso são conceitos relacionados, mas não devem ser usados como sinônimos automáticos durante a análise de um anúncio reprovado. Um site legítimo invadido pode distribuir malware, enviar visitantes para páginas fraudulentas ou carregar scripts inseridos por terceiros sem autorização do proprietário. Já um aviso relacionado a software malicioso pode envolver programas, downloads e funcionalidades prejudiciais, conforme o motivo específico exibido pela plataforma naquele caso. A investigação deve partir da redação exata da política indicada, porque diferentes reprovações podem exigir verificações e evidências diferentes para sua resolução. Também vale conferir se existem outros problemas simultâneos, como destino indisponível, que não desaparecem necessariamente depois da remoção dos arquivos infectados no servidor.

A reprovação de um anúncio não equivale, por si só, à suspensão da conta nem comprova que todas as páginas do domínio estejam infectadas. Ainda assim, uma ocorrência localizada pode exigir análise mais ampla quando a infraestrutura, os scripts ou as credenciais são compartilhados por vários sites. Em campanhas Performance Max, convém verificar os destinos configurados e, quando habilitada, a expansão de URL final, sem presumir que apenas uma página recebe tráfego. O formato da campanha não dispensa o cumprimento das políticas nem substitui a segurança do ambiente que recebe os usuários após o clique. O objetivo inicial é delimitar quais ativos foram afetados e quais caminhos precisam ser examinados antes de apresentar uma solicitação de revisão ao Google.

Quais informações reunir antes de alterar o site?

Antes de fazer alterações, registre o motivo da reprovação, os anúncios afetados e todos os destinos envolvidos no caminho do clique do usuário. Na interface disponível em sua conta, consulte os detalhes da política e anote eventuais URLs ou referências técnicas que apareçam na notificação recebida. Guarde capturas de tela e datas, pois essas informações ajudam a relacionar o aviso com atualizações, acessos administrativos e mudanças recentes na infraestrutura. Também registre a URL final, o modelo de acompanhamento e os parâmetros utilizados, incluindo ferramentas externas que possam executar redirecionamentos durante o acesso. Esse levantamento reduz tentativas aleatórias e permite entregar ao desenvolvedor ou à hospedagem um problema delimitado, em vez de apenas informar que o anúncio parou.

Preserve uma cópia dos arquivos, do banco de dados e dos registros disponíveis antes de excluir conteúdo suspeito ou restaurar qualquer versão anterior. Esse material serve para investigar o incidente, mas deve ficar isolado e protegido, pois um backup feito após a invasão pode conter a própria infecção. Quando houver sinais de risco ativo para visitantes, pause o tráfego pago direcionado ao ambiente afetado enquanto a equipe técnica organiza a contenção. Uma página temporária de manutenção pode reduzir a exposição, mas não deve ser tratada como prova de limpeza ou solução definitiva para a reprovação. A prioridade é impedir novos danos sem destruir as evidências necessárias para descobrir como ocorreu o acesso indevido e quais componentes precisam de correção.

Defina um responsável pela coordenação do incidente e separe claramente as tarefas de publicidade, desenvolvimento, hospedagem e administração de acessos ao ambiente afetado. O gestor de tráfego consegue reunir informações da conta, mas normalmente não possui sozinho os recursos necessários para examinar processos, permissões e registros do servidor. A hospedagem pode fornecer evidências sobre arquivos alterados, processos suspeitos e ocorrências em outros sites, conforme o serviço contratado e os dados disponíveis. O desenvolvedor deve avaliar o código da aplicação, os plugins, as integrações e os pontos de entrada que poderiam permitir uma nova invasão. Com essa divisão documentada, fica mais fácil acompanhar o trabalho e evitar que a revisão seja solicitada enquanto uma parte essencial da investigação continua pendente.

• 1. Registre o texto exato da reprovação e os identificadores dos anúncios ou recursos afetados para manter um histórico verificável.
• 2. Mapeie a URL final, os parâmetros de acompanhamento e os redirecionamentos para identificar todos os componentes do destino.
• 3. Preserve arquivos, banco de dados e logs em uma cópia isolada antes de iniciar a limpeza do ambiente.
• 4. Pause o tráfego pago para destinos com risco ativo e combine a contenção com a equipe responsável pelo site.
• 5. Defina quem investigará a aplicação, quem verificará o servidor e quem apresentará a solicitação de revisão.

Como verificar se o site realmente está comprometido?

A verificação confiável combina análise externa do destino com inspeção interna da aplicação, porque nenhum scanner isolado consegue confirmar a ausência de todas as ameaças. Consulte o relatório de problemas de segurança do Google Search Console, quando houver acesso à propriedade, e verifique o diagnóstico disponível no Google Safe Browsing. Esses recursos podem apontar ocorrências relevantes, mas a ausência de alertas não significa que o Google Ads necessariamente considere o destino adequado naquele momento. As ferramentas possuem finalidades, coberturas e ciclos de atualização diferentes, o que pode produzir resultados aparentemente contraditórios durante a investigação de um mesmo domínio. Use cada resultado como uma evidência parcial e complemente a análise com dados do servidor, do navegador e das integrações que participam do carregamento.

No servidor, procure arquivos inesperados, usuários administrativos desconhecidos, tarefas agendadas suspeitas e alterações em componentes que não deveriam ter sido modificados pela equipe. Em WordPress, isso inclui revisar plugins, temas, diretórios de uploads, arquivos centrais e registros do banco de dados que possam armazenar scripts injetados. A comparação com versões oficiais ajuda a identificar diferenças, embora modificações legítimas também precisem ser consideradas para não remover funcionalidades importantes por engano. Verifique ainda regras de redirecionamento, configurações do servidor e arquivos como o .htaccess, quando esse recurso fizer parte da infraestrutura utilizada pelo site. Datas de modificação são pistas úteis, mas não constituem prova suficiente, pois podem mudar em atualizações legítimas ou ser manipuladas durante uma invasão do ambiente.

No navegador, acompanhe as requisições e os redirecionamentos da página anunciada para descobrir quais domínios e scripts realmente participam da experiência de acesso. Uma infecção pode aparecer somente em dispositivos móveis, visitas originadas de determinados canais ou sessões sem cookies anteriores, escondendo o problema de verificações superficiais. Esses testes devem ocorrer em ambiente controlado, sem executar downloads suspeitos no computador utilizado para administrar campanhas, pagamentos ou credenciais de clientes e fornecedores. Inclua na análise o gerenciador de tags, widgets, chats, bibliotecas externas e sistemas de rastreamento, mesmo quando os arquivos principais do site parecem íntegros. Se o comportamento depender de um terceiro, documente a cadeia de carregamento e interrompa a integração comprometida até que sua segurança seja efetivamente restabelecida.

• 1. Consulte o Search Console e o Safe Browsing para identificar alertas que possam orientar a investigação técnica.
• 2. Compare arquivos da aplicação com versões confiáveis e procure alterações não autorizadas no banco de dados.
• 3. Revise administradores, tarefas agendadas e regras de redirecionamento para localizar possíveis mecanismos de persistência da invasão.
• 4. Inspecione requisições do navegador em diferentes condições de acesso para detectar comportamentos que não aparecem na primeira visita.
• 5. Avalie scripts externos e ferramentas de acompanhamento, pois o problema pode estar fora dos arquivos principais da página.

Como limpar o site e corrigir a causa da invasão?

Limpar o site exige remover a infecção e corrigir o ponto de entrada, porque apagar apenas o código visível pode permitir uma reinfecção rápida. Comece pela contenção do componente afetado e substitua arquivos adulterados por cópias confiáveis, respeitando as particularidades da aplicação e os dados legítimos armazenados. Em sistemas com plugins e temas, prefira pacotes obtidos de fontes oficiais e elimine extensões abandonadas, desnecessárias ou cuja origem não possa ser verificada. O banco de dados também precisa ser analisado quando houver conteúdo injetado, contas indevidas ou configurações alteradas que não dependem de arquivos infectados. A execução deve ficar com alguém capaz de distinguir código malicioso de personalizações legítimas, evitando uma limpeza improvisada que derrube funcionalidades importantes do negócio.

Depois de remover o conteúdo indevido, atualize os componentes vulneráveis e revise permissões de escrita, usuários administrativos e formas de autenticação utilizadas no ambiente. Troque as credenciais afetadas a partir de um dispositivo confiável, incluindo hospedagem, CMS, transferência de arquivos, banco de dados e integrações quando houver exposição. Revogue sessões e tokens comprometidos, habilite autenticação em dois fatores onde estiver disponível e reduza acessos que já não sejam necessários para a operação. Se um computador da equipe estiver infectado, trocar a senha sem resolver esse problema pode devolver ao invasor o acesso recém-protegido ao site. Um firewall de aplicação pode acrescentar proteção, mas não substitui a atualização do software, a remoção de portas de entrada e a revisão das credenciais.

Restaurar um backup só é uma solução adequada quando existe confiança de que a cópia antecede a invasão e não carrega a mesma vulnerabilidade. Mesmo nesse cenário, as correções de segurança precisam ser aplicadas antes de devolver o ambiente ao uso normal e liberar novamente o tráfego pago. Depois da limpeza, invalide caches da aplicação e da CDN quando necessário para impedir que versões antigas continuem entregando scripts ou páginas já removidos. Examine outros sites da mesma hospedagem se houver possibilidade de compartilhamento de credenciais, permissões ou arquivos que permitam contaminação entre aplicações vizinhas no servidor. Se aparecerem indícios de acesso indevido a dados pessoais, acione também os responsáveis por privacidade para avaliar obrigações aplicáveis, sem confundir revisão de anúncios com resposta completa ao incidente.

• 1. Remova arquivos, registros e contas maliciosas com base em evidências, preservando os dados legítimos necessários ao funcionamento do site.
• 2. Corrija a vulnerabilidade explorada e atualize os componentes envolvidos antes de considerar o ambiente recuperado.
• 3. Troque credenciais expostas, revogue acessos antigos e habilite autenticação em dois fatores nos serviços que ofereçam esse recurso.
• 4. Limpe os caches pertinentes e verifique outros sites que compartilhem a infraestrutura potencialmente afetada.
• 5. Documente as alterações realizadas para validar a recuperação e sustentar o pedido de revisão sem divulgar informações sensíveis.

O que validar antes de solicitar revisão no Google Ads?

Solicite revisão somente depois de confirmar que o destino está funcional, acessível e sem os comportamentos maliciosos identificados durante a investigação do incidente. Repita os testes na URL efetivamente utilizada pelo anúncio, incluindo parâmetros e redirecionamentos, em vez de verificar apenas a página inicial do domínio. Confira também as páginas necessárias para concluir a navegação, como formulários e checkout, principalmente quando carregam integrações ou scripts diferentes dos encontrados na entrada. Certificados HTTPS válidos são importantes para proteger a conexão, mas o cadeado do navegador não comprova que os arquivos e o conteúdo estejam seguros. A validação precisa demonstrar uma experiência legítima de ponta a ponta, sem downloads inesperados, mudanças indevidas de destino ou solicitações suspeitas de informações ao visitante.

Verifique se as medidas de proteção adotadas não passaram a bloquear visitantes legítimos ou impedir a avaliação técnica do destino pelos sistemas do Google. Regras excessivamente restritivas no firewall, desafios de navegação e bloqueios regionais podem introduzir problemas de acesso mesmo depois de a infecção ter sido removida. O ajuste correto é manter controles proporcionais e compatíveis com a documentação oficial, nunca oferecer uma página limpa ao avaliador e outra experiência ao público. Não desative toda a proteção apenas para tentar obter aprovação, pois isso pode reabrir a vulnerabilidade e expor novamente o ambiente ao mesmo ataque. Quando houver dúvida sobre bloqueios automatizados, envolva a hospedagem e utilize registros de acesso para separar tentativas maliciosas de requisições legítimas necessárias ao funcionamento do site.

Reúna evidências objetivas da correção, como os componentes atualizados, a integração removida, as permissões ajustadas e os resultados das verificações realizadas após a limpeza. Não existe um número universal de horas de observação que garanta segurança, mas sinais de reinfecção indicam que a causa ainda não foi resolvida. Monitore alterações inesperadas em arquivos e novas conexões suspeitas enquanto a equipe confirma a estabilidade do ambiente e revisa as hipóteses do diagnóstico inicial. Se também houver um alerta de segurança no Search Console, siga o procedimento correspondente nessa ferramenta, separadamente da contestação necessária dentro do Google Ads. Uma análise favorável em determinado produto não garante atualização imediata em todos os outros, por isso registre o andamento de cada processo de forma independente.

Como solicitar revisão de anúncio reprovado no Google Ads?

Para solicitar revisão no Google Ads, abra os detalhes da reprovação e utilize a opção de contestação ou revisão disponibilizada para o item afetado. A localização e os rótulos podem variar conforme a interface, o tipo de campanha e o status da conta, então siga as instruções apresentadas. Se a opção estiver disponível, selecione o motivo correspondente à situação real, distinguindo alterações feitas para cumprir a política de uma discordância fundamentada da decisão. Quando o sistema permitir definir o escopo, inclua os anúncios afetados que compartilham o destino corrigido, evitando ampliar a solicitação sem necessidade ou diagnóstico. Caso não encontre um caminho adequado, consulte a ajuda oficial ou o suporte disponível na conta para identificar o procedimento correto antes de enviar pedidos repetidos.

Na descrição, quando houver campo para isso, apresente um resumo factual do problema identificado, das correções concluídas e das verificações realizadas no destino anunciado. Um modelo possível é informar que houve remoção de código não autorizado, substituição do componente vulnerável, revisão de acessos e validação dos redirecionamentos da página. Adapte essa mensagem ao que realmente foi executado e não declare uma auditoria completa se o trabalho se limitou a um scanner ou ajuste pontual. Não envie senhas, chaves de API, dados pessoais de usuários ou cópias integrais de registros que exponham informações sensíveis sem necessidade para a análise. Se a investigação não encontrou comprometimento, explique o alcance dos testes e as evidências disponíveis, em vez de afirmar que a plataforma certamente cometeu um erro.

Após o envio, acompanhe o status na própria conta e eventuais comunicações, usando o prazo informado pelo Google como referência para aquele processo específico. Não há garantia universal de aprovação em vinte e quatro horas, e casos que dependem de verificações adicionais podem exigir mais tempo para conclusão. Evite repetir contestações idênticas enquanto existe uma análise em andamento, pois isso não corrige o site nem acrescenta evidências úteis à avaliação da plataforma. Se a reprovação permanecer, volte ao diagnóstico e examine destinos secundários, scripts de terceiros, rastreamento e possíveis mecanismos de reinfecção que tenham passado despercebidos. Caso o aviso envolva suspensão da conta, siga o fluxo específico de recurso indicado, sem criar outra conta para escapar da restrição aplicada pelo Google.

• 1. Abra os detalhes da política no item reprovado e identifique a opção de revisão disponível na sua conta.
• 2. Escolha o motivo que corresponde aos fatos, indicando correções realizadas ou uma discordância sustentada por evidências técnicas.
• 3. Delimite os anúncios afetados pelo destino corrigido quando a interface permitir selecionar o escopo da solicitação.
• 4. Descreva as ações executadas sem incluir credenciais, dados pessoais ou afirmações que não possam ser comprovadas.
• 5. Acompanhe o resultado e aprofunde a investigação se houver nova reprovação, evitando reenvios sem mudanças ou informações adicionais.

Como evitar novas reprovações e retomar as campanhas com segurança?

A prevenção depende de uma rotina de manutenção e controle de acessos, não de uma limpeza isolada realizada apenas quando os anúncios deixam de veicular. Mantenha inventário de plugins, temas, integrações e responsáveis, com um procedimento para remover componentes que perderam suporte ou deixaram de ser necessários à operação. Faça backups automáticos em ambiente separado e teste a restauração, porque a existência de arquivos de cópia não garante uma recuperação utilizável após um ataque. Combine alertas de disponibilidade com monitoramento de alterações e segurança, ajustando a frequência à criticidade do site e à capacidade de resposta da equipe. A configuração deve permitir identificar quem recebe o aviso e quem age, evitando um sistema que acumula notificações sem qualquer responsável por investigar as ocorrências.

Depois da aprovação, retome o tráfego de forma controlada e confirme que páginas, formulários, checkout e mensuração continuam funcionando corretamente após as alterações de segurança. A remoção de um script comprometido pode afetar uma integração legítima, então verifique eventos e conversões antes de interpretar oscilações como um problema de mídia. Em Performance Max, revise os destinos e a expansão de URL final, quando habilitada, para entender quais páginas estão elegíveis e precisam permanecer sob manutenção. Isso é governança do destino, não uma técnica para esconder páginas infectadas, que devem ser corrigidas mesmo quando não recebem tráfego direto das campanhas. Monitore novamente os acessos e os alertas durante a retomada para interromper rapidamente qualquer sinal de recorrência antes que o problema atinja mais visitantes do site.

Trocar de canal de aquisição não resolve uma falha de segurança, porque visitantes continuam expostos quando chegam ao mesmo ambiente por outras origens de tráfego. Em 2026, a discussão sobre AI Overviews, AI Mode e anúncios em interfaces de IA não altera a necessidade de manter destinos íntegros e confiáveis. Recursos, formatos e disponibilidade publicitária variam por plataforma e mercado, portanto não presuma que ChatGPT Ads esteja disponível no Brasil ou funcione como alternativa equivalente. Se o site participa de estratégias de SEO e GEO, a prioridade operacional continua sendo corrigir o incidente e restabelecer a experiência legítima do usuário. Distribuição, citação por IAs e aquisição paga são assuntos diferentes da recuperação de segurança, e nenhum deles substitui a limpeza técnica exigida para resolver a reprovação.

Perguntas Frequentes