Como Não Ter Seu Site Comprometido no Google Ads: Caso Real e Plano de Ação

Site comprometido no Google Ads é qualquer site cujo código foi manipulado para agir em benefício de terceiros sem o conhecimento do dono — incluindo WordPress operando com vulnerabilidades conhecidas e exploradas. O Google envia um aviso 7 dias antes da suspensão da conta de anúncios. Para evitar, o caminho prático é manter CMS e plugins sempre atualizados, nunca usar plugins piratas ("nulled"), e, em casos de infecção persistente, reescrever o site em código limpo.

O caso real: cliente com WordPress, plugins piratas e conta de Google Ads bloqueada

Esse post nasce de um trabalho recente. Cliente da Moggy Cloud rodava um WordPress de uns 3 anos, com tema e plugins premium baixados em "GPL clubs" (sites que distribuem versões piratas). Tudo "funcionando" — até o aviso chegar.

O Google Ads enviou a notificação de "compromised site" e bloqueou a conta. O cliente parou de receber leads do dia pra noite. Tentamos limpar primeiro: scan, remoção de arquivos suspeitos, atualização de plugins, recurso. Reaprovou por 9 dias. Bloqueou de novo.

A causa: backdoor persistente injetado em mu-plugins, fora do alcance da desinstalação padrão, programado pra reinjetar código após qualquer cleanup. Decisão tomada com o cliente: site novo, código próprio, Astro estático, zero dependência de plugin de terceiros. Sete dias de execução. Conta reaprovada e estável desde então.

Esse cenário é mais comum do que parece. E é exatamente o que motiva a query que aparece no Search Console de quem já passou perto do problema: "como faço para o site não ficar comprometido no anúncio do Google Ads".

O que o Google chama de "site comprometido" (e o que dispara a flag)

Política oficial do Google Ads, na íntegra: site comprometido é "um site ou destino cujo código foi manipulado para agir em benefício de terceiros sem o conhecimento do dono ou operador, frequentemente prejudicando os usuários". A própria documentação do Google lista, entre os motivos diretos de reprovação:

• Sites injetando scripts ou código que transmite dados do usuário sem consentimento (skimmer de cartão, malware, pop-ups indesejados, redirects).
• Operar um site usando um CMS com vulnerabilidades de segurança conhecidas, quando essas vulnerabilidades foram exploradas.

Esse segundo item é o gancho técnico que pega WordPress mal mantido. Não precisa haver malware ativo no momento — basta ter uma versão com CVE conhecida e sinal de exploração.

A política de Compromised Sites prevê aviso de 7 dias antes da suspensão da conta. Já a política de "Abusing the ad network" (malware ativo, redirect malicioso, phishing) é tratada como egregious violation: suspensão imediata, sem aviso, com banimento permanente possível.

Por que WordPress com plugins desatualizados ou piratas é a maior porta de entrada

WordPress roda mais de 43% dos sites do mundo, e por isso é o alvo mais explorado. Os números que importam, segundo o relatório anual da Patchstack:

• 7.966 novas vulnerabilidades descobertas no ecossistema WordPress em 2024 — alta de 34% ano a ano.
• 96% das vulnerabilidades em plugins de terceiros. Apenas 7 no core em 2024.
• 43% das vulnerabilidades exploráveis sem autenticação — atacante não precisa nem de senha.
• 33% sem patch disponível no momento da divulgação pública.
• 827 plugins e temas abandonados em 2024 — viraram zumbis com vulnerabilidades permanentes.

Plugin pirata ("nulled") é caso à parte. A Wordfence identifica essa prática como uma das maiores ameaças ao ecossistema WordPress. Sites rodando versão pirata do próprio Wordfence têm mais que o dobro de probabilidade de ter outras infecções não relacionadas. A razão é simples: quem cracka um plugin não está fazendo isso por ideologia — está injetando backdoor antes de redistribuir.

E o backdoor não some quando você desinstala o plugin. A Sucuri documentou casos em que o malware permanece em wp-content/mu-plugins/[nome-aleatório].php, que carrega automaticamente em todo request, mesmo sem o plugin original instalado.

Os sinais que o Google detecta antes de você

O Google usa Safe Browsing para varrer páginas continuamente. O que ele identifica antes de bloquear o anúncio:

• Cloaking pra Googlebot: spam ou redirect que aparece só para o crawler, invisível pro dono do site.
• Redirects condicionais: visitante mobile vai pra phishing, desktop vê página normal.
• Iframes ou scripts apontando pra domínios em blocklist.
• Modificação em arquivos críticos como wp-config.php, .htaccess, index.php.

O lugar pra olhar primeiro é o Google Search Console, aba Segurança e Ações Manuais → Problemas de Segurança. Se aparecer alerta ali, a conta de Ads costuma ser bloqueada em horas ou dias.

O que acontece quando o Google bloqueia: linha do tempo real

