WordPress redirecionando para outro site: causas e como corrigir

Seu WordPress redireciona para cassino, farmácia ou golpe? Veja por que acontece, por que só no celular ou vindo do Google, e como achar e corrigir.

Se o seu site WordPress está redirecionando para outro site (cassino, farmácia, "você ganhou um prêmio", falso antivírus), ele foi invadido. Não é bug, não é plugin com defeito e não é problema da hospedagem. Alguém colocou código no seu site que manda parte dos visitantes para um destino pago pelo invasor. O conserto é achar esse código, que costuma ficar em um destes cinco lugares: .htaccess, wp-config.php ou arquivos do núcleo, opções siteurl/home no banco, scripts injetados em posts e widgets, ou um plugin/tema adulterado. E depois fechar a porta por onde ele entrou.

Antes de começar a caçar, faça o básico de contenção: backup completo (mesmo infectado), troca de senhas e, se o redirecionamento atinge todo mundo, modo de manutenção. Isso está detalhado em site WordPress invadido: o que fazer nas primeiras horas.

Por que o redirecionamento "só acontece às vezes"

Esse é o detalhe que mais confunde. Você abre o site no computador, está tudo normal; um cliente reclama que caiu num site de apostas. Isso é proposital. O código malicioso costuma ser condicional:

• Só no celular. O script lê o user agent do navegador e só redireciona se for Android ou iPhone.
• Só vindo do Google. Ele verifica o cabeçalho referer: quem digitou o endereço direto vê o site normal, quem clicou num resultado de busca é desviado.
• Só para quem não está logado. Se existe o cookie de login do WordPress, o código fica quieto. Ou seja: o administrador nunca vê.
• Só uma vez por visitante ou por IP. Depois do primeiro redirecionamento, ele grava um cookie e não repete, para dificultar a reprodução.
• Só em alguns horários ou países.

Tudo isso existe para a invasão durar mais. Então, para testar, você precisa se passar pela vítima.

Como reproduzir o problema

Use uma janela anônima (sem login), de preferência no celular e na rede móvel, e entre no site a partir de uma busca no Google. No computador, dá para simular com curl:

# Simula um celular vindo do Google e mostra os cabeçalhos de resposta
curl -sI "https://seusite.com.br/" \
  -A "Mozilla/5.0 (Linux; Android 14) AppleWebKit/537.36 Chrome/130.0 Mobile Safari/537.36" \
  -e "https://www.google.com/"

Se a resposta vier com 301 ou 302 e um Location: apontando para um domínio estranho, o redirecionamento acontece no servidor (.htaccess ou PHP). Se a resposta for 200 normal, o redirecionamento provavelmente é feito por JavaScript no navegador, e você precisa olhar o HTML:

curl -s "https://seusite.com.br/" -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
  -e "https://www.google.com/" | grep -iE "<script[^>]+src=|window\.location|eval\(|atob\(|fromCharCode"

Essa distinção já corta a busca pela metade.

Onde o código malicioso costuma ficar

1. Arquivo .htaccess

Em servidores Apache e LiteSpeed (a maioria das hospedagens compartilhadas no Brasil), o .htaccess é o lugar favorito para redirecionamento condicional. Procure regras como estas:

RewriteCond %{HTTP_REFERER} (google|bing|yahoo|facebook) [NC]
RewriteCond %{HTTP_USER_AGENT} (android|iphone|mobile) [NC]
RewriteRule ^(.*)$ https://dominio-estranho.xyz/ [R=302,L]

O .htaccess padrão do WordPress é curto: o bloco entre # BEGIN WordPress e # END WordPress, mais o que plugins de cache ou segurança acrescentam. Qualquer RewriteRule apontando para fora do seu domínio é suspeita. E não olhe só a raiz: invasores espalham .htaccess em wp-content, wp-includes e uploads. Para listar todos:

find /caminho/do/site -name ".htaccess" -exec ls -la {} \;

Arquivos começados por ponto ficam ocultos no gerenciador de arquivos e no FTP por padrão. Ative "mostrar arquivos ocultos".

2. wp-config.php, index.php e arquivos do núcleo

Outro truque é colar uma linha no começo do wp-config.php, do index.php ou de um arquivo de wp-includes, quase sempre ofuscada: eval(base64_decode(...)), @include de um arquivo com nome aleatório, ou uma sequência de \x e chr(). Para os arquivos do núcleo, o WP-CLI compara tudo com as somas de verificação oficiais:

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

O primeiro comando aponta arquivos do núcleo alterados e arquivos que não deveriam existir. O segundo faz o mesmo para plugins do diretório oficial (plugins pagos não são verificados). O wp-config.php não entra nessa checagem, então abra e leia ele inteiro.

3. Banco de dados: siteurl, home e outras opções

Se o site inteiro, inclusive o painel, joga você para outro domínio, olhe primeiro as opções siteurl e home:

wp option get siteurl
wp option get home

