Por: Agostinho Filho – Especialista em SEO Técnico & WordPress | Server Express
Introdução
Imagine acessar o Google Search Console e, de repente, ver que seu site tem mais de 16 mil páginas detectadas — sendo que você sabe que o conteúdo real mal passa de 50 URLs.
Nenhuma delas está indexada. O tráfego caiu. E você começa a se perguntar:
“De onde vieram todas essas páginas?”
Essa é a realidade que muitos sites WordPress enfrentam hoje, mesmo com plugins atualizados, servidores rápidos e configurações aparentemente normais.
Neste artigo, vamos te mostrar um caso real, onde um site WordPress legítimo, bem estruturado, sofreu um ataque silencioso de injeção de URLs maliciosas. E o pior: o Google estava tentando rastrear cada uma dessas páginas falsas como se fossem conteúdo autêntico.
Você vai ver:
- Como o problema começou
- Quais os sintomas mais perigosos
- As causas por trás desse tipo de ataque
- E o passo a passo técnico completo para identificar, bloquear e resolver o problema definitivamente — com ações práticas via PHP,
.htaccess, RankMath e até Cloudflare.
Se você administra um site WordPress, ou oferece hospedagem e suporte técnico para clientes, esse conteúdo vai te mostrar como uma falha simples pode virar um buraco negro de SEO, reputação e crawl budget.
O problema: URLs falsas detectadas pelo Google como se fossem válidas
Durante uma análise de rotina no Google Search Console, percebemos algo incomum: o relatório de cobertura apontava mais de 16.800 URLs “Detectadas – atualmente não indexadas”. Ao inspecionar as páginas listadas, encontramos URLs como:
/?go=winrnr bet.aspx
/?gov=beto carrero bonus
/?edu=online casinos for new zealand players.phtm Essas páginas não existiam no site, não foram criadas por ninguém da equipe, e não constavam em nenhum sitemap ou plugin de SEO.
Ainda assim, o Google estava tentando rastreá-las.
Esse tipo de ataque é conhecido como injeção de URLs fantasmas via query strings — e pode acontecer com qualquer site WordPress que esteja com:
- Tema padrão ou com má configuração
- Plugins que não bloqueiam parâmetros GET inválidos
- Ou simplesmente aceitando qualquer URL com 200 OK por padrão
Print real da situação no GSC
📊 Print do Search Console com as mais de 16 mil páginas.
Diagnóstico técnico: como identificar esse tipo de ataque no seu site
Se você usa WordPress, especialmente com construtores como Elementor e plugins de SEO como RankMath ou Yoast, é altamente provável que seu site aceite parâmetros GET por padrão. Isso significa que um bot pode fazer uma requisição como:
https://seusite.com.br/?gov=bonus-cassino-pornografico
E o seu servidor pode simplesmente retornar a homepage com status 200 OK — como se aquela URL fosse válida.
E aí que o Google entra em cena. Mesmo que ele não indexe essa URL, ele vai rastrear. E isso entra no seu relatório de cobertura no Search Console como:
❌ “Detectada – atualmente não indexada”
Agora multiplique isso por 16 mil variações de palavras como bonus, viagra, pill, casino, porn, cheap, etc…
É o pesadelo do SEO técnico.
Sintomas claros de que seu site está vulnerável:
- URLs esquisitas aparecendo no GSC (com
?go=,?gov=,?edu=, etc.) - Tráfego orgânico caindo mesmo sem alterações no conteúdo
- Páginas legítimas demorando para indexar
- Aumento absurdo nas requisições do bot do Google
- CPU do servidor subindo sem explicação clara
Exemplo de URLs falsas detectadas:
https://seusite.com.br/?gov=beto-carrero-bonus
https://seusite.com.br/?go=appbet365ios.pptx
https://seusite.com.br/?edu=online-casinos-new-zealand.phtm
Todas essas URLs são criadas por bots. Muitas vezes, nem há link externo — os bots forçam essas URLs nos crawlers do Google como tentativa de criar páginas “hospedeiras” de spam.
É um tipo de ataque silencioso que não coloca vírus, mas coloca o seu SEO em risco.
Por que isso acontece?
Vamos listar agora as principais causas desse problema no ambiente WordPress:
Possíveis causas do problema (e por que ele passa despercebido)
1. ✅ WordPress retorna 200 para URLs com parâmetros inválidos
O comportamento padrão do WordPress é tratar qualquer parâmetro GET como válido, a menos que você configure algo diferente. Ou seja:
https://meusite.com.br/?xyz=qualquercoisa
→ Retorna a homepage com status 200, mesmo que xyz não tenha propósito algum no código.
Isso é funcional pra filtros, plugins, e interações dinâmicas, mas é um prato cheio pra bots.
2. 🧱 Elementor não interfere nisso
O Elementor é um page builder — ele atua na camada visual e não na filtragem de URLs. Portanto, ele não bloqueia nem filtra parâmetros GET. Se você usa Elementor sem firewall de aplicação, você está exposto.
3. ⚠️ LiteSpeed, RankMath, WP Rocket ou qualquer plugin de cache… também não filtram isso por padrão
Esses plugins trabalham com performance, compressão e cache — mas não barram URLs com parâmetros desconhecidos.
Resultado? O site continua carregando a home com status 200, e o Google pensa que você criou uma URL nova e válida.
4. 🚫 Nenhuma configuração de segurança no .htaccess ou no tema
A maioria dos temas e plugins não implementa filtros de segurança por padrão. O WordPress confia que o administrador vai cuidar disso. E aí, muitos sites ficam vulneráveis por omissão.
Como fazer o diagnóstico em poucos minutos
🔍 Passo 1: Use o Search Console
Vá até o menu “Cobertura” e filtre por páginas “Detectadas – atualmente não indexadas”. Veja se existem URLs com padrões de spam, termos em inglês, ou parâmetros duvidosos.
🔎 Passo 2: Teste URLs manualmente
Abra uma aba anônima no navegador e acesse:
https://seusite.com.br/?go=viagra-promo
Se a homepage carregar normalmente, você está vulnerável.
Se você ver algo como:
Erro 403 – Acesso negado
ou
URL inválida detectada. Nada pra ver aqui...
➡️ Então você já está protegido (a gente vai chegar nessa parte daqui a pouco).
📄 Passo 3: Verifique seu sitemap
Se seu sitemap estiver listando URLs maliciosas (incomum, mas possível), isso é sinal de que há injeção automatizada de rotas falsas.
Plugins infectados podem gerar mapas corrompidos.
📁 Passo 4: Analise os arquivos do tema
Vá até functions.php e verifique se há lógica tratando URLs desconhecidas como válidas.
Se não houver nenhum filtro ou redirecionamento, o site vai exibir tudo como se fosse real.
🔐 Ferramentas úteis para diagnóstico:
- Sucuri SiteCheck
- Wordfence (plugin WordPress)
- VirusTotal (para verificar arquivos PHP)
- Google Search Console (para ver rastreamento de URLs falsificadas)
- Logs do servidor via cPanel ou SSH (
access.log)
Como corrigir e blindar seu site contra injeção de URLs falsas no WordPress
Agora que você já entendeu como esse tipo de ataque funciona e identificou se está vulnerável, vamos ao que interessa:
Resolver definitivamente.
A seguir, você vai ver o passo a passo completo para bloquear esse tipo de ataque usando:
- Código no
functions.php - Regras no
.htaccess - Verificação e regeneração de sitemap com RankMath
- Configurações no Google Search Console
- (Opcional) Firewall avançado via Cloudflare
Etapa 1 – Bloqueando parâmetros maliciosos no functions.php
Essa é a defesa a nível de aplicação, ou seja: o WordPress carrega, mas antes de qualquer conteúdo ser renderizado, ele verifica se há parâmetros suspeitos na URL.
🔧 O que esse código faz?
Ele intercepta qualquer URL com os seguintes parâmetros GET:
?go=
?gov=
?edu=
?ac=
?ref=
?q=
E retorna um erro 403 se qualquer um deles estiver presente.
✅ Código completo para colar no functions.php do seu tema (ou tema filho):
add_action('init', function() {
$parametros_suspeitos = ['go', 'gov', 'edu', 'ac', 'ref', 'q'];
foreach ($parametros_suspeitos as $param) {
if (isset($_GET[$param])) {
wp_die('URL inválida detectada. Nada pra ver aqui...', '403 - Acesso Negado', ['response' => 403]);
}
}
});
💡 Coloque esse código no final do
functions.php, antes do?>(se houver).
Recomenda-se fazer backup antes de editar qualquer arquivo de tema.
Etapa 2 – Reforçando o bloqueio direto no .htaccess (nível Apache)
Enquanto o PHP age quando o WordPress é carregado, o .htaccess é mais rápido e leve: o Apache barra a requisição antes mesmo de passar pelo PHP.
🔐 Onde adicionar?
No arquivo .htaccess, logo acima da seção # BEGIN WordPress, adicione o seguinte:
# BLOQUEIO DE PARÂMETROS MALICIOSOS - SEO E SEGURANÇA
<IfModule mod_rewrite.c>
RewriteEngine On
# Bloqueia query strings spam
RewriteCond %{QUERY_STRING} (go=|gov=|edu=|ac=|ref=|casino|bet|bonus|viagra|cheap|pill|xxx|porn) [NC]
RewriteRule ^ - [F,L]
# Bloqueia extensões de arquivos maliciosos
RewriteCond %{REQUEST_URI} \.(shtml|phtm|pptx|aspx|php5|php4|php3|exe|cgi)$ [NC]
RewriteRule ^ - [F,L]
</IfModule>
🛑 O que isso bloqueia?
- Qualquer URL com parâmetros típicos de spam
- Extensões utilizadas em tentativas de redirecionamento malicioso
- URLs como
?gov=appbet365ios.pptxou/file.exepassam a ser 403 direto no navegador
Etapa 3 – Verificando e regenerando o sitemap (RankMath)
1. Acesse seu painel WordPress
Vá em Rank Math > Sitemap Settings.
2. Verifique se apenas posts, páginas e categorias importantes estão marcados.
Desative qualquer tipo de post desnecessário no sitemap (ex: anexos, taxonomias personalizadas).
3. Acesse seu sitemap principal:
https://seusite.com.br/sitemap_index.xml
Ele deve exibir apenas algo assim:
/post-sitemap.xml/page-sitemap.xml/category-sitemap.xml
Se estiver tudo certo, esse é o sitemap que vamos enviar ao GSC.
Etapa 4 – Enviando o sitemap limpo para o Google
- Acesse: Google Search Console
- Vá para Indexação > Sitemaps
- Em “Adicionar um novo sitemap”, digite: pgsql
sitemap_index.xml - Clique em ENVIAR
Isso diz ao Google: “Olha aqui o que é válido no meu site. Ignore o resto.”
Etapa 5 – (Opcional) Usando o Cloudflare como firewall avançado
Se seu site usa Cloudflare (recomendado para WordPress), você pode criar regras de firewall baseadas em expressões que barram esse tipo de ataque antes do servidor ser tocado.
📌 Regra 1 – Bloqueio de query strings maliciosas
- Vá até: Security > WAF > Custom Rules
- Clique em Create Rule
- Nome da Regra:
Bloqueio QueryString Spam - Expressão: cfCopiarEditar
(http.request.uri.query contains "gov=" or http.request.uri.query contains "casino" or http.request.uri.query contains "bonus" or http.request.uri.query contains "pill") - Ação: Block
💡 Resultado:
Cloudflare bloqueia a requisição antes mesmo de chegar no Apache ou no PHP. Leve, rápido e fatal para os spammers.
Etapa 6 – Usando a ferramenta de remoção temporária do GSC
Quer limpar rápido os rastros das URLs falsas?
- No GSC, vá para Remoções
- Clique em Nova solicitação temporária
- Insira uma das URLs falsas
- Clique em Próximo > Enviar
O Google irá remover essa URL dos resultados por 6 meses, enquanto você cuida da limpeza completa com sitemap e firewall.
✨ Resultado após aplicar todas essas etapas
Depois de aplicar essas soluções:
- O número de “Detectadas – não indexadas” vai começar a cair no Search Console;
- O crawl budget do Google será direcionado para as páginas reais do seu site;
- O tempo de resposta melhora, já que requisições lixo nem chegam ao PHP;
- A reputação técnica do seu domínio melhora aos olhos do algoritmo.
👉 Na próxima parte, vamos fechar com:
- Antes e depois (exemplo real com prints e status 403)
- Checklist de segurança/SEO técnico para WordPress
- Conclusão com reforço do valor da hospedagem profissional
Exemplo prático, checklist e conclusão poderosa
Agora que mostramos como o ataque acontece e como blindar o site, vamos mostrar na prática o que muda antes e depois da correção.
📸 Exemplo real — Antes da blindagem
Antes de aplicar as correções, qualquer pessoa (ou bot) podia acessar URLs como:
https://seudominio.com.br/?gov=meridiano20bet.net.html
E o resultado?
- A página carregava normalmente como se fosse válida.
- O Googlebot indexava essas URLs falsas.
- O Search Console mostrava centenas de páginas “detectadas – não indexadas”.
- Você tinha um SEO poluído, e seu site era tratado como potencialmente spam.
✅ Depois das correções implementadas
Com o código no functions.php, .htaccess e ajustes no sitemap:
- A mesma URL agora retorna um 403 – Acesso negado
- O Google para de indexar lixo
- O sitemap limpo é enviado novamente
- O crawl budget é focado no conteúdo real do site
- A reputação técnica do domínio melhora
📸 Print da tela após bloqueio:
“Erro 403 – Acesso negado” — direto e sem misericórdia.
📋 Checklist final: Blindagem técnica WordPress contra spam em parâmetros
| Ação | Status |
|---|---|
🔒 Código functions.php bloqueando parâmetros | ✅ |
🧱 Regras no .htaccess (Apache level) | ✅ |
| 🗺️ Sitemap regenerado com RankMath | ✅ |
| 📤 Sitemap reenviado no Google Search Console | ✅ |
| 🧹 URLs falsas removidas via GSC (Remoção Temporária) | ✅ |
| ☁️ (Opcional) Firewall no Cloudflare ativado | ✅ |
| 🧪 Monitoramento de logs do servidor ativado | ✅ |
| 💡 Lembrete: Atualizações futuras não sobrescrevem regras | 🔒 |
Pro tip: Faça backup do
.htaccesse do tema sempre que for editar.
✍️ Conclusão: Mais do que corrigir, você fortaleceu sua presença online
Esse tipo de ataque pode parecer inofensivo à primeira vista, mas é venenoso pro SEO e pra reputação técnica do seu domínio.
Ao seguir esse passo a passo:
- Você protege seu site WordPress como um profissional
- Otimiza o desempenho aos olhos do Google
- Evita que spammers drenem seus recursos de servidor e crawl
- E de quebra, dá aula pra concorrência que ainda tá tropeçando nas SERPs
🚀 Por que uma hospedagem profissional faz toda a diferença?
Na Server Express, não é só sobre espaço e velocidade.
Você tem:
✅ Suporte técnico que entende WordPress
✅ Monitoramento de segurança e uptime
✅ Recursos como Cloudflare, Litespeed, backup automático e WAF
✅ Painel otimizado pra devs e usuários com SEO na veia
Seu WordPress é sua vitrine, seu ativo digital. E uma vitrine mal protegida atrai ladrão.
Na dúvida, deixe com quem entende.
📢 Call to action para o artigo:
Quer evitar esse e outros problemas técnicos de SEO no seu site WordPress?
Fale com a equipe da Server Express e suba de nível com uma hospedagem pensada pra quem vive de performance, segurança e resultados reais.
