Site hackeadoComo saber, o que fazer nas primeiras 24 horas e como impedir que aconteça de novo.
Spam em japonês no Google, visitantes mandados para outro site, usuário administrador que você não criou. Este guia mostra como confirmar a invasão, conter o dano, limpar o WordPress com método e montar uma defesa em camadas.
O que fazer quando o site WordPress é hackeado?
Primeiro conter (modo de manutenção e troca de credenciais), depois preservar provas (cópia do estado atual e logs), limpar ou restaurar com verificação de integridade, corrigir a causa (atualizações, dois fatores, permissões) e, por fim, avisar quem precisa: Google (revisão no Search Console), hospedagem e, se houver dados pessoais em risco, clientes e a ANPD conforme a LGPD.
Seu site foi invadido. E agora?
A maioria das invasões não derruba o site: ela o usa. Por isso muita gente demora semanas para perceber.
Um site hackeado raramente aparece com uma tela preta e uma caveira. O cenário mais comum é discreto: o site continua no ar, mas passou a servir a interesses de outra pessoa. Páginas de spam hospedadas no seu domínio, redirecionamentos para sites suspeitos que só aparecem para quem veio do Google, formulários que roubam dados, ou um programa que usa o processamento do seu servidor. O dono do site, olhando a home, não vê nada de errado.
As consequências, porém, são reais: o Google pode marcar o site como inseguro, a hospedagem pode suspendê-lo, os e-mails da empresa passam a cair em spam, clientes perdem a confiança e, se o site guarda dados pessoais, pode haver obrigação legal de comunicar o incidente. Quanto mais tempo a invasão fica ativa, maior o custo da limpeza e da recuperação da reputação.
A boa notícia é que a imensa maioria dos casos em sites WordPress tem causas conhecidas e caminhos de resolução bem definidos. Este guia segue a ordem em que você vai precisar: confirmar, conter, limpar, avisar quem precisa saber e, só então, blindar.
Páginas que você não criou
Milhares de URLs com produtos, cassino ou textos em outro idioma, às vezes visíveis só para o Google. Derrubam a reputação do domínio.
Visitante enviado para outro site
Acontece só em certos dispositivos, origens (vindo do Google) ou horários, justamente para o dono não perceber.
Porta dos fundos escondida
Um arquivo ou usuário que permite voltar mesmo depois da limpeza. É o motivo de muita reinfecção.
Página falsa dentro do seu domínio
Cópias de páginas de bancos ou serviços, usando a boa reputação do seu site para enganar terceiros.
Código que ataca visitantes
Scripts injetados que tentam explorar o navegador ou forçar downloads. Costumam provocar o aviso de site perigoso.
Seu servidor trabalhando para outros
Envio de spam em massa, mineração de criptomoedas ou ataques a terceiros. Aparece como lentidão e alertas da hospedagem.
Teste: seu site mostra sinais de invasão?
Marque o que você já observou. A ferramenta pesa os sinais e sugere o próximo passo. Ela não substitui uma análise técnica, mas ajuda a decidir se é hora de agir.
Como uma invasão acontece, em seis passos
Entender o caminho mostra onde cada defesa age. Clique em uma etapa ou deixe a animação rodar.
Na maior parte dos casos não há um hacker mirando a sua empresa. Há robôs que varrem a internet atrás de sites com falhas conhecidas, testam milhares de endereços por hora e atacam automaticamente o que encontram. Por isso a frase “meu site é pequeno, ninguém vai atacar” não protege: o alvo é a falha, não o dono.
Clique em uma etapa para ver a defesa que a interrompe.
As portas de entrada mais frequentes
| Porta de entrada | Como é explorada | Defesa principal |
|---|---|---|
| Plugins e temas desatualizados | Falhas públicas são varridas por robôs poucas horas depois de divulgadas. | Atualizar com frequência e remover o que não usa. |
| Plugins e temas “nulled” (piratas) | Versões gratuitas de produtos pagos costumam vir com código malicioso embutido. | Nunca instalar fora do repositório oficial ou do fornecedor. |
| Senhas fracas ou reutilizadas | Listas de senhas vazadas em outros serviços são testadas no seu login. | Senha única e longa, gerenciador de senhas e dois fatores. |
| Contas esquecidas | Ex-colaboradores, agências antigas e freelancers com acesso ativo. | Revisar usuários e acessos a cada trimestre. |
| Hospedagem mal isolada | Um site vizinho infectado no mesmo servidor contamina os demais. | Hospedagem com isolamento por conta e atualizações do servidor. |
| Permissões de arquivos | Pastas graváveis por qualquer processo permitem enviar arquivos maliciosos. | Permissões corretas e bloqueio de execução de PHP em uploads. |
O plano das primeiras 24 horas
Na pressa é fácil piorar. A ordem importa: primeiro conter, depois entender, depois limpar.
Pare o dano e ganhe tempo
Guarde provas antes de mexer
Remova o problema e a porta de entrada
Volte ao ar com vigilância reforçada
Limpar, restaurar um backup ou reconstruir?
Cada caminho tem custo, risco e velocidade diferentes. Responda e veja a recomendação.
Restaurar um backup é o caminho mais rápido quando existe uma cópia anterior à invasão. O risco: se a causa não for corrigida (plugin desatualizado, senha vazada), a reinfecção costuma ocorrer em horas. Restaurar sem atualizar e sem trocar credenciais é o erro mais comum.
Limpar manualmente preserva o que está no ar, mas exige conhecimento e tempo: é preciso achar todos os arquivos, entradas de banco de dados e contas criadas pelo invasor. Qualquer resíduo (um único backdoor) basta para voltar.
Reconstruir em ambiente limpo é a opção mais segura em casos graves: instala-se um WordPress novo, plugins a partir das fontes oficiais e migra-se apenas o conteúdo (textos, imagens, produtos, pedidos), revisado.
Como limpar um WordPress infectado, com método
Roteiro técnico para quem tem acesso ao servidor. Faça sempre uma cópia completa do estado atual antes de qualquer alteração.
Isole e faça cópia do estado atual
Coloque o site em modo de manutenção ou bloqueie o acesso público. Copie arquivos e banco como estão: isso serve para investigação e para recuperar conteúdo legítimo.
Troque todas as credenciais
Senhas do painel da hospedagem, FTP/SFTP, SSH, banco de dados, e-mail do administrador e de todos os usuários. Gere novas chaves e salts no
wp-config.php.Reinstale o núcleo do WordPress
Substitua os arquivos do core por uma cópia limpa, preservando
wp-config.phpewp-content. Depois verifique a integridade (comandos abaixo).Reinstale plugins e temas a partir da fonte oficial
Apague e instale de novo a partir do repositório oficial ou do fornecedor. Remova o que não usa. Plugins piratas não voltam.
Inspecione
wp-contente uploadsProcure arquivos
.phpemuploads, arquivos modificados recentemente e nomes estranhos. Em uploads, não deveria existir PHP.Revise usuários e banco de dados
Remova administradores desconhecidos, verifique
siteurlehome, tarefas agendadas (cron) e trechos de script injetados em posts e opções.Corrija a causa
Atualize tudo, ative dois fatores, corrija permissões e aplique as medidas da seção 08. Sem isso, a infecção volta.
Vigie por 30 dias
Monitore alterações de arquivos, novos usuários, acessos ao login e o relatório de segurança do Search Console.
# núcleo: compara os arquivos com os oficiais wp core verify-checksums # plugins do repositório oficial wp plugin verify-checksums --all # administradores cadastrados wp user list --role=administrator --fields=ID,user_login,user_email,user_registered # arquivos PHP dentro de uploads (não deveria haver nenhum) find wp-content/uploads -type f -name "*.php" # arquivos alterados nos últimos 7 dias find . -type f -mtime -7 -not -path "./wp-content/cache/*" # endereço do site gravado no banco wp option get siteurl && wp option get home
Atenção: Se você não tem acesso a SSH, peça à hospedagem as mesmas verificações ou contrate uma limpeza profissional. Mexer sem método em um site infectado costuma deixar resíduos.
Google, clientes e a lei: quem avisar e quando
Limpar o site é metade do trabalho. A outra metade é restaurar a confiança.
Search Console
Se houver alerta em Problemas de segurança, depois de limpar peça a revisão. Páginas de spam que não devem existir mais devem retornar 410 ou 404 e sair do sitemap.
Suporte do servidor
Informe o incidente, peça logs de acesso e confirme se outros sites da mesma conta foram afetados. Em suspensão, envie evidência da limpeza.
Comunicação transparente
Se dados podem ter sido expostos, explique o que aconteceu, o que foi feito e o que o cliente deve fazer (trocar senha, atenção a golpes).
LGPD, art. 48
Quando o incidente puder causar risco ou dano relevante aos titulares, o controlador deve comunicar a ANPD e os titulares. Consulte um profissional para avaliar o seu caso.
Dois cuidados ao se comunicar: não minimize o que não sabe e não afirme o que ainda não confirmou. Uma mensagem curta e honesta (“detectamos acesso indevido em tal data, já contivemos, estamos revisando o impacto”) costuma preservar mais confiança do que o silêncio ou uma explicação excessivamente técnica.
Para o lado do posicionamento no Google, vale reler o guia sobre quando o site não aparece no Google e, se houve mudança de endereços durante a recuperação, o de migração com redirecionamentos 301.
Diagnóstico de defesa: onde o seu site está mais frágil?
Dê uma nota de 0 a 10 para cada camada. O radar mostra o desequilíbrio e a lista abaixo dele, o que fazer primeiro.
Backup que salva: a regra 3-2-1 e o teste de restauração
Backup é o seguro que ninguém lembra de testar. A pergunta certa não é “tenho backup?”, e sim “em quanto tempo e com que perda eu volto?”.
A regra 3-2-1 é simples: 3 cópias dos dados (a original e duas de backup), em 2 tipos de mídia ou serviços diferentes, com 1 cópia fora do servidor (em outra nuvem). Se o backup mora na mesma hospedagem do site, uma invasão ou falha do servidor leva os dois embora.
Dois números definem a sua proteção: o intervalo do backup (quanto de dados você aceita perder) e o tempo de restauração (quanto tempo o site pode ficar fora). Em lojas virtuais, cada hora sem backup é um conjunto de pedidos que pode desaparecer.
Sobre a restauração: ela deve ser testada ao menos uma vez por trimestre, em um ambiente de teste. Um backup que nunca foi restaurado é uma hipótese, não uma garantia.
Cálculo didático e simplificado: pior caso de dados perdidos entre dois backups, mais a receita parada durante a restauração.
Checklist de blindagem do WordPress
Quinze medidas que cobrem a grande maioria dos riscos. Marque o que já está feito e veja o seu avanço.
Nenhuma medida isolada protege tudo. A segurança vem da soma de camadas: se uma falha, a seguinte reduz o estrago. Se você precisa priorizar, comece pelas quatro que mais impedem invasões comuns: atualizações, dois fatores, backup externo testado e remoção do que não é usado.
Plugins de segurança ajudam (firewall de aplicação, varredura, bloqueio de tentativas de login), mas funcionam como complemento, não como substituto de manutenção. Um site desatualizado com plugin de segurança continua desatualizado.
- Limite os administradores: poucos e nominais. Prefira perfis com a menor permissão necessária.
- Use dois fatores para todos os usuários que publicam ou administram.
- Apague o que não usa: temas, plugins e usuários inativos aumentam a superfície de ataque.
- Não edite arquivos pelo painel:
DISALLOW_FILE_EDITdesativa o editor de código do WordPress.
Cinco ideias que deixam o site vulnerável
A segurança falha mais por hábito do que por tecnologia.
“Meu site é pequeno, ninguém ataca”
Os ataques são automatizados e buscam falhas, não empresas. Sites pequenos e abandonados são alvos fáceis.
“Plugin de segurança resolve”
Ele ajuda, mas não corrige plugin desatualizado, senha fraca ou conta esquecida. É camada, não solução.
Restaurar sem corrigir a causa
O backup traz de volta o mesmo código vulnerável. Atualize e troque credenciais antes de voltar ao ar.
Trocar só a senha do admin
Backdoors, usuários extras e credenciais de FTP e banco continuam valendo. A troca precisa ser completa.
Confiar em plugins “nulled”
O que parece economia costuma vir com código malicioso. O custo aparece depois, na limpeza e na reputação.
Nunca testar o backup
Descobrir que o backup está corrompido durante a emergência é o pior cenário possível.
Em resumo: confirmar, conter, limpar, avisar, blindar
Uma invasão é um evento ruim, mas administrável quando existe método e um ambiente preparado.
Se o seu site tem pedidos, cadastros ou formulários com dados de clientes, se há reincidência depois de uma limpeza, ou se você não tem acesso ao servidor, chame um profissional. O custo de uma análise técnica costuma ser muito menor do que o de uma reinfecção, uma suspensão de hospedagem ou a perda de confiança de clientes.
Se o seu projeto envolve migração de plataforma por causa de uma invasão grave, vale comparar as opções no guia sobre WordPress, Shopify, Wix ou código, e, ao reconstruir, preparar também a hospedagem e o e-mail conforme o guia de domínio, DNS e autenticação de e-mail.
A regra de ouro: segurança é rotina, não projeto. Uma hora por mês de manutenção (atualizar, revisar usuários, conferir backup) vale mais do que qualquer ferramenta sofisticada instalada uma vez e esquecida.
Como este guia foi feito
Conteúdo escrito pela equipe da Criação de Sites São Paulo, com base na documentação oficial listada ao lado e na nossa experiência em projetos de sites, lojas virtuais e presença digital. Última revisão em 14 de outubro de 2026.
As simulações e os números de exemplo são didáticos: troque pelos valores da sua operação. Informações técnicas, legais e de plataformas mudam; confirme na fonte oficial e, quando for o caso, com um profissional habilitado.
Quer aplicar isso no seu projeto? Você pode pedir uma revisão de segurança e manutenção do seu site.
Perguntas frequentes
Perguntas que surgem quando o site dá sinais de invasão.
Como saber se meu site WordPress foi hackeado?
Os sinais mais fortes são alerta de site perigoso no navegador ou no Search Console, páginas desconhecidas nos resultados do Google, redirecionamentos para outros sites, usuários administradores que você não criou e aviso de malware da hospedagem. Use o teste da seção 02 como apoio.
Posso limpar sozinho ou preciso de um especialista?
Se você tem acesso ao servidor e segue um roteiro com verificação de integridade, é possível. Se o site guarda dados de clientes, há reincidência ou você não tem acesso técnico, o melhor é contratar uma análise profissional.
Restaurar um backup resolve?
Só se o backup for anterior à invasão e você corrigir a causa antes de voltar ao ar. Caso contrário, a reinfecção costuma acontecer em horas.
O Google pune sites hackeados?
O Google pode sinalizar o site como inseguro e reduzir a visibilidade das páginas afetadas até a limpeza. Depois de limpar, é possível solicitar uma revisão pelo Search Console.
Preciso comunicar clientes e a ANPD?
Se o incidente puder causar risco ou dano relevante aos titulares de dados, a LGPD (art. 48) prevê a comunicação à ANPD e aos titulares. A avaliação do caso deve ser feita com apoio jurídico.
Plugin de segurança basta para evitar invasões?
Ele ajuda como camada extra (firewall, varredura, bloqueio de tentativas), mas não substitui atualizações, senhas fortes, dois fatores, backup externo e remoção do que não é usado.
Com que frequência devo fazer backup?
Depende de quanto conteúdo novo o site recebe. Em loja virtual com pedidos diários, backups a cada poucas horas são comuns. A calculadora da seção 09 ajuda a estimar a perda.
Plugins pagos “gratuitos” de sites piratas são seguros?
Não. Versões “nulled” frequentemente trazem código malicioso. Instale apenas do repositório oficial ou do fornecedor.
Leia também
Outros guias práticos da Criação de Sites São Paulo para quem quer decidir melhor.
Quer um site com segurança tratada como rotina?
Cuidamos de atualização, backup externo, monitoramento e resposta a incidentes para que o seu site fique no ar e protegido.
