← Todos os posts
Caso de uso 6 min de leitura

Scraping de painéis de vagas sem esbarrar no bloqueio de 50 salvamentos

O scraping de painéis de vagas se tornou um dos trabalhos mais difíceis na web aberta em 2026. Aqui está o que mudou e como as equipes de inteligência de talentos continuam coletando dados.

job board scrapingtalent intelligenceanti-botweb scraping

O Desafio

Um benchmark de junho de 2026 da ApplyArc testou cinco scrapers de vagas do LinkedIn em 200 coletas reais de vagas. Três tiveram a conta sinalizada ou sofreram throttling silencioso após cerca de 50 salvamentos. Apenas dois sobreviveram sem problemas.

Esse benchmark resume toda a situação. Os portais de vagas costumavam ser alvos fáceis. Agora eles estão entre os mais difíceis da web aberta.

Se você está desenvolvendo algo que depende de dados de vagas de emprego (planejamento de força de trabalho, benchmark salarial, mapeamento de talentos, contratação como indicador para pesquisa de ações), sua camada de coleta está enfrentando uma pilha de defesas que não existia há dois anos. O Indeed exibe páginas de verificação para sessões desconhecidas. O LinkedIn correlaciona sinais do lado do navegador entre 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 JavaScript que só renderiza se seus headers parecerem os de uma pessoa, não de um script.

Portanto, a barreira dos 50 salvamentos não é um problema exclusivo do LinkedIn. É uma propriedade de toda a categoria.

Por Que os Portais de Vagas Continuam Ficando Mais Difíceis

Três fatores mudaram em 2026, e eles se acumularam.

O primeiro é 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 parar scrapers amadores. Não mais. As defesas atuais observam como você navega pelo site: quais páginas você carrega e em qual ordem, quanto tempo passa nelas, se você busca novamente os mesmos pacotes JS que um navegador real armazenaria em cache. Escrevemos sobre essa mudança em A Detecção de Bots Tornou-se Comportamental. Os portais de vagas adotaram isso cedo porque seus visitantes executam um número pequeno de ações previsíveis (buscar, clicar, ler, salvar), o que torna um script fácil de detectar quando ele pula metade da sequência.

O segundo é 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 de ASN. Abordamos isso em Por Que o Tamanho do Pool de Proxies Deixou de Importar. O que funciona é escolher a saída correta para o site de destino, não ter mais saídas do que qualquer outro.

O terceiro é jurídico. Tanto o Indeed quanto o LinkedIn contam com equipes jurídicas ativas. A era de rodar um scraper público a partir do seu IP residencial acabou para quem planeja comercializar o que coleta.

Como a Coleta Funciona Agora

Para o trabalho de inteligência de talentos em 2026, o padrão que continua funcionando é uma stack dividida: uma busca renderizada em navegador real para os portais protegidos, combinada com uma seleção criteriosa de saída para que você não venha do mesmo provedor que todos os outros bots.

Com uma plataforma como o FourA, isso significa dois produtos se comunicando.

O Browser lida com a parte de renderização: envie uma URL com unblocker: true e receba de volta HTML renderizado, cookies e uma captura de tela de uma sessão real de navegador. O JS é executado, campos com carregamento lazy são preenchidos e a request passa pelas verificações na camada de conexão que barram a maioria dos clientes básicos. A seleção de proxy funciona nos bastidores: a plataforma escolhe uma saída por request e retorna o seu ID opaco em base36 na resposta (no nível superior em r.proxy no Single/Browser, ou em r.session.proxy no Auto), permitindo que chamadas seguintes reutilizem a mesma saída quando você precisar de continuidade de sessão. Para a maior parte do trabalho com painéis de vagas, o Auto é o ponto de entrada ideal; ele orquestra Single, Proxy e Browser com base no que cada destino exige, para que o 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 você realmente ganha com isso.

O bloqueio no estilo ApplyArc de 50 salvamentos é principalmente um problema de sessão, não de pool. Uma sessão de navegador real, rotacionada de forma criteriosa, dura muito mais tempo antes de acionar o rate limit do que um cliente HTTP comum. Além disso, a response traz um ID de proxy opaco em vez de um exit IP bruto, mantendo seu código simples e evitando que você precise rastrear qual exit processou cada request.

A segunda observação é sobre o que NÃO está no snippet. A desduplicação entre diferentes plataformas (a mesma vaga de engenharia de dados no LinkedIn, no Indeed e na página de carreiras da própria empresa, com três títulos ligeiramente diferentes) é um problema seu, não da camada de coleta. Já vimos equipes subestimarem isso. A normalização consome mais tempo de engenharia do que o fetching em si, e é aí que a maioria dos produtos de talent intelligence acaba competindo.

Resultados

Uma equipe de talent intelligence que monitora 200 empresas em três plataformas precisa de aproximadamente 50.000 page fetches 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ê deve buscar nessa carga de trabalho:

  • Taxa de sucesso acima de 95% em alvos no nível do Indeed, onde sucesso significa HTML renderizado com faixa salarial e data de publicação preenchidas.
  • Custo por vaga abaixo de US$ 0,004 de ponta a ponta, incluindo a renderização e a seleção do exit.
  • Cadência de atualização de 6 a 12 horas para vagas ativas, garantindo 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 equipes executando esse padrão de split-stack relatam. Seu custo real depende de quais plataformas você tem como alvo e de quão agressivamente você filtra publicações recentes.

Principal conclusão

Os job boards agora estão mais próximos em dificuldade de ad-tech e venda de ingressos do que de e-commerce tradicional. Essa é uma mudança real e explica por que bibliotecas de scraping que funcionavam em 2024 continuam esbarrando nos mesmos bloqueios em 2026.

As equipes que escalam além disso param de pensar no "scraper" como uma unidade de trabalho única. Elas tratam sessões, exits e desduplicação como três preocupações distintas, e adquirem a infraestrutura para as duas primeiras para que seus engenheiros possam focar a semana na terceira. O dado de vaga mais barato é aquele que você não precisou coletar novamente após um bloqueio.