Я сделал сервис со 100 онлайн-инструментами и 1894 страницами. Теперь проверяю, способен ли SEO вытянуть его с нуля

Несколько месяцев назад я начал делать Helionix — сервис с бесплатными онлайн-инструментами для повседневных задач.

Идея максимально простая: вместо десятка разных сайтов для сжатия картинки, объединения PDF, форматирования JSON, расчётов, работы с текстом или проверки SEO открыть один сервис и решить задачу там.

На момент публикации в Helionix уже около 100 полноценных инструментов, 12 категорий и 1894 страницы.

Но самое интересное для меня сейчас даже не разработка.

Я решил провести довольно долгий эксперимент:

может ли новый русскоязычный сайт практически без рекламного бюджета вырасти за счёт полезных инструментов, контента и поискового трафика?

Пока всё только начинается, поэтому вместо истории успеха здесь будет история о том, что уже сделано, как устроен проект и почему я вообще выбрал такой путь.

Я постоянно сталкивался с одной и той же ситуацией.

Нужно сделать какую-то элементарную операцию:

И начинается поиск.

Один сайт предлагает загрузить файл и зарегистрироваться.

Другой показывает три полноэкранных рекламных блока.

Третий даёт сделать одну операцию, а следующая функция уже находится на совершенно другом сервисе.

Четвёртый вообще требует установить программу ради задачи на 30 секунд.

Отсюда появилась довольно банальная идея:

а что если постепенно собрать большое количество таких небольших инструментов в одном месте?

Так появился Helionix.

Я специально не хотел делать сервис вокруг одной функции.

Сейчас инструменты распределены по отдельным направлениям:

При этом цель не в том, чтобы написать на странице:

«У нас 5000 инструментов»

а потом обнаружить, что 4900 из них — просто разные формы одного калькулятора.

На текущем этапе реально работает около 100 отдельных инструментов.

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

Есть отдельные инструменты для PDF, SEO, JSON, текста, дат и других задач.

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

То есть для некоторых задач файл вообще не обязательно куда-либо отправлять.

Здесь начинается более интересная часть проекта.

Я не хотел делать архитектуру вида:

Главная → Каталог → 100 инструментов

и ждать, когда поисковики когда-нибудь решат, что этого достаточно.

Вокруг каждого направления существует огромное количество отдельных поисковых задач.

Человек может искать не:

«инструмент для изображений»

а:

«как уменьшить размер PNG»

«как перевести WebP в JPG»

«почему фотография весит 15 мегабайт»

«как проверить JSON на ошибку»

«как объединить PDF без программы»

Поэтому кроме инструментов у Helionix появился большой информационный слой.

Есть страницы категорий, страницы функций и много статей под конкретные вопросы и сценарии использования.

В итоге текущая статическая сборка содержит:

1894 страницы.

Это не означает, что я рассчитываю получить трафик на каждую из них.

Наоборот.

Логика примерно следующая:

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

Для проекта я выбрал Astro.

Главная причина довольно очевидна: основная часть Helionix прекрасно подходит под статическую генерацию.

Мне не нужен тяжёлый серверный рендеринг для каждой информационной страницы.

Поэтому статьи, категории и большая часть оболочки сайта собираются заранее.

React используется там, где появляется непосредственно интерактивный инструмент.

В итоге схема примерно такая:

Astro отвечает за страницы и структуру → React появляется внутри интерактивных компонентов → на сервер отправляется уже статическая сборка.

Сейчас сайт работает на VPS через Nginx и Traefik.

При почти двух тысячах страниц это пока вообще не создаёт какой-либо серьёзной нагрузки на сервер.

И это одна из вещей, которые мне особенно нравятся в таком подходе.

Большой сайт вовсе не обязательно означает большой backend.

При таком количестве страниц неожиданно быстро понимаешь, что написать очередной инструмент иногда проще, чем поддерживать целостность всего проекта.

Например, недавно я решил привести внутренние URL к единому виду.

На сайте используется trailing slash:

/tools/image/compress/

но постепенно в разных местах накопились ссылки вида:

/tools/image/compress

Сервер корректно делал 301 redirect, поэтому внешне всё работало.

Но после полного анализа сборки оказалось:

41 497 внутренних ссылок вели сначала на редирект.

Уникальных URL без завершающего / было около 1900.

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

После нескольких проходов по исходникам результат стал таким:

Плохих внутренних ссылок: 0 Уникальных URL без trailing slash: 0 Битых внутренних href: 0

