Cómo hacer web scraping sin ser bloqueado (2026)

Para hacer web scraping sin ser bloqueado, mi orden de prioridades es: respetar robots.txt y las condiciones del sitio, limitar las peticiones a un ritmo humano con backoff exponencial, enviar cabeceras de navegador completas y coherentes, mantener cookies estables en cada sesión y repartir el volumen legítimo entre IPs residenciales rotativas, vigilando los códigos de estado desde el inicio.

Que te bloqueen no es mala suerte. Es la pila anti-bot de un sitio identificando correctamente tráfico que no parece una persona navegando, o tráfico al que ya le pidió explícitamente que se fuera. Esta guía cubre las prácticas de ingeniería que mantienen en marcha los proyectos de scraping legítimos (monitorización de precios, seguimiento SEO, verificación de anuncios, datos de entrenamiento para IA, investigación de mercado) y es explícita sobre las líneas que no ayudamos a cruzar a nadie. Para ver el panorama completo de cómo funciona el scraping de principio a fin, empieza por nuestra guía de web scraping.

Empieza por las reglas: robots.txt y términos de servicio

Antes de optimizar nada técnico, determina si deberías estar haciendo scraping de ese objetivo en absoluto.

1. Descarga y analiza robots.txt. El archivo en la raíz del sitio declara qué rutas están vetadas a los crawlers y a menudo incluye una directiva Crawl-delay. Respetarlo es la señal más clara de que tu proyecto actúa de buena fe, y la mayoría de los frameworks de scraping maduros pueden aplicarlo automáticamente.
2. Lee los términos de servicio. Algunos sitios prohíben directamente el acceso automatizado; otros restringen usos concretos. Que las cláusulas de los ToS sean exigibles varía según la jurisdicción y el caso — nuestro repaso sobre si el web scraping es legal cubre las sentencias principales —, pero saber qué dice el sitio es una obligación de base, no un extra opcional.
3. Prefiere los canales oficiales. Si el sitio ofrece una API, un feed de datos o un programa de licencias que cubra tu caso de uso, úsalo. Es más estable que el scraping y elimina por completo el problema de los bloqueos.
4. Acota tu recolección. Toma solo los campos que necesitas, solo de páginas públicas, y excluye cualquier cosa que identifique a personas. Bajo el RGPD y regímenes similares, los datos personales conllevan obligaciones que la mayoría de los proyectos de scraping no están preparados para cumplir.

Nuestra postura de cumplimiento, dicha sin rodeos: ProxyFacts no ofrece orientación para saltarse muros de pago o de login, derrotar CAPTCHAs a escala mediante granjas de resolución, extraer datos personales ni automatizar compras (bots de zapatillas, reventa de entradas, creación de cuentas). La ingeniería anti-bloqueo, tal como se trata aquí, consiste en hacer fiable el acceso legítimo, no en conseguir un acceso que nunca te fue permitido.

Entiende por qué los sitios bloquean a los scrapers

Los sistemas anti-bot buscan patrones que ningún humano produce. Conocer las capas de detección te dice qué corregir:

De aquí se derivan dos implicaciones. Primera: la rotación de IP por sí sola arregla una única capa — un scraper con IP rotativa pero con el User-Agent por defecto de Python sigue cayendo en la capa dos. Segunda: las capas se acumulan — cabeceras coherentes con sesiones incoherentes resultan más sospechosas que cualquiera de los dos fallos por separado. Un trabajo anti-bloqueo eficaz consiste en que todas las capas cuenten la misma historia, y que sea verdad: un cliente razonable haciendo un número razonable de peticiones.

Límite de peticiones y backoff: el arreglo de mayor impacto

La forma más rápida de que te bloqueen es enviar peticiones tan rápido como tu conexión lo permita. Es lo primero que revisaría en cualquier scraper bloqueado, porque la solución no cuesta casi nada:

• Fija una base conservadora. Una petición cada pocos segundos por dominio es un punto de partida sensato para la mayoría de los sitios. Si robots.txt declara un Crawl-delay, trátalo como un mínimo, no como una sugerencia.
• Añade jitter. Aleatoriza el retardo entre peticiones (por ejemplo, un retardo base multiplicado por un factor aleatorio entre 0.5 y 1.5). Los intervalos perfectamente regulares son una firma de máquina.
• Implementa backoff exponencial. Ante un HTTP 429 o 503, espera y reintenta con un retardo que se duplica: 1 segundo, 2, 4, 8, y así sucesivamente, con un tope razonable. Si la respuesta incluye una cabecera Retry-After, obedécela al pie de la letra.
• Presupuesta la concurrencia por dominio, no en global. Veinte workers concurrentes repartidos entre veinte sitios están bien; veinte workers sobre un solo sitio son una ráfaga que parece un ataque.
• Programa fuera de las horas punta. Rastrear una tienda online durante su pico de tráfico compite con clientes reales por los recursos del servidor. Rastrear en horas valle es más educado y es menos probable que dispare defensas basadas en carga.

Un scraper que respeta estas reglas a menudo no necesita ningún otro trabajo anti-bloqueo para tareas pequeñas y medianas. Todo lo que sigue importa sobre todo a medida que crece el volumen.

Envía cabeceras realistas y coherentes

Las cabeceras por defecto de los clientes HTTP anuncian exactamente lo que eres. Corrige las delaciones obvias:

1. Configura un User-Agent de navegador real — una cadena de Chrome o Firefox actual, no el valor por defecto de una librería ni una versión de navegador con años de antigüedad.
2. Envía el conjunto completo de cabeceras que enviaría ese navegador: Accept, Accept-Language, Accept-Encoding y las cabeceras de client hints Sec-CH-UA que incluye el Chrome moderno. Un User-Agent de Chrome sin client hints es una contradicción que los sistemas de fingerprinting cazan.
3. Mantén las cabeceras coherentes entre sí. Accept-Language debería coincidir con la geografía que declara tu IP. Una IP residencial española combinada con una única cabecera de idioma en-US es una incoherencia.
4. Configura un Referer plausible. A las páginas profundas de un sitio se llega normalmente desde algún lugar, no se invocan de la nada.
5. Rota los User-Agents con moderación y correctamente. Si rotas, rota el paquete completo de cabeceras coherentes en bloque — nunca mezcles el User-Agent de un navegador con los client hints de otro.

Si el objetivo renderiza el contenido con JavaScript y desafía a los clientes que no son navegadores, el trabajo de cabeceras no bastará por sí solo; necesitarás un navegador headless real, y llegados a ese punto una API de scraping gestionada suele tener más sentido que construir la pila tú mismo; operar una flota de navegadores en producción es el tipo de infraestructura que yo no asumiría sin un motivo de peso — mira nuestra comparativa de APIs de scraping frente a proxies puros para ver dónde se inclina la balanza.

Gestiona sesiones y cookies con intención

Los sitios usan cookies para seguir la continuidad de un visitante. A los scrapers los marcan cuando esa continuidad se rompe:

• Acepta y persiste las cookies dentro de una sesión lógica. Un cliente que recibe una cookie de sesión y nunca la devuelve parece roto u hostil.
• Mantén emparejados la IP y el bote de cookies. Una cookie de sesión que llega desde tres países en diez minutos es un viajero imposible. Si rotas IPs, rota los botes de cookies con ellas.
• Ajusta el tipo de sesión a la tarea. Las tareas sin estado — descargar miles de páginas de producto independientes — encajan con rotación de IP por petición y sin cookies persistentes. Los flujos con estado — paginar un conjunto de resultados de búsqueda, recorrer un listado de varias páginas — necesitan una sesión sticky donde IP y cookies permanezcan fijas mientras dure el flujo.
• Caduca las sesiones como lo haría un humano. Nadie navega por un mismo sitio de forma continua durante 72 horas. Retira las identidades de sesión tras una vida útil plausible y empieza de cero.

Los grandes proveedores de proxies residenciales exponen control de sesión exactamente por esta razón. Según sus páginas de producto (consultadas en julio de 2026): Oxylabs ofrece sesiones rotativas más sesiones sticky de hasta 24 horas; Decodo (antes Smartproxy) ofrece rotación por petición y sesiones sticky desde minutos hasta días; IPRoyal admite intervalos sticky de hasta 7 días; y Bright Data ofrece tanto modo sticky como rotativo. Qué ventana necesitas depende por completo de cuánto dura tu flujo con estado más largo.

