¿Scraping web limitado? Resolver fingerprinting, bloqueos de IP, CAPTCHAs e inicio de sesión multi-cuenta

Cuando un trabajo de scraping se topa con 403, 429, un CAPTCHA o fallos de inicio de sesión repetidos, la respuesta correcta no es rotar IPs, enmascarar huellas o intentar «imitar a una persona real». Estas señales suelen indicar que la frecuencia de peticiones, el alcance del acceso, el método de autenticación o el comportamiento automatizado han cruzado un límite que el sitio está dispuesto a permitir. Seguir forzando el paso suele escalar la restricción y puede infringir los términos de servicio, contratos, derechos de autor o normativa de protección de datos.

Un camino más estable consiste en confirmar primero la autorización y las interfaces disponibles, después reducir el tráfico, aplicar caché y backoff cuando haga falta, y dejar la automatización del navegador solo para las páginas que realmente requieren renderizado de JavaScript o un inicio de sesión humano. Trata un CAPTCHA como una señal de pausa, no como un obstáculo técnico que haya que romper.

Empieza por el síntoma para acotar la causa

Síntoma	Causa frecuente	Respuesta conforme
429 Too Many Requests	Peticiones demasiado rápidas, demasiado paralelas o repetidas	Reducir la velocidad, respetar Retry-After, usar backoff exponencial
403 Forbidden	Ruta no autorizada, bloqueo por política, falta de sesión	Revisar permisos, términos, robots.txt y método de autenticación
Aparece un CAPTCHA	El sitio exige verificación humana o bloquea la automatización	Pausar la tarea, hacerla manualmente o pedir una API
El inicio de sesión falla repetidamente	Cookies caducadas, sesiones sobrescritas, autenticación fallida	Usar OAuth oficial o cuentas de servicio, organizar la entrega de sesiones
La página tiene contenido pero el script no lo lee	Renderizado de JavaScript, carga asíncrona de la API	Usar la API oficial; con permiso, renderizar en un navegador y leer el DOM
Los selectores dejan de funcionar de repente	Rediseño del DOM, prueba A/B, cambio de idioma	Usar localizadores semánticos, pruebas estructurales y alertas, evitar jerarquías codificadas
Datos duplicados o faltantes	Paginación, cursores, zonas horarias, ventana de actualización	Crear claves únicas, marca de agua incremental y mecanismo de reejecución

Cambia una sola variable cada vez y conserva registros. Si modificas a la vez la IP, el User-Agent, la cuenta y el parser, puedes acertar por casualidad pero no podrás saber qué cambio resolvió realmente el problema.

Paso 1: confirma que tienes derecho a recoger estos datos

Antes de empezar, responde cuatro preguntas:

1. ¿Los datos son públicos, o solo están disponibles tras iniciar sesión, pagar o para ciertos roles?
2. ¿Ofrece el sitio una API, una exportación, un feed, un webhook o una interfaz de datos para socios?
3. ¿Los términos de servicio, robots.txt, los contratos y la legislación local permiten el uso previsto?
4. ¿Incluyen los datos información personal, contenido protegido por derechos de autor u otros campos sensibles?

robots.txt es el mecanismo estándar por el que un sitio expresa a los clientes automatizados qué rutas permite o prohíbe. La RFC 9309 define la sintaxis y las reglas de coincidencia del Robots Exclusion Protocol y deja claro que robots.txt no es una autorización de acceso. En otras palabras, que robots.txt lo permita no te da el derecho completo a copiar, tratar o usar comercialmente los datos; las rutas prohibidas no deben sortearse por otra entrada.

Los proyectos empresariales deben documentar las fuentes de datos, la base del acceso, el uso, los campos, el periodo de retención y el mecanismo de borrado. Cuando los datos agregados resuelvan el problema, evita recoger información que permita identificar a personas.

Paso 2: prioriza puntos de entrada de datos estables

El orden habitual de prioridad es:

1. API oficiales, webhooks o exportaciones de datos;
2. feeds públicos, sitemaps o archivos por lotes;
3. páginas HTTP ordinarias con permiso;
4. automatización del navegador solo cuando sea imprescindible renderizar JavaScript;
5. páginas que requieren cuenta humana e interacción, al final.

Las API suelen ofrecer definiciones de campos, paginación, límites de velocidad y códigos de error, por lo que mantenerlas es más barato que parsear una interfaz. Una página web es una superficie para ojos humanos; puede cambiar en cualquier momento y no debe tratarse como una base de datos estable.

Si el sitio no tiene una interfaz adecuada, contacta primero con el propietario de los datos y explica el uso, la frecuencia, los campos y el alcance comercial. Una licencia clara suele ser más barata que una pelea larga contra las restricciones.

