Qué hacer cuando el crawl falla, desactivando temporalmente los mecanismos de seguridad

Si tu crawl de InspectWP falla, devuelve un informe vacío o solo analiza visiblemente una página de challenge, casi siempre la causa son los mecanismos de seguridad del sitio objetivo. Esta guía te lleva por todos los obstáculos habituales, desde Cloudflare hasta Wordfence pasando por .htaccess, y muestra cómo desactivarlos durante el crawl o cómo poner a InspectWP en la lista blanca.

1. Por qué fallan los crawls

Síntomas típicos que indican que hay una barrera de seguridad por en medio:

• Timeout / crawl abortado: el sitio no responde, o solo después de más de 30 segundos.
• Informe vacío o casi vacío: sin título, sin plugins, sin tema detectado; lo más probable es que se haya rastreado una página de challenge o de bloqueo.
• HTTP 403 / 429 / 503: un firewall ha rechazado la petición o se ha disparado un rate-limit.
• Contenido erróneo: la captura de pantalla muestra una página de comprobación de Cloudflare, una página de bloqueo de Wordfence, una pantalla de „próximamente“ o un formulario de inicio de sesión en lugar de tu sitio web real.

2. Antes de empezar

InspectWP usa un navegador Chrome headless real y no se disfraza de bot de motor de búsqueda. El user agent contiene la marca InspectWP. Es decir: si bloqueas bots de forma general, también bloquearás InspectWP, y esa es la causa raíz real. Poner en la lista blanca suele ser una solución más limpia que desactivar la protección por completo.

3. Cloudflare

Cloudflare es el motivo más común de los crawls fallidos. Inicia sesión en el panel de Cloudflare y comprueba:

• Security → Bots: pon Bot Fight Mode y Super Bot Fight Mode en Off.
• Security → Settings: pon temporalmente Security Level en Essentially Off o Low.
• Security → WAF → Tools: asegúrate de que Under Attack Mode está apagado (usa High o inferior).
• Custom Rules: si tienes tus propias reglas WAF, comprueba si alguna bloquea user agents o IPs.

Si no quieres desactivar la protección antibot por completo, crea una regla custom de WAF en Cloudflare con acción Skip para user agents que contengan InspectWP.

4. Wordfence

Wordfence es el plugin de seguridad de WordPress más popular y suele bloquear crawlers de forma muy agresiva. Cómo manejarlo:

• Wordfence → Tools → Live Traffic: busca peticiones bloqueadas desde las IPs de InspectWP 195.201.17.43 y 46.224.183.125 y añádelas en Whitelisted IPs.
• Wordfence → Firewall → All Firewall Options: pasa el firewall brevemente a Learning Mode o Disabled.
• Rate Limiting: aumenta significativamente los umbrales de „How many page views can a crawler visit per minute“.
• Block fake Google crawlers: esta opción puede bloquear InspectWP, desactívala temporalmente.

5. Sucuri, Solid Security, iThemes Security, All-In-One Security (AIOS)

Otros plugins de seguridad conocidos usan mecanismos muy similares. Busca específicamente:

• Protección contra fuerza bruta / detección de 404
• Rate-limiting para user agents desconocidos
• Listas de bloqueo destacadas / recomendadas
• Bloqueo por país

Desactiva la función correspondiente o sube los umbrales temporalmente.

6. Limit Login Attempts / Loginizer

Estos plugins bloquean IPs tras intentos fallidos de inicio de sesión. InspectWP nunca intenta iniciar sesión, pero: si tu servidor acaba de registrar otros inicios fallidos desde el rango de IPs del crawl, la IP puede estar ya baneada. Comprueba la lista de bloqueo del plugin y elimina la entrada si hace falta.

7. Plugins antibot y antispam

CleanTalk, Blackhole for Bad Bots, StopBadBots y similares se basan en heurísticas y bloquean cualquier user agent inusual. La única solución es: desactivarlos brevemente, o añadir el user agent de InspectWP a la lista blanca del plugin.

8. Plugins de „próximamente“ y mantenimiento

Plugins como SeedProd, WP Maintenance Mode, Elementor Coming Soon o WP Maintenance muestran a los visitantes externos una página de marcador de posición. InspectWP analiza entonces esa página, no tu sitio real. Los enlaces de bypass que ofrecen algunos plugins normalmente no funcionan para crawls externos. Solución: desactiva el plugin brevemente, ejecuta el crawl, vuelve a activarlo.

