Site hackeado: como limpar o spam e recuperar o Google

Se uma busca pelo próprio domínio no Google retorna títulos em japonês, farmácias online, réplicas de produtos de grife ou páginas de apostas que você nunca criou, o site foi comprometido por um ataque de hack spam. É diferente de uma invasão que derruba o site ou rouba dados: aqui o invasor quer manter o site no ar e indexado, porque o objetivo é usar a autoridade e o histórico de rastreamento que você já construiu para promover produtos ilegais nos resultados de busca. Enquanto o site continuar funcionando normalmente para visitantes casuais, o esquema pode passar meses sem ser notado.

Recuperar isso exige três frentes, nesta ordem: identificar exatamente o que foi injetado e por onde o invasor entrou, remover o código malicioso e fechar essa porta de entrada, e só depois sinalizar ao Google que o site está limpo — pelo relatório de problemas de segurança do Search Console e pela remoção das URLs de spam já indexadas. Pular a segunda etapa é o erro mais comum: quem apaga só as páginas visíveis, sem corrigir a vulnerabilidade, vê o mesmo spam reaparecer em poucos dias, porque o script que gera as páginas continua ativo no servidor.

Os sinais de um ataque de hack spam

Hack spam raramente aparece como algo visualmente óbvio para quem administra o site. O painel de controle abre normalmente, o design não muda e as páginas principais continuam no ar. O que muda é o que o Google vê e indexa, e é por isso que o primeiro sinal costuma vir de fora: alguém encontra uma página estranha do seu domínio numa busca, ou o tráfego orgânico cresce de forma inexplicável para termos que nada têm a ver com o seu negócio.

Alguns padrões são específicos o bastante para servir de diagnóstico:

• Hack de palavras-chave em japonês: o site passa a ter centenas ou milhares de páginas com texto corrompido em japonês (ou outro idioma que não o seu) e links para lojas afiliadas, réplicas ou produtos falsificados. Essas páginas costumam existir só para o rastreador — abrir o link direto no navegador às vezes mostra um erro 404, porque o conteúdo é servido de forma condicional.
• Redirecionamentos com cloaking: um visitante comum vê a página normal do site, mas quem chega a partir de uma busca no Google — ou o próprio Googlebot — é redirecionado para um site de apostas, farmácia online ou golpe. O código verifica o user-agent ou o referenciador antes de decidir o que mostrar, exatamente para escapar da detecção manual.
• Páginas injetadas em diretórios de upload: pastas que deveriam conter só imagens e mídia passam a ter arquivos .php ou .html com nomes aleatórios, cada um gerando uma página de spam indexável.
• Explosão no número de páginas indexadas: o relatório de indexação de páginas ou uma busca site:seudominio.com mostra milhares de URLs muito além do que o site realmente tem.
• Títulos e descrições estranhos no resultado de busca: o próprio snippet do Google mostra termos de farmácia, apostas ou produtos de luxo falsificados em páginas que, ao abrir, parecem normais — sinal de que o Google está enxergando algo diferente do que um visitante vê.

Como confirmar a invasão sem esperar o Google avisar

A detecção automática do Google para conteúdo hackeado não é instantânea, e esperar por ela custa tempo em que o spam continua sendo indexado. Duas verificações rápidas confirmam ou descartam a suspeita antes de qualquer aviso oficial chegar.

A primeira é comparar o que existe no site com o que o Google mostra. Uma busca por site:seudominio.com seguida de termos suspeitos, como farmácia, réplica, apostas, ou palavras num idioma que o site não usa, revela rapidamente se há páginas estranhas indexadas. A segunda é usar a Inspeção de URL no Search Console para testar como o Googlebot renderiza uma página específica: como o cloaking depende do user-agent e do referenciador, uma página que parece limpa no navegador pode aparecer com conteúdo completamente diferente na renderização testada pelo Google — esse é justamente o sintoma do redirecionamento condicional.

Vale também revisar, no painel de hospedagem, os arquivos modificados mais recentemente ordenados por data. Um arquivo de tema ou de configuração alterado numa data em que ninguém da equipe fez deploy é o tipo de evidência que confirma a invasão antes mesmo de encontrar a página de spam que ela gerou.

Onde o código malicioso costuma se esconder

Antes de apagar qualquer coisa, vale mapear onde o invasor provavelmente deixou código, porque removendo só o sintoma visível — a página de spam — sem achar a origem, ela volta a ser gerada horas depois.

• Arquivos de tema, principalmente cabeçalho e rodapé, onde é fácil inserir um trecho de código que injeta conteúdo ou faz o redirecionamento condicional em toda página do site de uma só vez.
• Regras de reescrita no arquivo de configuração do servidor, como o arquivo .htaccess em servidores Apache, que podem conter condições que só disparam o redirecionamento quando o visitante chega via busca do Google ou quando o user-agent é o do Googlebot.
• Pastas de upload de mídia com arquivos executáveis, de extensão .php ou similar, que não deveriam estar lá — uma pasta de imagens não tem motivo para conter um script.
• Contas de administrador ou de usuário que a equipe não reconhece, criadas silenciosamente para manter acesso mesmo depois de uma limpeza parcial.
• Tarefas agendadas no servidor, do tipo cron, que reinjetam o conteúdo periodicamente, o que explica por que uma limpeza manual às vezes volta em poucos dias.
• Linhas adicionadas dentro de tabelas do banco de dados que armazenam o conteúdo das páginas ou as configurações do site, quando o próprio banco foi comprometido em vez de apenas os arquivos.

