Site WordPress redirecionando para outro site: encontre o redirecionamento

Por que você não vê o redirecionamento

Um redirecionamento instalado durante uma invasão escolhe a quem se aplica. Quase sempre ele poupa a pessoa que administra o site, para ficar no lugar pelo maior tempo possível. As condições mais comuns:

• A origem: só são redirecionados os visitantes que chegam de um buscador ou de uma rede social. O código lê o cabeçalho Referer da requisição.
• O dispositivo: só os celulares são redirecionados. O código lê o cabeçalho User-Agent.
• O login: um administrador conectado ao WordPress vê o site normal.
• A primeira visita: um cookie registra que o visitante já foi redirecionado, e a visita seguinte acontece normalmente. A falha parece então intermitente.

Uma mensagem de cliente que diz “seu site me manda para outro lugar” merece ser levada a sério, mesmo que tudo apareça corretamente para você.

Reproduzir o redirecionamento

Coloque-se na situação do visitante que é redirecionado:

1. Abra uma janela anônima, pesquise o nome de sua empresa em um buscador e clique em seu resultado.
2. Repita a partir de um celular, nos dados móveis e não no Wi-Fi.
3. Anote o endereço de destino, o horário e o dispositivo: essas três informações servem para a hospedagem e, mais tarde, para o pedido de revisão ao Google.

Se você tem acesso a um terminal, este comando pede sua página inicial apresentando-se como um iPhone vindo do Google:

curl -s -i -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://www.seu-site.com/

Leia as primeiras linhas da resposta. Um código 301 ou 302 seguido de uma linha Location: para um endereço desconhecido indica um redirecionamento feito pelo servidor: ele está no .htaccess ou em um arquivo PHP. Um código 200 enquanto o navegador é redirecionado indica um redirecionamento feito dentro da página, em JavaScript: quase sempre ele está no banco de dados ou em um arquivo do tema.

Antes de mexer no site: três passos

1. Uma cópia completa, como está. Arquivos e banco de dados, com data, guardados fora do servidor. Ela serve de prova, de ponto de comparação e de rede de segurança se uma limpeza remover algo útil.
2. As senhas, a partir de um dispositivo limpo. Painel do cliente da hospedagem, contas FTP ou SFTP, usuário do banco de dados (copie a nova senha no wp-config.php, constante DB_PASSWORD), depois cada conta de administrador do WordPress.
3. As chaves de segurança. Substitua as oito linhas de AUTH_KEY a NONCE_SALT do wp-config.php por um conjunto novo, gerado em https://api.wordpress.org/secret-key/1.1/salt/. Todas as sessões abertas são encerradas, inclusive a do invasor.

wp config shuffle-salts

Onde o redirecionamento se esconde

1. O arquivo .htaccess

Na raiz do site, e às vezes em uma subpasta, o .htaccess pode receber regras de reescrita adicionadas pelo invasor. O bloco que o próprio WordPress escreve é curto, delimitado por # BEGIN WordPress e # END WordPress:

# BEGIN WordPress
# As diretrizes (linhas) entre "BEGIN WordPress" e "END WordPress" são
# geradas dinamicamente e só devem ser modificadas através de filtros do WordPress.
# Quaisquer alterações nas diretivas entre esses marcadores serão sobrescritas.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Uma regra RewriteCond que testa %{HTTP_REFERER} (google, bing, facebook) ou %{HTTP_USER_AGENT} (android, iphone, mobile), seguida de uma RewriteRule para um endereço externo, é o redirecionamento. Os plugins de cache e de segurança também escrevem os próprios blocos, marcados com o nome deles: compare cada bloco com a lista de seus plugins antes de removê-lo.

2. Os arquivos PHP

O WP-CLI compara os arquivos do núcleo do WordPress e dos plugins com as somas de verificação publicadas pelo WordPress.org, e lista cada arquivo modificado ou adicionado:

wp core verify-checksums
wp plugin verify-checksums --all

O segundo comando cobre os plugins distribuídos pelo diretório de plugins do WordPress.org. Um plugin comprado de um desenvolvedor se compara com uma cópia nova, baixada de sua conta no site dele. É um caso frequente: entre os 540 sites WordPress de PMEs de nosso levantamento de 1º de setembro de 2026, 66 % carregam ao menos um plugin ausente do repositório público.

