The Challenge
W czerwcu 2026 roku benchmark od ApplyArc przetestował pięć scraperów LinkedIn na próbie 200 rzeczywistych pobrań ofert. Trzy z nich doprowadziły do oflagowania konta lub cichego throttlingu po około 50 zapisach. Tylko dwa przetrwały bez problemów.
Ten benchmark mówi wszystko. Portale z ofertami pracy były kiedyś łatwym celem. Teraz należą do najtrudniejszych w otwartej sieci.
Jeśli budujesz cokolwiek, co zależy od danych o ofertach pracy (planowanie zatrudnienia, benchmarki płacowe, mapowanie talentów, analizowanie rekrutacji jako sygnału rynkowego dla equity research), Twoja warstwa zbierania danych walczy z zestawem zabezpieczeń, które nie istniały jeszcze dwa lata temu. Indeed rzuca CAPTCHA przy nieznanych sesjach. LinkedIn koreluje sygnały po stronie przeglądarki przy rotacji IP. Glassdoor nakłada rate limit na poziomie ASN, a nie pojedynczych IP. ZipRecruiter wrzuca widełki płacowe i datę publikacji do JavaScriptu, który renderuje się tylko wtedy, gdy Twoje headers wyglądają jak u człowieka, a nie skryptu.
Więc blokada 50 zapisów to nie jest problem samego LinkedIn. To cecha całej tej kategorii.
Dlaczego portale z ofertami pracy stają się coraz trudniejsze
W 2026 roku zmieniły się trzy rzeczy i nałożyły się na siebie.
Po pierwsze, detekcja botów stała się behawioralna. Statyczne weryfikacje (User-Agent, reputacja IP, liczba żądań na sekundę) wystarczały kiedyś do zatrzymania amatorskich scraperów. Już nie. Dzisiejsze zabezpieczenia śledzą, jak poruszasz się po stronie: które podstrony ładujesz i w jakiej kolejności, ile czasu na nich spędzasz, czy ponownie pobierasz te same paczki JS, które prawdziwa przeglądarka by zapisała w pamięci podręcznej. Pisaliśmy o tej zmianie w artykule Detekcja botów stała się behawioralna. Portale z ofertami pracy wdrożyły to wcześnie, ponieważ ich użytkownicy wykonują niewielką liczbę powtarzalnych czynności (szukaj, kliknij, czytaj, zapisz), a to ułatwia wykrycie skryptu, który pomija połowę tej sekwencji.
Po drugie, wielkość puli proxy przestała mieć znaczenie. Pula 50 milionów domowych adresów IP nie pomaga, gdy zabezpieczeniem jest korelacja fingerprintów na warstwie połączenia oraz reputacja ASN. Opisaliśmy to w Dlaczego wielkość puli proxy przestała mieć znaczenie. To, co naprawdę działa, to wybór odpowiedniego exitu dla docelowej witryny, a nie posiadanie większej liczby adresów niż ktokolwiek inny.
Po trzecie, kwestie prawne. Zarówno Indeed, jak i LinkedIn mają zespoły prawne, które składają pozwy. Era uruchamiania publicznego scrapera z domowego IP dobiegła końca dla każdego, kto planuje sprzedawać zebrane dane.
Jak dzisiaj wygląda zbieranie danych
W pracy związanej z talent intelligence w 2026 roku schematem, który nadal się sprawdza, jest rozdzielony stos (split stack): pobieranie danych renderowanych przez rzeczywistą przeglądarkę dla zabezpieczonych portali oraz ostrożny dobór exitu, aby nie korzystać z tego samego dostawcy, co wszystkie inne boty.
Na platformie takiej jak FourA sprowadza się to do dwóch komunikujących się ze sobą produktów.
Browser zajmuje się renderowaniem: wysyłasz URL z parametrem unblocker: true, a w odpowiedzi otrzymujesz wyrenderowany HTML, cookies i zrzut ekranu z rzeczywistej sesji przeglądarki. JS jest wykonywany, pola ładowane leniwie (lazy-loaded) się uzupełniają, a request przechodzi testy na warstwie połączenia, które wyłapują większość prostych klientów. Wybór proxy odbywa się pod maską: platforma dobiera exit dla każdego requestu i zwraca jego niejawny identyfikator base36 w response (na najwyższym poziomie r.proxy w Single/Browser lub r.session.proxy w Auto), dzięki czemu kolejne wywołania mogą ponownie użyć tego samego exitu, gdy potrzebujesz ciągłości sesji. W przypadku większości prac związanych z portalami pracy, Auto to najlepszy punkt wejścia, który zarządza modułami Single, Proxy i Browser w zależności od potrzeb danego celu, dzięki czemu Twój kod nie musi tego robić.
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.
Dwie uwagi o tym, co dzięki temu zyskujesz.
Blokada 50 zapisów w stylu ApplyArc to głównie problem z sesją, a nie z pulą adresów. Rzeczywista sesja przeglądarki, mądrze rotowana, działa znacznie dłużej przed aktywowaniem rate-limitera niż surowy klient HTTP. Ponadto response zawiera niejawny identyfikator proxy (proxy id) zamiast surowego exitu, dzięki czemu Twój kod pozostaje prosty i nie musisz śledzić, który exit obsłużył dany request.
Druga uwaga dotyczy tego, czego NIE ma w tym fragmencie kodu. Deduplikacja ofert z różnych portali (ta sama rola data-engineer na LinkedIn, Indeed i własnej stronie kariery firmy, z trzema nieco różnymi nazwami stanowisk) to Twój problem, a nie warstwy zbierania danych. Widzieliśmy, jak zespoły to lekceważą. Normalizacja pochłania więcej czasu inżynieryjnego niż samo pobieranie danych i to właśnie na tym polu konkuruje większość produktów talent intelligence.
Wyniki
Zespół talent intelligence monitorujący 200 firm na trzech portalach potrzebuje około 50 000 pobrań stron tygodniowo: wyników wyszukiwania, stron ze szczegółami ofert oraz okazjonalnego odświeżenia profilu firmy. Wyniki, które chcesz osiągnąć przy takim obciążeniu:
- Wskaźnik sukcesu (success rate) powyżej 95% na celach klasy Indeed, gdzie sukces oznacza wyrenderowany HTML z uzupełnionymi widełkami płacowymi i datą publikacji.
- Koszt pojedynczej oferty poniżej 0,004 USD end-to-end, wliczając w to renderowanie i wybór exitu.
- Częstotliwość odświeżania co 6 do 12 godzin dla aktywnych ról, aby Twoje pulpity nawigacyjne (dashboards) z sygnałami rekrutacyjnymi nie pozostawały w tyle za rynkiem.
Te liczby mają charakter poglądowy i opierają się na raportach zespołów korzystających z tego wzorca split-stack. Rzeczywisty koszt zależy od tego, które portale weźmiesz na cel i jak agresywnie filtrujesz nowe ogłoszenia.
Kluczowe wnioski
Portale z ofertami pracy są dziś pod względem trudności bliższe branży ad-tech i systemom biletowym niż ogólnemu e-commerce. To poważna zmiana i wyjaśnia ona, dlaczego biblioteki do scrapowania, które działały w 2024 roku, wciąż rozbijają się o tę samą ścianę w 2026 roku.
Zespoły, które skutecznie skalują swoje działania, przestają myśleć o „scraperze” jako o jednostce pracy. Traktują sesje, exity i deduplikację jako trzy osobne kwestie i kupują infrastrukturę dla pierwszych dwóch, aby ich inżynierowie mogli spędzić tydzień pracy nad trzecią. Najtańsze dane o ofertach pracy to te, których nie trzeba było pobierać ponownie po oflagowaniu.