El desafío
Un benchmark de junio de 2026 de ApplyArc evaluó cinco scrapers de empleo de LinkedIn en 200 extracciones reales. Tres de ellos provocaron que la cuenta fuera marcada o limitada silenciosamente después de unos 50 guardados. Solo dos sobrevivieron limpios.
Ese benchmark cuenta toda la historia. Los portales de empleo solían ser objetivos fáciles. Ahora son algunos de los más difíciles en la web abierta.
Si estás construyendo algo que depende de datos de ofertas de empleo (planificación de fuerza laboral, benchmarking salarial, mapeo de talento, contratación como señal para investigación de capital), tu capa de recolección está luchando contra una pila de defensas que no existía hace dos años. Indeed lanza CAPTCHAs a sesiones desconocidas. LinkedIn correlaciona señales del lado del navegador a través de rotaciones de IP. Glassdoor aplica rate limit por ASN, no por IP. ZipRecruiter empuja el rango salarial y la fecha de publicación en JavaScript que solo se renderiza si tus headers parecen de una persona, no de un script.
Así que el bloqueo de 50 guardados no es un problema de LinkedIn. Es una característica de toda la categoría.
Por qué los portales de empleo son cada vez más difíciles
Tres cosas cambiaron en 2026, y se acumularon.
La primera es que la detección de bots se volvió conductual. Las comprobaciones estáticas (User-Agent, reputación de IP, requests por segundo) solían ser suficientes para detener a scrapers aficionados. Ya no. Las defensas de hoy observan cómo te mueves por el sitio: qué páginas cargas en qué orden, cuánto tiempo pasas, si vuelves a pedir los mismos paquetes JS que un navegador real almacenaría en caché. Escribimos sobre ese cambio en Bot Detection Went Behavioral. Los portales de empleo lo adoptaron pronto porque sus visitantes realizan un número pequeño de acciones repetibles (buscar, hacer clic, leer, guardar), y eso hace que un script sea fácil de detectar cuando se salta la mitad de la secuencia.
La segunda es que el tamaño del grupo de proxy dejó de importar. Un grupo residencial de 50 millones de IP no ayuda cuando la defensa es la correlación de huellas dactilares en la capa de conexión más la reputación del ASN. Cubrimos eso en Why Proxy Pool Size Stopped Mattering. Lo que funciona es elegir la salida correcta para el sitio objetivo, no tener más salidas que los demás.
La tercera es legal. Indeed y LinkedIn tienen equipos legales que presentan demandas. La era de ejecutar un scraper público desde tu IP doméstica ha terminado para cualquiera que planee vender lo que recopila.
Cómo es la recolección ahora
Para el trabajo de inteligencia de talento en 2026, el patrón que sigue funcionando es un stack dividido: un fetch renderizado en un navegador real para los portales protegidos, más una cuidadosa selección de salida para no provenir del mismo proveedor que todos los demás bots.
Con una plataforma como FourA, eso son dos productos comunicándose entre sí.
Browser maneja el lado del renderizado: envía una URL con unblocker: true, obtén 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 se completan, y el request pasa las comprobaciones de la capa de conexión que atrapan a la mayoría de los clientes básicos. La selección de proxy funciona bajo el capó: la plataforma elige una salida por request y devuelve su id base36 opaco en el response (en el nivel superior r.proxy en Single/Browser, o r.session.proxy en Auto), para que las llamadas de seguimiento puedan reutilizar la misma salida cuando necesites continuidad de sesión. Para la mayoría del trabajo en portales de empleo, Auto es el punto de entrada correcto (orquesta Single, Proxy y Browser según lo que cada objetivo necesite, para que tu 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 realmente te aporta.
El bloqueo de 50 guardados al estilo ApplyArc es principalmente un problema de sesión, no un problema del grupo de IPs. Una sesión de navegador real, rotada cuidadosamente, dura mucho más antes de activar el rate limit que un cliente HTTP puro. Y el response lleva un id de proxy opaco en lugar de una salida en bruto, por lo que tu código se mantiene simple y no tienes que rastrear qué salida manejó qué request.
La segunda nota es sobre lo que NO está en el fragmento de código. Desduplicar en los portales (el mismo rol de ingeniero de datos en LinkedIn, Indeed y la propia página de empleo de la empresa, con tres títulos ligeramente diferentes) es problema tuyo, no de la capa de recolección. Hemos visto a equipos subestimar esto. La normalización consume más tiempo de ingeniería que el proceso de fetching, y es donde la mayoría de los productos de inteligencia de talento terminan compitiendo.
Resultados
Un equipo de inteligencia de talento que rastrea 200 empresas en tres portales necesita aproximadamente 50,000 requests de página por 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 querrías alcanzar en esa carga de trabajo:
- Tasa de éxito superior al 95% en objetivos del tipo Indeed, donde el éxito significa HTML renderizado con el rango salarial y la fecha de publicación completados.
- Costo por empleo inferior a $0.004 de extremo a extremo, incluyendo el renderizado y la selección de salida.
- Cadencia de actualización de 6 a 12 horas para roles activos, para que tus paneles de señales de contratación no se queden atrás respecto al mercado.
Estos números son ilustrativos, basados en lo que reportan los equipos que ejecutan este patrón de stack dividido. Tu costo real depende de a qué portales te dirijas y de lo agresivo que seas al filtrar las publicaciones recientes.
Conclusión clave
Los portales de empleo están ahora más cerca en dificultad del ad-tech y la venta de entradas 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 chocando con el mismo muro 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, salidas y desduplicación como tres áreas separadas, y compran la infraestructura para las dos primeras para que sus ingenieros puedan dedicar su semana a la tercera. El dato de oferta de empleo más barato es aquel que no tuviste que volver a recopilar después de ser marcado.