Sem o WP-CLI, duas buscas fazem uma primeira triagem:

find . -name "*.php" -mtime -30
find wp-content/uploads -name "*.php"

A primeira lista os arquivos PHP modificados nos últimos 30 dias, a segunda os arquivos PHP guardados na pasta de mídia, onde são suspeitos por padrão (alguns plugins colocam ali um index.php vazio, que é legítimo). Uma data de modificação pode ser falsificada: um arquivo antigo continua merecendo exame se estiver no lugar errado.

Abra primeiro o wp-config.php, o index.php da raiz, o functions.php e o header.php do tema ativo, e a pasta wp-content/mu-plugins: os plugins que ficam ali são carregados automaticamente e não podem ser desativados pelo painel. Os sinais a procurar: eval(, base64_decode(, gzinflate(, str_rot13(, longas sequências ilegíveis, ou window.location seguido de um endereço que você não conhece.

3. O banco de dados

Um redirecionamento em JavaScript costuma ser inserido no conteúdo das páginas ou nas configurações, onde nenhum arquivo o mostra. O WP-CLI procura um trecho de texto em todas as tabelas do WordPress:

wp db search "<script"
wp db search "fromCharCode"

Sem o WP-CLI, as mesmas buscas são feitas no phpMyAdmin, na aba SQL:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Alguns resultados são legítimos: uma ferramenta de medição de audiência, um aviso de cookies ou um widget que você instalou. O que não corresponde a nada do que você instalou merece exame, em particular um script que monta um endereço a partir de códigos de caracteres.

4. As configurações de endereço e as contas

Em Configurações > Geral, “Endereço do WordPress (URL)” e “Endereço do site (URL)” devem mostrar seu domínio. Os mesmos valores podem ser impostos no wp-config.php pelas constantes WP_HOME e WP_SITEURL: verifique os dois lugares.

wp option get home
wp option get siteurl
wp user list --role=administrator

Quando as constantes estão definidas, os dois primeiros comandos retornam o valor delas. O último lista os administradores, com a data de cadastro; no painel, a mesma lista aparece no menu Usuários, filtrada pela função Administrador. Uma conta que ninguém reconhece deve ser excluída, atribuindo o conteúdo dela a uma conta legítima.

Remover o redirecionamento, e depois o acesso que o instalou

Apagar a linha que redireciona interrompe o sintoma. O acesso usado pelo invasor continua aberto enquanto não for encontrado, e o redirecionamento volta nos dias seguintes. A ordem que funciona:

1. Substitua os arquivos do núcleo por uma cópia nova: exclua as pastas wp-admin e wp-includes, depois execute wp core download --skip-content --force, que reescreve o núcleo sem tocar em seus plugins, temas e mídias. O comando sobrescreve os arquivos existentes, mas não exclui nenhum arquivo adicionado: por isso as duas pastas são excluídas antes, e os arquivos PHP desconhecidos da raiz são removidos à mão.
2. Reinstale o tema e cada plugin a partir da fonte oficial, e exclua os que o site não usa mais, inclusive os desativados: os arquivos deles continuam no servidor.
3. Remova os arquivos PHP estranhos de wp-content/uploads, as regras adicionadas ao .htaccess e os scripts encontrados no banco de dados.
4. Verifique as tarefas agendadas com wp cron event list: uma tarefa com nome desconhecido pode recolocar o código.
5. Atualize o WordPress, o tema e os plugins.
6. Refaça os testes do início, a partir de vários dispositivos e durante vários dias.

Se o site guarda dados pessoais (formulários, contas de clientes, pedidos), anote a data e o horário em que você constatou a invasão. A LGPD e o regulamento de comunicação de incidentes de segurança da ANPD preveem comunicar à ANPD e aos titulares, no prazo de três dias úteis, um incidente de segurança que possa acarretar risco ou dano relevante aos titulares dos dados.

O Google, e o que seus visitantes veem

Quando o Google detecta o redirecionamento, o Chrome pode exibir uma página vermelha “Site perigoso” antes de abrir o site, e o Google pode escrever sob seu resultado “Este site pode ter sido invadido”. O relatório Problemas de segurança do Google Search Console diz o que foi detectado e em quais endereços. Com o site limpo, o botão Solicitar revisão inicia a verificação.