Мультиаккаунтинг в рекрутинге: вакансии клиентов без путаницы
Как HR-агентства и рекрутеры ведут аккаунты работодателей на hh.ru, LinkedIn и Indeed без банов, путаницы и потери доступа при смене сотрудника.
Рекрутинговое агентство редко работает с одним работодателем. В среднем у агентства среднего размера на руках 15–40 активных аккаунтов клиентов на hh.ru, LinkedIn, Indeed, Glassdoor — где-то агентство публикует вакансии от своего имени, где-то заходит под логином самого клиента, потому что так настроена его подписка. Один рекрутер в неделю может переключаться между 8–10 такими кабинетами. Проблема в том, что большинство платформ для найма построены вокруг идеи «один человек — один аккаунт», а агентская модель работы этому прямо противоречит.
Разберём, что в этой ситуации законно, что рискованно, и как организовать работу так, чтобы не терять доступы и не ловить блокировки на ровном месте.
Что разрешают платформы, а что нет
Важно различать два сценария, которые внешне похожи, а по сути разные.
Сценарий А — легитимный. У каждого клиента есть свой официальный аккаунт работодателя. Агентство получает к нему доступ (логин-пароль, права администратора вакансий, API-ключ) и работает в его периметре. Это стандартная агентская модель, её разрешают все крупные платформы — именно для этого у hh.ru и LinkedIn есть тарифы и роли для агентств.
Сценарий Б — рискованный. Агентство создаёт несколько аккаунтов от своего имени, чтобы обойти лимит вакансий на одном кабинете, или заводит фиктивные профили рекрутеров, чтобы писать кандидатам массово в обход анти-спам фильтров. Здесь правила площадок прямо против: LinkedIn блокирует за создание дублирующих аккаунтов и автоматизированный аутрич без согласия, hh.ru ограничивает число откликов и контактов с одного IP при подозрении на спам.
Таблица ниже — не исчерпывающий список правил (они меняются), а ориентир, на что стоит смотреть перед тем, как заводить очередной кабинет.
| Платформа | Официальная агентская модель | Основной риск при мультиаккаунтинге |
|---|---|---|
| Есть (Recruiter Lite, Recruiter corporate seats) | Блокировка за дублирующие личные профили, за массовые инвайты с разных аккаунтов с одного устройства | |
| hh.ru | Есть (доступ по доверенности, суб-пользователи работодателя) | Ограничение контактов/откликов при подозрении на одного человека за несколькими кабинетами |
| Indeed | Частично (один employer account может иметь нескольких пользователей) | Подозрительная активность при входе в разные employer-аккаунты с одного браузера подряд |
| Glassdoor | Ограниченно | Жалобы на фейковые отзывы от имени разных «сотрудников» — отдельная, более серьёзная проблема репутации, не технический мультиаккаунтинг |
Вывод простой: если за каждым кабинетом стоит реальный работодатель, который дал агентству доступ, — это нормальная практика. Технические меры ниже нужны не для обхода правил, а чтобы платформа не путала законные параллельные сессии с подозрительной автоматизацией.
Почему один браузер на все кабинеты — плохая идея
Самый частый способ организовать работу в маленьком агентстве — вкладки Chrome, переключение логинов, иногда режим инкогнито для «параллельного» входа. Это работает, пока кабинетов три. На десятом начинаются проблемы:
- Общие куки и кэш. Платформа видит один и тот же браузерный отпечаток и IP для всех кабинетов клиентов. Если один из них попадает под подозрение (например, клиент сам вёл себя подозрительно до вас), система может насторожиться и к соседним сессиям из того же окружения.
- Случайные действия не под тем логином. Рекрутер отвечает кандидату или редактирует вакансию, забыв, что переключился на другой аккаунт клиента. Это не технический риск, а репутационный — и случается он тем чаще, чем больше кабинетов висит параллельно.
- Нет разделения по IP. Для многих платформ геопривязка важна: вакансия, опубликованная «из региона клиента», выглядит органичнее, чем если все 20 клиентских аккаунтов агентства заходят с одного офисного IP в другой стране.
Решение — изолированные профили браузера, каждый со своим набором куки, кэша, истории и, если нужно, отдельным IP. Подробно о том, какой тип прокси выбрать под конкретную задачу — геопривязку клиента, стабильность сессии или просто разделение нагрузки — разобрано в материале про типы прокси для мультиаккаунтинга.
Как агентство организует профили под клиентов на практике
Рабочая схема, которая масштабируется с 5 до 50+ клиентских кабинетов, обычно выглядит так.
1. Один профиль — один аккаунт работодателя. Не «один профиль — одна платформа», а именно по клиенту. Если у клиента есть кабинет и на hh.ru, и на LinkedIn, для них можно держать отдельные профили или один профиль с несколькими вкладками — но без смешивания с другими клиентами.
2. Прокси привязан к региону клиента, а не к региону агентства. Если клиент нанимает в Алматы, разумно вести его кабинет через прокси с казахстанским IP — это снимает лишние вопросы у платформы и даёт более релевантную выдачу вакансии в поиске по региону.
3. Куки и сессия переносятся при передаче клиента другому рекрутеру. Когда менеджер уходит в отпуск или клиента передают другому сотруднику, важно не создавать новый вход с нуля (это может выглядеть подозрительно для платформы и лишний раз требует повторного прохождения капчи и подтверждения по почте/телефону), а передать уже рабочую сессию. Для этого удобен экспорт и импорт куки в формате JSON или Netscape — профиль переезжает к новому рекрутеру без потери авторизации.
https://www.youtube.com/
https://www.wikipedia.org/
https://www.reddit.com/
https://www.amazon.com/
Приложение само откроет профиль, прогонит по сайтам и закроет — занятый профиль пропускается.
4. 2FA клиента хранится отдельно и привязана к профилю. Многие работодательские кабинеты на LinkedIn и hh.ru защищены двухфакторной аутентификацией, которую настраивал сам клиент. Если коды 2FA разбросаны по почте, мессенджерам и бумажкам у разных сотрудников — это и путаница, и дыра в безопасности. Хранилище 2FA-ключей, привязанное к конкретному профилю, снимает эту проблему: код генерируется там же, где открывается нужный кабинет, и не теряется при смене сотрудника.
Подробнее о том, как устроено шифрование профильных данных и где хранить коды двухфакторной аутентификации командой, можно почитать в материале про безопасность профилей. В GetAntik это реализовано через управление безопасностью профиля — данные шифруются на устройстве паролем аккаунта, а сервер их прочитать не может.
Прогрев нового кабинета, когда клиент только подключился
Когда агентство получает доступ к свежесозданному аккаунту работодателя — например, клиент только зарегистрировался на hh.ru специально для работы с вами — резкий вход и публикация пяти вакансий подряд выглядит для платформы нетипично. Разумная последовательность:
- В первый день — только вход, просмотр интерфейса, заполнение карточки компании.
- На второй-третий день — публикация одной вакансии, без автоматических откликов и массовых приглашений.
- Постепенное увеличение активности в течение одной-двух недель, прежде чем выходить на полный объём публикаций и откликов.
Это не магия и не гарантия от блокировки, а снижение вероятности того, что система примет новый аккаунт за бота. Общий принцип прогрева подробно разобран в статье про подготовку аккаунтов перед стартом активности — там же про типичные ошибки вроде слишком быстрого набора активности в первые часы.
Команда: кто и что видит в кабинетах клиентов
В агентстве с 5–10 рекрутерами логины клиентов не должны лежать в общей таблице Excel. Разумное разделение прав:
- Руководитель отдела видит все профили клиентов, может передавать их между рекрутерами.
- Рекрутер работает только с теми аккаунтами, которые закреплены за ним, и не видит кабинеты коллег.
- Стажёр может получить временный доступ к одному кабинету под наблюдением, без права менять настройки аккаунта клиента.
Если нужно проверить, что именно делает новый сотрудник в кабинете важного клиента в первую неделю — не для слежки, а чтобы вовремя поймать ошибку вроде случайного отклонения всех откликов подряд — удобно заглянуть в его браузер в реальном времени, не прерывая работу.
- lev открыл Airdrop zkSync 07
- artem закрыл FB · US · BM-14
- maya смотрит браузер artem
- lev передал TikTok Shop 03
Когда клиента передают от одного рекрутера другому — при увольнении, отпуске или просто перераспределении нагрузки — важно, чтобы доступ переходил вместе с профилем, а не терялся в переписке «скинь логин в личку». Эта механика и типичные грабли разобраны в статье про роли и передачу профилей в команде. В GetAntik это работает через командные роли и лимиты: у каждого участника свои права и свой пул профилей, а передача кабинета — это смена владельца профиля, а не пересылка пароля.
Частые ошибки
Один логин клиента — на нескольких компьютерах без разделения. Рекрутер заходит с ноутбука в офисе, потом с домашнего компьютера вечером — оба раза с разным отпечатком браузера и разным IP. Платформа видит два разных устройства для одного аккаунта в течение суток и может запросить дополнительное подтверждение или временно ограничить доступ. Решается синхронизацией профиля между устройствами, чтобы отпечаток и сессия оставались те же независимо от того, с какого компьютера рекрутер вошёл — об этом подробнее в материале про синхронизацию профилей между устройствами.
Смешивание личного LinkedIn-аккаунта рекрутера с рабочими кабинетами клиентов. Рекрутер ищет кандидатов и со своего личного профиля, и параллельно администрирует вакансии трёх клиентов в соседних вкладках того же браузера. Если платформа заблокирует личный аккаунт за что-то не связанное с работой, под вопросом может оказаться вся сессия, включая соседние вкладки с кабинетами клиентов.
Отсутствие регламента на увольнение. Рекрутер уволился, а пароли от пяти клиентских кабинетов остались у него в менеджере паролей браузера. Без централизованного управления доступами агентству приходится вручную обзванивать клиентов и просить сменить пароли — долго и неловко перед клиентом.
Игнорирование требований платформы к единому бренду вакансии. Если у клиента есть и официальный employer-аккаунт, и параллельно агентство публикует те же вакансии от своего имени «для скорости», это путает кандидатов и иногда прямо нарушает правила площадки насчёт дублирования объявлений. Прежде чем заводить параллельный кабинет, стоит свериться с условиями конкретной платформы.
Сколько это стоит в реальности
Для агентства с 20 активными клиентскими кабинетами и 4–5 рекрутерами обычно достаточно плана на 100 профилей — туда укладывается не только по одному профилю на кабинет, но и резерв под тестовые или временные доступы. Отдельные прокси на регион клиента стоят от нескольких долларов в месяц за статичный IP у большинства провайдеров — расход небольшой по сравнению со стоимостью потерянного доступа к кабинету крупного клиента или недели простоя из-за блокировки. Актуальные тарифы на число профилей можно посмотреть на странице с тарифами.
FAQ
Нужно ли согласие клиента на то, чтобы агентство работало в его кабинете через отдельный браузерный профиль с изменённым отпечатком? Отдельный профиль — это внутренняя организация работы агентства, а не вмешательство в аккаунт клиента. Но доступ к самому кабинету клиент должен предоставить явно — логином, ролью администратора вакансий или другим официальным способом, который предусмотрен платформой.
Можно ли вести личный LinkedIn рекрутера и клиентские employer-аккаунты в одном и том же профиле браузера? Технически можно, но не стоит. Личный аккаунт рекрутера подвержен своим рискам — спам-жалобы от кандидатов, случайные нарушения правил площадки — и смешивать его с рабочими кабинетами клиентов значит переносить эти риски на чужие аккаунты.
Что делать, если платформа всё равно запросила подтверждение личности по одному из клиентских кабинетов? Пройти верификацию от имени клиента — обычно это телефон или email, привязанный к аккаунту клиента, а не агентства. Если агентство проходит верификацию за клиента без его ведома, это может нарушать условия платформы и создаёт риски при утрате доступа в будущем.
Как быстро восстановить доступ, если клиентский кабинет внезапно заблокировали? Первым делом проверить переписку платформы — обычно указана причина. Если дело в подозрении на автоматизацию или аномальную активность, стоит снизить интенсивность после разблокировки и первое время работать по схеме прогрева. Общий порядок действий при блокировке профиля разобран в чек-листе диагностики и восстановления доступа.