9. Plugins de caché y optimización

WP Rocket, LiteSpeed Cache, W3 Total Cache y herramientas similares pueden producir resultados de crawl extraños cuando hay optimización agresiva activada, por ejemplo cuando JavaScript se retrasa o se combina. Recomendaciones:

• Vacía la caché antes de rastrear
• Mantén activado „Bot Cache“ / „Cache for logged-out users“, si no, InspectWP puede ver una versión obsoleta
• Revisa las opciones de JavaScript-Delay / lazy-render: InspectWP sí espera la interacción, pero los retardos extremos provocan timeouts

10. Protección con contraseña, solo socios, contenido restringido

Una página solo accesible para usuarios autenticados o detrás de HTTP basic auth no puede ser rastreada por InspectWP. Asegúrate de que la URL que quieres analizar es accesible públicamente sin necesidad de iniciar sesión. Desactiva brevemente plugins como Restrict Content Pro, MemberPress o Password Protected, o pon la página objetivo como pública.

11. .htaccess y nginx, bloqueos por IP, país y user agent

A nivel de servidor, los crawlers se bloquean a menudo con Deny o RewriteRule. Ejemplos típicos de archivos .htaccess que puedes comentar temporalmente:

# Bot user-agent block (común)
RewriteCond %{HTTP_USER_AGENT} (bot|crawler|spider) [NC]
RewriteRule .* - [F,L]

# Bloqueo por IP
Deny from 1.2.3.4

# Bloqueo por país con mod_geoip
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

En nginx, el equivalente es:

if ($http_user_agent ~* (bot|crawler|spider)) {
    return 403;
}

Comenta esas líneas durante el crawl.

12. Mecanismos de protección del alojamiento

Algunos hosts ejecutan su propio Web Application Firewall (WAF) o reglas de ModSecurity que no verás ni en el plugin ni en la auditoría del .htaccess. Pide a su soporte que añadan a la lista blanca las IPs de InspectWP 195.201.17.43 y 46.224.183.125. Ejemplos conocidos:

• All-Inkl, IONOS, Strato: protección antibot en el panel de hosting; contacta con soporte o desactívala desde el menú de cliente.
• SiteGround: AI anti-bot, Smart-WAF, en Site Tools → Security.
• Kinsta, WP Engine: detección de bots propia; solicita la inclusión en la lista blanca a través del soporte.
• Hetzner / proveedores cloud: rara vez problemas de WAF, pero son posibles las restricciones GeoIP.

13. CSP, X-Frame-Options y robots.txt

Para que quede claro: un robots.txt con Disallow: / no impide a InspectWP rastrear, no respetamos robots.txt de forma estricta. Content-Security-Policy y X-Frame-Options sí pueden, en cambio, impedir subpeticiones individuales (iframes, scripts de terceros); eso es normal y no es un error. Los bloqueadores que sí importan son las respuestas 403/429/503 al documento principal.

14. Rate limiting y Fail2Ban

A nivel de servidor, fail2ban, mod_evasive o nginx limit_req pueden banear la IP del crawl en cuestión de segundos, especialmente con muchas subpeticiones en paralelo. Si tienes acceso SSH, revisa /var/log/fail2ban.log o iptables -L. Una lista blanca a corto plazo de la IP del servidor de InspectWP soluciona el problema.

15. Checklist antes de volver a rastrear

• ☐ Cloudflare Bot Fight Mode apagado
• ☐ Firewall de Wordfence en Learning Mode o IP de InspectWP en la lista blanca
• ☐ Plugin de seguridad (Sucuri / Solid / AIOS) con configuración moderada
• ☐ IPs de InspectWP 195.201.17.43 y 46.224.183.125 añadidas a la lista blanca del plugin/alojamiento
• ☐ Plugin de „próximamente“ / mantenimiento desactivado
• ☐ Caché del plugin de caché vaciada
• ☐ .htaccess / nginx revisados en busca de bloqueos por user agent/IP
• ☐ Panel del alojamiento: revisada la protección antibot / WAF
• ☐ La página es accesible públicamente sin iniciar sesión
• ☐ Caché del navegador vaciada y crawl de prueba lanzado en limpio

16. Cuando nada funciona

Escríbenos a hello@inspectwp.com con el dominio y la hora aproximada del crawl fallido.

Tras un crawl correcto, ¡no olvides volver a activar todos los mecanismos de seguridad!