Screaming Frog no está roto. Está desactualizado para el mercado actual.
El 32,8% de los sitios top ya corre sobre Cloudflare. Si tu crawler no pasa el WAF, estás entregando auditorías con agujeros que no ves.
Voy a decir algo que sé que genera fricción en la comunidad SEO: Screaming Frog, tal como está hoy, falla silenciosamente en una parte importante de los sitios que vas a auditar. No tira error. No avisa. Simplemente no ve lo que no puede ver, y vos entregás un reporte que parece completo pero tiene agujeros.
No es un tema de configuración ni de que lo estés usando mal. Es una limitación de arquitectura que se volvió relevante a medida que Cloudflare y otros WAF se convirtieron en el estándar de infraestructura web.
Y el problema no es menor: según las últimas estimaciones, Cloudflare protege más del 30% de todos los sitios con tráfico relevante. Si tu crawler no puede pasar ese filtro, un tercio de tus auditorías tiene datos incompletos.
Por qué pasa esto
Cuando un navegador establece una conexión HTTPS, negocia los parámetros de cifrado con el servidor. Esa negociación genera una huella digital llamada JA3 fingerprint. Chrome tiene la suya. Firefox tiene la suya. Screaming Frog —y prácticamente todo crawler estándar— tiene la de Python o Java, que no se parece a ningún navegador real.
Cloudflare tiene una base de datos de estas firmas. Cuando detecta que el request viene de una herramienta y no de un humano navegando, puede bloquearlo, servir contenido distinto, o devolver un CAPTCHA que el crawler no puede resolver.
El resultado en la práctica: el crawler te devuelve 403 en páginas que el navegador carga perfectamente, o —peor— te devuelve 200 con contenido de bloqueo que parece una página real. No sabés que algo falló.
Aclaración necesaria: no estoy diciendo que Screaming Frog sea una mala herramienta. Para sitios sin protección agresiva sigue siendo sólido y la interfaz es insuperable. Pero si el 30% del mercado está protegido con WAF y tu herramienta principal no puede pasar ese filtro, hay que nombrarlo.
Qué herramientas resuelven esto hoy
La solución técnica existe y no es nueva: usar librerías que suplantan la huella TLS a nivel de handshake, haciendo que el crawler se comporte como Chrome a nivel de protocolo. La más robusta en este momento es curl_cffi, que permite especificar exactamente qué fingerprint TLS emitir.
La herramienta que estoy usando y recomendando actualmente para este tipo de sitios es SEOdiag. Es un crawler SaaS enfocado en agencias B2B, construido sobre curl_cffi, que en mis pruebas pasó sin problemas en sitios donde Screaming Frog rebotaba sistemáticamente.
Lo que me convenció, además del motor, es el modelo de precios: credit-based, sin suscripción mensual forzada. Pagás por página auditada. Para el volumen de una agencia mediana que no hace auditorías técnicas profundas todos los días, tiene mucho más sentido económico que pagar $130/mes por Semrush para usar el 15% de sus funciones.
Los planes:
- Testing · $1 — 1.000 créditos, 30 días. Para ver si el motor funciona en tu caso específico.
- Growth · $29 — 50.000 créditos sin vencimiento, backlinks con DataForSEO incluidos.
- Agency · $99 — 500.000 créditos, White-Label, usuarios ilimitados.
El Testing a $1 es deliberadamente barato para que puedas probarlo en un dominio real antes de comprometerte con algo. Es la forma correcta de validar una herramienta técnica.
Mi opinión sobre cómo debería cambiar tu stack
No creo que la respuesta sea abandonar Screaming Frog. Creo que la respuesta es tener claro para qué sirve cada herramienta y cuándo usarla.
La forma en que lo estoy pensando ahora:
- Screaming Frog para sitios pequeños, sin CDN agresivo, donde necesito la interfaz visual para explorar la estructura rápido.
- SEOdiag para clientes con Cloudflare activo, sitios medianos y grandes, o cuando necesito el informe con análisis de IA integrado para presentar a alguien que no es técnico.
- Google Search Console siempre, en paralelo, como fuente de verdad sobre lo que Google realmente ve —que tampoco es lo mismo que lo que ve el crawler.
El punto de fondo es este: en 2026, una auditoría técnica que no contempla la posibilidad de bloqueo por WAF no es una auditoría completa. Podemos seguir usando las mismas herramientas de siempre, o podemos actualizar el stack a la realidad del mercado.
Yo elegí lo segundo.
¿Tenés casos donde el crawler te haya devuelto datos inconsistentes con lo que ve Google? Dejalo en los comentarios, me interesa armar un patrón con ejemplos reales.