Un especialista en SEO inicia una auditoría técnica de un gran sitio y, a los 10 minutos, Screaming Frog comienza a devolver constantes 403 Forbidden o 429 Too Many Requests. El servidor de protección ha confundido al crawler con un bot atacante y ha bloqueado la dirección IP. El resultado: la auditoría tendrá que reiniciarse y habrá que explicar al cliente por qué se ha retrasado el informe. Este problema se resuelve con una configuración adecuada de proxies para el crawler; veamos cómo hacerlo.
Por qué los sitios bloquean Screaming Frog durante la auditoría
Screaming Frog, Sitebulb, JetOctopus y Netpeak Spider funcionan técnicamente igual que los bots de los motores de búsqueda: recorren rápidamente miles de URL, descargan HTML, CSS, JS e imágenes, verifican redirecciones y códigos de estado. Desde la perspectiva de la protección del sitio (Cloudflare, Qrator, DDoS-Guard, WAF integrado del hosting), esto parece una actividad sospechosa: demasiadas solicitudes desde una sola IP en poco tiempo.
Las bloqueos ocurren especialmente durante la auditoría de:
- grandes tiendas en línea en infraestructuras similares a Wildberries con su propia protección contra scraping;
- sitios detrás de Cloudflare con el modo "Under Attack" activado o un alto nivel de Security Level;
- portales con contenido dinámico, donde cada solicitud genera carga en el servidor (búsqueda, filtros, listado de productos);
- sitios de competidores que se analizan desde un dominio diferente — no tienen razones para confiar en tu IP.
Una dificultad adicional: si la agencia tiene una sola IP estática de oficina y la auditoría de sitios se realiza regularmente (varios clientes al día), esta IP rápidamente termina en listas negras de sistemas de protección. Después de eso, se bloquean no solo las auditorías actuales, sino también futuras desde la misma dirección — incluso para sitios que antes se abrían sin problemas.
Cómo reconocer el bloqueo por códigos de respuesta
Antes de cambiar la configuración del proxy, es importante entender qué está sucediendo. Screaming Frog muestra el código de respuesta en la columna Status Code; a partir de esto, es fácil determinar la causa de la detención del crawling.
| Código de respuesta | Qué significa | Qué hacer |
|---|---|---|
| 403 Forbidden | IP bloqueada por la protección del sitio | Cambiar IP, reducir la velocidad de crawling |
| 429 Too Many Requests | Se ha superado el límite de solicitudes en un período de tiempo | Reducir el número de hilos, añadir un retraso |
| 503 Service Unavailable | El servidor está sobrecargado o la protección contra bots está activada | Cambiar User-Agent, usar IP residencial |
| Sin respuesta / Timeout | IP en lista negra, las solicitudes no llegan | Reemplazo completo del pool de proxies |
Si en el informe aparece masivamente el mismo código en miles de URL consecutivas, casi siempre se trata de un bloqueo por IP, y no de un problema real del sitio. Para comprobar la hipótesis, simplemente abre la URL problemática en un navegador normal desde la misma IP. Si la página se abre normalmente, pero Screaming Frog recibe un 403, el problema está en el crawler, no en el sitio.
Qué proxies son adecuados para el crawling SEO
La elección del tipo de proxy depende de la tarea: una auditoría única de su propio sitio, monitoreo regular de competidores o escaneo de un marketplace protegido. Vamos a analizar tres tipos principales y su aplicabilidad para los crawlers.
| Tipo de proxy | Velocidad | Riesgo de bloqueo | Cuándo usar |
|---|---|---|---|
| Proxies de centros de datos | Alta | Medio-alto en sitios protegidos | Auditoría de su propio sitio sin protección estricta |
| Proxies residenciales | Media | Bajo | Auditoría de competidores, sitios detrás de Cloudflare, marketplaces |
| Proxies móviles | Media-baja | Mínimo | Protecciones más agresivas, auditoría puntual rara |
Para la mayoría de las auditorías técnicas regulares, el equilibrio óptimo lo proporcionan proxies residenciales — utilizan direcciones IP reales de proveedores, por lo que la protección del sitio percibe las solicitudes del crawler como tráfico de un usuario normal. Esto es especialmente importante si estás analizando no tu propio dominio, sino el de un competidor o un marketplace con un sistema anti-bots estricto.
Los proxies de centros de datos siguen siendo una buena opción cuando auditas tu propio sitio y puedes agregar previamente el rango de IP a la lista blanca a nivel de WAF o Cloudflare — así la velocidad de escaneo será máxima sin riesgo de bloqueos.
Configuración paso a paso de proxies en Screaming Frog
Screaming Frog soporta proxies "out of the box", la configuración toma un par de minutos:
- Abre el programa y ve al menú Configuration → System → Proxy.
- Marca la opción Use Proxy Server for All Traffic.
- Introduce la dirección y el puerto del servidor proxy que recibiste del proveedor.
- Si el proxy requiere autenticación con nombre de usuario y contraseña, indícalos en la ventana emergente en la primera solicitud.
- Haz clic en OK y reinicia el crawling para aplicar la configuración.
Un matiz importante: Screaming Frog en su versión gratuita y de pago solo puede trabajar con un servidor proxy a la vez a través de la interfaz integrada. Si necesitas rotación de IP en tiempo real (relevante al escanear más de 50,000 páginas), utiliza proxies con cambio automático de IP del lado del proveedor — esto se configura no en el propio crawler, sino en el panel personal del servicio de proxies, donde se establece el intervalo de cambio de IP (por ejemplo, cada 10 minutos o en cada nueva solicitud).
Este esquema alivia la carga de una sola dirección: el crawler continúa trabajando con un solo puerto, mientras que la IP detrás de él cambia automáticamente, y el sitio no ve una frecuencia anormalmente alta de solicitudes desde una dirección específica.
Configuraciones de velocidad y hilos para grandes sitios
Incluso con un proxy funcional, configuraciones de velocidad de crawling demasiado agresivas provocarán bloqueos. En Screaming Frog, esto se controla en la sección Configuration → Speed. Los valores recomendados para sitios de más de 100,000 páginas son:
- Max Threads: 2–5 para sitios protegidos, 10–15 para sitios sin protección estricta;
- Max URI/s: limita a 2–3 solicitudes por segundo al inicio, aumentando gradualmente mientras observas los códigos de respuesta;
- Custom User-Agent: en la sección Configuration → HTTP Header, utiliza un User-Agent de un navegador real en lugar del estándar "Screaming Frog SEO Spider", si el sitio bloquea crawlers por el encabezado;
- Respect robots.txt / crawl-delay: ten en cuenta la directiva Crawl-delay, si está especificada — ignorarla a menudo lleva a un ban a nivel de servidor.
Para sitios con protección agresiva contra bots, también es útil activar el modo JavaScript Rendering solo donde sea realmente necesario (sitios SPA en React/Vue) — el renderizado de JS aumenta drásticamente la carga en el servidor y eleva la posibilidad de bloqueo al hacer crawling a través de una sola IP.
Rotación de IP al escanear más de 100,000 páginas
Cuanto más grande es el sitio, más importante es distribuir correctamente la carga entre las direcciones IP. Para auditorías de tal magnitud, funcionan dos esquemas:
Rotación por tiempo. La IP cambia automáticamente cada 5–15 minutos independientemente del número de solicitudes. Es adecuado para un crawling prolongado y uniforme, cuando el escaneo se extiende por varias horas.
Rotación por solicitud. Cada nueva solicitud HTTP se envía desde una nueva IP del pool. Este modo ofrece la máxima protección contra bloqueos, pero puede interferir con el correcto funcionamiento de la autorización basada en cookies o parámetros de sesión del sitio — para una auditoría técnica limpia (recolección de códigos de estado, redirecciones, metaetiquetas) esto no es crítico.
Para agencias que realizan auditorías paralelas de varios sitios de clientes, es razonable dividir los pools de IP por proyectos — esto evita la situación en la que un bloqueo en un dominio se "extiende por error" a la reputación de la IP al trabajar con otro sitio.
Consejo práctico: antes de una gran auditoría, realiza un crawling de prueba en 500–1000 URL con la configuración actual de velocidad y proxies. Si durante este tiempo no aparecen errores 403/429, puedes escalar el escaneo a todo el sitio sin problemas.
Lista de verificación antes de iniciar la auditoría
- ✅ Proxy conectado y probado por disponibilidad (verificación a través de curl o un navegador separado);
- ✅ Max Threads y Max URI/s configurados de manera conservadora para la primera ejecución;
- ✅ User-Agent configurado correctamente, no genera sospechas en el WAF;
- ✅ Respect robots.txt activado, si el sitio pide explícitamente respetar Crawl-delay;
- ✅ JavaScript Rendering activado solo cuando sea realmente necesario;
- ✅ Rotación de IP configurada para sitios de 20,000–30,000 páginas;
- ✅ Guardado del progreso del crawling activado (Configuration → Save Crawl) en caso de interrupción de sesión;
- ✅ Para auditorías de marketplaces y portales protegidos, se eligieron proxies residenciales o móviles en lugar de proxies de centros de datos.
Errores comunes al hacer crawling a través de proxies
Velocidad demasiado alta al inicio. Los especialistas a menudo establecen el máximo de hilos de inmediato, esperando acelerar la auditoría. Como resultado, la protección del sitio reacciona rápidamente, y en cuestión de minutos, todo el pool de proxies termina en la lista negra.
Una IP estática para todos los proyectos de clientes. Si la agencia utiliza el mismo proxy de centro de datos para decenas de auditorías al mes, la reputación de esta IP cae rápidamente — los sistemas de protección de diferentes sitios intercambian datos sobre direcciones sospechosas a través de bases de datos comunes (por ejemplo, Cloudflare IP Reputation).
Ignorar el geo-targeting. Si el sitio auditado está configurado para una región específica (por ejemplo, una tienda en línea rusa con geo-bloqueo de tráfico extranjero), el uso de proxies con IP de otro país provocará por sí mismo una restricción de acceso — incluso sin un crawling agresivo.
Falta de monitoreo durante el proceso. Al iniciar un crawling durante varias horas, los especialistas a menudo no revisan los códigos de respuesta intermedios. Como resultado, descubren el problema solo al finalizar, cuando la mitad del informe consiste en errores de bloqueo, y no en datos reales sobre el sitio.
Conclusión
Los bloqueos durante la auditoría técnica en Screaming Frog casi siempre se resuelven combinando tres factores: el tipo correcto de proxy, una velocidad de crawling razonable y una rotación adecuada de IP. Para los sitios propios sin protección estricta, son suficientes los proxies de centros de datos con adición a la lista blanca. Para auditar competidores, marketplaces y sitios detrás de Cloudflare, se necesitan IP que se asemejen al tráfico de usuarios normales.
Si regularmente auditas dominios ajenos o plataformas protegidas, te recomendamos comenzar con proxies residenciales — reducen el riesgo de bloqueo en los sistemas anti-bots más agresivos. Para tareas puntuales en recursos altamente protegidos, vale la pena considerar proxies móviles, mientras que para auditorías masivas de infraestructura propia, los proxies de centros de datos siguen siendo una buena y rápida solución.