Wyzwanie
W czerwcu 2026 roku benchmark od ApplyArc przetestował pięć scraperów ofert pracy na LinkedIn na próbie 200 rzeczywistych pobrań. Trzy z nich doprowadziły do oznaczenia konta lub po cichu nałożonego 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ś łatwymi celami. Dziś należą do najtrudniejszych w otwartym internecie.
Jeśli budujesz cokolwiek opartego na danych o ofertach pracy (planowanie zatrudnienia, benchmarking wynagrodzeń, mapowanie talentów, analiza rekrutacji jako sygnału dla rynku akcji), twoja warstwa pobierania danych walczy ze stosem zabezpieczeń, które nie istniały dwa lata temu. Indeed wyświetla strony weryfikacyjne dla nierozpoznanych sesji. LinkedIn koreluje sygnały z przeglądarki pomiędzy rotacjami IP. Glassdoor nakłada rate limit na poziomie ASN, a nie pojedynczego IP. ZipRecruiter umieszcza widełki płacowe i datę publikacji w kodzie JavaScript, który renderuje się tylko wtedy, gdy twoje nagłówki wyglądają jak od człowieka, a nie ze skryptu.
Bariera 50 zapisów nie jest więc problemem samego LinkedIna. 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 przeszła na analizę behawioralną. Statyczne kontrole (User-Agent, reputacja IP, liczba zapytań na sekundę) wystarczały kiedyś do powstrzymania amatorskich scraperów. Już nie. Dzisiejsze zabezpieczenia obserwują sposób poruszania się po stronie: które podstrony ładujesz i w jakiej kolejności, ile czasu na nich spędzasz, czy pobierasz ponownie te same paczki JS, które prawdziwa przeglądarka zapisałaby w pamięci podręcznej. Pisaliśmy o tej zmianie w Bot Detection Went Behavioral. Portale z ofertami wdrożyły to wcześnie, ponieważ ich użytkownicy wykonują niewielką liczbę powtarzalnych czynności (wyszukiwanie, kliknięcie, czytanie, zapisanie), co ułatwia wykrycie skryptu pomijającego połowę tej sekwencji.
Po drugie, wielkość puli proxy przestała mieć znaczenie. Pula 50 milionów rezydencjalnych adresów IP nie pomaga, gdy obrona opiera się na korelacji fingerprintu w warstwie połączenia oraz reputacji ASN. Omówiliśmy to w Why Proxy Pool Size Stopped Mattering. Działa dobór odpowiedniego punktu wyjściowego 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ą dział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 wygląda zbieranie danych obecnie
W analizie rynku pracy w 2026 roku schematem, który stale działa, jest rozdzielony stos technologiczny: pobieranie z renderowaniem w prawdziwej przeglądarce dla chronionych serwisów oraz staranny dobór wyjścia proxy, aby nie łączyć się od tego samego dostawcy, co każdy inny bot.
W przypadku platformy takiej jak FourA oznacza to współpracę dwóch produktów.
Browser obsługuje renderowanie: wyślij URL z unblocker: true, odbierz wyrenderowany HTML, pliki cookie i zrzut ekranu z prawdziwej sesji przeglądarki. JS jest wykonywany, leniwie ładowane pola się uzupełniają, a żądanie przechodzi kontrole warstwy połączenia, które wyłapują większość prostych klientów. Dobór proxy odbywa się pod maską: platforma wybiera węzeł wyjściowy dla każdego żądania i zwraca jego nieprzezroczysty identyfikator base36 w odpowiedzi (w r.proxy na najwyższym poziomie w Single/Browser lub r.session.proxy w Auto), dzięki czemu kolejne wywołania mogą użyć tego samego węzła, gdy potrzebujesz ciągłości sesji. W przypadku większości zadań związanych z job boardami Auto to właściwy punkt wejścia, koordynuje Single, Proxy i Browser zależnie od wymagań celu, więc 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 na temat tego, co to w praktyce daje.
Blokada po 50 zapisach w stylu ApplyArc to głównie problem sesji, a nie samej puli. Prawdziwa sesja przeglądarki, rotowana z rozmysłem, działa znacznie dłużej przed uruchomieniem rate limitu niż zwykły klient HTTP. Ponadto response zawiera nieprzejrzysty identyfikator proxy zamiast surowego adresu wyjściowego (exit), dzięki czemu 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 między różnymi portalami (ta sama rola data engineera na LinkedInie, Indeed i na stronie kariery firmy, z trzema nieco różnymi tytułami) to zadanie dla Twojej aplikacji, a nie warstwy pobierania danych. Widzieliśmy zespoły, które to lekceważyły. Normalizacja pochłania więcej czasu inżynierów niż samo pobieranie i to na niej ostatecznie 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 i okazjonalnego odświeżenia profilu firmy. Liczby, które warto osiągnąć przy takim obciążeniu:
- Wskaźnik sukcesu powyżej 95% dla celów pokroju Indeed, gdzie sukces oznacza wyrenderowany HTML z wypełnionymi widełkami płacowymi i datą publikacji.
- Koszt pojedynczej oferty poniżej 0,004 USD end-to-end, wliczając renderowanie i dobór exit node.
- Częstotliwość odświeżania co 6 do 12 godzin dla aktywnych stanowisk, aby panele sygnałów rekrutacyjnych nie miały opóźnień względem rynku.
Liczby te mają charakter poglądowy i opierają się na raportach zespołów stosujących ten model rozdzielonego stosu. Rzeczywisty koszt zależy od wybranych portali oraz stopnia agresywności filtrowania najnowszych ogłoszeń.
Główne wnioski
Pod względem trudności portale z ofertami pracy są dziś bliższe branży ad-tech i systemom sprzedaży biletów niż standardowemu e-commerce. To istotna zmiana, która wyjaśnia, dlaczego biblioteki do scrapingu działające w 2024 roku w 2026 roku nieustannie trafiają na tę samą barierę.
Zespoły, które skutecznie się skalują, przestają traktować scraper jako pojedynczy moduł. Postrzegają sesje, węzły wyjściowe (exits) i deduplikację jako trzy odrębne zagadnienia. Kupują gotową infrastrukturę dla dwóch pierwszych, dzięki czemu inżynierowie mogą poświęcić czas na trzecie. Najtańsze dane o ofertach pracy to te, których nie trzeba pobierać ponownie po nałożeniu blokady.