Проблема
В июне 2026 года benchmark от ApplyArc протестировал пять скраперов вакансий LinkedIn на 200 реальных загрузках вакансий. Три из них получили пометку аккаунта или были незаметно ограничены после примерно 50 сохранений. Только два отработали чисто.
Этот бенчмарк описывает всю суть. Раньше сайты вакансий были легкими целями. Теперь они одни из самых сложных в открытом вебе.
Если вы создаете что-либо, зависящее от данных о вакансиях (планирование персонала, бенчмаркинг зарплат, картирование талантов, наем как сигнал для исследования акций), ваш слой сбора борется с набором защит, которых не было два года назад. Indeed выдает CAPTCHA для незнакомых сессий. LinkedIn сопоставляет сигналы на стороне браузера при ротации IP. Glassdoor применяет rate limit на уровне ASN, а не IP. ZipRecruiter помещает вилку зарплат и дату публикации в JavaScript, который рендерится только в том случае, если ваши headers похожи на человека, а не на скрипт.
Поэтому ограничение в 50 сохранений не является проблемой LinkedIn. Это свойство всей категории.
Почему сайты вакансий становятся сложнее
В 2026 году изменились три вещи, и они наложились друг на друга.
Первое: обнаружение ботов стало поведенческим. Статических проверок (User-Agent, репутация IP, количество запросов в секунду) раньше было достаточно для остановки любительских скраперов. Больше нет. Сегодняшние системы защиты следят за тем, как вы перемещаетесь по сайту: какие страницы вы загружаете и в каком порядке, сколько времени вы проводите, запрашиваете ли вы заново те же JS-бандлы, которые реальный браузер закешировал бы. Мы писали об этом сдвиге в статье Bot Detection Went Behavioral. Сайты вакансий внедрили это рано, потому что их посетители выполняют небольшое количество повторяющихся действий (поиск, клик, чтение, сохранение), и это позволяет легко обнаружить скрипт, когда он пропускает половину последовательности.
Второе: размер пула proxy перестал иметь значение. Пул резидентных IP на 50 миллионов не помогает, когда защита представляет собой корреляцию отпечатков на уровне соединения плюс репутацию ASN. Мы рассмотрели это в статье Why Proxy Pool Size Stopped Mattering. Что работает, так это выбор правильного выхода для целевого сайта, а не наличие большего количества выходов, чем у кого-либо еще.
Третье: юридический аспект. У Indeed и LinkedIn есть команды юристов, которые подают иски. Эра запуска публичного скрапера с домашнего IP закончилась для всех, кто планирует продавать собранные данные.
Как выглядит сбор данных сейчас
Для работы с аналитикой талантов в 2026 году продолжающим работать паттерном является разделенный стек: реальный рендеринг в браузере для защищенных сайтов, плюс тщательный выбор выхода, чтобы вы не приходили от того же провайдера, что и все остальные боты.
С платформой вроде FourA это два продукта, взаимодействующих друг с другом.
Browser управляет рендерингом: отправьте URL с unblocker: true, получите отрендеренный HTML, cookie и скриншот реальной сессии браузера. JS выполняется, поля с ленивой загрузкой заполняются, и request проходит проверки на уровне соединения, которые ловят большинство базовых клиентов. Выбор proxy работает под капотом: платформа выбирает выход для каждого request и возвращает его непрозрачный base36 id в response (на верхнем уровне 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.
Два замечания о том, что это вам дает.
Ограничение в 50 сохранений в стиле ApplyArc в основном является проблемой сессии, а не проблемой пула. Настоящая сессия браузера при продуманной ротации длится намного дольше до срабатывания rate limit, чем обычный HTTP-клиент. Кроме того, response содержит непрозрачный id proxy, а не прямой выход, поэтому ваш код остается простым и вам не нужно отслеживать, какой выход обработал какой request.
Второе замечание касается того, чего НЕТ в сниппете. Дедупликация между сайтами (одна и та же должность дата-инженера в LinkedIn, Indeed и на собственной странице вакансий компании с тремя немного разными названиями) является вашей проблемой, а не проблемой слоя сбора. Мы наблюдали, как команды недооценивают это. Нормализация съедает больше инженерного времени, чем получение данных, и именно здесь большинство продуктов аналитики талантов в конечном итоге конкурируют.
Результаты
Команде аналитики талантов, отслеживающей 200 компаний на трех сайтах, требуется около 50 000 загрузок страниц в неделю: результаты поиска, страницы с подробным описанием вакансий и периодическое обновление страниц компаний. Показатели, которых вы хотели бы достичь при такой нагрузке:
- Уровень успеха выше 95% на целях класса Indeed, где успех означает отрендеренный HTML с заполненной вилкой зарплат и датой публикации.
- Стоимость одной вакансии менее $0.004 от начала до конца, включая рендеринг и выбор выхода.
- Частота обновления от 6 до 12 часов для активных вакансий, чтобы ваши дашборды сигналов найма не отставали от рынка.
Эти цифры приведены для примера на основе отчетов команд, использующих этот паттерн разделенного стека. Ваша реальная стоимость зависит от того, на какие сайты вы нацелены и насколько агрессивно вы фильтруете свежие публикации.
Основной вывод
Сайты вакансий сейчас по сложности ближе к ad-tech и продаже билетов, чем к обычной электронной коммерции. Это реальный сдвиг, и он объясняет, почему библиотеки скрапинга, которые работали в 2024 году, продолжают сталкиваться с тем же препятствием в 2026 году.
Команды, которые масштабируются дальше, перестают думать о "скрапере" как о единице работы. Они думают о сессиях, выходах и дедупликации как о трех разных задачах и покупают инфраструктуру для первых двух, чтобы их инженеры могли тратить свое время на третью. Самые дешевые данные о вакансиях это те, которые вам не пришлось собирать заново после блокировки.