И именно подобные вещи сейчас занимают заметную часть времени.

Когда страниц десять — можно открыть каждую руками.

Когда их почти две тысячи — без собственных проверок сборки уже становится неприятно.

Это произошло буквально недавно.

Во время массовой обработки большого файла с данными статей PowerShell неправильно обработал UTF-8.

В результате вместо:

Горизонтальное и вертикальное отражение

на проде появились классические:

Горизонтальное...

Причём сами статьи были целыми.

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

Визуально это выглядело так, будто одновременно сломалась огромная часть сайта.

К счастью, перед массовым изменением была сделана копия файла.

Откат занял несколько минут.

После этого у проекта появилось ещё одно правило:

никаких массовых изменений исходников без свежего backup.

И отдельное правило для Windows:

не доверять обработку UTF-8 исходников первой попавшейся PowerShell-команде.

Мелочь, а бодрит прекрасно.

Вот здесь как раз начинается сам эксперимент.

Домен новый.

Сайт появился в продакшене совсем недавно.

Поэтому ожидать сейчас десятки тысяч переходов было бы странно.

Google уже начал постепенно находить страницы.

На одном из первых замеров было известно около двух тысяч URL, часть из них уже попала в индекс, появились первые показы и первые переходы.

Средние позиции пока далеко не впечатляющие.

И это нормально.

Сейчас мне гораздо интереснее наблюдать, какие страницы вообще начнут получать поисковый спрос.

Потому что заранее можно сколько угодно рассуждать:

«Вот этот инструмент точно нужен людям».

А потом поисковик показывает совершенно другую картину.

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

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

Если SEO — значит SEO.

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

То есть эти 1894 страницы для меня не конечный продукт, а большая первая выборка.

Можно было бы запустить рекламу и довольно быстро получить красивые цифры посещаемости.

Но тогда эксперимент потерял бы часть смысла.

Helionix изначально строится как проект с очень низкой стоимостью содержания.

Статические страницы почти ничего не требуют от сервера.

Большинство инструментов бесплатные.

Поэтому хочется проверить модель, при которой основной поток пользователей постепенно появляется из поиска.

Первые внешние публикации я тоже начал делать только сейчас.

Например, отправил проект на Product Radar.

Теперь хочу постепенно размещать Helionix на других российских площадках и рассказывать не столько:

«посмотрите на мой замечательный сайт»,

сколько о самом процессе его развития.

Сейчас монетизация для меня вторична.

Это сознательное решение.

Пока нет стабильного трафика, оптимизировать доход с каждого пользователя практически бессмысленно.

Сначала хочется доказать более фундаментальную вещь:

сервис способен стабильно привлекать аудиторию.

Если это получится, вариантов развития уже много.

Самый очевидный — реклама.

Дальше могут появиться более тяжёлые инструменты, платные функции, дополнительные возможности обработки файлов, API и AI-функции.

Но превращать новый сайт без аудитории в SaaS с пятью тарифами по 990 рублей мне совершенно не хочется.

Сначала пользователи.

Потом монетизация.

Потому что одна отдельная страница практически ничего не решает.

Если сделать десять инструментов и десять страниц, а потом каждый день открывать Search Console с вопросом:

«Ну когда уже трафик?»

эксперимент закончится довольно быстро.

Мне гораздо интереснее построить достаточно большую систему.

Допустим, из 1900 страниц серьёзный органический трафик в итоге начнут получать только 50.

Это уже 50 точек входа на сайт.

Часть пользователей перейдёт дальше по инструментам.

По каким-то запросам Helionix со временем сможет закрепиться.

После этого можно создавать новые страницы уже не вслепую, а на основании данных.

Поэтому стратегия здесь довольно скучная:

делать → индексировать → ждать данные → усиливать то, что начинает работать → повторять.

Никакой кнопки «получить SEO-трафик».

В ближайшее время я не планирую резко увеличивать количество страниц.

Основной каркас уже достаточно большой.

Сейчас важнее:

Через несколько месяцев будет особенно интересно сравнить цифры с сегодняшними.

В худшем случае получится довольно большой технический эксперимент.

В лучшем — основа самостоятельного интернет-сервиса.

Сервис уже находится в открытом доступе:

Helionix — https://helionix.ru/

Все текущие инструменты бесплатные.

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

Особенно интересно услышать мнение людей, которые сами развивали проекты через SEO:

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

Продолжение с реальными цифрами индексации и трафика, думаю, будет намного интереснее первой части.