The Challenge
През юни 2026 г. benchmark от ApplyArc тества пет LinkedIn job scrapers при 200 реални извличания на обяви. Три доведоха до маркиране на акаунта или тихо ограничаване на заявките след около 50 записвания. Само два оцеляха без проблеми.
Този benchmark казва всичко. Сайтовете за работа преди бяха лесни цели. Сега те са едни от най-трудните в отворената мрежа.
Ако разработвате нещо, което зависи от данни за обяви за работа (планиране на работната сила, сравняване на заплати, картографиране на таланти, анализ на наемането като сигнал за инвестиционни проучвания), вашият слой за събиране на данни се бори със защити, които не съществуваха преди две години. Indeed изисква CAPTCHAs при непознати сесии. LinkedIn съпоставя сигнали от страна на браузъра при ротация на IP адреси. Glassdoor налага rate limit на ниво ASN, а не на ниво IP. ZipRecruiter зарежда диапазона на заплатите и датата на публикуване чрез JavaScript, който се рендира само ако вашите headers изглеждат като на реален човек, а не като на скрипт.
Така че лимитът от 50 записвания не е проблем само на LinkedIn. Това е характеристика на цялата категория.
Защо сайтовете за работа стават все по-трудни
Три неща се промениха през 2026 г. и те се натрупаха едно върху друго.
Първото е, че засичането на ботове стана поведенческо. Статичните проверки (User-Agent, репутация на IP, заявки в секунда) преди бяха достатъчни за спиране на любителските scrapers. Вече не. Днешните защити наблюдават как се движите в сайта: кои страници зареждате и в какъв ред, колко време прекарвате там, дали изтегляте отново същите JS пакети, които реален браузър би кеширал. Писахме за тази промяна в Bot Detection Went Behavioral. Сайтовете за работа я приеха рано, защото техните посетители извършват малък брой повтарящи се действия (търсене, кликване, четене, запазване), което прави скриптовете лесни за откриване, когато прескачат половината от последователността.
Второто е, че размерът на proxy пула спря да има значение. Жилищен пул от 50 милиона IP адреса не помага, когато защитата е корелация на пръстови отпечатъци на ниво връзка плюс репутация на ASN. Разгледахме това в Why Proxy Pool Size Stopped Mattering. Това, което работи, е изборът на правилния exit за целевия сайт, а не притежаването на повече exits от всеки друг.
Третото е от правно естество. Indeed и LinkedIn имат правни екипи, които завеждат дела. Ерата на стартиране на публичен scraper от домашното ви IP приключи за всеки, който планира да продава това, което събира.
Как изглежда събирането на данни сега
За работата в сферата на talent-intelligence през 2026 г. моделът, който продължава да работи, е разделен стек: реално извличане с рендиране в браузър за защитените сайтове, плюс внимателен избор на exit, за да не идвате от същия доставчик като всеки друг бот.
С платформа като FourA това са два продукта, които комуникират помежду си.
Browser се справя с рендирането: изпращате URL с unblocker: true, получавате обратно рендиран HTML, cookies и екранна снимка от реална браузърна сесия. JS се изпълнява, полетата с мързеливо зареждане се попълват и заявката преминава проверките на ниво връзка, които улавят повечето базови клиенти. Изборът на proxy работи под капака: платформата избира exit за всяка заявка и връща неговия непрозрачен base36 идентификатор в отговора (в r.proxy на най-високо ниво при Single/Browser или в r.session.proxy при Auto), така че следващите повиквания да могат да използват повторно същия exit, когато имате нужда от приемственост на сесията. За повечето задачи, свързани със сайтове за работа, 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-limiter, отколкото чист HTTP клиент. А отговорът съдържа непрозрачен proxy id вместо суров exit, така че кодът ви остава прост и не се налага да проследявате кой exit е обработил дадена заявка.
Втората бележка е за това какво НЕ е включено в кода. Дедупликацията между различните сайтове (една и съща роля за data engineer в LinkedIn, Indeed и собствената страница за кариери на компанията, с три леко различни заглавия) е ваш проблем, а не на слоя за събиране на данни. Наблюдавали сме как екипи подценяват това. Нормализацията отнема повече инженерно време, отколкото самото извличане, и точно там се конкурират повечето talent-intelligence продукти.
Резултати
Един talent-intelligence екип, който проследява 200 компании в три сайта за работа, се нуждае от около 50 000 извличания на страници на седмица: резултати от търсене, страници с подробности за обявите и периодично опресняване на страниците на компаниите. Числата, които бихте искали да постигнете при такова натоварване:
- Процент на успех над 95% при цели от класа на Indeed, където успехът означава рендиран HTML с попълнени диапазон на заплатата и дата на публикуване.
- Цена на обява под $0.004 от край до край, включително рендирането и избора на exit.
- Честота на опресняване от 6 до 12 часа за активни позиции, така че вашите табла за управление с сигнали за наемане да не изостават от пазара.
Тези числа са илюстративни и се основават на доклади от екипи, които използват този split-stack модел. Вашите реални разходи зависят от това кои сайтове за работа таргетирате и колко агресивно филтрирате за нови обяви.
Основен извод
Сайтовете за работа вече са по-близо по трудност до ad-tech и платформите за билети, отколкото до общата електронна търговия. Това е съществена промяна и обяснява защо библиотеките за scraping, които работеха през 2024 г., продължават да се сблъскват със същия лимит през 2026 г.
Екипите, които успяват да мащабират отвъд това, спират да мислят за „scraper-а“ като за единична задача. Те разглеждат сесиите, exits и дедупликацията като три отделни казуса и купуват инфраструктурата за първите два, за да могат техните инженери да посветят седмицата си на третия. Най-евтините данни за обяви за работа са тези, които не е трябвало да събирате отново след маркиране на акаунта.