Paso 3: aborda los 429 y los bloqueos de IP reduciendo carga, no ocultando el origen

Define topes de velocidad y concurrencia

Empieza con un único worker y un intervalo generoso, y observa el tiempo de respuesta y la tasa de error. Cuando el servidor devuelva Retry-After, espera exactamente ese tiempo. Si no, aplica backoff exponencial con jitter aleatorio para que varias tareas no reintenten a la vez.

Una política sencilla:

espera = min(tope, base × 2^reintentos) + jitter

Cuando alcances el número máximo de reintentos, detente y emite una alerta. No entres en bucles infinitos.

Aplica caché y actualizaciones incrementales

Pon en caché la misma URL y, cuando sea posible, envía peticiones condicionales con ETag o Last-Modified. Registra la última hora de actualización o un cursor para traer solo lo nuevo o lo modificado. Separar las tareas completas de las incrementales diarias reduce mucho el volumen de peticiones.

Identifica a tu cliente con honestidad

Un crawler conforme utiliza un User-Agent estable y real, declara su propósito y ofrece una página de contacto o un correo. Hacerse pasar por un navegador genérico y cambiar de identidad con frecuencia dificulta al sitio distinguir el tráfico bueno del malo, lo que aumenta las posibilidades de bloqueo.

Si una IP queda restringida, pausa la tarea y revisa la causa. Rotar proxies para seguir accediendo puede interpretarse como un modo de eludir los controles de acceso, no como una solución.

Paso 4: trata el fingerprinting y el análisis de comportamiento

Las huellas del navegador combinan señales como el User-Agent, el sistema operativo, el idioma, la zona horaria, la resolución, Canvas y WebGL. El sitio también puede analizar la cadencia de peticiones, las rutas de navegación y el comportamiento de la sesión. OWASP enumera Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing y otros como categorías diferenciadas de amenazas automatizadas, lo que explica por qué un sitio suele combinar varias señales para evaluar el riesgo de automatización.

Para tareas autorizadas, el objetivo no es producir muchas identidades «humanas», sino mantener el entorno estable y explicable:

• usar un entorno fijo y autenticación normal para la misma cuenta de negocio;
• mantener los parámetros del navegador coherentes con la región y el dispositivo reales;
• no modificar huellas al azar para esquivar bloqueos;
• registrar la frecuencia de recogida, el ID de tarea y la persona responsable;
• acordar con el sitio el número de cuentas, la concurrencia y el alcance de datos permitidos.

Si aun así el sitio clasifica mal una tarea autorizada, facilítale marcas de tiempo, User-Agent, IP de salida y muestras de peticiones, y pide que te incluya en una lista blanca o te proporcione una interfaz dedicada.

Paso 5: detén la automatización cuando aparece un CAPTCHA

El CAPTCHA existe para confirmar a una persona o para bloquear automatizaciones sospechosas. No uses OCR, servicios de resolución de CAPTCHA, plugins para romper CAPTCHA ni cualquier otro medio de salto automático.

El flujo correcto es:

1. pausar de inmediato la cuenta actual y la cola de tareas;
2. guardar la frecuencia de peticiones, las rutas y el registro de errores justo antes de que se disparara;
3. que una persona autorizada complete la verificación necesaria en la página oficial;
4. comprobar si las peticiones eran demasiado rápidas, si la sesión había caducado o si se accedió a una ruta no permitida;
5. para automatizaciones de larga duración, solicitar al sitio una API, una cuenta de servicio o una lista blanca.

Aunque una persona resuelva un CAPTCHA una vez, eso no te da derecho a enviar luego peticiones automatizadas ilimitadas. Primero corrige la causa.

Paso 6: gestiona los inicios de sesión y el multi-cuenta con permisos formales

Los datos tras un inicio de sesión son más sensibles que las páginas públicas. Prioriza OAuth, cuentas de servicio, tokens de API o permisos concedidos por el equipo oficial de la plataforma. No permitas que un script guarde la contraseña principal de una persona.

Cuando la sesión del navegador sea realmente necesaria:

• una cuenta de negocio legítima se asocia a un entorno estable;
• almacena las cookies cifradas, con caducidad y forma de revocarlas;
• activa MFA y no permitas que la automatización omita la doble verificación;
• prohíbe que varias personas reinicien contraseñas o copien cookies al mismo tiempo;
• registra quién inició qué tarea y cuándo;
• revoca el acceso de inmediato cuando alguien se vaya, termine el proyecto o cambie el rol.

El multi-cuenta solo aplica a cuentas que realmente posees o cuyo uso te han autorizado. Cuando un sitio limita a una entidad a una sola cuenta, el aislamiento de entornos no debe usarse para saltarse ese límite.

