Предизвикателството
Бенчмарк от ApplyArc от юни 2026 г. тества пет LinkedIn job scraper-а върху 200 реални извличания на обяви за работа. Три от тях доведоха до маркиране на акаунта или тихо ограничаване след приблизително 50 записа. Само два оцеляха без проблеми.
Този бенчмарк описва цялата ситуация. Сайтовете за обяви за работа преди бяха лесни мишени. Сега те са едни от най-трудните в отворената мрежа.
Ако изграждате нещо, което зависи от данни за обяви за работа (планиране на работната сила, бенчмаркинг на заплати, мапинг на таланти, наемане като сигнал за анализ на акции), вашият слой за събиране на данни се бори със стек от защити, които не съществуваха преди две години. Indeed показва страници за верификация на непознати сесии. LinkedIn корелира сигнали от страната на браузъра при ротация на IP адреси. Glassdoor налага rate limit на ниво ASN, а не на ниво IP. ZipRecruiter зарежда диапазона на заплатата и датата на публикуване чрез JavaScript, който се рендира само ако вашите headers изглеждат като от човек, а не от скрипт.
Така че лимитът от 50 записа не е проблем само на LinkedIn. Това е свойство на цялата категория.
Защо сайтовете за обяви за работа стават все по-трудни
Три неща се промениха през 2026 г. и те се натрупаха едно върху друго.
Първото е, че засичането на ботове стана поведенческо. Статичните проверки (User-Agent, IP репутация, брой requests в секунда) преди бяха достатъчни, за да спрат любителските scraper-и. Вече не. Днешните защити следят как се движите из сайта: кои страници зареждате и в какъв ред, колко време прекарвате, дали изтегляте отново същите JS пакети, които реален браузър би кеширал. Писахме за тази промяна в Bot Detection Went Behavioral. Сайтовете за обяви за работа я възприеха рано, защото техните посетители извършват малък брой повтарящи се действия (търсене, клик, четене, запазване), а това прави скрипта лесен за откриване, когато пропусне половината от последователността.
Второто е, че размерът на proxy пула спря да има значение. Пул от 50 милиона резидентни IP адреса не помага, когато защитата представлява корелация на пръстови отпечатъци на ниво връзка плюс ASN репутация. Описахме това в Why Proxy Pool Size Stopped Mattering. Това, което работи, е изборът на правилната изходна точка за целевия сайт, а не наличието на повече изходни точки от всички останали.
Третото е от правно естество. И Indeed, и LinkedIn имат правни екипи, които завеждат дела. Ерата на стартиране на публичен scraper от домашния ви IP адрес приключи за всеки, който планира да продава събраните данни.
Как изглежда събирането на данни сега
За работа с данни за пазара на труда през 2026 г. моделът, който продължава да работи, е разделен стек: реално извличане с рендиране в браузър за защитените платформи, плюс внимателен подбор на изходните точки, така че да не идвате от същия доставчик като всеки друг бот.
С платформа като FourA това са два продукта, които комуникират помежду си.
Browser поема рендирането: изпращате URL с unblocker: true и получавате рендиран HTML, cookies и скрийншот от реална браузърна сесия. JS се изпълнява, полетата с lazy loading се зареждат, а заявката преминава проверките на ниво връзка, които спират повечето базови клиенти. Изборът на proxy се управлява автоматично: платформата избира изходна точка за всяка заявка и връща нейния непрозрачен base36 идентификатор в отговора (на най-високо ниво във 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.
Две бележки за това какво реално ви носи това.
Бариерата от типа на ApplyArc при 50 записа е основно проблем на сесията, а не проблем на пула. Реална браузърна сесия, ротирана разумно, издържа значително по-дълго, преди да задейства rate limit, отколкото чист HTTP клиент. Освен това response съдържа opaque proxy id вместо суров exit, така че кодът ви остава прост и не е нужно да следите кой exit е обслужил даден request.
Втората бележка е за това какво НЕ присъства в snippet-а. Дедупликацията между различни портали (една и съща позиция за 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 г.
Екипите, които мащабират успешно отвъд това, спират да възприемат скрапера като единна работна единица. Те разглеждат сесиите, изходите и дедупликацията като три отделни задачи и купуват инфраструктура за първите две, за да могат техните инженери да посветят седмицата си на третата. Най-евтините данни за обяви за работа са тези, които не се е наложило да събирате повторно след блокиране.