Site WordPress redireciona para outro site: encontrar o redirecionamento

Porque é que não vê o redirecionamento

Um redirecionamento colocado durante um ataque escolhe a quem se aplica. Poupa quase sempre a pessoa que gere o site, para ficar no lugar o máximo de tempo possível. As condições mais comuns:

• A origem: só os visitantes que chegam de um motor de pesquisa ou de uma rede social são redirecionados. O código lê o cabeçalho Referer do pedido.
• O dispositivo: só os telemóveis são redirecionados. O código lê o cabeçalho User-Agent.
• A sessão: um administrador com sessão iniciada no WordPress vê o site normal.
• A primeira visita: um cookie guarda o facto de o visitante já ter sido redirecionado, e a visita seguinte decorre normalmente. A avaria parece então intermitente.

Uma mensagem de um cliente a dizer «o seu site envia-me para outro lado» merece por isso toda a atenção, mesmo que tudo apareça corretamente do seu lado.

Reproduzir o redirecionamento

Coloque-se no lugar do visitante que o sofre:

1. Abra uma janela de navegação privada, pesquise o nome da sua empresa num motor de pesquisa e clique no seu resultado.
2. Repita a partir de um telemóvel, com dados móveis em vez de Wi-Fi.
3. Anote o endereço de destino, a hora e o dispositivo: estas três informações servem ao seu fornecedor de alojamento e, mais tarde, ao pedido de revisão junto do Google.

Se tiver acesso a um terminal, este comando pede a 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.o-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: está no .htaccess ou num ficheiro PHP. Um código 200 quando o navegador é redirecionado indica um redirecionamento feito dentro da página, em JavaScript: está quase sempre na base de dados ou num ficheiro do tema.

Antes de mexer no site: três gestos

1. Uma cópia completa tal como está. Ficheiros e base de dados, com data, guardados fora do servidor. Serve de prova, de ponto de comparação e de rede de segurança se uma limpeza retirar algo útil.
2. As palavras-passe, a partir de um dispositivo limpo. Área de cliente do alojamento, contas FTP ou SFTP, utilizador da base de dados (copie a nova para o wp-config.php, constante DB_PASSWORD) e cada conta de administrador 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 terminadas, incluindo a do intruso.

wp config shuffle-salts

Onde se esconde o redirecionamento

1. O ficheiro .htaccess

Na raiz do site, e por vezes numa subpasta, o .htaccess pode receber regras de reescrita acrescentadas pelo intruso. O bloco que o próprio WordPress escreve é curto e fica entre # BEGIN WordPress e # END WordPress:

# BEGIN WordPress
# As directivas (linhas) entre "BEGIN WordPress" e "END WordPress" são geradas
# dinamicamente e não deverão ser modificadas através de filtros do WordPress.
# Qualquer alteração às instruções entre estes marcadores será sobreposta.
<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 seus próprios blocos, identificados com o respetivo nome: compare cada bloco com a lista dos seus plugins antes de o retirar.

2. Os ficheiros PHP

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

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

O segundo comando abrange os plugins distribuídos pelo diretório do WordPress.org. Um plugin comprado ao respetivo editor compara-se com uma cópia nova descarregada a partir da sua conta junto dele. É um caso frequente: nos 540 sites WordPress de PME do nosso levantamento de 1 de setembro de 2026, 66 % têm pelo menos um plugin ausente do diretório público.

Sem WP-CLI, duas pesquisas dão uma primeira triagem:

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

A primeira lista os ficheiros PHP modificados nos últimos 30 dias, a segunda os ficheiros PHP guardados na pasta de multimédia, onde são suspeitos à partida (alguns plugins colocam lá um index.php vazio, o que é legítimo). Uma data de modificação pode ser falsificada: um ficheiro antigo no sítio errado continua a merecer exame.

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 lá estão carregam-se automaticamente e não se desativam a partir da administração. Os sinais a procurar: eval(, base64_decode(, gzinflate(, str_rot13(, longas cadeias ilegíveis, ou window.location seguido de um endereço que não conhece.

3. A base de dados

Um redirecionamento em JavaScript instala-se facilmente no conteúdo das páginas ou nas definições, onde nenhum ficheiro o mostra. O WP-CLI procura uma cadeia de caracteres em todas as tabelas do WordPress:

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

Sem WP-CLI, as mesmas pesquisas fazem-se no phpMyAdmin, separador 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ências, um aviso de cookies ou um widget colocado por si. O que não corresponde a nada do que instalou merece exame, em particular um script que constrói um endereço a partir de códigos de caracteres.

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

Em Opções > Geral, «Endereço do WordPress (URL)» e «Endereço do site (URL)» devem indicar o seu domínio. Os mesmos valores podem ser impostos no wp-config.php pelas constantes WP_HOME e WP_SITEURL: verifique os dois sítios.

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

Quando as constantes estão definidas, os dois primeiros comandos devolvem o valor delas. O último lista os administradores, com a data de registo; na administração, a mesma lista obtém-se no menu Utilizadores, filtrado por Administrador. Uma conta que ninguém reconhece elimina-se, atribuindo os seus conteúdos a uma conta legítima.

Retirar o redirecionamento, e depois o acesso que o colocou

Apagar a linha que redireciona acaba com o sintoma. O acesso usado pelo intruso, esse, continua aberto enquanto não for encontrado, e o redirecionamento volta nos dias seguintes. A ordem que resulta:

1. Substitua os ficheiros do núcleo por uma cópia nova: elimine as pastas wp-admin e wp-includes e execute wp core download --skip-content --force, que reescreve o núcleo sem tocar nos seus plugins, temas e multimédia. O comando substitui os ficheiros existentes mas não elimina nenhum ficheiro acrescentado: é por isso que as duas pastas se eliminam primeiro, e que os ficheiros PHP desconhecidos da raiz se retiram à mão.
2. Reinstale o tema e cada plugin a partir da sua fonte oficial, e elimine os que o site já não usa, desativados incluídos: os ficheiros deles continuam no servidor.
3. Retire os ficheiros PHP estranhos de wp-content/uploads, as regras acrescentadas ao .htaccess e os scripts encontrados na base de dados.
4. Verifique as tarefas agendadas com wp cron event list: uma tarefa com um nome desconhecido pode voltar a colocar o código.
5. Atualize o WordPress, o tema e os plugins.
6. Repita 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, encomendas), anote a hora a que constatou o ataque. Na União Europeia, o RGPD prevê a notificação de uma violação de dados pessoais à autoridade de controlo até 72 horas após ter tido conhecimento da mesma, a menos que a violação não seja suscetível de resultar num risco para os direitos e liberdades das pessoas singulares.

O Google, e o que os seus visitantes veem

Quando o Google deteta o redirecionamento, o Chrome pode mostrar uma página vermelha «Site perigoso» antes de abrir o site, e o Google pode indicar por baixo do seu resultado de pesquisa que o site pode ter sido pirateado. O relatório de problemas de segurança do Google Search Console diz o que foi detetado e em que endereços. Com o site limpo, o pedido de revisão, feito a partir desse mesmo relatório, lança a verificação.