O que fazer quando a varredura falha, desativando temporariamente mecanismos de segurança

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 desativá-los pelo tempo da varredura ou autorizar o InspectWP em uma whitelist.

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 não se disfarça como bot de mecanismo de busca. O user agent contém o marcador InspectWP. Isso significa: se você bloquear bots de forma geral, também bloqueará o InspectWP, e essa é a verdadeira causa raiz. Adicionar à whitelist costuma ser a solução mais limpa do que desativar a proteção totalmente.

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.

Se não quiser desativar a proteção contra bots por completo, crie uma regra customizada do Cloudflare WAF com a ação Skip para user agents que contenham InspectWP.

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: Procure requisições bloqueadas dos IPs do InspectWP 195.201.17.43 e 46.224.183.125 e adicione-os em Whitelisted IPs.
• 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, ou adicionar o user agent do InspectWP à whitelist do plugin.

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=BlockCountry

Para 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 autorizar os IPs do InspectWP 195.201.17.43 e 46.224.183.125. 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 a inclusão na whitelist 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. Uma autorização de curto prazo do IP do servidor InspectWP resolve a questão.

15. Checklist antes de re-analisar

• ☐ Cloudflare Bot Fight Mode desligado
• ☐ Firewall do Wordfence em Learning Mode ou IP do InspectWP autorizado
• ☐ Plugin de segurança (Sucuri / Solid / AIOS) em configuração moderada
• ☐ IPs do InspectWP 195.201.17.43 e 46.224.183.125 adicionados à whitelist do plugin/hospedagem
• ☐ 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!