Se sua varredura do InspectWP falhar, retornar um relatório vazio ou claramente analisar apenas uma página de desafio, mecanismos de segurança no site de destino são quase sempre a causa. Este guia conduz você por todos os obstáculos comuns, do Cloudflare ao Wordfence ao .htaccess, e mostra como afrouxá-los ou desativá-los brevemente pelo tempo da varredura.
1. Por que as varreduras falham
Sintomas típicos que indicam uma barreira de segurança no caminho:
- Timeout / varredura abortada: O site não responde, ou apenas após mais de 30 segundos.
- Relatório vazio ou quase vazio: Sem título, sem plugins, sem tema detectado, muito provavelmente uma página de desafio ou bloqueio foi analisada.
- HTTP 403 / 429 / 503: Um firewall rejeitou a requisição ou o limite de taxa foi acionado.
- Conteúdo errado: A captura de tela mostra uma página de verificação do Cloudflare, uma página de bloqueio do Wordfence, uma tela em-breve ou um formulário de login em vez do seu site real.
2. Antes de começar
O InspectWP usa um navegador Chrome headless real e se apresenta como um visitante normal com um Chrome atual. A varredura vem de um pool de IPs de servidor que mudam. Não existe, portanto, nem um IP fixo do crawler nem um marcador do InspectWP no user agent que você pudesse autorizar. Isso significa: se a sua proteção contra bots bloqueia visitantes desconhecidos ou lhes impõe um desafio, isso também atinge o InspectWP, e essa é a verdadeira causa do problema. Por isso a solução é sempre afrouxar a proteção em questão durante a varredura ou desativá-la brevemente.
3. Cloudflare
O Cloudflare é o motivo mais comum de varreduras falhas. Faça login no painel do Cloudflare e verifique:
- Security → Bots: Defina Bot Fight Mode e Super Bot Fight Mode como Off.
- Security → Settings: Defina temporariamente o Security Level como Essentially Off ou Low.
- Security → WAF → Tools: Certifique-se de que o Under Attack Mode esteja desligado (use High ou inferior).
- Custom Rules: Se você tem suas próprias regras WAF, verifique se alguma bloqueia user agents ou IPs.
Em muitos casos, o InspectWP consegue passar sozinho por uma Managed Challenge. Se isso falhar, só ajuda reduzir o Security Level ou desligar o Bot Fight Mode durante a varredura.
4. Wordfence
O Wordfence é o plugin de segurança WordPress mais popular e frequentemente bloqueia crawlers de forma muito agressiva. Veja como lidar com ele:
- Wordfence → Tools → Live Traffic: Verifique se houve requisições bloqueadas no momento da varredura. A entrada mostra qual regra foi acionada.
- Wordfence → Firewall → All Firewall Options: Mude brevemente o firewall para Learning Mode ou Disabled.
- Rate Limiting: Aumente significativamente os limiares para „Quantas visualizações de página um crawler pode visitar por minuto“.
- Block fake Google crawlers: Esta opção pode bloquear o InspectWP, desative-a temporariamente.
5. Sucuri, Solid Security, iThemes Security, All-In-One Security (AIOS)
Outros plugins de segurança conhecidos usam mecanismos muito similares. Procure especificamente:
- Proteção contra força bruta / detecção de 404
- Limite de taxa para user agents desconhecidos
- Listas de bloqueio em destaque / recomendadas
- Bloqueio por país
Desative o recurso relevante ou aumente os limiares temporariamente.
6. Limit Login Attempts / Loginizer
Esses plugins bloqueiam IPs após tentativas de login falhas. O InspectWP nunca tenta fazer login, mas: se seu servidor acabou de registrar outras tentativas falhas a partir do intervalo de IPs da varredura, o IP pode já estar banido. Verifique a lista de bloqueio do plugin e remova a entrada se necessário.
7. Plugins anti-bot e anti-spam
CleanTalk, Blackhole for Bad Bots, StopBadBots e similares operam com base em heurísticas e bloqueiam qualquer user agent incomum. A única solução é: desativá-los brevemente durante a varredura.
8. Plugins de em-breve e manutenção
Plugins como SeedProd, WP Maintenance Mode, Elementor Coming Soon ou WP Maintenance mostram aos visitantes externos uma página de espaço reservado. O InspectWP então analisa esse espaço reservado, não seu site real. Os links de bypass oferecidos por alguns plugins geralmente não funcionam para varreduras externas. Solução: desative brevemente o plugin, execute a varredura, reative o plugin.
9. Plugins de cache e otimização
WP Rocket, LiteSpeed Cache, W3 Total Cache e ferramentas similares podem produzir resultados estranhos quando a otimização agressiva está habilitada, por exemplo quando o JavaScript é adiado ou combinado. Recomendações:
- Limpe o cache antes da varredura
- Mantenha „Bot Cache“ / „Cache para usuários deslogados“ habilitado, caso contrário o InspectWP pode ver uma versão obsoleta
- Verifique opções de JavaScript-Delay / lazy-render, o InspectWP aguarda interação, mas atrasos extremos causam timeouts
10. Proteção por senha, somente para membros, conteúdo restrito
Uma página acessível somente para usuários logados ou atrás de HTTP basic auth não pode ser analisada pelo InspectWP. Garanta que a URL que você quer analisar seja publicamente acessível sem login. Desative brevemente plugins como Restrict Content Pro, MemberPress ou Password Protected, ou defina a página de destino como pública.
11. .htaccess e nginx, bloqueios por IP, país e user-agent
Em nível de servidor, crawlers são frequentemente bloqueados via Deny ou RewriteRule. Exemplos de arquivos .htaccess típicos que você pode comentar temporariamente:
# Bloqueio de user-agent de bot (comum)
RewriteCond %{HTTP_USER_AGENT} (bot|crawler|spider) [NC]
RewriteRule .* - [F,L]
# Bloqueio de IP
Deny from 1.2.3.4
# Bloqueio de país via mod_geoip
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountryPara nginx, o equivalente é assim:
if ($http_user_agent ~* (bot|crawler|spider)) {
return 403;
}Comente essas linhas durante a varredura.
12. Mecanismos de proteção do lado da hospedagem
Alguns hosts executam seu próprio Web Application Firewall (WAF) ou regras ModSecurity que você não verá na auditoria do plugin ou do .htaccess. Peça ao suporte deles para afrouxar a proteção contra bots durante a varredura. Exemplos conhecidos:
- All-Inkl, IONOS, Strato: Proteção contra bots no painel de hospedagem, contate o suporte ou desative pelo menu do cliente.
- SiteGround: Anti-bot por IA, Smart-WAF, em Site Tools → Security.
- Kinsta, WP Engine: Detecção proprietária de bots, solicite o afrouxamento via suporte.
- Hetzner / provedores de nuvem: Raramente problemas de WAF, mas restrições de GeoIP são possíveis.
13. CSP, X-Frame-Options e robots.txt
Para esclarecer: um robots.txt com Disallow: / não impede o InspectWP de fazer a varredura, não respeitamos estritamente o robots.txt. Content-Security-Policy e X-Frame-Options, por outro lado, podem impedir sub-requisições individuais (iframes, scripts de terceiros); isso é normal e não é um erro. Os bloqueadores que realmente importam são respostas 403/429/503 no documento principal.
14. Limite de taxa e Fail2Ban
Em nível de servidor, fail2ban, mod_evasive ou nginx limit_req podem banir o IP da varredura em segundos, especialmente com muitas sub-requisições paralelas. Se você tem acesso SSH, verifique /var/log/fail2ban.log ou iptables -L. Aumente os limiares durante a varredura ou remova o IP banido da lista de banimentos.
15. Checklist antes de re-analisar
- ☐ Cloudflare Bot Fight Mode desligado
- ☐ Firewall do Wordfence em Learning Mode
- ☐ Plugin de segurança (Sucuri / Solid / AIOS) em configuração moderada
- ☐ Plugin de em-breve / manutenção desativado
- ☐ Cache do plugin de cache limpo
- ☐ .htaccess / nginx verificado quanto a bloqueios de user-agent/IP
- ☐ Painel da hospedagem: proteção contra bots / WAF revisada
- ☐ Página é publicamente acessível sem login
- ☐ Cache do navegador limpo e uma nova varredura de teste executada
16. Quando nada ajuda
Envie-nos um e-mail para hello@inspectwp.com com o domínio e o horário aproximado da varredura falha.
Após uma varredura bem-sucedida, não esqueça de reativar todos os mecanismos de segurança!