Cómo hacerse pasar por humano: web scraping sin bloqueos

Hay una especie de prueba de Turing: la máquina intenta convencer al humano de que también es humano. En el scraping pasa exactamente al revés: es el sitio el que intenta entender que no eres humano, y tú intentas convencerlo de lo contrario. Y cuanto mejor entiendes cómo exactamente el sitio te está mirando, más fácil es lograrlo. Analicemos por capas.

Capa primera: parecer humano

Escribo scrapers con Playwright — es una herramienta que controla un navegador real: Chromium, WebKit o Firefox. No emula solicitudes HTTP, sino que ejecuta un motor real, como lo hace un usuario común.

Pero eso no basta. El problema es que el navegador headless por defecto se delata: en las cabeceras hay señales características, navigator.webdriver sobresale como bandera, los parámetros del entorno difieren de un Chrome normal. Los sistemas anti-bot conocen esas señales de memoria, y no hay ninguna máscara que las oculte — simplemente está escrito “soy un bot” con otras palabras. Playwright permite reconfigurar todo eso: User-Agent correcto, cabeceras correctas, parámetros de inicio adecuados.

El siguiente paso es configurar el fingerprint. Hay que entender que los sitios grandes son sistemas enormes que reciben datos de multitud de fuentes: trackers publicitarios, contadores de visitas, etiquetas de sistemas de tracking, analíticas de comportamiento. Todo eso forma un perfil incluso antes de que entres al sitio objetivo, y hay que corresponderse con ese perfil. Un navegador con cookies vacías inmediatamente despierta sospechas — o es un paranoico, o es un bot; casi siempre es lo segundo. Por eso, antes de iniciar la sesión suelo visitar una pequeña lista de sitios habituales que contienen tanto contadores como trackers publicitarios — todo para que esos sistemas creen nuestro fingerprint, y al entrar al sitio objetivo ya den la señal: es un humano conocido, aquí está su perfil.

Y lo último en esta capa es la dirección IP. Las direcciones de servidores en centros de datos se detectan rápido, porque sus rangos son bien conocidos por los sistemas anti-bot — esas direcciones inmediatamente parecen una bandera roja para cualquier sitio grande. La elección aquí es clara: proxies residenciales. Sí, son mucho más caros, pero funcionan donde los servidores ya no pasan.

Capa segunda: comportarse como humano

Bien, técnicamente ya parecemos humanos. Pero eso no es suficiente — también hay que comportarse como tal.

Piensa cómo se comporta un usuario real en un sitio. No abre una página y empieza a hacer clics metódicos inmediatamente. Hace scroll, mueve el ratón, lee algo que no era, sigue enlaces dentro del sitio — y todo eso sin ningún sistema ni previsibilidad. Exactamente eso es lo que hay que reproducir: movimientos aleatorios del ratón, scroll, navegación mediante clics en los elementos de la página, no mediante un goto directo.

Podría parecer que perdemos tiempo en esas acciones extra. En realidad no — y aquí está el porqué. Una sesión que se comporta de forma natural vive más tiempo, y levantar una nueva sesión cuesta recursos: nueva dirección del pool de proxies, nueva instancia del navegador, nuevo precalentamiento de cookies. Gastar unos segundos en hacer scroll para que la sesión funcione durante horas no es una pérdida, es una inversión. La diferencia entre “100 páginas en una corrida” y “miles de intentos en vacío” es bastante palpable.

Otro punto que no es obvio de inmediato: siempre entro primero en la página principal del servicio y luego voy a la sección necesaria. Un usuario que aparece directamente en la página de resultados de búsqueda o en la ficha de un producto y empieza a hacer clics activamente se ve sospechoso, porque la gente no se comporta así. Entró en la página principal, miró alrededor, siguió adelante — es otra historia.

Y sobre la rotación: no conviene trabajar con un mismo esquema demasiado tiempo. Las direcciones cambian, los perfiles de fingerprint rotan, los patrones de comportamiento varían — porque la previsibilidad en sí misma también es una señal.