IPs residenciales rotativas para volumen legítimo

Cuando un proyecto necesita escala de forma legítima — pongamos, monitorizar 100,000 páginas de producto al día o comprobar posiciones de búsqueda desde 20 países —, una sola IP no puede soportar la carga sin superar cualquier tasa razonable por IP. Distribuir las peticiones entre un pool de IPs residenciales mantiene la tasa de peticiones por IP en un rango plausible para un humano mientras el trabajo agregado termina a tiempo. Las IPs residenciales, además, tienen la reputación normal de un consumidor, a diferencia de los rangos de datacenter que muchos sitios bloquean en masa — los fundamentos están en nuestro explicador de qué es un proxy residencial.

Los cuatro proveedores que seguimos publican las siguientes capacidades relevantes (todas las cifras proceden de sus páginas de producto y de políticas, consultadas en julio de 2026; los tamaños de pool son afirmaciones del proveedor, no verificadas de forma independiente):

Fíjate en la última fila. Todo proveedor serio verifica a sus clientes porque su negocio depende de mantener el abuso fuera de la red. Bright Data restringe el acceso a su red residencial a empresas verificadas que superan un proceso KYC con revisión humana, según su FAQ de KYC. Oxylabs exige un formulario KYC a cada cliente en el registro, con escalado según riesgo, según su política de KYC y seguridad. Decodo ejecuta controles antifraude automatizados y KYC en cada registro y bloquea activamente objetivos de alto riesgo como banca y venta de entradas, según su página de seguridad y cumplimiento. IPRoyal realiza el KYC a través del proveedor externo iDenfy, según su política de KYC. Si tu caso de uso no sobrevive a la revisión de cumplimiento de un proveedor, el problema es el caso de uso, no el proveedor.

Perspectiva del ingeniero (Hinata): Antes de comparar tamaños de pool, yo haría la aritmética de gigabytes: con precios de entrada entre 4 y 7.35 dólares por GB, la factura la define el peso medio de página multiplicado por el número de páginas, no el logo del proveedor. La trampa clásica es el navegador headless, que descarga JavaScript, CSS e imágenes y multiplica el consumo frente a peticiones de HTML puro; decidir qué parte del objetivo puedes extraer sin renderizar es la decisión de coste más importante del proyecto. Y como los tamaños de pool son cifras del propio proveedor, empezaría por el plan más pequeño disponible y mediría la tasa de éxito sobre mi objetivo real antes de comprometer presupuesto.

Guía práctica de rotación para volumen legítimo:

• Dimensiona el pool según la tasa, no según el ego. Lo que importa es que las peticiones por IP por hora sigan siendo plausibles para un humano en tu objetivo concreto, no la cifra de pool del titular. El Proxy Market Research 2026 de Proxyway (datos recogidos entre marzo y abril de 2026) sitúa la mediana del pool residencial anunciado en 54M de IPs — cualquier proveedor grande tiene más direcciones de las que necesita cualquier trabajo legítimo.
• Usa la segmentación geográfica con propósito. Si monitorizas precios en España, solicita IPs españolas y envía cabeceras coherentes con el mercado español. La segmentación geográfica sirve para ver lo que ven los usuarios locales reales, no para evadir baneos a nivel de región.
• Mantén alineadas la rotación y la estrategia de sesión, como se describe en la sección de sesiones de arriba.

Para criterios de selección de proveedor más allá de los bloqueos — estructuras de precios, pruebas, soporte —, consulta nuestro ranking de los mejores proxies residenciales.

Por qué los proxies gratuitos empeoran los bloqueos, no los mejoran

El atajo tentador fracasa ante la evidencia. Un estudio académico longitudinal de 30 meses sobre más de 640,600 proxies gratuitos de 11 proveedores, presentado en NDSS MADWeb 2024, halló que solo el 34.5% estuvo activo en algún momento, identificó 4,452 vulnerabilidades distintas en IPs de proxies — incluidas 1,755 que permitían ejecución remota de código — y cazó a 16,923 proxies manipulando el contenido en tránsito.

Para el anti-bloqueo en concreto, los proxies gratuitos son contraproducentes: esas IPs las comparte cualquier otro scraper de nivel gratuito que golpea los mismos objetivos, así que llegan ya quemadas en las listas de bloqueo de los grandes sitios. Heredas la mala reputación de otros además de tu propio riesgo. En ningún diseño que yo firmara entraría un proxy gratuito en el camino de datos de producción. El argumento completo está en nuestro análisis de proxies gratuitos frente a de pago.

