O desafio
Um benchmark de junho de 2026 da ApplyArc testou cinco scrapers de vagas do LinkedIn em 200 extrações reais de vagas. Três tiveram a conta sinalizada ou silenciosamente limitada após cerca de 50 salvamentos. Apenas dois sobreviveram limpos.
Esse benchmark é a história toda. Painéis de vagas costumavam ser alvos fáceis. Agora eles são alguns dos mais difíceis na web aberta.
Se você está construindo algo que depende de dados de listagem de vagas (planejamento de força de trabalho, benchmarking salarial, mapeamento de talentos, contratação como sinal para pesquisa de ações), sua camada de coleta está lutando contra uma pilha de defesas que não existia há dois anos. O Indeed lança CAPTCHAs em sessões desconhecidas. O LinkedIn correlaciona sinais do lado do browser através de rotações de IP. O Glassdoor aplica rate limit por ASN, não por IP. O ZipRecruiter empurra a faixa salarial e a data de postagem para um JavaScript que só renderiza se seus headers parecerem com uma pessoa, não com um script.
Portanto, o bloqueio de 50 salvamentos não é um problema do LinkedIn. É uma propriedade de toda a categoria.
Por que os painéis de vagas 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, requests por segundo) costumavam ser suficientes para parar scrapers amadores. Não mais. As defesas de hoje observam como você se move 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 browser real faria cache. Nós escrevemos sobre essa mudança em A detecção de bots se tornou comportamental. Os painéis de vagas adotaram isso cedo porque seus visitantes fazem um pequeno número de ações repetíveis (pesquisar, clicar, ler, salvar), e isso torna um script fácil de detectar quando ele pula metade da sequência.
A segunda é que o tamanho do pool de proxies parou de importar. Um pool residencial de 50 milhões de IPs não ajuda quando a defesa é correlação de fingerprint na camada de conexão combinada com a reputação do ASN. Nós cobrimos isso em Por que o tamanho do pool de proxies parou de importar. O que funciona é escolher a saída certa para o site alvo, não ter mais saídas do que qualquer outra pessoa.
A terceira é legal. O Indeed e o LinkedIn possuem equipes jurídicas que abrem processos. A era de rodar um scraper público a partir do seu IP residencial acabou para qualquer um que planeja vender o que coleta.
Como a coleta se parece agora
Para o trabalho de inteligência de talentos em 2026, o padrão que continua funcionando é uma stack dividida: um fetch renderizado em um browser real para os painéis protegidos, além de uma seleção de saída cuidadosa para que você não venha do mesmo provedor que todos os outros bots.
Com uma plataforma como a FourA, são dois produtos conversando entre si.
O Browser lida com o lado da renderização: envie uma URL com unblocker: true, receba de volta o HTML renderizado, cookies e uma captura de tela de uma sessão de browser real. O JS é avaliado, os campos de lazy-load são preenchidos e a request passa nas verificações da camada de conexão que pegam os clientes mais 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 r.proxy no Single/Browser, ou r.session.proxy no Auto), para que as chamadas subsequentes possam reutilizar a mesma saída quando você precisar de continuidade de sessão. Para a maioria dos trabalhos em painéis de vagas, o Auto é o ponto de entrada certo, pois orquestra o Single, o Proxy e o Browser com base no que cada alvo precisa, para que o seu código não tenha que 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 notas sobre o que isso realmente traz para você.
O bloqueio de 50 salvamentos no estilo ApplyArc é principalmente um problema de sessão, não um problema de pool. Uma sessão de browser real, rotacionada cuidadosamente, dura muito mais antes de acionar o rate limit do que um cliente HTTP bruto. E a response carrega um id de proxy opaco em vez de uma saída bruta, assim o seu código permanece simples e você não precisa rastrear qual saída lidou com qual request.
A segunda nota é sobre o que NÃO está no snippet. A desduplicação entre painéis (a mesma vaga de engenheiro de dados no LinkedIn, no Indeed e na página de carreiras da própria empresa, com três títulos ligeiramente diferentes) é o seu problema, não o da camada de coleta. Nós vimos equipes subestimarem isso. A normalização consome mais tempo de engenharia do que o fetching, e é onde a maioria dos produtos de inteligência de talentos acaba competindo.
Resultados
Uma equipe de inteligência de talentos rastreando 200 empresas em três painéis precisa de aproximadamente 50.000 fetches de páginas por semana: resultados de pesquisa, páginas de detalhes de vagas e a atualização ocasional da página da empresa. Os números que você gostaria de atingir nessa carga de trabalho:
- Taxa de sucesso acima de 95% em alvos da classe do Indeed, onde sucesso significa HTML renderizado com a faixa salarial e a data de postagem preenchidas.
- Custo por vaga abaixo de US$ 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 dashboards 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 executando esse padrão de stack dividida. O seu custo real depende de quais painéis você segmenta e do quão agressivamente você filtra por postagens recentes.
Principal conclusão
Os painéis de vagas agora estão mais próximos em dificuldade de ad-tech e venda de ingressos do que de e-commerce em 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 escalam além disso param de pensar em "o scraper" como uma unidade de trabalho. Eles pensam sobre sessões, saídas e desduplicação como três preocupações separadas, e eles compram a infraestrutura para as duas primeiras para que seus engenheiros possam gastar a semana na terceira. O dado de listagem de vagas mais barato é aquele que você não teve que coletar de novo após uma sinalização.