O desafio
Um benchmark da ApplyArc de junho de 2026 testou cinco scrapers de LinkedIn em 200 extrações de vagas reais. Três tiveram a conta sinalizada ou sofreram throttling silencioso após cerca de 50 salvamentos. Apenas dois sobreviveram intactos.
Esse benchmark resume bem a situação. Os job boards costumavam ser alvos fáceis. Agora, eles são alguns dos mais difíceis na web aberta.
Se você está desenvolvendo algo que depende de dados de listagem de vagas (planejamento de força de trabalho, benchmarking salarial, mapeamento de talentos, sinais de contratação para equity research), sua camada de coleta está combatendo uma pilha de defesas que não existia há dois anos. O Indeed exibe CAPTCHAs para sessões desconhecidas. O LinkedIn correlaciona sinais do lado do navegador em rotações de IP. O Glassdoor aplica rate limit por ASN, não por IP. O ZipRecruiter insere a faixa salarial e a data de publicação em um JavaScript que só é renderizado se seus headers parecerem os de uma pessoa, não os de um script.
Portanto, a barreira dos 50 salvamentos não é um problema do LinkedIn. É uma característica de toda a categoria.
Por que os job boards continuam ficando mais difíceis
Três coisas mudaram em 2026, e elas se acumularam.
A primeira é que a detecção de bots se tornou comportamental. Verificações estáticas (User-Agent, reputação de IP, requisições por segundo) costumavam ser suficientes para impedir scrapers amadores. Não mais. As defesas de hoje monitoram como você navega pelo site: quais páginas você carrega e em qual ordem, quanto tempo você gasta, se você busca novamente os mesmos pacotes JS que um navegador real armazenaria em cache. Escrevemos sobre essa mudança em Bot Detection Went Behavioral. Os job boards adotaram isso cedo porque seus visitantes realizam um número pequeno de ações repetitivas (buscar, clicar, ler, salvar), o que torna um script fácil de detectar quando ele pula metade da sequência.
A segunda é que o tamanho do pool de proxies deixou de importar. Um pool residencial de 50 milhões de IPs não ajuda quando a defesa é a correlação de fingerprints na camada de conexão somada à reputação do ASN. Abordamos isso em Why Proxy Pool Size Stopped Mattering. O que funciona é escolher a saída certa para o site de destino, e não ter mais saídas do que qualquer outra pessoa.
A terceira é jurídica. O Indeed e o LinkedIn têm equipes jurídicas que abrem processos. A era de rodar um scraper público a partir do IP residencial acabou para quem planeja vender o que coleta.
Como é a coleta de dados atualmente
Para o trabalho de inteligência de talentos em 2026, o padrão que continua funcionando é uma stack dividida: uma busca real renderizada por navegador para os portais protegidos, além de uma seleção cuidadosa de saída para que você não venha do mesmo provedor que todos os outros bots.
Com uma plataforma como a FourA, são dois produtos se comunicando.
O Browser cuida da renderização: envie uma URL com unblocker: true e receba de volta o HTML renderizado, cookies e uma captura de tela de uma sessão de navegador real. O JS é avaliado, os campos de carregamento tardio (lazy-loaded) são preenchidos e a request passa pelas verificações de camada de conexão que detectam a maioria dos clientes básicos. A seleção de proxy roda nos bastidores: a plataforma escolhe uma saída por request e retorna seu ID opaco em base36 na response (no nível superior em r.proxy no Single/Browser, ou em r.session.proxy no Auto), para que as chamadas seguintes possam reutilizar a mesma saída quando você precisar de continuidade de sessão. Para a maior parte do trabalho com job boards, o Auto é o ponto de entrada ideal, pois ele orquestra o Single, o Proxy e o Browser com base no que cada destino precisa, para que seu código não precise fazer isso.
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.
Duas observações sobre o que isso realmente oferece a você.
A barreira de 50 salvamentos no estilo ApplyArc é principalmente um problema de sessão, não de pool. Uma sessão de navegador real, rotacionada de forma inteligente, dura muito mais tempo antes de ativar o rate-limiter do que um cliente HTTP bruto duraria. E a response carrega um ID de proxy opaco em vez de uma saída bruta, de modo que seu código permanece simples e você não precisa rastrear qual saída tratou qual request.
A segunda observação é sobre o que NÃO está no trecho de código. A eliminação de duplicatas entre diferentes portais (a mesma vaga de engenheiro de dados no LinkedIn, no Indeed e na própria página de carreiras da empresa, com três títulos ligeiramente diferentes) é um problema seu, não da camada de coleta. Vimos equipes subestimarem isso. A normalização consome mais tempo de engenharia do que a busca de dados, e é aí que a maioria dos produtos de inteligência de talentos acaba competindo.
Resultados
Uma equipe de inteligência de talentos que monitora 200 empresas em três portais precisa de aproximadamente 50.000 buscas de página por semana: resultados de busca, páginas de detalhes de vagas e a atualização ocasional de páginas de empresas. Os números que você desejaria alcançar nessa carga de trabalho são:
- Taxa de sucesso acima de 95% em alvos do nível do Indeed, onde o sucesso significa o HTML renderizado com a faixa salarial e a data de publicação preenchidas.
- Custo por vaga abaixo de $0,004 de ponta a ponta, incluindo a renderização e a seleção de saída.
- Cadência de atualização de 6 a 12 horas para vagas ativas, para que seus painéis de sinais de contratação não fiquem defasados em relação ao mercado.
Esses números são ilustrativos, baseados no que relatam as equipes que executam esse padrão de stack dividida. Seu custo real depende de quais portais você tem como alvo e de quão agressivamente você filtra as publicações recentes.
Principal conclusão
Os job boards agora estão mais próximos em nível de dificuldade de ad-tech e venda de ingressos (ticketing) do que do e-commerce geral. Essa é uma mudança real, e explica por que as bibliotecas de scraping que funcionavam em 2024 continuam esbarrando na mesma barreira em 2026.
As equipes que conseguem escalar além disso deixam de pensar no "scraper" como uma unidade de trabalho. Elas pensam em sessões, saídas e eliminação de duplicatas como três preocupações distintas, e compram a infraestrutura para as duas primeiras para que seus engenheiros possam dedicar a semana à terceira. O dado de listagem de vagas mais barato é aquele que você não precisou coletar novamente após uma sinalização.