SEO spam no WordPress: encontrar links ocultos de casinos

Se o Google mostra resultados inesperados de casinos, farmácias online ou em japonês para o seu domínio, mas o site parece normal no seu navegador, investigue SEO spam no WordPress. Os resultados podem refletir um comprometimento ativo ou spam que continua indexado depois de uma limpeza. O spam está escondido no código da página ou é servido apenas ao Google e a visitantes que chegam a partir da pesquisa. Este guia mostra como ver o seu site tal como o Google o vê, onde o spam fica guardado e como o retirar do índice do Google.

Como é o SEO spam no WordPress e porque não o vê

Não o vê porque não foi feito para si. Os atacantes querem a reputação do seu domínio, não a atenção dos seus visitantes. O código injetado costuma ignorar utilizadores autenticados e pessoas que escrevem o seu endereço diretamente no navegador.

Há três formas comuns:

• Hacklinks. São injetados nas suas páginas links para sites de casinos, farmácias ou crédito. Costumam estar dentro de um bloco display:none, posicionados fora do ecrã ou num rodapé que ninguém lê.
• O hack das palavras-chave japonesas. Milhares de páginas geradas automaticamente, com texto em japonês e links para lojas. Muitas vezes trazem o seu próprio sitemap, para que o Google as encontre depressa.
• Redirecionamentos condicionais e cloaking. O código verifica o agente de utilizador, o endereço IP ou o referenciador (referrer). O Googlebot recebe conteúdo de spam. Um visitante que chega a partir do Google é redirecionado. Você vê a página normal.

O dano é real, mesmo que não o veja. As posições podem cair, os visitantes perdem a confiança e o Google pode gastar o seu esforço de rastreio em páginas de spam em vez das páginas verdadeiras. Se ainda tem dúvidas sobre ter sido ou não atacado, comece por 12 sinais de que o seu site WordPress foi hackeado.

Veja o seu site como o Google o vê

Comece no próprio Google. Pesquise site:example.com, percorra os resultados e depois afunile:

site:example.com casino
site:example.com viagra OR cialis
site:example.com 激安
site:example.com inurl:.html

Resultados num idioma em que não publica, ou padrões de URL que o seu site não usa, são um indício forte.

Outra verificação útil é a Inspeção de URL (URL Inspection) no Google Search Console. Os nomes dos menus neste guia seguem a interface em inglês. Cole um URL suspeito (ou a sua página inicial), clique em Test live URL e depois em View tested page. O separador HTML mostra o código que o rastreador do Google recebeu, e a captura de ecrã mostra o que ele renderizou. Procure nesse HTML por casino, href ou display:none. O teste em direto usa o rastreador de inspeção do Google, que os atacantes podem tratar de forma diferente do rastreador de indexação. Pode revelar cloaking, mas um resultado limpo não o exclui.

Pode fazer uma comparação aproximada a partir da sua própria máquina com o curl:

curl -s https://example.com/ -o normal.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -o googlebot.html
diff normal.html googlebot.html
curl -sS -D - -o /dev/null -e "https://www.google.com/" https://example.com/

O último comando faz um pedido GET com um referenciador do Google e mostra os cabeçalhos da resposta. Um cabeçalho Location: pode revelar um redirecionamento HTTP, mas isto não deteta redirecionamentos em JavaScript nem reproduz todas as sessões de navegador. Há ainda outra limitação: se o código injetado verificar os intervalos de IP do Google, o curl a partir do seu portátil verá uma página limpa. Um resultado limpo no curl não significa que o site esteja limpo.

Por fim, abra Indexing > Pages no Search Console. Um aumento súbito de URL indexados ou descobertos que não publicou aponta, em regra, para páginas de spam geradas.

Onde se esconde o SEO spam no WordPress

Antes de investigar, guarde uma cópia de segurança de ficheiros e base de dados. Proteja essa cópia, porque pode conter dados pessoais e segredos. Dê preferência a uma cópia isolada, com acesso de rede restrito, e execute os comandos abaixo a partir da raiz do WordPress dessa cópia: muitos comandos do WP-CLI carregam o WordPress e podem executar código comprometido. Acrescentar --skip-plugins --skip-themes reduz esse risco, mas os mu-plugins e um wp-config.php alterado continuam a ser executados. Se não conseguir isolar a cópia em segurança, peça ao seu alojamento ou a um especialista em resposta a incidentes que faça a investigação.

