Как мы разрабатывали Spiders Pro и какую пользу получили

  • 7 мин.
Фото

Часть инструментов для своей работы мы разрабатываем сами — там, где рыночные сервисы не тянут наши объемы (около полусотни SEO-проектов одновременно, PBN-сетки клиентов до тысячи сайтов) или просто не делают того, что нам нужно. Таких собственных разработок у агентства накопилось несколько, и Spiders Pro — самая давняя из них: мы строим его почти десять лет. Сначала собрали для себя, по дороге пару раз переосмыслили, а в 2025-м переписали с нуля.

Это история о том, как он развивался, что мы поняли за эти годы и какую пользу в итоге получили. Без глянца — с теми решениями, которые в моменте казались правильными, а спустя годы превращались в технический долг.

Как все началось — с инструмента, который сегодня почти не нужен

Началось это в 2015 году, когда самого агентства еще толком не существовало. Первая задача, под которую мы вообще задумали свой сервис, была про динамические сквозные ссылки: тогда это хорошо подтягивало низкочастотку в Яндексе. Технически история была неудобная — площадке нужно было разместить у себя ссылки определенным образом и на всех страницах, причем разные. Решили сделать сервис, который отдает площадке готовый скрипт: она просто ставит его у себя, а все остальное тянется с нашей стороны. Это и было первое ТЗ на то, что позже стало Spiders.

Над названием не мудрили: пауки, которые бегают по вебу, — Spiders. Имя закрепилось в начале 2017-го, тогда же зарегистрировали домены.

Почему центр тяжести сместился на проверку позиций

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

Здесь стоит вспомнить контекст середины 2010-х: зрелых Topvisor и Rush Analytics на рынке еще не было. Существовавшие инструменты часть данных хранили, но график видимости показывали в лучшем случае за месяц — для серьезной аналитики это несерьезно. Поэтому мы заложили в свое ТЗ простое требование: хранить все без ограничения по времени, чтобы строить графики видимости за два-три года. Сделали и внедрили внутри.

Следом появился мониторинг — по той же логике «на рынке этого нет». Полноценного мониторинга в вебмастерах тогда не существовало, а у нас была понятная боль: клиент что-то ломает на сайте, а мы видим просадку позиций спустя месяц. Так в Spiders добавился модуль, который отслеживал состояние и предупреждал заранее.

К 2017-му мы инструмент упаковали и понемногу давали действующим клиентам — им было удобно, что вся история проверок хранится в одном месте, даже если они от нас потом уходили. Но продуктом в полном смысле слова Spiders не стал: не было ни ресурсов, ни, честно говоря, намерения его продавать. Мы просто им пользовались.

Где старая версия начала проигрывать

Дальше произошла поучительная вещь. Решение, которое в 2015–2017 годах опережало рынок — бесконечное хранение данных, — за десять лет превратилось в балласт. Данных копилось все больше, система тяжелела, а архитектура и стек, нормальные для своего времени (старая версия была написана на Zend Framework), к концу десятилетия заметно устарели. Поддерживать архитектуру десятилетней давности стало дороже, чем она того стоила: каждое улучшение давалось все сложнее, а отдача падала.

Вывод, который мы из этого сделали и который полезен любой команде, строящей внутренние инструменты: сервис, собранный «под здесь и сейчас», без расчета на годы вперед, — это отложенный технический долг. Рано или поздно он предъявляется к оплате. И рефакторить такую систему примерно раз в десять лет — не аврал, а нормальный инженерный цикл.

К этой точке мы и подошли: дешевле и честнее было построить новое, чем бесконечно латать старое.

Как делали новый Spiders

В 2025-м мы переписали сервис заново — на современном стеке, с архитектурой, рассчитанной на рост. Самым нетривиальным оказался не сам код, а перенос данных: за десять лет накопился огромный объем истории, и задача была затащить ее в новую систему так, чтобы та не унаследовала старую захламленность. Над этим мы возились заметную часть года.

Поменялся и сам подход к разработке. ТЗ на функционал ставят не продакты в вакууме, а действующие SEO- и PBN-специалисты агентства — те же люди, которые завтра этим инструментом будут пользоваться. Находится баг или неудобство — правится по алерту, потому что мотивация прямая.

Фото Фото Фото Фото

Отдельно отметим то, что за последние пару лет сильно изменило скорость: часть вещей теперь собирается с помощью AI-инструментов кратно быстрее, чем раньше. Появилось пространство для внутренних мини-проектов — когда специалист сам набрасывает рабочий прототип под свою задачу, не дожидаясь, пока она попадет в приоритет большой разработки. Удачные прототипы мы потом доводим до состояния модуля. Один из таких — инструмент, который анализирует выдачу и помогает собирать SEO-ТЗ: пока в тестовой стадии, но направление рабочее.

Параллельная история — PBN-автоген

Второй большой модуль рос с 2024 года и закрывал другую боль. У клиентов были сетки по 30, 200, 800, иногда тысяче сайтов, а развернуть несколько десятков PBN-сайтов в месяц руками физически невозможно. К тому моменту нейросети дали технологическую базу для автоматизации контента — и мы собрали автоген.

Сейчас PBN-модуль закрывает весь цикл работы с сеткой:

  • автоматическая развертка WordPress-сайтов с панелью управления на сервере;
  • в библиотеке 150+ PBN-оптимизированных тем, можно загружать собственные;
  • темы помечаются как использованные в конкретной сети — чтобы внутри одной сетки не уходило по двадцать сайтов на одном шаблоне;
  • генерация информационных и коммерческих текстов по готовым промптам, генерация изображений через AI, управление публикациями из одного интерфейса;
  • мониторинг сети: доступность, скорость, индексация, ссылочный профиль, ранжирование, трафик;
  • автобиддеры для аукционных доменов с контролем ставок за выкуп.

В цифрах: через автоген за время работы прошло около двух десятков PBN-проектов и порядка пяти тысяч сайтов. Развертка и первичное наполнение одного сайта раньше занимали два-три часа ручной работы — сейчас около получаса. В ближайших планах — автогенерация контент-плана и автозалив текстов по нему.

Фото Фото Фото

Какую пользу мы получили

Главное, что дал нам Spiders Pro, — это инструмент, заточенный ровно под наши процессы, а не под усредненного пользователя чужого сервиса. Массовые проверки на полусотне проектов, кластерная работа, своя логика отчетности — все это делается так, как удобно нам.

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

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

Есть и менее очевидная польза. Инструмент строят и каждый день используют одни и те же люди — те, кто ведет клиентские проекты, — поэтому он правится быстро и не отрывается от реальных задач. Многолетняя история данных позволяет смотреть на видимость не вспышками, а в динамике за годы. А современный стек снова дал нам то, ради чего все затевалось десять лет назад, — возможность быстро добавлять то, что нужно прямо сейчас.

Теперь, возможно, это пригодится и вам

Мы не строили Spiders Pro как продукт на продажу. Мы строили рабочий инструмент для себя и своих клиентов и пользуемся им ежедневно. Но раз он закрывает наши задачи на таких объемах, велик шанс, что закроет и ваши.

Если у вашей команды похожая история — большая семантика и массовые проверки, сетки, которые перестало тянуть руками, — покажем, как это устроено изнутри.

Будет полезно

    Заявка на сотрудничество








    Публикации

    Смотреть все
    Смотреть все