Vigila las señales de bloqueo de forma continua

Los bloqueos rara vez llegan de golpe; escalan. Instrumenta tu scraper para ver esa escalada a tiempo:

1. Mezcla de códigos de estado por dominio. Una proporción creciente de respuestas 403, 429 o 503 es la primera alarma. Alerta sobre tendencias, no sobre fallos aislados.
2. Detección de CAPTCHAs y páginas de desafío. Muchos sitios devuelven HTTP 200 con una página de desafío en lugar del contenido. Toma la huella de las páginas de desafío (patrones de título, marcado conocido) y cuéntalas como fallos, o tus métricas de éxito te mentirán.
3. Anomalías de tamaño de respuesta y de contenido. Una página de producto que de repente devuelve 5 KB en lugar de 80 KB, o cuyo parseo extrae cero campos, es probablemente una página de bloqueo o datos señuelo.
4. Cambios de latencia. La ralentización progresiva — respuestas que pasan de 300 ms a 5 segundos — es una señal de bloqueo blando que precede a los baneos duros.
5. Tasa de éxito por subred de proxy y por sesión. Si los fallos se concentran en rangos de IP concretos, retira esos rangos; si se concentran en sesiones longevas, acorta la vida de tus sesiones.

Cuando saltan las señales, la respuesta correcta es frenar y diagnosticar, no escalar la agresividad. Reduce tu tasa de peticiones a la mitad, verifica que tus cabeceras siguen correspondiendo a un navegador actual, comprueba si el sitio cambió su estructura o sus condiciones, y solo entonces reanuda. Los scrapers que responden a los bloqueos apretando más convierten una ralentización temporal en un baneo permanente.

Lo que deliberadamente no vamos a cubrir

Algunas preguntas de anti-bloqueo tienen respuestas que no publicaremos, porque la técnica solo existe para derrotar controles de acceso:

• Saltarse muros de pago o de login. El contenido tras autenticación tiene el acceso controlado por diseño. Automatizar para rodear ese control es acceso no autorizado, sea cual sea la herramienta.
• Granjas de resolución de CAPTCHAs. Un CAPTCHA es un sitio diciendo no a la automatización. La resolución a escala industrial existe para anular esa negativa.
• Scraping de datos personales. Nombres, correos, perfiles y datos de contacto conllevan obligaciones legales (RGPD, CCPA) y un potencial de daño real. Los proveedores serios bloquean estos casos de uso en sus políticas de uso aceptable por una buena razón.
• Automatización de compras. Los bots de zapatillas, la reventa de entradas y las granjas de cuentas son los casos de uso que dieron mala fama a los proxies y los que los programas KYC de los proveedores existen para filtrar.

Si un proyecto necesita cualquiera de estas cosas, no tiene un problema de bloqueos; tiene un problema de permisos, y ninguna ingeniería arregla eso.

Checklist: una configuración anti-bloqueo ética

• Lee robots.txt y los ToS; confirma que los datos son públicos y no personales
• Prefiere una API o un feed oficial cuando existan
• Limita las peticiones por dominio con jitter; obedece Retry-After; aplica backoff exponencial
• Envía un conjunto de cabeceras de navegador actual, completo y coherente entre sí
• Persiste las cookies dentro de cada sesión; empareja botes de cookies con IPs; caduca las sesiones de forma plausible
• Usa IPs residenciales rotativas de un proveedor que exija KYC cuando el volumen lo requiera de verdad
• Ajusta las ventanas de sesión sticky a tu flujo con estado más largo
• Vigila códigos de estado, páginas de desafío, anomalías de contenido y latencia por dominio
• Responde a las señales de bloqueo frenando y diagnosticando, nunca escalando

Planteado así, el anti-bloqueo no es una carrera armamentística: es cortesía básica expresada en ingeniería. Los sitios bloquean el tráfico que se comporta mal; el arreglo duradero es un tráfico que se comporte bien. Para el contexto más amplio sobre herramientas, legalidad y arquitectura, continúa con nuestra guía completa de web scraping.