Это моя первая статья на Хабре, поэтому сначала немного предыстории. Работаю в интернет‑маркетинге с 2011 года. Застал смену десятков алгоритмов поисковиков, эволюцию подходов в SEO, был опыт работы с перформанс‑каналами (хотя база всё же сеошная). Из чисто технического — базовое знание Python. Само собой, HTML+CSS. Одним словом, не разработчик. Но вот я и подхожу к сути — почему вообще тема возникла.

Развивался как SEO‑специалист, SEO‑тимлид, а затем дорос до руководителя направления роста. Где‑то полтора года назад споткнулся об очевидную вещь: в Рунете практически нет единой, структурированной базы знаний по интернет‑маркетингу. Подобных ресурсов немало на английском, есть на испанском, видел и на азиатских языках. На русском — ноль.

В сентябре прошлого года закончился контракт с работодателем. Планировал отдохнуть пару недель и приняться за поиск работы, но в какой‑то момент решил систематизировать свои знания. Задумался: почему такого ресурса не существует? У меня накопилось много заметок по основным терминам и явлениям, подкреплённых личным опытом и реальными кейсами. В один прекрасный день я создал собственную вики‑энциклопедию и начал её заполнение и развитие. Но это тоже преамбула, а теперь — к сути.

Я подумал: в работе мы пользуемся огромным количеством разных сервисов. Почему бы мне самому не попробовать создать инструменты для автоматизации рутины? Уж я точно знаю индустрию изнутри и чего конкретно не хватает в быту. К осени довелось поработать и с набирающим силу GEO (Generative Engine Optimization). Проанализировал свои знания и отсутствие бюджета на наёмную разработку и понял: придётся осваивать роль разработчика в бытовом понимании.

По итогу остановился на создании нескольких pet‑проектов: прототипа сервиса для анализа упоминаний бренда в нейровыдаче и набора утилит для автоматизации отчётности. До MVP первого прототипа я дошел за 3 месяца, используя связку no‑code инструментов и API для отладки сценариев и промптов.

Затем я решил сделать третий проект — то, о чём, собственно, эта статья. Вкратце: набор из 5 SEO‑инструментов для малого бизнеса (генератор Title и Description, генератор FAQ, аудит по критериям E‑E-A‑T, анализатор структуры сайта, парсер конкурентов).

Идея: владелец бизнеса в той или иной нише (скажем, стоматологии, юрфирмы, клининга или ремонтной бригады) выбирает свою нишу и получает готовые материалы, вместо того чтобы нанимать SEO‑специалиста или гуглить по ночам, что вообще такое этот ваш E‑E-A‑T и для чего он нужен. От первой строчки до запуска прошло 25–30 дней, работал по 2–4 часа в день, без выходных как таковых, но и без супергеройства.

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

План? Какой такой план?

Расписанного по дням техзадания на месяц вперёд у меня не было. Я делал то, что казалось важнее прямо сейчас. Конечно, звучит как отсутствие дисциплины — так а зачем скрывать то, что было? Но в оправдание скажу: когда ты сам себе и разработчик, и тестировщик, и продакт‑менеджер, актуализация красивого плана иногда съедает больше времени, чем практика. Моя система работала нормально, но ровно до первой серьёзной ошибки.

Косяк первый: письма с результатом уходили пустыми

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

Со спамом разобрался быстро: помогла привязка правильного SMTP‑плагина к WordPress вместо стандартного модуля хостинга. А вот пустые письма я заметил не потому, что кто‑то пожаловался (продукт ещё даже не был запущен), а потому что проверял себя же.

Тест выглядел следующим образом: я оформил заказ ровно так, как это сделал бы клиент, и полез проверять почту. Если бы я просто пробежался глазами по коду, скорее всего, ничего бы не заметил. С точки зрения кода письмо честно отправлялось. Просто внутри было пусто.

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

Косяк второй: голый код прямо на странице

Второй случай был неприятнее, потому что вылез не во время целенаправленного тестирования, а уже после того, как я мысленно поставил галочку «готово».

Я зашёл на одну из нишевых страниц просто проверить, как она выглядит, и вместо формы заказа увидел натурально исходный HTML, отображённый как обычный текст. Прямо на странице, для любого посетителя. Смотрелось это, мягко говоря, не как продукт, готовый к использованию. Если бы я не решил на всякий случай ещё раз пройтись глазами по каждой готовой странице перед финальным релизом, узнал бы об этом от первого реального гостя. Это был бы худший из возможных моментов.

Тестировать себя — вообще не формальность

QA‑отдела у меня, конечно, нет. Поэтому единственный рабочий способ поймать проблему до пользователя — самому пройти весь путь от начала до конца, без скидок на «да я и так знаю, как это должно работать». Знать мало, надо перепроверить всё с дотошностью поискового робота.

Именно так я отловил оба косяка. Не код‑ревью (кому его делать, если ты без команды), а буквально эмуляция действий постороннего человека: выбрать нишу, заполнить форму, дождаться письма, открыть его. Тут я для себя чётко понял одну вещь, вроде бы очевидную, но которую сам регулярно игнорировал.

Проверка «код исполняется без ошибок» и проверка «то, что видит живой человек, реально работает» — это разные проверки, и они ловят разные классы проблем. Баг с пустыми письмами прошёл бы любую формальную техническую проверку на ура. Ошибок‑то не было. Просто внутри — пустота.

5 инструментов, одинаковая боль, и почему это всё же хорошо

Спрашивали потом несколько раз: какой из 5 дался тяжелее всего? Ждали, наверное, историю про один особенно проклятый компонент. Но на самом деле все они дались примерно одинаково.
Сперва думал, это просто совпадение. Потом пришёл к другой мысли: если один инструмент из пяти похожих внезапно выстреливает сложностью сильно выше остальных, это обычно значит, что задачу изначально плохо разбили на части, и куда‑то незаметно затесалась лишняя сложность.

У меня все 5 инструментов используют одну и ту же базовую логику обработки заказа и генерации результата, различаясь только содержанием (какие данные мы тянем под какую нишу). Основу я строил 1 раз, довольно медленно и внимательно, и остальные четыре легли на неё почти без трения. Осознанным планом это не было — скорее повезло, что первый инструмент делал не торопясь, и заложенная структура оказалась достаточно универсальной.

Что получилось в итоге

Сформировались выводы.

Без тестировщиков единственная защита от глупых, но обидных багов — прогонять весь пользовательский путь целиком и регулярно, а не полагаться на «так код же работает, чего ещё нужно?». Такие проблемы иначе не находятся вообщ
2 дня из 30 на непредвиденный баг — это вполне нормальная цена соло‑разработки, а не провал. Вопрос не в том, случится баг или нет, а в том, потратишь ты на его починку полчаса или неделю. Тут помогает только привычка тестировать рано и часто.
Если несколько похожих задач ощущаются одинаково по сложности — это неплохой косвенный признак, что фундамент под ними построен правильно. Продукт я запустил, все 5 инструментов работают. Но тот момент с голым кодом на живой странице я запомнил хорошо: с тех пор лишний раз, перед тем как сказать себе «готово», прохожу всё заново глазами постороннего, а не разработчика, который и так знает, что должно произойти.
Понимаю, что эти рассуждения могут звучать наивно, и своего дилетантизма в разработке и QA я не скрываю. Но надо же с чего‑то начинать, правильно? Зато теперь я лучше понимаю, что и как позиционировать в плане техники, отрыв от продукта отсутствует как класс, и маркетинговые задачи решать намного проще.

Сделал 5 автоматических инструментов для SEO за месяц и дважды чуть не опозорился на старте