Свой трекер позиций вместо Topvisor и Serpstat: расчёт стоимости на 1000 ключей в день

SEO-агентства и внутренние маркетологи рано или поздно задают себе один и тот же вопрос: зачем платить за подписку на трекер позиций, если можно собрать собственный парсер выдачи? Ответ не так прост, как кажется — себестоимость самостоятельного мониторинга складывается не только из серверов, но и из прокси, капчи и времени на поддержку скриптов. В этой статье разберём реальную математику на примере проверки 1000 ключевых фраз в день.

Зачем агентства делают свой трекер позиций

Готовые сервисы вроде Topvisor, Serpstat, SE Ranking или Rush Analytics удобны: не нужно думать о прокси, капче и серверах — просто вводишь ключи и получаешь отчёт. Но у этой удобности есть цена, которая растёт пропорционально количеству проверяемых фраз и регионов. Если агентство ведёт 15-20 клиентов, и у каждого по 500-2000 ключей, счёт за подписку быстро достигает суммы, сравнимой с зарплатой junior-специалиста.

Вторая причина — гибкость. В готовом сервисе вы не можете изменить частоту проверки для отдельных ключей, добавить кастомную логику (например, отслеживать не только позицию, но и сниппет, наличие быстрых ссылок или отзывов), выгрузить сырые данные в свою BI-систему. Собственный трекер решает эти задачи, но требует инфраструктуры: сервер, база данных, скрипты парсинга и, главное, прокси для обхода защиты поисковых систем от автоматических запросов.

Третья причина — контроль над данными. Агентства, которые работают с крупными клиентами по NDA, не всегда готовы передавать список ключевых запросов и доменов сторонним облачным сервисам. Свой трекер позволяет хранить всё на собственной инфраструктуре.

Из чего складывается стоимость проверки позиций

Прежде чем считать деньги, нужно понять механику: чтобы узнать позицию сайта по ключевому запросу, парсер должен отправить запрос в выдачу Яндекса или Google, получить HTML-страницу результатов и найти в ней нужный домен. Для 1000 ключей в день — это минимум 1000 запросов, а если вы проверяете оба поисковика и несколько регионов, цифра умножается в 2-4 раза.

Поисковые системы агрессивно блокируют автоматические запросы с одного IP: после 20-50 запросов подряд с одного адреса Яндекс начинает показывать капчу, а Google — временно банит IP на несколько часов. Поэтому каждый запрос должен идти через отдельный или часто сменяемый прокси. Отсюда появляется основная статья расходов — не сервер и не скрипт, а именно прокси-инфраструктура.

Полная структура затрат выглядит так:

• Прокси для ротации IP — основная переменная статья расходов, зависит от объёма запросов
• Сервер или VPS для запуска скриптов по расписанию — фиксированная небольшая сумма
• Решение капчи (антикапча-сервисы) — дополнительная статья, если прокси недостаточно качественные
• Время разработчика на написание и поддержку парсера — разовая и периодическая затрата
• Хранение и визуализация данных — база данных, дашборд, обычно минимальные расходы

Подписка vs свой трекер: сравнение по статьям расходов

Чтобы оценить, когда свой трекер выгоднее подписки, удобно сравнить статьи расходов напрямую. Ниже — обобщённая таблица без привязки к конкретным тарифам, которая показывает логику выбора.

Параметр	Готовый сервис (подписка)	Свой трекер позиций
Стоимость на 1000 ключей/день	Растёт пропорционально тарифному плану, фиксированная ежемесячная сумма	Складывается из трафика прокси + аренды сервера, масштабируется плавно
Гибкость настройки	Ограничена функционалом сервиса	Полная — любая частота, регион, глубина выдачи
Нужен разработчик	Нет	Да, на старте и периодически для поддержки
Риск банов/капчи	Берёт на себя сервис	Ложится на вас, решается прокси и задержками
Точка окупаемости	—	Обычно от 3000-5000 ключей в день и выше

Вывод из таблицы простой: при небольшом объёме ключей (до 2000-3000 в день) подписка почти всегда выгоднее, потому что затраты на разработку и поддержку своего решения не окупаются. Но при больших объёмах — от нескольких тысяч ключей в день, особенно если нужно проверять их несколько раз в сутки или в разных регионах — собственная инфраструктура начинает выигрывать по экономике.

Расчёт прокси на 1000 ключей в день

Главный вопрос в себестоимости — сколько прокси нужно для 1000 запросов в день без банов и капчи. Возьмём средние безопасные лимиты, которые на практике используют парсеры выдачи:

• Яндекс: 30-50 запросов с одного IP в сутки без риска капчи при случайных задержках между запросами 10-30 секунд
• Google: 15-25 запросов с одного IP в сутки, система банит жёстче и быстрее

Если вы проверяете 1000 ключей только в Яндексе, при лимите 40 запросов на IP нужно минимум 25 уникальных адресов в день. С учётом ретраев при неудачных запросах и запаса на случай временных банов закладывайте 30-40 IP. Если проверяете оба поисковика, цифра удваивается — потребуется порядка 60-80 IP в сутки.

Важный нюанс: при работе через пул IP с ротацией по запросу (а не по сессии) один и тот же физический прокси-сервер может «закрывать» гораздо больше IP-адресов, если провайдер предоставляет динамическую ротацию. В этом случае расчёт идёт не по количеству адресов, а по объёму трафика — обычно одна проверка позиции весит 50-200 КБ HTML, то есть 1000 запросов в день — это 50-200 МБ трафика, совсем не критичная нагрузка даже для среднего тарифа.

Какие прокси нужны для Яндекса и Google

Тип прокси напрямую влияет на то, сколько капчи и банов вы получите, а значит — и на реальную себестоимость проверки. Разберём три варианта.

Прокси дата-центров — самый дешёвый вариант по стоимости трафика, но у них плохая репутация в базах поисковых систем: IP дата-центров массово используются для парсинга, поэтому Яндекс и Google быстро распознают их и показывают капчу уже после нескольких запросов. Для низкочастотной проверки небольшого количества ключей прокси дата-центров ещё можно использовать, но на объёме в 1000+ запросов в день доля капчи становится слишком высокой, и экономия на трафике съедается расходами на антикапчу.

Резидентные прокси — IP-адреса реальных домашних пользователей, которые поисковые системы воспринимают как обычный трафик. Доля капчи здесь в разы ниже, что критично при больших объёмах проверки. Для парсинга выдачи на 1000 и более ключей в день резидентные прокси обычно дают лучшее соотношение стоимости и стабильности, особенно при работе с Google, который жёстче всего банит дата-центровые адреса.

Мобильные прокси — используют IP мобильных операторов, которые часто меняются у тысяч реальных абонентов (NAT), поэтому один и тот же адрес может «принадлежать» разным пользователям в течение дня. Это даёт максимальную живучесть при агрессивном парсинге, но стоит дороже. Мобильные прокси оправданы, если вы проверяете позиции в мобильной выдаче отдельно от десктопной или работаете с особенно капризными региональными запросами Яндекса.

Тип прокси	Доля капчи на 1000 запросов	Когда использовать
Дата-центр	Высокая	До 200-300 ключей в день, низкая частота
Резидентные	Низкая	1000+ ключей в день, Google и Яндекс
Мобильные	Минимальная	Мобильная выдача, сложные регионы

Пошаговая настройка своего трекера

Разберём процесс сборки своего трекера позиций по шагам — без глубокого погружения в код, на уровне архитектуры решения.

1. Выбор источника данных. Определите, парсите ли вы напрямую выдачу поисковика через HTTP-запросы или используете headless-браузер (например, через Puppeteer/Playwright) для имитации реального пользователя. Второй вариант надёжнее против антибот-защиты, но медленнее и дороже по ресурсам сервера.
2. Настройка пула прокси. Подключите прокси-провайдера с ротацией IP по запросу или по времени. Для Яндекса и Google лучше использовать разные пулы прокси, так как у систем разные пороги блокировки.
3. Логика ретраев. Если запрос вернул капчу или ошибку, скрипт должен автоматически сменить IP и повторить запрос, а не просто зафиксировать ошибку.
4. Парсинг результата. Из полученного HTML извлекается позиция нужного домена в выдаче — обычно через поиск по тегам ссылок и сравнение с доменом клиента.
5. Хранение истории. Результаты сохраняются в базу данных с датой проверки, чтобы можно было строить графики динамики позиций.
6. Расписание запуска. Скрипт запускается по cron или планировщику задач раз в сутки (или чаще), равномерно распределяя 1000 запросов по времени, чтобы не создавать пиковую нагрузку на прокси-пул.

Пример кода проверки позиций на Python

Ниже — упрощённый пример логики запроса к поисковой выдаче через прокси с ротацией. Это демонстрационный каркас, который показывает принцип работы, а не готовое боевое решение.

import requests
import random
import time

PROXY_LIST = [
    "http://user:[email protected]:8000",
    "http://user:[email protected]:8000",
    # ... пул прокси из сотен адресов
]

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

