← Всички публикации
Случай на употреба 6 мин. четене

Скрапинг на платформи за работа без сблъсък със стената от 50 записа

Скрапингът на платформи за работа стана една от най-трудните задачи в отворената мрежа през 2026 г. Ето какво се промени и как екипите за анализ на таланти продължават да събират данни.

job board scrapingtalent intelligenceanti-botweb scraping

The Challenge

бенчмарк от ApplyArc през юни 2026 г. тества пет LinkedIn скрапера чрез 200 реални извличания на обяви за работа. Три от тях доведоха до маркиране на акаунта или тихо ограничаване след около 50 записа. Само два оцеляха чисто.

Този бенчмарк е цялата история. Платформите за работа преди бяха лесни цели. Сега те са едни от най-трудните в отворената мрежа.

Ако изграждате нещо, което зависи от данни за обяви за работа (планиране на работната сила, сравнителен анализ на заплатите, картографиране на таланти, наемането като сигнал за капиталови проучвания), вашият слой за събиране се бори със стек от защити, които не съществуваха преди две години. Indeed хвърля CAPTCHA към непознати сесии. LinkedIn съпоставя сигнали от страна на браузъра при ротации на IP адреси. Glassdoor прилага rate limit на база ASN, а не на база IP. ZipRecruiter избутва диапазона на заплатата и датата на публикуване в JavaScript, който се рендира само ако вашите headers изглеждат като на човек, а не като на скрипт.

Така че стената от 50 записа не е проблем на LinkedIn. Това е характеристика на цялата категория.

Why Job Boards Keep Getting Harder

Три неща се промениха през 2026 г. и те се натрупаха.

Първото е, че засичането на ботове стана поведенческо. Статичните проверки (User-Agent, IP репутация, заявки в секунда) преди бяха достатъчни за спиране на любителски скрапери. Вече не. Днешните защити наблюдават как се движите през сайта: кои страници зареждате и в какъв ред, колко време прекарвате, дали изтегляте отново същите JS пакети, които реален браузър би кеширал. Писахме за тази промяна в Засичането на ботове стана поведенческо. Платформите за работа го въведоха рано, защото техните посетители извършват малък брой повтарящи се действия (търсене, кликване, четене, запазване) и това прави скрипта лесен за забелязване, когато пропусне половината от последователността.

Второто е, че размерът на proxy пула спря да има значение. Пул от 50 милиона резидентни IP адреса не помага, когато защитата е корелация на отпечатъци на слоя на връзката плюс ASN репутация. Обсъдихме това в Защо размерът на proxy пула спря да има значение. Това, което работи, е изборът на правилния изход за целевия сайт, а не наличието на повече изходи от всеки друг.

Третото е правно. Indeed и LinkedIn имат правни екипи, които завеждат дела. Ерата на изпълнение на публичен скрапер от домашното ви IP приключи за всеки, който планира да продава събраното.

What Collection Looks Like Now

За работата с анализ на таланти през 2026 г. моделът, който продължава да работи, е разделен стек: реално извличане, рендирано в браузър, за защитените платформи, плюс внимателен избор на изход, така че да не идвате от същия доставчик като всеки друг бот.

С платформа като FourA това са два продукта, които комуникират помежду си.

Browser се грижи за рендирането: изпращате URL с unblocker: true, получавате обратно рендиран HTML, cookies и екранна снимка от реална браузърна сесия. JS се изпълнява, мързеливо зарежданите полета се попълват и вашият request преминава проверките на слоя на връзката, които хващат повечето базови клиенти. Изборът на proxy работи под капака: платформата избира изход за всеки request и връща неговия непрозрачен base36 идентификатор в получения response (на най-високо ниво r.proxy при Single/Browser или r.session.proxy при Auto), така че последващите извиквания могат да използват същия изход, когато се нуждаете от непрекъснатост на сесията. За повечето задачи с платформи за работа Auto е правилната входна точка, тя оркестрира Single, Proxy и Browser въз основа на нуждите на всяка цел, така че вашият код да не трябва да го прави.

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.

Две бележки относно това какво реално ви носи това.

Стената от 50 записа в стил ApplyArc е предимно проблем със сесията, а не проблем с пула. Реална браузърна сесия, ротирана обмислено, издържа много по-дълго преди да задейства rate limit-а, отколкото би го направил базов HTTP клиент. А полученият response носи непрозрачен proxy идентификатор вместо суров изход, така че вашият код остава опростен и не се налага да проследявате кой изход е обработил съответния request.

Втората бележка е за това какво НЕ е в кода. Дедупликирането в различните платформи (същата роля на data-engineer в LinkedIn, Indeed и собствената кариерна страница на компанията, с три леко различни заглавия) е ваш проблем, а не на слоя за събиране. Виждали сме екипи да подценяват това. Нормализацията изяжда повече инженерно време от самото извличане и точно тук повечето продукти за анализ на таланти в крайна сметка се състезават.

Results

Екип за анализ на таланти, който проследява 200 компании в три платформи, се нуждае от около 50 000 извличания на страници седмично: резултати от търсене, страници с детайли за обяви и периодично опресняване на страници на компании. Числата, които бихте искали да постигнете при такова натоварване:

  • Успеваемост над 95% при цели от класа на Indeed, където успех означава рендиран HTML с попълнени диапазон на заплатата и дата на публикуване.
  • Разход за обява под $0.004 от край до край, включително рендирането и избора на изход.
  • Честота на опресняване от 6 до 12 часа за активни роли, така че вашите табла за сигнали за наемане да не изостават от пазара.

Тези числа са илюстративни, базирани на това, което съобщават екипите, изпълняващи този модел на разделен стек. Вашият реален разход зависи от това към кои платформи се насочвате и колко агресивно филтрирате за нови публикации.

Key Takeaway

Платформите за работа сега са по-близки по трудност до ad-tech и продажбата на билети, отколкото до общата електронна търговия. Това е реална промяна и обяснява защо библиотеки за скрапинг, които са работили през 2024 г., продължават да се блъскат в същата стена през 2026 г.

Екипите, които се мащабират отвъд това, спират да мислят за "скрапера" като единица работа. Те мислят за сесии, изходи и дедупликация като за три отделни проблема и купуват инфраструктурата за първите две, така че инженерите им да могат да прекарат седмицата си върху третото. Най-евтините данни за обяви за работа са тези, които не е трябвало да събирате отново след маркиране.