Na base de dados

wp db search 'casino' --all-tables
wp db search 'viagra' --all-tables
wp post list --post_type=any --post_status=any --orderby=date --order=DESC --fields=ID,post_type,post_status,post_date,post_title
wp option list --search='widget_*'
wp option list --search='theme_mods_*'
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Verifique os artigos e os metadados (post meta) à procura de links que não escreveu e procure artigos ou páginas recentes com títulos ou estados estranhos. Em wp_options, veja:

• widgets de texto e HTML
• theme mods, onde muitas vezes fica o código personalizado do rodapé
• opções com carregamento automático (autoload) cujos nomes não reconhece

Os nomes de tabelas wp_ acima pressupõem o prefixo predefinido; se o seu for diferente, consulte $table_prefix no wp-config.php. Administradores desconhecidos são, por si só, uma constatação grave.

Nos ficheiros

wp core verify-checksums
wp plugin verify-checksums --all
ls -la wp-content/mu-plugins
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)
find . -type f -name "*.php" -mtime -14
grep -rnE "base64_decode|gzinflate|str_rot13|eval\(" wp-content --include=*.php

O wp core verify-checksums compara os ficheiros do núcleo com os do WordPress.org. O wp plugin verify-checksums --all só funciona para plugins alojados no WordPress.org. Para plugins premium, obtenha uma cópia nova junto do fornecedor e compare com ela.

O grep por marcas de ofuscação produz falsos positivos, porque plugins legítimos também usam algumas destas funções. Procure cadeias codificadas longas e código que não faz sentido no contexto.

Verifique também à mão estes locais:

• functions.php, header.php e footer.php do tema
• pastas de plugins que não instalou (os atacantes gostam de nomes plausíveis)
• wp-config.php e index.php, à procura de linhas include a mais
• .htaccess, à procura de regras RewriteCond sobre HTTP_USER_AGENT ou HTTP_REFERER
• a raiz web, à procura de ficheiros XML de sitemap e ficheiros de verificação google*.html que não criou

Procure no Search Console as pegadas do atacante

Os atacantes verificam-se muitas vezes como proprietários da sua propriedade no Search Console. Depois submetem os seus próprios sitemaps para que o Google indexe o spam mais depressa. Enquanto mantiverem esse acesso, podem continuar a empurrar URL.

Abra Settings > Users and permissions e remova qualquer proprietário ou utilizador que não conheça. Remova depois também o respetivo método de verificação. Pode ser um ficheiro google*.html na raiz web, uma meta tag nas definições do tema ou do cabeçalho, ou um registo DNS TXT. Se saltar este passo, basta-lhes verificar de novo.

Em Indexing > Sitemaps, investigue as submissões desconhecidas: plugins legítimos ou outros gestores autorizados do site podem tê-las submetido. Remova do Search Console os sitemaps submetidos pelo atacante e remova ou desative a respetiva origem no site. Abra depois Security & Manual Actions e leia os relatórios Security issues e Manual actions. Os URL de exemplo aí listados indicam o spam que o Google encontrou, o que dá uma boa lista de verificação para a limpeza.

Limpe o spam e depois feche a entrada

Apagar os links visíveis é cosmético. Se o ponto de entrada continuar aberto, o spam costuma voltar, muitas vezes em poucos dias.

1. Se ainda não o fez, guarde uma cópia do estado infetado (ficheiros e base de dados) e conserve-a como prova.
2. Remova da base de dados os artigos, opções, widgets e utilizadores de spam.
3. Substitua os ficheiros alterados do núcleo, dos plugins e do tema por cópias novas de fontes fiáveis. Não edite os ficheiros infetados linha a linha.
4. Encontre o ponto de entrada. Os mais comuns são um plugin vulnerável ou pirateado (nulled), uma palavra-passe de administrador roubada ou credenciais de FTP ou do alojamento que foram divulgadas.
5. Corrija-o e depois mude todas as palavras-passe e os salts no wp-config.php.

O nosso plano de remoção de malware no WordPress descreve o procedimento completo. Plugins WordPress vulneráveis trata da via de entrada mais comum.