Limpando o site e fechando a porta de entrada

Apagar as páginas de spam sem corrigir a vulnerabilidade original resolve o problema por algumas horas. Antes de qualquer outra coisa, vale colocar o site em modo de manutenção: isso evita que visitantes vejam conteúdo malicioso enquanto a limpeza está em andamento e reduz a chance de o Google rastrear justamente a versão comprometida no meio do processo.

Se existir um backup limpo, de antes da data em que os sinais começaram a aparecer, restaurá-lo costuma ser mais rápido e mais confiável do que caçar cada arquivo alterado manualmente. Na ausência de um backup confiável, o caminho é comparar os arquivos atuais do sistema, incluindo tema, plugins e núcleo do CMS, com uma cópia nova e oficial da mesma versão, procurando por diferenças — qualquer arquivo modificado que não devesse ter sido tocado é suspeito.

A parte que mais gente esquece é a credencial que permitiu a entrada. Um invasor raramente usa uma vulnerabilidade complexa quando uma senha reaproveitada ou vazada em outro serviço já resolve o acesso. Depois de limpar o código, trocar todas as senhas — hospedagem, FTP, banco de dados, painel de administração e qualquer chave de API guardada em arquivos de configuração — é o que impede que a mesma porta seja usada de novo.

• Atualizar o CMS, os plugins e o tema para a versão mais recente antes de reconectar o site à internet publicamente.
• Remover plugins e temas que não estão em uso — código inativo continua sendo uma porta de entrada, mesmo desativado.
• Remover qualquer conta de administrador que a equipe não reconheça.
• Ativar autenticação em duas etapas nas contas de administração.
• Bloquear a execução de scripts dentro das pastas de upload de mídia, quando a hospedagem permitir essa configuração.

O relatório de problemas de segurança e a solicitação de revisão

Dentro do Search Console existe um relatório específico para isto, separado do relatório de ações manuais: o relatório de problemas de segurança. Enquanto ações manuais tratam de violações de política avaliadas por um revisor humano, problemas de segurança é onde o Google lista automaticamente os tipos de conteúdo malicioso detectados no site, incluindo especificamente conteúdo hackeado, com exemplos de URLs afetadas e uma descrição do tipo de injeção identificada.

Só depois de ter certeza de que o código malicioso foi removido e a vulnerabilidade corrigida é que vale usar o botão de solicitar revisão dentro desse relatório. A solicitação deve descrever com honestidade o que foi comprometido, como o invasor entrou, quando isso puder ser identificado, e quais medidas corrigiram o problema — troca de credenciais, atualização de software, remoção de contas não autorizadas. Uma revisão malfeita, pedida antes da limpeza estar completa, custa tempo duplo: o Google leva dias para reavaliar, e se encontrar qualquer sinal remanescente durante essa reavaliação, o problema aparece como ainda ativo.

• Descrever qual foi o vetor de entrada identificado, como um plugin desatualizado, uma senha comprometida ou um upload sem verificação de extensão.
• Listar as medidas de correção tomadas, não apenas a remoção das páginas visíveis.
• Confirmar que o conteúdo injetado foi checado em múltiplas páginas, não só nas URLs de exemplo listadas pelo Google.

Removendo as URLs de spam que já foram indexadas

Corrigir os arquivos no servidor não apaga automaticamente as páginas de spam que já estão indexadas — elas continuam aparecendo nos resultados até o Google rastrear de novo e confirmar que retornam erro. Dependendo de quantas páginas o script malicioso chegou a gerar, esse recadastramento natural pode demorar, e cada dia com spam visível nos resultados custa reputação e confiança de quem pesquisa pelo domínio.

Para a urgência imediata, a ferramenta de remoções do Search Console permite ocultar temporariamente URLs específicas — ou, o que é mais útil num ataque desse tipo, um prefixo de caminho inteiro — dos resultados de busca por cerca de seis meses, tempo suficiente para o sinal permanente, a própria página retornando 404 ou 410, se propagar pelo rastreamento normal. Quando o hack gerou milhares de URLs sob um padrão previsível, como tudo dentro de uma mesma subpasta de uploads, remover o prefixo de uma vez é bem mais prático do que enviar cada URL individualmente.

Depois da limpeza, enviar um sitemap atualizado, contendo só as páginas legítimas do site, ajuda o Google a priorizar o rastreamento do conteúdo real em vez de continuar tentando acessar as URLs fantasmas que ainda existem em links externos ou em cache.

O que monitorar depois da limpeza

O tráfego e os rankings voltando ao normal são um efeito da limpeza, não uma confirmação de que ela funcionou — o sinal real é o relatório de problemas de segurança ficando vazio depois da revisão aprovada. Vale continuar de olho nele por algumas semanas, porque um invasor que manteve acesso residual costuma reaparecer justamente quando a atenção diminui.

Monitoramento contínuo de integridade de arquivos, ou um scanner de malware que rode periodicamente, encurta a distância entre uma nova invasão e a sua detecção. E backups: manter uma cópia fora do mesmo servidor é importante, porque alguns ataques têm como alvo específico os backups guardados no próprio host, exatamente para impedir uma restauração rápida. Testar o processo de restauração antes de precisar dele é o tipo de tarefa que ninguém prioriza até o dia em que faz toda a diferença.