Все статьи

Парсинг джоб-бордов без блокировки на 50 сохранениях

В 2026 году парсинг джоб-бордов стал одной из самых сложных задач в открытом вебе. Рассказываем, что изменилось и как команды по анализу рынка труда продолжают собирать данные.

Сложности

В июне 2026 года бенчмарк от ApplyArc протестировал пять инструментов для скрапинга LinkedIn на 200 реальных выгрузках вакансий. Три из них привели к пометке аккаунта или скрытому ограничению скорости запросов примерно после 50 сохранений. Только два прошли тест без последствий.

Этот бенчмарк описывает всю ситуацию. Раньше джоб-борды были легкой мишенью. Теперь они стали одними из самых сложных целей в открытом вебе.

Если вы создаете продукт, зависящий от данных о вакансиях (планирование рабочей силы, бенчмаркинг зарплат, картирование талантов, анализ найма как сигнал для инвестиционных исследований), ваш уровень сбора данных сталкивается со стеком защитных механизмов, которых не существовало два года назад. Indeed выдает CAPTCHA для незнакомых сессий. LinkedIn сопоставляет сигналы на стороне браузера при ротации IP. Glassdoor применяет rate limit на уровне ASN, а не отдельных IP. ZipRecruiter переносит диапазон зарплат и дату публикации в JavaScript, который рендерится только в том случае, если ваши header выглядят как человеческие, а не как скрипт.

Таким образом, лимит в 50 сохранений не является проблемой одного лишь LinkedIn. Это свойство всей категории сайтов.

Почему парсить джоб-борды становится все сложнее

В 2026 году изменились три вещи, и они наложились друг на друга.

Во-первых, системы обнаружения ботов стали поведенческими. Раньше статических проверок (User-Agent, репутация IP, количество запросов в секунду) было достаточно, чтобы остановить любительские скрипты. Теперь этого мало. Современные системы защиты следят за тем, как вы перемещаетесь по сайту: какие страницы и в каком порядке загружаете, сколько времени проводите на них, запрашиваете ли вы повторно те же JS-бандлы, которые реальный браузер сохранил бы в кэше. Мы писали об этом сдвиге в статье Переход систем обнаружения ботов на поведенческий анализ. Джоб-борды внедрили этот подход одними из первых, поскольку их посетители совершают небольшое количество повторяющихся действий (поиск, клик, чтение, сохранение), из-за чего скрипт легко заметить, если он пропускает половину этой цепочки.

Во-вторых, размер пула proxy перестал иметь значение. Пул из 50 миллионов резидентных IP не поможет, если защита использует корреляцию фингерпринтов на уровне соединения в сочетании с репутацией ASN. Мы подробно разобрали это в статье Почему размер пула proxy больше не имеет значения. Эффективно работает выбор правильной точки выхода для целевого сайта, а не владение самым большим количеством адресов.

В-третьих, юридический аспект. У Indeed и LinkedIn есть юридические отделы, которые активно подают иски. Эра запуска публичных парсеров с домашнего IP закончилась для всех, кто планирует продавать собранные данные.

Как выглядит сбор данных сегодня

Для задач анализа рынка труда в 2026 году по-прежнему работает разделенный стек: рендеринг страниц в реальном браузере для защищенных сайтов плюс тщательный выбор точек выхода, чтобы ваши запросы не шли от того же провайдера, что и у всех остальных ботов.

На платформе FourA это реализовано как взаимодействие двух продуктов.

Браузер берет на себя рендеринг: вы отправляете URL с параметром unblocker: true и получаете отрендеренный HTML, cookies и скриншот реальной сессии браузера. JS выполняется, поля с ленивой загрузкой заполняются, а request проходит проверки на уровне соединения, которые отсекают большинство базовых клиентов. Выбор proxy происходит под капотом: платформа выбирает точку выхода для каждого request и возвращает ее скрытый идентификатор в формате base36 в 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 содержит скрытый идентификатор proxy вместо прямого адреса точки выхода, поэтому ваш код остается простым, и вам не нужно отслеживать, какая именно точка выхода обработала конкретный request.

Второе замечание касается того, чего нет в этом фрагменте кода. Дедупликация данных с разных платформ (одна и та же вакансия инженера данных на LinkedIn, Indeed и собственной странице компании, но с тремя слегка отличающимися заголовками) является вашей задачей, а не уровня сбора данных. Мы видели, как команды недооценивают эту сложность. Нормализация отнимает больше времени инженеров, чем сам сбор данных, и именно в этой области конкурирует большинство продуктов для анализа рынка труда.

Результаты

Команде по анализу рынка труда, отслеживающей 200 компаний на трех джоб-бордах, требуется около 50 000 загрузок страниц в неделю: результаты поиска, страницы с описанием вакансий и периодическое обновление страниц компаний. Показатели, к которым стоит стремиться при такой нагрузке:

  • Доля успешных запросов (success rate) выше 95% на целях уровня Indeed, где под успехом понимается отрендеренный HTML с заполненными полями диапазона зарплат и даты публикации.
  • Стоимость обработки одной вакансии менее $0,004 под ключ, включая рендеринг и выбор точки выхода.
  • Частота обновления от 6 до 12 часов для активных вакансий, чтобы ваши дашборды с сигналами о найме не отставали от рынка.

Эти цифры приведены для иллюстрации и основаны на отчетах команд, использующих паттерн с разделенным стеком. Ваши реальные затраты зависят от того, какие джоб-борды вы парсите и насколько агрессивно фильтруете новые публикации.

Главный вывод

По сложности парсинга джоб-борды теперь ближе к сферам ad-tech и продажи билетов, чем к обычному e-commerce. Это серьезный сдвиг, который объясняет, почему библиотеки для скрапинга, работавшие в 2024 году, постоянно натыкаются на те же ограничения в 2026 году.

Команды, которые успешно масштабируют свои процессы, перестают думать о «парсере» как о единице работы. Они рассматривают сессии, точки выхода и дедупликацию как три отдельные задачи. Они покупают готовую инфраструктуру для первых двух, чтобы их инженеры могли сосредоточиться на третьей. Самые дешевые данные о вакансиях — это те, которые вам не пришлось собирать заново после блокировки.