Un punto aparte sobre el captcha. Muchos lo ven como un problema que hay que resolver: comprar un servicio de reconocimiento, integrarlo en el pipeline y seguir adelante. Pero esa es una formulación incorrecta, porque el captcha no es una barrera, es un indicador. Indica que el sistema ya te considera sospechoso, y el grado de sospecha influye directamente en lo que verás. Yandex, por ejemplo, a veces muestra un captcha que se resuelve con un clic en el campo correcto — pero solo si eres solo un sospechoso. Si te consideran un bot, mostrarán uno gráfico: complejo, lento, caro de resolver. El objetivo correcto no es “resolver captchas rápidamente”, sino “nunca llegar a ellos”.

Capa tercera: pensar como ingeniero

Los sitios modernos a menudo entregan los datos no en HTML, sino a través de solicitudes XHR: la página carga y luego obtiene datos mediante peticiones separadas a una API. Al verlo en DevTools, da la tentación de encontrar esos endpoints y llamarlos directamente con un fetch normal, evitando el navegador por completo — rápido, barato, sin sobrecarga.

Los dueños de los sitios no son tontos: los endpoints se cierran con un token, verifican estrictamente quién los solicita y desde dónde, y además se verifica el fingerprint — como resultado obtendrás los datos como mucho un par de veces, y luego un error 429 detendrá tu scraping para siempre.

Esto es lo que funciona bien. Cuando Playwright abre la página, todas las solicitudes XHR pasan por el navegador con todas las cabeceras correctas, cookies y contexto — exactamente como lo hace un usuario real. Con page.on('response', ...) puedes escuchar todos los eventos de red e interceptar las respuestas necesarias en el momento de la carga. El navegador recibió JSON — nosotros también lo recibimos, de forma asíncrona y sin movimientos innecesarios. No hay que parsear el DOM, no hay que buscar datos en selectores que se romperán en el siguiente rediseño.

Qué solicitud interceptar hay que verlo una vez en DevTools y entender la estructura. Ese es el trabajo del ingeniero: comprender cómo está montado el sistema, elegir la estrategia óptima, tomar una decisión. No tirar todo a una LLM esperando un milagro — aquí hay que pensar, no generar.

Escalado: si necesitas más — tomas más

Toda esta construcción escala bien horizontalmente — y esa es su principal ventaja. El navegador vive en un contenedor, los proxies se conectan a él, necesitas parsear más — levantas más contenedores y tomas más direcciones del pool. No hay magia, simplemente multiplicar lo que ya funciona.

Un principio importante aquí — no intentar exprimir al máximo una sola sesión, llevarla al límite. Es un camino directo hacia bloqueos, captchas y funcionamiento inestable. Es mucho mejor tener diez instancias tranquilas a un ritmo normal que una agresiva que constantemente cae y necesita reinicio.

Arquitectura: una vez configurado — lo usas en todas partes

Tengo un núcleo: navegador con enmascaramiento configurado, lógica de precalentamiento de cookies, pool de proxies, patrones de comportamiento. Todo eso se resolvió una vez y ahora funciona para todos los proyectos sin cambios.

Para cada nuevo sitio solo se escribe un módulo con la lógica del negocio — qué datos se necesitan, dónde están, cómo acceder a ellos. Todo lo específico de un recurso concreto está solo ahí, la infraestructura es común. Un proyecto nuevo no es “escribir un scraper desde cero”, sino “describir qué y de dónde tomar”. El tiempo de arranque es mínimo, la fiabilidad alta.

El análisis competitivo, el monitoreo de precios, la generación de leads, la investigación de mercado — la mitad de las decisiones empresariales modernas se apoyan en datos que hubo que recopilar en algún sitio. El scraping es la herramienta para esas tareas, y como herramienta de calidad debe ser aburrida, fiable y discreta. Nada de heroísmo, nada de “exprimir al máximo”. Solo un sistema que funciona.