Сервисы сбора позиций в Яндекс и Google: между SEO-аналитикой и программированием
Для любого специалиста в области IT и поисковой оптимизации ранжирование сайта в выдаче — не магия, а математическая модель, приближённую к реальности. Однако ключевой вопрос остаётся открытым: как получить объективные, чистые и пригодные для машинной обработки данные о позициях во 2-м десятке результатов, когда сами поисковые системы активно сопротивляются автоматическим запросам?
С одной стороны, SEO-аналитик хочет видеть тренды. С другой — разработчик создаёт парсеры и интеграции с API. Именно на стыке этих двух ролей рождается истинная ценность сервисов сбора позиций. Давайте без воды разберём, как они устроены «под капотом», какие риски несёт закон РФ и почему программирование в этой нише — не роскошь, а инструмент выживания.
Архитектура сбора данных: от браузера до кластера
Любой сервис позиций решает три фундаментальные задачи:
Имитация реального пользователя — подмена User-Agent, ротация прокси, работа с куками и отпечатками браузера.
Масштабирование — тысячи запросов в минуту к Яндекс и Google без банов.
Нормализация результата — выделение нужного URL в выдачи с учётом персонализации, региона и устройства.
С точки зрения программирования, современный сборщик позиций — это распределённая система, где каждый воркер управляет headless-браузером (Puppeteer, Playwright) либо использует прямой HTTP-клиент с ручным разбором HTML. Второй способ быстрее, но хрупкий: Google всё чаще использует динамическую подгрузку через JavaScript, а Яндекс применяет поведенческие фильтры.
Законодательные ограничения в РФ: что нельзя, а что можно
Статья 272 УК РФ («Неправомерный доступ к компьютерной информации») и Федеральный закон «Об информации» (149-ФЗ) прямо не запрещают сбор общедоступных позиций сайта. Однако есть три критических нюанса:
Автоматизированный сбор с нарушением user-agreement (например, игнорирование robots.txt или агрессивная частота запросов) может быть квалифицирован как нарушение условий использования.
Подмена идентификаторов (подделка IP, заголовков) косвенно попадает под статью о неправомерном доступе, если доказан умышленный обход блокировок.
Хранение персональных данных — если в логах запросов засветились реальные IP частных лиц (не прокси), это уже нарушение 152-ФЗ.
Легальный подход: использовать официальные API Яндекс.Вебмастер (ограниченная выдача) и Google Search Console (только средние позиции, не по каждому запросу). Для детерминированного сбора по конкретным фразам применяют прокси-пулы провайдеров, которые официально предоставляют чистые IP без привязки к физическим лицам.
Почему же тогда программисты всё ещё пишут собственные парсеры? Потому что API дают усреднение по времени, а маркетологам нужна «здесь и сейчас» реакция на изменения алгоритма. Это вечная гонка: система обновляет выдачу — сервис переписывает селекторы.
Что делает сервисы незаменимыми для айтишника
Допустим, вы разработчик и хотите автоматизировать SEO-отчётность внутри своей CRM. Можно написать парсер на Python за неделю, потратить ещё месяц на поддержку 50 прокси и обработку капчи. А можно отдать этот слой на аутсорсинг специализированному сервису.
В этом контексте Тулзар выступает не как «ещё один инструмент», а как готовый backend-агрегатор. Важно понимать: он не решает магически проблему банов, а предоставляет структурированный API, где уже учтены регион, язык, тип устройства и даже обход капчи через сервисы распознавания. Для программиста это означает, что из 200 часов разработки самописного решения остаётся только 10 часов на интеграцию по REST API.
Более того, продвинутые сервисы позволяют загружать до 500 000 ключей и выгружать позиции в JSON или Excel с метаданными: наличие сниппета, ссылки на карточки товаров, блоки «Люди также спрашивают». Для машинного обучения такие сырые данные — золото.
Технический ликбез: метрики качества позиций
Ни один профессиональный инструмент не покажет вам «точную позицию» в смысле «строка №7». Поисковики динамически подгружают рекламу, пакетные ответы, голосовые подсказки. Поэтому грамотный сервис возвращает:
Absolute rank — порядковый номер на странице выдачи (от 1 до 10, далее «дальше 10»).
Relative rank — процент от общего количества результатов.
Variance — разброс позиций по дата-центру (актуально для Яндекса).
Для программиста важнее другое: наличие поля raw_html_hash — чтобы при подозрении на баг можно было запросить оригинальную страницу выдачи и самостоятельно написать парсер-валидатор.
Альтернативы и DIY-подход
Если по закону или бюджету использование готового сервиса невозможно, остаётся путь open-source: библиотека serpapi (но работает через чужое API) или самодельный кластер на Scrapy + Scrapy-rotating-proxies. Пример архитектуры:
Оркестратор (Airflow) ставит задачи.
Worker на Node.js запускает 5 параллельных браузеров с разными профилями.
Решение капчи — через CapMonster или ручной ввод в трекере.
Хранилище — ClickHouse для быстрых агрегатов по временным рядам.
Затраты: ~$200/мес на прокси-пул (3000 IP), $50 на капчу, плюс сервер. Для 10 000 ключей в сутки это выгоднее готового сервиса только если ваш час работы стоит меньше $30.
Итог: когда сервис побеждает код
Сбор позиций в Яндекс и Google — редкая область, где чистый код проигрывает инфраструктуре. Законодательство РФ оставляет узкий коридор для легального парсинга, но не запрещает полностью анализировать открытые данные. Готовые решения, такие как упомянутая платформа, освобождают айти-отдел от рутины: ротации прокси, распознавания капчи и мониторинга структурных изменений в выдаче.
Разработчику же стоит рассматривать подобные сервисы не как «коробку», а как источник надёжного data lake для своих аналитических пайплайнов. И, как всегда в IT, истина между честным API и самописным велосипедом. Выбирайте по задаче, но помните: в погоне за позициями ваш главный актив — время.
Редактор: Анастасия