Sem WP-CLI, no phpMyAdmin (troque wp_ pelo seu prefixo):

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Se estiverem erradas, corrija com wp option update siteurl "https://seusite.com.br" (e o mesmo para home). Mas desconfie: se o invasor mexeu ali, mexeu em outras coisas também. Vale procurar scripts em qualquer opção:

SELECT option_name, LEFT(option_value, 200) FROM wp_options
WHERE option_value LIKE '%<script%' OR option_value LIKE '%eval(%';

4. Scripts injetados em posts, páginas e widgets

Ataques automatizados a plugins vulneráveis muitas vezes injetam um <script src="https://..."> no fim de todos os posts, ou em widgets de HTML personalizado. O WP-CLI busca no banco inteiro:

wp db search "<script" --all-tables --stats
wp db search "eval(" --all-tables

Depois, revise os resultados em wp_posts (campo post_content), wp_postmeta e wp_options. Cuidado: códigos legítimos (Google Analytics, pixel do Meta, chat) também são scripts. O que você procura é domínio que você não reconhece ou código ofuscado.

Atenção: não faça search-replace em massa sem backup e sem saber exatamente o que vai substituir. Um padrão mal escrito pode corromper dados serializados e quebrar o site.

5. Plugins e temas adulterados

Se um plugin desatualizado foi a porta de entrada, o próprio arquivo dele pode ter sido modificado. E plugins ou temas piratas muitas vezes já vêm com o código de redirecionamento ou com um backdoor (falamos disso em plugins e temas nulled: os riscos reais). Liste o que está instalado e compare:

wp plugin list --fields=name,status,version,update
wp theme list

Plugins que você não instalou, com nomes genéricos ("wp-security-helper", "core-stats") ou sem autor, são candidatos fortes. Também existem os chamados must-use plugins, em wp-content/mu-plugins, que rodam sempre e não aparecem na lista comum de plugins. Confira essa pasta.

Resumo: sintoma x onde procurar

Como corrigir de verdade (e não só por uma semana)

Achar e apagar o redirecionamento é a parte fácil. O motivo pelo qual tanta gente vê o problema voltar é que o invasor quase sempre deixa backdoors: arquivos PHP escondidos que permitem reinstalar o redirecionamento quando quiser. A correção completa é:

1. Backup do estado infectado, guardado fora do servidor e identificado como tal.

2. Reinstalar o núcleo a partir da fonte oficial (wp core download --force --skip-content), sem tocar em wp-content.

3. Reinstalar todos os plugins e temas de fontes oficiais, na versão mais recente. Remover o que não usa.

4. Caçar PHP onde não deveria haver PHP, principalmente em wp-content/uploads:

   find wp-content/uploads -type f -name "*.php"
   

5. Limpar o banco: opções, posts, widgets e usuários administradores desconhecidos.

6. Revisar tarefas agendadas do WordPress (wp cron event list) e o cron da hospedagem.

7. Trocar todas as senhas e regenerar os salts (wp config shuffle-salts).

8. Corrigir a porta de entrada: plugin vulnerável, tema pirata, senha fraca ou vazada.

9. Limpar caches (plugin de cache, CDN, Cloudflare) e testar de novo como visitante de celular vindo do Google.

O passo a passo detalhado da limpeza está em como remover malware e backdoors do WordPress.

E o Google?

Redirecionamento para golpe é exatamente o tipo de coisa que faz o Google exibir o aviso vermelho de "site enganoso" ou "site perigoso". Mesmo sem aviso, o Google pode ter indexado páginas de spam criadas pelo invasor. Depois de limpar:

• confira o relatório Problemas de segurança no Google Search Console;
• procure páginas estranhas com site:seusite.com.br na busca;
• se houver aviso, peça revisão só depois de terminar a limpeza.

Se o aviso já está no ar, siga como remover o aviso de site perigoso do Google.

Checklist rápido

• Backup completo feito antes de mexer
• Redirecionamento reproduzido (celular, anônimo, vindo do Google)
• Todos os .htaccess revisados, não só o da raiz
• wp core verify-checksums sem alertas
• siteurl e home corretos
• Banco sem scripts desconhecidos
• Nenhum .php em uploads
• Plugins e temas reinstalados de fonte oficial
• Senhas trocadas, salts regenerados, admins revisados
• Porta de entrada identificada e corrigida
• Caches limpos e teste final feito

Se preferir que alguém resolva

Com acesso SSH, WP-CLI e paciência, dá para seguir este guia sozinho. Redirecionamento condicional é chato justamente porque se esconde, e o que mais dá trabalho não é apagar a regra no .htaccess, é achar o backdoor que a recoloca.

Se quiser delegar, a Mobgeek faz a limpeza de site WordPress invadido a partir de R$ 790, com início em até 24h e 30 dias de garantia contra reinfecção, incluindo relatório do que foi encontrado e pedido de revisão ao Google quando necessário. Se fizer sentido, conte o seu caso no orçamento.