• Dia 0: notificação de "Compromised site" no painel do Google Ads. Aviso de 7 dias.
• Dia 1–7: identificar o vetor, limpar, documentar e enviar recurso. Anúncios pausam ou rodam com aviso.
• Dia 8: se o problema persistir, conta suspensa.
• Recurso pós-suspensão: 3–15 dias úteis, sem garantia. Se o malware reaparecer, o ciclo recomeça e a chance de banimento permanente cresce.

Em e-commerce ou serviço local que vive de Google Ads, o lucro do mês pode evaporar em uma semana de pause. Custo médio de recovery após data breach em SMBs fica entre R$ 250 mil e R$ 1 milhão segundo agregados de mercado.

Limpar o site infectado vs reescrever do zero — quando cada um vale a pena

Limpar faz sentido quando:

• A infecção é recente (descoberta em horas/dias).
• Você tem backup limpo anterior à infecção.
• Não há plugins piratas instalados.
• Os arquivos modificados são identificáveis (file integrity scan funciona).

Reescrever em código limpo faz sentido quando:

• Há plugins piratas (mesmo desinstalados — ainda tem rastro).
• A infecção é antiga ou desconhecida (mu-plugins mexido, banco de dados injetado).
• O site teve mais de uma reinfecção.
• Performance já era ruim mesmo sem malware (LCP > 4s, Lighthouse < 50).
• O site usa muitos plugins abandonados sem alternativa direta.

A regra prática: se o cleanup demanda mais de 8 horas de auditoria forense, o investimento se paga melhor refazendo. Site novo em HTML estático, Astro ou Next.js sem CMS pesado entra no ar com Lighthouse 95+ no mobile, sem plugins, sem painel de administração exposto, sem superfície de ataque relevante.

Checklist de prevenção: 10 itens que mantêm o Google Ads aprovado

1. Atualize WordPress core, tema e plugins toda semana — automatize quando possível.
2. Nunca use plugin ou tema pirata. Se o orçamento aperta, use a versão free do plugin oficial.
3. Reduza o número de plugins ao mínimo absoluto. Cada plugin é superfície de ataque.
4. Remova plugins desativados. Desativar não basta — código continua no servidor.
5. Verifique o repositório oficial antes de instalar qualquer plugin. Plugin abandonado (sem update há 12+ meses) é red flag.
6. Ative 2FA em todas as contas admin e mude senhas de admin a cada 90 dias.
7. Monitore o Search Console semanalmente — aba Problemas de Segurança.
8. Configure backups offsite diários com retenção de pelo menos 30 dias.
9. Use WAF na frente do site (Cloudflare free já resolve casos básicos).
10. Considere arquitetura sem CMS para landing pages e sites institucionais que não precisam de blog frequente — site estático em Astro ou HTML não tem painel pra ser invadido.

Como construir um site que o Google Ads aprova e mantém aprovado

Site institucional ou landing page que roda Google Ads tem três escolhas viáveis em 2026:

• Site estático em Astro/Next.js com hospedagem em CDN (Vercel, Cloudflare Pages, Netlify): zero plugins, zero painel admin público, deploy via Git. Risco de comprometimento próximo de zero, Lighthouse 95+ no mobile.
• WordPress headless com frontend desacoplado: WP fica isolado e o site público é estático. Combina edição via WP com exposição mínima.
• WordPress tradicional bem mantido: viável com disciplina de updates, plugins exclusivamente do repositório oficial, WAF ativo, auditoria mensal. Mais barato no curto prazo, mais caro em manutenção contínua.

Site que existe pra rodar tráfego pago não pode depender de updates manuais semanais. O custo de oportunidade de uma conta bloqueada por 15 dias quase sempre paga a refatoração pra uma stack mais segura.

Resumo rápido

• Site comprometido no Google Ads = código manipulado por terceiros OU CMS com vulnerabilidade conhecida e explorada. Aviso de 7 dias antes da suspensão.
• Plugins desatualizados e piratas são o vetor #1: 96% das vulnerabilidades WP em 2024 vieram de plugins.
• Plugin pirata deixa backdoor que sobrevive à desinstalação — limpeza superficial não resolve.
• Reinfeção é o padrão quando a infecção original veio de plugin nulled. Reescrever em código limpo costuma sair mais barato que limpar duas vezes.
• Site estático (Astro, HTML) elimina ~95% da superfície de ataque que afeta WordPress padrão.

Pronto para evitar (ou sair de) um bloqueio?

A Moggy Cloud reescreve sites WordPress comprometidos em código limpo (Astro, HTML estático ou Next.js) com Lighthouse 90–100 mobile, sem plugins piratas, sem dependência de painel exposto e prontos para rodar Google Ads sem risco de "compromised site". Se sua conta foi bloqueada ou se você quer se prevenir antes que aconteça, chama no WhatsApp que a gente faz uma auditoria gratuita do seu site e mostra exatamente onde está a exposição.