El desafío
Un benchmark de junio de 2026 de ApplyArc probó cinco scrapers de ofertas de empleo de LinkedIn en 200 extracciones reales. Tres provocaron que la cuenta fuera marcada o limitada silenciosamente tras unas 50 operaciones de guardado. Solo dos sobrevivieron sin problemas.
Ese benchmark resume toda la historia. Las bolsas de trabajo solían ser objetivos fáciles. Ahora son de las más difíciles de la web abierta.
Si estás desarrollando algo que dependa de datos de ofertas de empleo (planificación de personal, comparativas salariales, mapeo de talento o análisis de contrataciones como indicador para research bursátil), tu capa de recolección se enfrenta a una serie de defensas que no existían hace dos años. Indeed muestra pantallas de verificación a sesiones no reconocidas. LinkedIn correlaciona señales del lado del navegador a través de rotaciones de IP. Glassdoor aplica rate limits por ASN, no por IP. ZipRecruiter inserta el rango salarial y la fecha de publicación en JavaScript que solo se procesa si tus headers parecen de una persona y no de un script.
Por lo tanto, el límite de las 50 operaciones de guardado no es un problema exclusivo de LinkedIn. Es una característica de toda la categoría.
Por qué las bolsas de trabajo son cada vez más difíciles
Tres factores cambiaron en 2026 y se sumaron entre sí.
El primero es que la detección de bots pasó a ser conductual. Las comprobaciones estáticas (User-Agent, reputación de IP, requests por segundo) antes bastaban para detener scrapers aficionados. Ya no. Las defensas actuales analizan cómo te mueves por el sitio: qué páginas cargas y en qué orden, cuánto tiempo pasas o si vuelves a solicitar los mismos paquetes de JS que un navegador real guardaría en caché. Escribimos sobre este cambio en La detección de bots se volvió conductual. Las bolsas de trabajo lo adoptaron rápidamente porque sus visitantes realizan pocas acciones repetibles (buscar, hacer clic, leer, guardar), lo que facilita detectar un script cuando omite la mitad de la secuencia.
El segundo es que el tamaño del pool de proxies dejó de ser determinante. Un pool residencial de 50 millones de IP no ayuda cuando la defensa es la correlación de huellas digitales en la capa de conexión combinada con la reputación del ASN. Hablamos de esto en Por qué el tamaño del pool de proxies dejó de importar. Lo que funciona es elegir la salida adecuada para el sitio de destino, no tener más salidas que los demás.
El tercero es legal. Tanto Indeed como LinkedIn cuentan con equipos legales activos. La era de ejecutar un scraper público desde la IP de tu casa terminó para cualquiera que planee comercializar lo que recolecta.
Cómo es la recolección hoy en día
Para proyectos de inteligencia de talento en 2026, el patrón que sigue funcionando es un stack dividido: un fetch renderizado en navegador real para los portales protegidos, junto con una selección cuidadosa de salidas para no provenir del mismo proveedor que el resto de los bots.
Con una plataforma como FourA, esto se traduce en dos productos comunicándose entre sí.
Browser se encarga del renderizado: envía una URL con unblocker: true y obtén HTML renderizado, cookies y una captura de pantalla desde una sesión de navegador real. Se evalúa el JS, se cargan los campos diferidos (lazy load) y la request supera las comprobaciones de capa de conexión que bloquean a la mayoría de clientes básicos. La selección de proxies funciona de fondo: la plataforma elige una salida por cada request y devuelve su id opaco en base36 dentro de la response (en el nivel superior r.proxy en Single/Browser, o r.session.proxy en Auto), permitiendo que las llamadas siguientes reutilicen la misma salida si necesitas continuidad de sesión. Para la mayoría de tareas con portales de empleo, Auto es el punto de entrada adecuado: orquesta Single, Proxy y Browser según lo que requiera cada objetivo, evitando que tu código 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 realmente te aporta.
El límite de 50 guardados al estilo ApplyArc es principalmente un problema de sesión, no de pool. Una sesión de navegador real, rotada con criterio, dura mucho más antes de activar el rate limit que un cliente HTTP básico. Además, la response incluye un proxy id opaco en lugar de una salida en bruto, por lo que tu código se mantiene simple y no tienes que rastrear qué salida procesó cada request.
La segunda nota trata sobre lo que NO está en el snippet. La deduplicación entre plataformas (el mismo puesto de data engineer en LinkedIn, Indeed y la página de empleo propia de la empresa, con tres títulos ligeramente diferentes) es tu problema, no de la capa de recolección. Hemos visto a muchos equipos subestimar esto. La normalización consume más tiempo de ingeniería que la extracción en sí, y es ahí donde la mayoría de los productos de talent intelligence terminan compitiendo.
Resultados
Un equipo de talent intelligence que rastrea 200 empresas en tres plataformas necesita aproximadamente 50.000 extracciones de páginas por semana: resultados de búsqueda, páginas de detalles de ofertas y la actualización ocasional de la página de la empresa. Las métricas que querrías alcanzar con esa carga de trabajo:
- Tasa de éxito superior al 95% en objetivos tipo Indeed, donde el éxito implica HTML renderizado con el rango salarial y la fecha de publicación completados.
- Coste por oferta inferior a $0.004 de extremo a extremo, incluyendo el render y la selección de la salida.
- Frecuencia de actualización de 6 a 12 horas para puestos activos, de modo que tus paneles de señales de contratación no vayan por detrás del mercado.
Estas cifras son ilustrativas, basadas en lo que reportan los equipos que ejecutan este patrón de stack dividido. Tu coste real dependerá de las plataformas a las que apuntes y de la agresividad con la que filtres las publicaciones recientes.
Conclusión clave
Las plataformas de empleo ahora están más cerca en dificultad del ad-tech y la venta de entradas que del e-commerce general. Es un cambio real, y explica por qué las librerías de scraping que funcionaban en 2024 siguen chocando contra el mismo muro en 2026.
Los equipos que logran escalar dejan de ver el "scraper" como una unidad de trabajo única. Tratan las sesiones, las salidas y la deduplicación como tres problemas independientes, y contratan la infraestructura para los dos primeros para que sus ingenieros puedan dedicar su tiempo al tercero. Los datos de ofertas de empleo más baratos son aquellos que no tuviste que volver a extraer tras un bloqueo.