Проблема
В июне 2026 года бенчмарк от ApplyArc протестировал пять скраперов вакансий для LinkedIn на 200 реальных выгрузках. У трех аккаунты получили флаги или скрытый троттлинг примерно после 50 сохранений. Без проблем отработали только два.
Этот бенчмарк отлично описывает ситуацию. Сайты поиска работы раньше были простыми целями. Сейчас они стали одними из самых сложных в открытом вебе.
Если вы создаете продукт на основе данных о вакансиях (планирование найма, бенчмаркинг зарплат, анализ талантов, оценка динамики найма для инвестиционного анализа), ваш слой сбора данных сталкивается со стеком защит, которого не было еще два года назад. Indeed выдает страницы проверки для незнакомых сессий. LinkedIn сопоставляет сигналы на стороне браузера при ротации IP. Glassdoor накладывает rate limit на уровне ASN, а не per-IP. ZipRecruiter помещает вилку зарплат и дату публикации в JavaScript, который рендерится, только если ваши headers выглядят как запросы от реального пользователя, а не скрипта.
Барьер в 50 сохранений характерен не только для LinkedIn. Это общее свойство всей категории.
Почему сайты поиска работы защищаются все сильнее
В 2026 году изменились три фактора, и они наложились друг на друга.
Во-первых, обнаружение ботов перешло на поведенческий анализ. Статических проверок (User-Agent, репутация IP, количество requests в секунду) раньше хватало для блокировки простых скраперов. Теперь этого мало. Современные системы защиты следят за вашими действиями на сайте: какие страницы и в каком порядке вы открываете, сколько времени на них проводите, запрашиваете ли повторно те же JS-бандлы, которые реальный браузер сохранил бы в кэш. Мы рассказывали об этом сдвиге в статье Bot Detection Went Behavioral. Доски вакансий внедрили этот подход одними из первых, так как действия их пользователей понятны и повторяемы (поиск, клик, просмотр, сохранение), поэтому скрипт легко выявить, если он пропускает часть шагов.
Во-вторых, размер пула proxy перестал иметь значение. Пул из 50 миллионов резидентских IP не спасет, если защита использует корреляцию отпечатков на уровне соединения и репутацию ASN. Мы подробно разобрали это в материале Why Proxy Pool Size Stopped Mattering. Результат дает правильный выбор точки выхода под целевой сайт, а не максимальное количество адресов.
В-третьих, усилились юридические риски. У Indeed и LinkedIn есть юридические команды, которые регулярно подают иски. Время запуска публичных скраперов с домашнего IP прошло для каждого, кто планирует монетизировать собранные данные.
Как устроен сбор данных сегодня
Для работы с аналитикой рынка труда в 2026 году стабильно работает раздельный стек: сбор с полноценным рендерингом в браузере для защищенных платформ плюс точный выбор точек выхода, чтобы не использовать того же провайдера, что и остальные боты.
На платформе вроде FourA это решается связкой двух продуктов.
Browser берет на себя рендеринг: отправьте URL с unblocker: true, получите отрендеренный HTML, cookies и скриншот из реальной сессии браузера. JS выполняется, поля с lazy-load заполняются, а request проходит проверки на уровне соединения, отсекающие большинство базовых клиентов. Выбор proxy происходит под капотом: платформа подбирает exit-узел для каждого request и возвращает его opaque base36 id в response (в r.proxy верхнего уровня для Single/Browser или в r.session.proxy для Auto), поэтому последующие вызовы могут использовать тот же exit, когда требуется непрерывность сессии. Для большинства задач по сбору данных с job-бордов оптимальной точкой входа является 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 limit, чем обычный HTTP-клиент. При этом response содержит непрозрачный proxy id вместо прямого exit IP, поэтому код остается простым и вам не нужно отслеживать, какой именно exit обработал конкретный request.
Второе замечание касается того, чего в сниппете НЕТ. Дедупликация между разными сайтами (одна и та же вакансия data engineer на LinkedIn, Indeed и карьерном сайте компании с тремя слегка отличающимися названиями) остается вашей задачей, а не задачей уровня сбора данных. Мы часто видим, как команды недооценивают эту сложность. Нормализация отнимает больше инженерного времени, чем сам сбор, и именно здесь конкурирует большинство продуктов в сфере аналитики найма.
Результаты
Команде talent intelligence, отслеживающей 200 компаний на трех площадках, требуется около 50 000 запросов страниц в неделю: результаты поиска, страницы вакансий и периодическое обновление страниц компаний. Целевые метрики для такой нагрузки:
- Успешность выше 95% на целях уровня Indeed, где успехом считается отрисованный HTML с заполненной вилкой зарплаты и датой публикации.
- Стоимость одной вакансии менее $0.004 под ключ, включая рендеринг и выбор exit node.
- Интервал обновления от 6 до 12 часов для активных вакансий, чтобы дашборды сигналов найма не отставали от рынка.
Эти цифры ориентировочные и основаны на отчетах команд, использующих такой раздельный стек. Реальные расходы зависят от целевых площадок и агрессивности фильтрации свежих публикаций.
Главный вывод
Сайты с вакансиями по сложности защиты приблизились к ad-tech и билетным сервисам, обогнав обычный e-commerce. Это серьезный сдвиг, объясняющий, почему библиотеки для парсинга из 2024 года упираются в одни и те же блокировки в 2026 году.
Команды, которые успешно масштабируются, перестают воспринимать скрапер как единую неделимую задачу. Они разделяют сессии, exit nodes и дедупликацию на три независимых уровня. Они берут готовую инфраструктуру для первых двух задач, чтобы инженеры могли сосредоточиться на третьей. Самые дешевые данные о вакансиях это те, которые не пришлось собирать заново после блокировки.