Acordar com todas as campanhas pausadas e uma notificação vermelha no painel do Google Ads dizendo "reprovado por software malicioso" é o pesadelo de qualquer gestor de mídia paga. O choque vem acompanhado de confusão: você não instalou nenhum vírus, não distribuiu malware intencionalmente e, ainda assim, o sistema da plataforma bloqueou seus anúncios e colocou sua conta em risco. A boa notícia é que, na imensa maioria dos casos, essa reprovação não reflete má-fé - ela sinaliza uma vulnerabilidade técnica na landing page de destino, um plugin desatualizado ou um script de terceiro comprometido que passou despercebido.
O Google utiliza o Safe Browsing, um sistema automatizado extremamente sensível, para proteger usuários de páginas que possam infectar dispositivos ou roubar dados. Quando seu rastreador detecta qualquer comportamento suspeito - injeção de código, redirecionamento encoberto, certificado SSL inválido ou assinaturas conhecidas de malware -, a plataforma age de forma preventiva e imediata, paralisando todos os anúncios que apontam para aquele domínio de destino. O problema é que esse radar pega tanto ameaças reais quanto falsos positivos, e cabe ao anunciante provar que a landing page está limpa.
Este artigo detalha o que realmente significa essa reprovação, como o Google detecta software malicioso, quais são as causas técnicas mais comuns, o passo a passo para diagnosticar e corrigir o problema, e como solicitar revisão para recuperar a operação de Google Ads sem perder mais dias de veiculação - além de boas práticas para blindar sua infraestrutura contra novos bloqueios.
O que significa a reprovação por software malicioso no Google Ads
Quando o Google Ads reprova um anúncio por software malicioso, ele está informando que a URL de destino - ou algum recurso carregado por ela - foi identificada como potencialmente perigosa pelo sistema de Safe Browsing. Essa classificação não implica necessariamente que você tenha instalado um vírus de forma consciente; na verdade, significa que algum elemento da página está emitindo sinais que o Google interpreta como ameaça à segurança do usuário final. Pode ser um iframe escondido que redireciona para um site de phishing, um script de analytics adulterado por invasores ou até mesmo um banner de rede de afiliados que carrega conteúdo malicioso sem seu conhecimento.
A política de anúncios Google é explícita: anúncios não podem direcionar tráfego para sites que contenham ou distribuam software prejudicial, incluindo malware, vírus, cavalos de Troia, spyware ou qualquer código que comprometa a experiência ou os dados do usuário. O sistema trata essa violação com máxima severidade porque o risco é duplo - para o usuário que clica e para a reputação da própria plataforma de anúncios. Por isso, a reprovação é automática e instantânea assim que o rastreador identifica o padrão suspeito.
O impacto operacional é imediato: todas as campanhas vinculadas àquela URL param de veicular, o painel exibe o status "Reprovado: software malicioso", e o anunciante perde visibilidade até que o problema seja corrigido e a revisão seja aprovada. Em contas com histórico de múltiplas infrações ou reprovações recorrentes, o Google pode escalar a penalidade, suspendendo temporariamente ou até permanentemente a conta. Por isso, agir rápido - e com método - é essencial para minimizar a perda de receita e preservar a saúde da conta.
Vale destacar que a reprovação pode afetar anúncios de Search, Display, Shopping e YouTube, desde que todos compartilhem a mesma landing page comprometida. Se você mantém campanhas separadas com URLs distintas e apenas uma delas é flagrada, as demais continuam ativas - mas a conta como um todo fica marcada no radar do sistema de compliance, exigindo atenção redobrada para evitar novos episódios.
Como o Google detecta software malicioso em anúncios e sites
O Google utiliza uma combinação de rastreamento automatizado contínuo, inteligência de ameaças compartilhada e análise heurística para identificar software malicioso em landing pages vinculadas a anúncios. O Safe Browsing - sistema responsável por essa camada de proteção - varre milhões de URLs todos os dias, cruzando informações com bases de dados globais de ameaças conhecidas, analisando certificados SSL, inspecionando scripts e monitorando comportamentos de redirecionamento. Esse processo acontece de forma proativa, não apenas no momento da criação do anúncio, mas também ao longo de toda a vida útil da campanha.
Rastreamento automatizado de landing pages
Assim que você submete um anúncio no Google Ads, o sistema dispara um crawler (robô de rastreamento) que acessa a URL de destino como se fosse um usuário real, renderiza a página completa - incluindo JavaScript, CSS e todos os recursos externos carregados - e analisa o código-fonte em busca de padrões suspeitos. Esse crawler verifica se há tentativas de download automático de arquivos executáveis, iframes ocultos, redirecionamentos para domínios não declarados, requisições a endereços IP conhecidos por hospedar malware e qualquer técnica de cloaking que apresente conteúdo diferente para usuários e para bots.
O rastreamento não para na aprovação inicial. O Google revisita as landing pages periodicamente - especialmente aquelas com alto volume de impressões - para garantir que nenhuma alteração posterior introduziu código malicioso. Esse monitoramento contínuo é a razão pela qual um anúncio pode funcionar perfeitamente por semanas e, de repente, ser reprovado: alguém atualizou um plugin, um script de terceiro foi comprometido ou o servidor sofreu uma invasão, e o próximo scan detectou a mudança.
Além do crawler próprio, o Google integra dados do Safe Browsing API, que alimenta navegadores como Chrome, Firefox e Safari. Quando um domínio é reportado como perigoso por milhões de usuários ou por parceiros de segurança - empresas como ESET, Bitdefender, TrendMicro -, essa informação chega ao sistema de compliance do Google Ads em tempo quase real, disparando a reprovação antes mesmo que o próximo rastreamento programado aconteça.
Flags de Safe Browsing e vulnerabilidades de servidor
O Safe Browsing mantém uma lista pública de sites classificados como perigosos, acessível por meio do Transparency Report. Quando uma landing page entra nessa lista - seja por detecção automatizada ou por denúncia manual -, qualquer anúncio que aponte para ela é imediatamente suspenso. Os critérios para inclusão vão além da presença de malware: incluem phishing (páginas que imitam sites legítimos para roubar credenciais), engenharia social (pop-ups enganosos que forçam downloads), hospedagem de exploits (scripts que tentam explorar vulnerabilidades do navegador) e distribuição de unwanted software (programas que se instalam sem consentimento claro).
Vulnerabilidades de servidor são outra fonte comum de flags. Um certificado SSL expirado, ausente ou emitido por uma autoridade não reconhecida gera alertas porque conexões não criptografadas expõem dados sensíveis. Servidores desatualizados rodando versões antigas de Apache, Nginx ou PHP com falhas conhecidas também entram no radar, porque invasores exploram essas brechas para injetar código malicioso sem que o proprietário do site perceba. O Google não diferencia entre "site hackeado" e "site que distribui malware intencionalmente" - a reprovação acontece da mesma forma, cabendo ao anunciante limpar o ambiente e solicitar reavaliação.
Por fim, o sistema verifica se a landing page carrega recursos (imagens, scripts, fontes) de domínios externos que já foram marcados como problemáticos. Mesmo que o seu próprio código esteja impecável, se você usa um CDN comprometido, um widget de chat de terceiros invadido ou um pixel de tracking adulterado, o Safe Browsing detecta a requisição para aquele domínio malicioso e reprova o anúncio. Essa interdependência explica por que auditoria de segurança precisa cobrir toda a cadeia de dependências, não apenas o HTML principal.
Principais causas técnicas do erro: do redirecionamento ao código injetado
A reprovação por software malicioso no Google Ads raramente decorre de ação intencional do anunciante. Na prática, as causas mais frequentes envolvem vulnerabilidades de infraestrutura, bibliotecas de terceiros comprometidas e configurações inadequadas de servidor - todos cenários que passam despercebidos até que o Safe Browsing acenda o alerta. Compreender esses vetores de ataque é o primeiro passo para diagnosticar e corrigir o problema na raiz, evitando reincidências que podem escalar para suspensão da conta.
Scripts de terceiros comprometidos
Quase toda landing page moderna carrega scripts externos: pixels de tracking (Google Analytics, Facebook Pixel, LinkedIn Insight Tag), ferramentas de chat ao vivo (Drift, Intercom), mapas de calor (Hotjar), testes A/B (Optimizely), CDNs de JavaScript (jQuery, Bootstrap). Cada um desses recursos representa um ponto de falha potencial. Se o servidor que hospeda o script for invadido, o invasor pode injetar código malicioso que será executado em todas as páginas que o carregam - incluindo a sua. O Google detecta essa injeção de código e reprova o anúncio, mesmo que você não tenha feito nada de errado diretamente.
Casos comuns incluem redes de publicidade de terceiros (AdSense de parceiros menores, banners de afiliados) que veiculam anúncios infectados; widgets de redes sociais adulterados que forçam downloads ou redirecionam para páginas de phishing; e bibliotecas JavaScript populares hospedadas em repositórios públicos que sofreram ataques de supply chain, onde o invasor substitui o arquivo legítimo por uma versão maliciosa. A solução envolve auditar cada script, verificar a integridade dos arquivos (usando Subresource Integrity, ou SRI), e hospedar internamente recursos críticos sempre que possível.
Outro vetor são os gerenciadores de tags como Google Tag Manager ou Segment. Se alguém com acesso à conta injeta um código malicioso por meio de uma tag personalizada, todas as páginas que carregam o container passam a distribuir o malware. Revisar permissões de usuários e ativar autenticação de dois fatores nos gerenciadores de tags reduz esse risco, mas auditoria periódica das tags ativas é indispensável para pegar inserções não autorizadas.
Plugins desatualizados em WordPress
WordPress alimenta mais de 40% da web e é, portanto, alvo favorito de invasores. A plataforma em si é robusta, mas o ecossistema de plugins - muitos desenvolvidos por equipes pequenas ou indivíduos, sem manutenção contínua - é repleto de vulnerabilidades. Um plugin de formulário de contato, slider de imagens ou otimização de SEO com falha de segurança não corrigida pode abrir a porta para injeção de código, permitindo que invasores insiram iframes ocultos, redirecionamentos encobertos ou scripts de mineração de criptomoedas que rodam em segundo plano.
A lista de vulnerabilidades conhecidas em plugins WordPress é pública e atualizada diariamente em sites como WPScan e Wordfence Intelligence. Muitas vezes, o invasor usa bots automatizados para escanear milhares de sites em busca de instalações que rodam versões antigas de plugins populares com falhas já documentadas. Uma vez dentro, ele cria backdoors, injeta malware em arquivos de tema e, em alguns casos, altera o arquivo .htaccess para redirecionar usuários vindos de determinados países ou navegadores para páginas maliciosas - exatamente o tipo de comportamento que o Safe Browsing detecta e penaliza.
Manter WordPress, temas e plugins sempre atualizados é a defesa mais básica, mas não suficiente. Plugins abandonados (sem atualizações há mais de um ano) devem ser substituídos ou removidos. Instalar um firewall de aplicação web (WAF) como Wordfence ou Sucuri adiciona uma camada de proteção em tempo real, bloqueando tentativas de exploração antes que elas atinjam o código do site. Auditorias regulares com ferramentas de escaneamento de malware em WordPress ajudam a identificar arquivos modificados ou desconhecidos que possam ter sido inseridos por invasores.
Redirecionamentos encobertos em domínios de destino
Redirecionamento encoberto (cloaking) é uma técnica em que a página apresenta conteúdo diferente para o rastreador do Google e para o usuário final. Isso pode acontecer de forma intencional - para tentar burlar as políticas de anúncios - ou acidental, como resultado de configuração incorreta de servidor ou infecção por malware. Um exemplo comum: o anunciante configura um redirecionamento 301 legítimo do domínio antigo para o novo, mas o servidor foi comprometido e alguém adicionou uma regra no .htaccess que redireciona visitantes vindos de anúncios para um site de phishing, enquanto tráfego orgânico vê a página correta.
Outro cenário envolve landing pages que carregam diferentes scripts dependendo do user-agent. Se o código detecta que o visitante é um crawler do Google e omite certos elementos (como pop-ups agressivos ou redirecionamentos), o Safe Browsing interpreta isso como tentativa de enganar o sistema e reprova o anúncio. Mesmo que a intenção seja melhorar a experiência do usuário, a diferença de comportamento entre bot e humano acende o alerta de cloaking.
Domínios de destino recém-registrados ou com histórico duvidoso também levantam suspeitas. Se o domínio foi usado anteriormente para distribuir malware, foi abandonado e depois recomprado, o Safe Browsing pode manter a classificação negativa por algum tempo. Verificar o histórico do domínio no Wayback Machine e no Google Transparency Report antes de usá-lo em campanhas pagas ajuda a evitar surpresas. Em casos de redirecionamento legítimo, garantir que tanto a origem quanto o destino estejam limpos e que o redirecionamento seja transparente para bots e usuários é essencial para passar pela auditoria do Google.
Passo a passo para diagnosticar a origem do problema
Identificar exatamente o que disparou a reprovação por software malicioso exige método e ferramentas adequadas. O Google raramente oferece detalhes específicos sobre qual elemento foi detectado - por questões de segurança, para evitar que invasores ajustem o código até passar pelo radar -, cabendo ao anunciante ou à equipe técnica conduzir uma investigação completa da landing page comprometida e de toda a infraestrutura associada.
Ferramentas de escaneamento: VirusTotal, Sucuri SiteCheck
O primeiro passo é submeter a URL de destino a scanners de segurança públicos e gratuitos que utilizam múltiplos engines de detecção de malware. O VirusTotal analisa a página com mais de 70 antivírus e serviços de reputação diferentes, consolidando os resultados em um único relatório. Ele não apenas verifica o código HTML, mas também baixa e analisa todos os recursos carregados (scripts, imagens, iframes), identifica redirecionamentos e cruza o domínio com listas negras conhecidas. Se o VirusTotal marcar a URL como maliciosa - mesmo que apenas um ou dois engines detectem algo -, você tem uma pista concreta de onde concentrar a investigação.
O Sucuri SiteCheck é outra ferramenta