def check_position(keyword, domain, search_engine="yandex"):
    proxy = random.choice(PROXY_LIST)
    proxies = {"http": proxy, "https": proxy}

    if search_engine == "yandex":
        url = f"https://yandex.ru/search/?text={keyword}"
    else:
        url = f"https://www.google.com/search?q={keyword}"

    try:
        response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=10)
        if "captcha" in response.text.lower():
            return None  # нужна ротация IP и повтор запроса
        position = find_domain_position(response.text, domain)
        return position
    except requests.RequestException:
        return None

def find_domain_position(html, domain):
    # упрощённая логика поиска позиции домена в выдаче
    results = extract_links(html)
    for i, link in enumerate(results, start=1):
        if domain in link:
            return i
    return None

for keyword in keyword_list:
    pos = check_position(keyword, "example.com")
    save_to_db(keyword, pos)
    time.sleep(random.uniform(5, 15))  # случайная задержка между запросами
  

В реальном проекте вместо ручного парсинга HTML часто используют headless-браузер с подменой User-Agent и fingerprint, а пул прокси подключают через провайдера с автоматической ротацией на уровне endpoint — это снимает необходимость хранить список адресов вручную и упрощает масштабирование до нескольких тысяч запросов в день.

Сколько реально можно сэкономить

Чтобы ответить на вопрос об экономии, нужно сравнить две модели расходов в динамике по мере роста объёма ключей.

При небольшом объёме — до 1000-2000 ключей в день — стоимость подписки на готовый трекер обычно сопоставима или даже ниже совокупных затрат на разработку и поддержку своего решения, если учитывать время специалиста. Разработка минимально жизнеспособного парсера с нуля занимает от нескольких дней до пары недель, плюс периодическая поддержка при изменении вёрстки поисковой выдачи — а Яндекс и Google меняют разметку результатов нередко.

Переломный момент наступает, когда объём проверки растёт до нескольких тысяч ключей в день или нужно проверять позиции несколько раз в сутки, в разных регионах и устройствах (десктоп/мобайл). В этом сценарии стоимость готовой подписки растёт линейно или даже прогрессивно с объёмом, а расходы на свой трекер растут гораздо медленнее — основная статья (прокси-трафик) дорожает не так резко, как тарифные планы SaaS-сервисов при переходе на следующий уровень пакета.

Практический ориентир для агентств: если вы отслеживаете позиции 5-10 и более клиентов одновременно, совокупный объём обычно превышает 5000-10000 ключевых фраз в день — именно на этом масштабе свой трекер почти всегда выгоднее любой готовой подписки, при условии что в штате есть кто-то, способный поддерживать парсер.

Частые ошибки при самостоятельном парсинге

На практике большинство проблем со своим трекером позиций связаны не с кодом, а с недооценкой инфраструктурных нюансов.

• Экономия на прокси. Попытка сэкономить на дешёвых дата-центровых прокси приводит к массовым капчам, которые нужно решать через сторонние антикапча-сервисы — в итоге суммарные расходы оказываются выше, чем при использовании более качественных прокси изначально.
• Отсутствие задержек между запросами. Слишком быстрые последовательные запросы с одного IP моментально привлекают внимание антибот-систем, даже если IP качественный.
• Игнорирование региональности. Яндекс показывает разную выдачу в зависимости от региона пользователя — без правильной геопривязки прокси данные о позициях будут некорректными.
• Отсутствие мониторинга здоровья парсера. Поисковики периодически меняют вёрстку страницы выдачи, и без алертов на падение успешности парсинга можно неделями собирать пустые или некорректные данные, не замечая этого.
• Игнорирование мобильной выдачи. Десктопная и мобильная выдача часто отличаются, и если клиенту важна именно мобильная позиция, нужен отдельный контур парсинга с соответствующими User-Agent и, желательно, мобильными IP.

Заключение

Собственный трекер позиций становится экономически оправданным, когда объём проверки превышает несколько тысяч ключей в день, а в команде есть ресурс на поддержку парсера. На меньших объёмах готовая подписка почти всегда дешевле с учётом скрытых затрат на разработку. Главная переменная в себестоимости своего решения — не сервер и не код, а прокси-инфраструктура, которая определяет долю капчи и стабильность данных.

Если вы планируете собрать трекер позиций на 1000 и более ключей в день, начните с расчёта трафика и тестового пула прокси на небольшой выборке запросов. Для стабильного парсинга Яндекса и Google на таких объёмах разумно сразу закладывать резидентные прокси — они дают минимальную долю капчи при приемлемой стоимости трафика и хорошо масштабируются вместе с ростом количества отслеживаемых клиентов.