El desafío
Un benchmark de ApplyArc de junio de 2026 probó cinco scrapers de LinkedIn en 200 extracciones de empleo reales. Tres sufrieron el marcado de la cuenta o una limitación silenciosa tras aproximadamente 50 guardados. Solo dos sobrevivieron limpios.
Ese benchmark lo dice todo. Los portales de empleo solían ser objetivos fáciles. Ahora son de los más difíciles de la web abierta.
Si está desarrollando algo que depende de datos de ofertas de empleo (planificación de personal, benchmarking salarial, mapeo de talento, señales de contratación para investigación de renta variable), su capa de recopilación se enfrenta a un conjunto de defensas que no existían hace dos años. Indeed lanza CAPTCHAs ante sesiones desconocidas. LinkedIn correlaciona señales del lado del navegador en las rotaciones de IP. Glassdoor aplica un rate limit por ASN, no por IP. ZipRecruiter inserta el rango salarial y la fecha de publicación en un JavaScript que solo se renderiza si sus headers parecen los de una persona y no los de un script.
Así que la barrera de los 50 guardados no es un problema exclusivo de LinkedIn. Es una propiedad de toda la categoría.
Por qué los portales de empleo son cada vez más difíciles
Tres factores cambiaron en 2026 y se acumularon.
El primero es que la detección de bots pasó a ser conductual. Las comprobaciones estáticas (User-Agent, reputación de IP, peticiones por segundo) solían bastar para detener a los scrapers aficionados. Ya no. Las defensas actuales analizan cómo se mueve por el sitio: qué páginas carga y en qué orden, cuánto tiempo pasa en ellas, o si vuelve a solicitar los mismos paquetes de JS que un navegador real almacenaría en caché. Escribimos sobre este cambio en Bot Detection Went Behavioral. Los portales de empleo lo adoptaron pronto porque sus visitantes realizan un número reducido de acciones repetitivas (buscar, hacer clic, leer, guardar), lo que hace que un script sea fácil de detectar si se salta la mitad de la secuencia.
El segundo es que el tamaño del pool de proxies dejó de importar. Un pool residencial de 50 millones de IPs no ayuda cuando la defensa consiste en la correlación de fingerprints en la capa de conexión combinada con la reputación de la ASN. Tratamos esto en Why Proxy Pool Size Stopped Mattering. Lo que funciona es elegir el punto de salida adecuado para el sitio de destino, no tener más puntos de salida que los demás.
El tercero es legal. Tanto Indeed como LinkedIn cuentan con equipos legales que presentan demandas. La era de ejecutar un scraper público desde la IP de su casa ha terminado para cualquiera que planee vender lo que recopila.
Cómo es la recopilación de datos ahora
Para el trabajo de talent intelligence en 2026, el patrón que sigue funcionando es un stack dividido: una obtención de datos renderizada por un navegador real para los portales protegidos, junto con una selección cuidadosa del punto de salida para no provenir del mismo proveedor que el resto de los bots.
Con una plataforma como FourA, se trata de dos productos que se comunican entre sí.
Browser se encarga de la renderización: envíe una URL con unblocker: true, reciba el HTML renderizado, cookies y una captura de pantalla de una sesión de navegador real. El JS se evalúa, los campos de carga diferida (lazy-loaded) se completan y la request supera las comprobaciones de la capa de conexión que detectan a los clientes más básicos. La selección de proxy se ejecuta en segundo plano: la plataforma elige un punto de salida por request y devuelve su ID opaco en base36 en la response (en el nivel superior r.proxy en Single/Browser, o en r.session.proxy en Auto), de modo que las llamadas de seguimiento puedan reutilizar el mismo punto de salida cuando necesite continuidad de sesión. Para la mayoría de los trabajos con portales de empleo, Auto es el punto de entrada adecuado: orquesta Single, Proxy y Browser según lo que necesite cada objetivo, para que su código no tenga que hacerlo.
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
"validate": {
"status": {"accept": [200]},
"data": {"accept": ["data-testid=\"job-card\""],
"fail": ["Just a moment", "captcha"]},
},
},
).json()
# r["data"] or r["body"] — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"] — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.
Dos notas sobre lo que esto le aporta realmente.
La barrera de los 50 guardados al estilo de ApplyArc es principalmente un problema de sesión, no de pool. Una sesión de navegador real, rotada de manera inteligente, dura mucho más tiempo antes de activar el rate-limiter de lo que duraría un cliente HTTP básico. Y la response incluye un ID de proxy opaco en lugar de un punto de salida directo, por lo que su código sigue siendo sencillo y no tiene que rastrear qué punto de salida gestionó cada request.
La segunda nota se refiere a lo que NO está en el fragmento de código. La deduplicación entre diferentes portales (el mismo puesto de data engineer en LinkedIn, Indeed y la propia página de empleo de la empresa, con tres títulos ligeramente distintos) es problema suyo, no de la capa de recopilación. Hemos visto a equipos subestimar esto. La normalización consume más tiempo de ingeniería que la propia obtención de datos, y es ahí donde la mayoría de los productos de talent intelligence terminan compitiendo.
Resultados
Un equipo de talent intelligence que realiza el seguimiento de 200 empresas en tres portales de empleo necesita aproximadamente 50 000 descargas de páginas a la semana: resultados de búsqueda, páginas de detalles de empleo y la actualización ocasional de la página de la empresa. Los números que debería alcanzar con esa carga de trabajo son:
- Tasa de éxito superior al 95% en objetivos de la categoría de Indeed, donde el éxito significa obtener el HTML renderizado con el rango salarial y la fecha de publicación completados.
- Coste por empleo inferior a 0,004 $ de extremo a extremo, incluyendo la renderización y la selección del punto de salida.
- Cadencia de actualización de 6 a 12 horas para puestos activos, de modo que sus dashboards de señales de contratación no vayan por detrás del mercado.
Estos números son ilustrativos, basados en lo que reportan los equipos que ejecutan este patrón de stack dividido. Su coste real dependerá de a qué portales se dirija y de la agresividad con la que filtre las nuevas publicaciones.
Conclusión clave
Los portales de empleo están ahora más cerca en dificultad de la tecnología publicitaria (ad-tech) y la venta de entradas (ticketing) que del comercio electrónico general. Ese es un cambio real, y explica por qué las librerías de scraping que funcionaban en 2024 siguen topándose con la misma barrera en 2026.
Los equipos que logran escalar más allá de esto dejan de pensar en "el scraper" como una unidad de trabajo. Piensan en sesiones, puntos de salida y deduplicación como tres problemas independientes, y adquieren la infraestructura para los dos primeros para que sus ingenieros puedan dedicar su semana al tercero. Los datos de ofertas de empleo más baratos son aquellos que no tuvo que volver a recopilar tras un bloqueo.