Wyzwanie
Benchmark z czerwca 2026 roku od ApplyArc przetestował pięć scraperów ofert pracy z LinkedIn na 200 rzeczywistych pobraniach. Trzy spowodowały oflagowanie konta lub cichy throttling po około 50 zapisach. Tylko dwa przetrwały bez problemów.
Ten benchmark mówi wszystko. Portale pracy były kiedyś łatwym celem. Teraz są jednymi z najtrudniejszych w otwartym internecie.
Jeśli budujesz cokolwiek zależnego od danych z ogłoszeń o pracę (planowanie kadr, benchmarki wynagrodzeń, mapowanie talentów, zatrudnianie jako sygnał do badań kapitałowych), twoja warstwa zbierania walczy ze stosem zabezpieczeń, które nie istniały dwa lata temu. Indeed rzuca CAPTCHA w nieznane sesje. LinkedIn koreluje sygnały po stronie przeglądarki podczas rotacji IP. Glassdoor nakłada rate limit na ASN, a nie na IP. ZipRecruiter wypycha widełki płacowe i datę publikacji do JavaScript, który renderuje się tylko, jeśli twoje nagłówki wyglądają na człowieka, a nie skrypt.
Zatem ściana 50 zapisów nie jest problemem LinkedIn. To właściwość całej kategorii.
Dlaczego portale pracy są coraz trudniejsze
Trzy rzeczy zmieniły się w 2026 roku i się nałożyły.
Po pierwsze, wykrywanie botów stało się behawioralne. Kontrole statyczne (User-Agent, reputacja IP, zapytania na sekundę) kiedyś wystarczały do zatrzymania hobbystycznych scraperów. Już nie. Dzisiejsze zabezpieczenia obserwują, jak poruszasz się po stronie: które strony ładujesz w jakiej kolejności, ile czasu spędzasz, czy ponownie pobierasz te same paczki JS, które prawdziwa przeglądarka zapisałaby w pamięci podręcznej. Pisaliśmy o tej zmianie w Wykrywanie botów stało się behawioralne. Portale pracy wdrożyły to wcześnie, ponieważ ich odwiedzający wykonują małą liczbę powtarzalnych działań (szukaj, kliknij, czytaj, zapisz), a to sprawia, że skrypt jest łatwy do zauważenia, gdy pomija połowę sekwencji.
Po drugie, rozmiar puli proxy przestał mieć znaczenie. Pula 50 milionów domowych IP nie pomaga, gdy obroną jest korelacja fingerprintów w warstwie połączenia plus reputacja ASN. Opisaliśmy to w Dlaczego rozmiar puli proxy przestał mieć znaczenie. To, co działa, to wybór odpowiedniego wyjścia dla strony docelowej, a nie posiadanie większej liczby wyjść niż inni.
Po trzecie, kwestie prawne. Indeed 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 teraz wygląda zbieranie danych
Dla prac talent intelligence w 2026 roku wzorzec, który nadal działa, to podzielony stos: pobieranie renderowane przez prawdziwą przeglądarkę dla chronionych portali oraz ostrożny wybór wyjścia, aby nie pochodzić od tego samego dostawcy co każdy inny bot.
Z platformą taką jak FourA, to dwa komunikujące się ze sobą produkty.
Browser obsługuje stronę renderowania: wyślij URL z unblocker: true, otrzymaj wyrenderowany HTML, cookies i zrzut ekranu z prawdziwej sesji przeglądarki. JS jest ewaluowany, pola ładowane leniwie są wypełniane, a request przechodzi kontrole warstwy połączenia, które łapią większość prostych klientów. Wybór proxy działa w tle: platforma dobiera wyjście per request i zwraca jego zaciemnione id w base36 w response (na poziomie głównym r.proxy w Single/Browser lub r.session.proxy w Auto), aby kolejne wywołania mogły użyć tego samego wyjścia, gdy potrzebujesz ciągłości sesji. Do większości zadań związanych z portalami pracy, Auto jest właściwym punktem wejścia, ponieważ orkiestruje Single, Proxy i Browser na podstawie 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 o tym, co to właściwie daje.
Ściana 50 zapisów w stylu ApplyArc to głównie problem sesji, a nie problem puli. Prawdziwa sesja przeglądarki, rozsądnie rotowana, działa znacznie dłużej przed uruchomieniem rate limit niż surowy klient HTTP. Ponadto response niesie zaciemnione proxy id zamiast surowego wyjścia, dzięki czemu twój kod pozostaje prosty i nie musisz śledzić, które wyjście obsłużyło który request.
Druga uwaga dotyczy tego, czego NIE ma w fragmencie kodu. Deduplikacja między portalami (ta sama rola inżyniera danych na LinkedIn, Indeed i własnej stronie kariery firmy, z trzema nieco różnymi tytułami) to twój problem, a nie warstwy zbierania. Obserwowaliśmy, jak zespoły to niedoceniają. Normalizacja pochłania więcej czasu inżynieryjnego niż pobieranie i to na tym polu większość produktów talent intelligence ostatecznie konkuruje.
Wyniki
Zespół talent intelligence śledzący 200 firm na trzech portalach potrzebuje około 50 000 pobrań stron tygodniowo: wyników wyszukiwania, stron ze szczegółami pracy i okazjonalnego odświeżania stron firmowych. Liczby, które chcesz osiągnąć przy takim obciążeniu to:
- Wskaźnik sukcesu powyżej 95% na celach klasy Indeed, gdzie sukces oznacza wyrenderowany HTML z wypełnionymi widełkami płacowymi i datą publikacji.
- Koszt per oferta poniżej 0,004 USD kompleksowo, włączając renderowanie i wybór wyjścia.
- Częstotliwość odświeżania co 6 do 12 godzin dla aktywnych ról, aby twoje dashboardy z sygnałami rekrutacyjnymi nie pozostawały w tyle za rynkiem.
Te liczby są poglądowe, oparte na raportach zespołów uruchamiających ten podzielony stos. Twój rzeczywisty koszt zależy od tego, w które portale celujesz i jak agresywnie filtrujesz nowe ogłoszenia.
Kluczowy wniosek
Portale pracy są teraz bliższe pod względem trudności do ad-tech i sprzedaży biletów niż do ogólnego e-commerce. To prawdziwa zmiana i wyjaśnia, dlaczego biblioteki do scrapingu, które działały w 2024 roku, ciągle uderzają w tę samą ścianę w 2026 roku.
Zespoły, które się poza to skalują, przestają myśleć o scraperze jako o jednostce pracy. Myślą o sesjach, wyjściach i deduplikacji jako o trzech oddzielnych kwestiach i kupują infrastrukturę dla dwóch pierwszych, aby ich inżynierowie mogli spędzić tydzień na trzeciej. Najtańsze dane z ofert pracy to te, których nie trzeba było ponownie zbierać po oflagowaniu.