Paso 7: haz que el parseo de páginas dinámicas resista mejor los rediseños

Usa atributos semánticos y estables

Prioriza títulos, encabezados, atributos de accesibilidad e identificadores de prueba públicos del sitio. Evita jerarquías frágiles como div:nth-child(7). Vuelve a leer el DOM tras refrescar la página, no asumas que un nodo antiguo sigue ahí.

Separa la extracción de la lógica de negocio

La capa de recogida solo convierte la página en campos estructurados. La capa de validación revisa tipos, rangos, claves únicas y campos obligatorios. Con esa separación, un rediseño solo toca el parser y no rompe el análisis posterior.

Crea muestras y alertas

Guarda un número reducido de instantáneas HTML o estructurales conformes como muestras de prueba. No almacenes páginas de cuenta completas ni datos sensibles. Monitoriza tasas de campos faltantes, número de registros, tasa de duplicados y títulos de página; cuando se desvíen, deja de escribir en producción.

El papel adecuado de PurpleMark en el scraping autorizado

Cuando un equipo debe mantener a la vez varias cuentas autorizadas, distintos entornos de clientes o de regiones, puede usar el PurpleMark web app para crear un entorno de navegador independiente por cada cuenta de negocio y guardar juntos las cookies correspondientes, la página que se debe abrir tras iniciar sesión y la configuración de red habitual. Al volver a abrir ese entorno, el navegador regresa a la última sesión y a la página de trabajo, evitando que varias personas compartan un mismo juego de cookies y ahorrando tener que volver a iniciar sesión cada vez.

Cuando hay que separar cuentas por cliente, plataforma o región, los grupos de entornos permiten clasificar las cuentas de negocio en carpetas distintas, y los permisos de miembros, el uso compartido y la transferencia definen quién puede abrir cada entorno. El registro de operaciones guarda cuándo y quién abrió o modificó cada entorno. Si surge una duda sobre un scraping autorizado, se puede rastrear rápidamente hasta una cuenta concreta y un responsable identificado.

PurpleMark ayuda a un equipo a mantener «cuentas, entornos, sesiones y responsabilidad» en un único espacio de trabajo a lo largo del tiempo, pero no está pensado para saltarse bloqueos de IP, CAPTCHAs, límites de número de cuentas o las defensas antiautomatización de un sitio. Primero consigue la autorización, después habla de automatización.

Una arquitectura de scraping mantenible

Una separación útil en cinco capas:

1. Planificación: controla frecuencia, concurrencia, prioridad de tareas y pausas;
2. Acceso: API, HTTP o sesión de navegador autorizada;
3. Parseo: convierte las respuestas en campos estructurados;
4. Calidad: deduplicación, comprobaciones de tipo, alertas por campos faltantes y registro de versiones;
5. Gobernanza: permisos, origen, uso, periodo de retención y borrado.

Cada registro conserva la URL de origen, la hora de recogida y la versión del parser. Si algo falla, puedes localizar y reejecutar los registros afectados en vez de re-rastrear todo el sitio.

Preguntas frecuentes

¿Rotar proxies resuelve un bloqueo de IP?

Puede cambiar la dirección de salida un rato, pero no soluciona el problema de frecuencia, permisos o comportamiento. Rotar proxies para mantener el acceso puede contar como elusión. Detén primero la tarea, reduce las peticiones y contacta con el sitio.

¿Se puede resolver un CAPTCHA automáticamente?

No. Un CAPTCHA es una señal para pausar o para que intervenga una persona. Para automatizaciones continuas, solicita una API, una cuenta de servicio o una lista blanca.

Si robots.txt lo permite, ¿siempre se puede scrapear?

No necesariamente. robots.txt no es una autorización de acceso; también hay que considerar los términos, derechos de autor, privacidad, contratos y el uso previsto de los datos.

¿Un navegador anti-detección hace que el scraping sea «indetectable»?

No se puede garantizar, y no debería ser el objetivo. Resulta más útil para separar las sesiones legítimas de cuentas y los permisos del equipo, y para reducir confusiones de cookies y errores de manejo.

Cierre

Las restricciones del scraping web no son solo un «problema técnico anti-bot». Los 403, 429, fingerprinting, CAPTCHAs y límites de multi-cuenta apuntan todos a permisos, carga y gestión de identidad.

Un enfoque estable siempre vuelve a la API como prioridad, autorización clara, peticiones contenidas, caché incremental, parseo testeable y cuentas auditables. Cuando aparezca un CAPTCHA o un bloqueo, detente y corrige el proceso en lugar de seguir ocultando el origen de la automatización.