Как я превратил сайт из архива в систему продолжения чтения

Этот кейс про сайт, на котором вы читаете этот кейс 🙂

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

Большинство читателей приходили из поиска или по ссылкам в Telegram-канале, открывали один материал, получали ответ и чаще всего завершали визит.

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

В какой-то момент хранить материалы стало недостаточно. Сайт должен был научиться вести читателя дальше.

Контекст и задача

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

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

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

Что я собрал

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

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

Этот кейс показывает discovery-слой более крупного продукта. За три месяца я в одиночку сформулировал продуктовую рамку, спроектировал интерфейс и логику поиска и рекомендаций, разработал Studio, запустил сайт и настроил сбор сигналов.

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

Решением стал не отдельный поиск или новый блок рекомендаций, а управляемая петля: запрос → материал → следующий шаг → сигнал → редакторская правка → более связанная библиотека.

Как это работает на одном сценарии

Например, пользователь ищет ноушен.

Для человека это нормальная формулировка. Но в библиотеке используется название Notion, поэтому старый поиск мог не связать запрос с существующим материалом и показывать слабую или пустую выдачу.

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

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

Дальше редактор выбирает, что чинить:

• добавить вариант написания в словарь;
• поправить описание или метаданные материала;
• создать недостающий материал;
• связать найденный материал с нормальным следующим шагом.

В этом случае редактор добавляет ноушен как вариант написания термина Notion. После этого поиск начинает учитывать живую формулировку пользователя в быстром поиске и полной выдаче.

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

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

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

Как устроена новая система

Поиск через живой язык

Сценарий с запросом «ноушен» — не исключение. Люди пишут variables фигма, иконки как оформлять, миджорней и другие живые формулировки.

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

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

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

Если выдача ломается, редактор видит конкретную причину — опечатку, отсутствующий вариант термина или слабые метаданные — и может её исправить. Семантический ИИ-сигнал можно добавить позже как один из факторов ранжирования, но не как единственный источник ответа.

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

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

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

Поиск помогает человеку найти материал. Следующий вопрос — что должно произойти после того, как ответ найден.

Рекомендации как следующий шаг

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

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

Поэтому рекомендация должна отвечать не на вопрос «что похоже?», а на вопрос:

Что пользователю логично открыть после этого материала?

Система рассматривает рекомендацию как направленную связь: исходный материал → следующий материал. Одна публикация может быть хорошим продолжением для конкретной темы и совершенно неуместной для другой.

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

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

Чтобы автоматический подбор оставался объяснимым, для каждой пары материалов рассчитывается вес связи.

Как считается вес связи

Для каждой направленной пары исходный материал → следующий материал рассчитывается общий вес связи.

Сигналы имеют разный вес. Самый высокий приоритет получают ручные редакторские решения: закрепление и усиление конкретной связи.

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

Есть и штрафы: за слишком общую связь только по метаданным, недостаток контекста в материале и устаревание.

Но даже сильную рекомендацию важно показать в подходящий момент и в подходящем месте.

Где и зачем появляется рекомендация

Рекомендация не должна заполнять свободное место в макете. Она появляется там, где читателю может понадобиться следующий шаг.

На странице материала есть три таких момента:

• в начале — если читателю нужно быстро понять, куда он может двигаться дальше;
• рядом с конкретным фрагментом — на десктопе рекомендация живёт в правом rail, а на адаптиве становится частью текста;
• в конце — когда человек дочитал материал и готов выбрать продолжение.

Рекомендация становится понятнее, когда у неё есть роль:

• сначала — помогает закрыть базовый вопрос перед текущей темой;
• глубже — ведёт к более подробному объяснению;
• применить — помогает превратить идею в действие;
• шире — расширяет контекст соседней темой;
• пример — показывает применение на конкретном кейсе;
• посмотреть / послушать — продолжает тему через видео или подкаст.

Один материал может быть хорошим финальным продолжением, но плохо работать внутри текста. Другой нужен именно рядом с конкретным фрагментом, потому что объясняет соседнюю мысль.

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

Та же логика работает не только внутри материалов, но и на главной странице сайта.

Главная как управляемая витрина

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

Ниже работает блок «В фокусе». Четыре материала подбираются автоматически с учётом веса, ротации и ограничений по сериям, категориям и тегам.

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

Студия, где редактор чинит связи

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

Поэтому я собрал отдельный контур рекомендаций в Studio. В разделе Discovery редактор видит:

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

Studio показывает не только клики, но и продолжение маршрута: открытие следующего материала, чтение хотя бы до 25% и качественное продолжение.

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

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

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

Для рекомендаций важен не отдельный клик, а цепочка: показ → переход → открытие следующего материала → продолжение чтения.

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

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

Сигналы помогают принимать решения, но не превращают систему в необъяснимое самообучение.

Вокруг ядра

Чтобы discovery-петля работала, вокруг неё пришлось собрать полноценную платформу: страницы материалов, редактор, медиатеку, внешние плееры, генеративные обложки, типографику, SEO-карточки, аналитику и систему редиректов.

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

В конце мая 2026 года сайт был запущен на основном домене. Работа строится в трёх контурах:

• локальный контур — разработка и быстрая проверка решений;
• тестовый стенд — stage-окружение в Railway для проверки в рабочей среде;
• продакшн-стенд — основной домен.

Код хранится в GitHub, окружения собираются через Docker, а итоговый продукт развёрнут на Railway.

После запуска я собираю количественные данные в Яндекс Метрике и изучаю реальные сценарии через Вебвизор.

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

Что уже работает и что проверить дальше

Сайт уже запущен, но важно разделить два результата: работающую продуктовую систему и её влияние на поведение читателей.

Что уже работает

Discovery-механика работает как единый контур:

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

Это уже работающий продуктовый результат, а не прототип или концепция.

Что пока не доказано

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

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

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

Что проверять дальше

Следующие 60–90 дней я буду смотреть на три связанных слоя:

• поиск — запросы без результатов, восстановленные запросы и повторяющиеся формулировки;
• рекомендации — показы, клики, CTR конкретных пар и слабые связи;
• чтение — переходы, глубину и продолжение маршрута после рекомендации.

Главный результат проекта — работающая инфраструктура для проверки и наблюдения за поведением discovery-слоя.

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

uxrdsgn.ru стал не просто архивом публикаций, а управляемой системой, связывающей читателя, библиотеку и редакторские решения.