Seu WordPress abre normalmente quando você digita o endereço, mas leva o visitante para outro site quando ele vem do Google? O teste precisa reproduzir essa diferença. Regras no servidor e códigos inseridos no WordPress podem escolher quem será redirecionado pelo endereço de origem, pelo dispositivo ou por um cookie.
Para corrigir, descubra primeiro quem manda o navegador trocar de endereço. Abaixo você vai testar a resposta HTTP, abrir os campos home e siteurl no banco e procurar regras no .htaccess, no tema e em plugins que ficam fora da lista comum do painel.
Se o destino é desconhecido, não informe sua senha ali. Use o painel da hospedagem ou SFTP para examinar a instalação e guarde uma cópia privada dos arquivos, do banco e dos logs antes de editar.
Como testar o redirecionamento com curl
O curl permite ler o status HTTP e o cabeçalho Location, que informa o destino de um redirecionamento enviado pelo servidor. Ele não executa o JavaScript da página.
No terminal do Windows, use curl.exe. No macOS ou Linux, use curl. Comece sem seguir o destino:
curl.exe -sS -I --max-time 20 "https://seu-dominio.example/"Troque o endereço pelo seu site. Se aparecer um status como 301 ou 302 com Location apontando para um domínio desconhecido, o servidor já está enviando a troca. Não acrescente a opção de seguir a cadeia antes de ler esse destino.
Como visualizar a cadeia de redirecionamentos
Para acompanhar uma cadeia entre endereços conhecidos, use -L. O exemplo abaixo consulta a versão HTTP deste domínio:
curl.exe -sS -I -L --max-redirs 5 --max-time 20 "http://juanmoura.com/"Os trechos da resposta mostram a passagem para HTTPS e a página final:
HTTP/1.1 301 Moved Permanently
Location: https://juanmoura.com/
HTTP/1.1 200 OKNesse caso, a mudança conserva o domínio e entrega a página em HTTPS. Num site afetado, leia cada Location para encontrar onde a cadeia sai do endereço esperado. O limite de cinco saltos encerra o teste se o servidor continuar redirecionando.
Alguns servidores respondem de forma diferente a HEAD, usado por -I, e a GET, usado para carregar a página. Para consultar com GET e mostrar apenas os cabeçalhos no Windows:
curl.exe -sS -D - -o NUL --max-time 20 "https://seu-dominio.example/"No macOS ou Linux, troque NUL por /dev/null. Essa consulta descarta o HTML recebido e também não executa scripts. As opções do curl permitem ajustar os testes sem abrir o destino no navegador.
Quando só acontece para quem vem do Google
Compare a mesma URL com e sem o cabeçalho Referer. Este comando informa uma origem do Google:
curl.exe -sS -I --max-time 20 -e "https://www.google.com/" "https://seu-dominio.example/pagina-afetada/"Se o destino muda nesse teste, procure condições ligadas à origem no servidor e no código. Se as duas respostas estão normais, repita com GET e examine o navegador: o redirecionamento pode depender de JavaScript, de um cookie ou de outra condição que ainda não foi reproduzida.
Uma janela privada e um teste no celular ajudam a reproduzir o acesso público. Mantenha anotados a URL inicial, o destino e a condição que acionou a mudança. Depois da limpeza, você vai repetir esse mesmo caminho.
Confira home e siteurl no banco de dados
home guarda o endereço público do site; siteurl, o local dos arquivos do WordPress. Se foram alterados para outro domínio, corrija os valores correspondentes à instalação.
Com o painel acessível, abra Configurações > Geral e leia Endereço do WordPress e Endereço do site.
Sem conseguir entrar, abra o phpMyAdmin pela hospedagem e escolha o banco indicado em DB_NAME, no wp-config.php. Localize a tabela que termina em _options. O prefixo correto aparece em $table_prefix no mesmo arquivo.
Na aba SQL, esta consulta apenas lê os dois campos. Substitua wp_options pelo nome da tabela da sua instalação:
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('home', 'siteurl');Para corrigir, abra as linhas correspondentes na tabela, clique em Editar e salve cada option_value com a URL correta, incluindo HTTPS quando configurado. Preserve uma cópia dos valores anteriores. Se o WordPress fica em uma subpasta e o site abre na raiz, os campos podem ser diferentes; não iguale os dois automaticamente.
Confira ainda se WP_HOME ou WP_SITEURL estão definidos no wp-config.php. Essas constantes podem impor valores diferentes dos gravados no banco. Corrija uma definição indevida existente em vez de acrescentar outra por cima.
Depois de salvar, abra o login no domínio esperado. Se o endereço volta a mudar no banco, algum código ou acesso continua fazendo a alteração. A configuração correta e os caminhos de subpasta estão descritos na alteração de endereço do WordPress.
Procure regras condicionais no .htaccess e no servidor
Em servidores que usam .htaccess, baixe uma cópia privada e abra o arquivo como texto. Examine a pasta da instalação e as pastas superiores que também alcançam o site. Ative a exibição de arquivos ocultos no gerenciador ou no SFTP.
Procure por Redirect, RewriteRule, HTTP_REFERER, HTTP_USER_AGENT e pelo domínio de destino. Uma regra condicionada à origem pode ter esta forma:
# Exemplo para reconhecer na leitura; nao adicione esta regra.
RewriteCond %{HTTP_REFERER} google\. [NC]
RewriteRule ^ https://destino-invalido.example/ [R=302,L]O domínio reservado no exemplo serve apenas para mostrar onde estaria o destino. Num arquivo comprometido, a condição e a regra precisam ser lidas juntas: apagar somente o endereço pode deixar uma instrução incompleta.
Compare o bloco com uma cópia confiável e remova a regra indevida identificada. Preserve os redirecionamentos legítimos e o bloco de links permanentes do WordPress. Apagar o arquivo inteiro pode quebrar URLs e retirar proteções que não tinham relação com a invasão.
Se o servidor é Nginx, esse arquivo não controla os redirecionamentos. Procure as diretivas return e rewrite na configuração do site, ou a área de redirecionamentos do painel. Confira também regras na CDN, como Redirect Rules ou Bulk Redirects quando usa Cloudflare. Salve a regra anterior e teste uma alteração de cada vez.
A página carrega e depois muda? Procure JavaScript
Se o servidor entrega 200 e o navegador troca de endereço logo depois, abra as ferramentas do desenvolvedor, entre em Rede/Network e marque Preservar registro/Preserve log. Recarregue na condição em que o problema aparece e leia a coluna de iniciador da nova navegação.
Procure no HTML e nos scripts pelo domínio de destino e por chamadas como estas:
window.location.href = 'https://destino-invalido.example/';
window.location.replace('https://destino-invalido.example/');São exemplos para reconhecer uma troca de endereço, não instruções para instalar no site. Também existe redirecionamento por meta refresh. Um código malicioso pode montar o destino a partir de pedaços, então buscar só pelo domínio completo nem sempre o encontra.
Tema, plugins e a pasta mu-plugins
Abra wp-content/themes e compare o tema ativo com uma versão confiável. Examine header.php, footer.php, functions.php e os JavaScript carregados pela página. Compare também o tema filho, onde podem existir alterações legítimas que precisam ser preservadas.
Revise wp-content/mu-plugins. Esses plugins carregam automaticamente e aparecem numa área separada do painel; desativar os plugins comuns não interrompe os arquivos dessa pasta. A hospedagem também pode instalar componentes legítimos ali. Confira a autoria e o conteúdo de cada arquivo antes de retirá-lo.
Em wp-content/plugins, verifique componentes de redirecionamento e de inserção de scripts, como Redirection, WPCode e similares. Uma regra indevida pode ter sido salva nas configurações de um plugin legítimo. Remova a entrada confirmada e preserve as regras que o site usa.
Buscas por base64_decode, gzinflate ou eval podem revelar trechos que merecem inspeção, mas essas palavras também aparecem em código legítimo. Compare os arquivos com o pacote oficial e não execute um trecho desconhecido para tentar descobrir o que ele faz.
Scripts salvos no banco, em widgets e em páginas
Abra widgets, HTML personalizado e as áreas de scripts do tema e do construtor. No banco, confira os registros correspondentes em _options, _posts e nos metadados usados pelo componente. A tela de pesquisa do phpMyAdmin permite buscar o domínio suspeito sem editar os registros.
Salve uma cópia da linha encontrada antes de retirar o trecho. Se o valor está serializado, prefira editar pela interface do plugin ou usar um procedimento que preserve esse formato. Uma troca de texto feita diretamente no SQL pode quebrar o restante da configuração.
Quando o domínio aparece em um script externo, revise também quem autorizou esse script e a conta que o publica. Restaurar o arquivo local não remove uma injeção mantida por uma integração externa.
Como limpar e confirmar que o redirecionamento acabou
Depois de localizar a alteração, remova o arquivo adicional confirmado ou substitua o componente comprometido por uma cópia confiável. Preserve as personalizações legítimas separadamente. Um scanner como o Wordfence ajuda a comparar arquivos e localizar mudanças; cada reparo precisa corresponder ao arquivo encontrado.
Revise as contas administrativas e os acessos à hospedagem. Atualize ou substitua o componente que permitiu a entrada, troque as credenciais comprometidas e encerre as sessões anteriores. O passo a passo de recuperação de um WordPress hackeado trata dessa limpeza completa.
Limpe o cache do site, da hospedagem e da CDN depois de corrigir o código e as regras. O navegador também pode ter guardado um redirecionamento permanente. Repita o teste em uma sessão nova, com a mesma URL e origem que acionavam a troca.
Teste a home, uma página interna, o login e o formulário. Compare de novo as respostas do curl com e sem Referer. Se o redirecionamento retorna depois de algumas horas, procure um arquivo que o recria, uma tarefa agendada ou uma conta ainda comprometida, em vez de apenas apagar a regra outra vez.
Dúvidas que mudam o diagnóstico
O DNS pode redirecionar para outra página?
Registros como A, AAAA e CNAME indicam servidores, não uma URL com caminho. Um endereço alterado no DNS pode levar seu domínio a um servidor que entrega outro conteúdo ou envia um redirecionamento HTTP. Confira os registros com os valores do serviço contratado e as opções de encaminhamento de URL no provedor, que são um recurso separado.
Restaurar um backup resolve?
Resolve quando a cópia confiável substitui o que foi alterado e a entrada usada pelo invasor também é corrigida. Um backup do WordPress não desfaz automaticamente uma regra na CDN ou uma alteração no painel do domínio. Veja como restaurar arquivos e banco sem perder os dados recentes antes de escolher a data.
O redirecionamento saiu, mas continua o aviso no Google
O aviso de segurança tem um pedido de revisão próprio. Depois da limpeza, abra o relatório do Search Console e siga a revisão do aviso de site perigoso. Se também apareceram URLs falsas, elas precisam receber o tratamento de remoção do spam nos resultados.
Conclusão
Guarde a URL e a condição que faziam o visitante sair do site. A correção fica comprovada quando esse acesso entrega a página esperada e o arquivo ou a regra indevida deixa de ser recriado.
O redirecionamento continua aparecendo depois desses testes? Envie a URL inicial e o destino observado para eu avaliar a instalação. A manutenção do WordPress inclui a investigação dos arquivos, do banco e das regras que mantêm essa troca.