A mesma brecha pode também ter exposto dados de clientes, como entradas de formulários ou contas de utilizador. Nesse caso, podem aplicar-se as obrigações do RGPD em caso de violação de dados pessoais; veja a notificação de violações do RGPD em 72 horas.

Retire o spam do Google: 410, remoções e pedido de revisão

Depois de as páginas geradas só com spam desaparecerem, os respetivos URL devem devolver 404 (Not Found) ou 410 (Gone); qualquer um serve. Se páginas legítimas tiverem sido alteradas, restaure-as em vez de remover os seus URL. Não redirecione os URL de spam para a página inicial. O Google pode tratá-lo como um soft 404 e continuar a rastreá-los.

Se os URL de spam partilharem um padrão que nenhuma das suas páginas verdadeiras usa, pode responder com 410 ao nível do servidor:

RedirectMatch 410 "^/spam-pattern/"

location ~ ^/spam-pattern/ { return 410; }

Em casos urgentes, como spam a aparecer com o nome da sua marca, use a ferramenta Removals do Search Console. Ela oculta URL dos resultados apenas temporariamente e não é um método de remoção permanente. Mantenha os URL só de spam a devolver 404/410 e deixe o Google rastrear essas respostas; não os bloqueie no robots.txt, porque o Google precisa de ver o estado de remoção. Consulte as orientações do Google sobre a ferramenta de remoções. Volte a submeter o seu sitemap genuíno para que o Google rastreie de novo as páginas que importam.

Se precisa de uma revisão depende dos relatórios:

• Se o relatório Security issues ou Manual actions listar um problema por resolver, use a respetiva opção de revisão depois de corrigir todas as páginas afetadas. Mantenha o pedido curto e factual: o que encontrou, o que removeu, como o atacante entrou e o que alterou para fechar essa brecha.
• Se nenhum dos relatórios listar um problema, não há revisão a pedir. O Google precisa de voltar a rastrear o site já limpo.

Tenha expectativas realistas. As revisões demoram, os URL de spam saem gradualmente e as posições podem recuperar devagar ou não recuperar por completo. Ninguém pode prometer um prazo.

Detete a próxima injeção a tempo

O SEO spam foi concebido para passar despercebido, por isso precisa de verificações que não dependam de olhar para a página:

• Mantenha uma referência de integridade dos ficheiros e investigue qualquer alteração que não tenha feito.
• Faça uma pesquisa site: do seu domínio uma vez por mês.
• Ative as notificações por email no Search Console para que os Security issues e as ações manuais lhe cheguem.
• Analise a base de dados com regularidade à procura de padrões de links como os acima.
• Trate como incidente qualquer conta de administrador nova que não tenha criado.

O plugin Security Audit & Compliance da secaudit.eu analisa SEO spam oculto e hacklinks, spam na base de dados, administradores ocultos e outros indicadores de comprometimento. Compara também os ficheiros com uma referência. Deteta e comunica. Não limpa o site automaticamente, e o ponto de entrada continua a precisar de uma pessoa que o corrija. → secaudit.eu

FAQ

Porque não vejo o spam quando visito o meu próprio site?

O código injetado decide quem vê o quê. Costuma excluir utilizadores autenticados e verifica o agente de utilizador, o endereço IP e o referenciador. Alguns ataques visam o Googlebot ou visitantes que chegam da pesquisa; outros mostram também spam a visitantes comuns ou escondem links no código servido a todos. Use o teste em direto da Inspeção de URL como uma das verificações, mas lembre-se de que os atacantes podem servir ao seu rastreador de inspeção conteúdo diferente do que servem ao rastreador de indexação.

O Google vai penalizar o meu site para sempre?

Não há garantias, num sentido ou noutro. Limpe a fundo, feche o ponto de entrada e remova o acesso do atacante no Search Console. Peça uma revisão se um relatório de Security issues ou Manual actions o exigir. A recuperação depende então de o Google voltar a rastrear o seu site, o que demora.

Um plugin de segurança chega para remover o SEO spam?

Um plugin pode ajudar a encontrar o spam e os ficheiros alterados. Remover o spam de forma limpa e descobrir como o atacante entrou exige trabalho manual ou ajuda profissional. Caso contrário, o spam tende a voltar.