Автоматизация · Продажи
Макет в Figma, продукт на проде — что я собирал
Ко мне пришёл готовый дизайн-макет: SEO-маркетплейс элитной недвижимости Москвы. Каталог жилых комплексов, карточки лотов, фильтры, страницы районов — всё уже нарисовано в Figma, дизайнер свою часть сделал. Моя задача была превратить картинки в работающий Next.js-продукт, который не просто красиво выглядит, а собирает органический трафик и превращает его в заявки.
Разница между «сверстать макет» и «собрать SEO-продукт» — это разница между витриной и воронкой. Витрину можно набросать за вечер. Продукт, который индексируется, ранжируется и доводит человека до заявки, требует решений на уровне архитектуры, а не только вёрстки. Именно об этом кейс: как я через диалог с нейросетью прошёл путь от макета до полноценной воронки «органика → квалифицированный лид», и какая техническая деталь оказалась решающей для SEO.
Фаза 1: превратить дизайн в код
Первый этап — самый механический на вид и самый обманчивый по сложности. Задача звучит просто: взять хендофф из Figma и получить рабочие страницы на Next.js с App Router. На практике дизайн-макет — это набор статичных экранов, а сайт — это состояния: пустой каталог, каталог с одним фильтром, с пятью фильтрами, карточка лота без фото, карточка ЖК с 40 лотами внутри. Дизайнер рисует счастливый путь, а собирать нужно все ветки.
Я работал через Claude Code итеративно: описывал экран, получал компонент, тут же смотрел на реальных данных — не на трёх тестовых лотах, а на реалистичном объёме. Расхождения всплывали быстро: где в макете плашка с ценой влезает в одну строку, на реальных данных с ценой в цифрах с пробелами она уже переносится. Такие мелочи проще ловить сразу, чем на проде.
Результат первой фазы — рабочий каталог лотов и жилых комплексов. Уже полезно, уже можно смотреть объекты. Но с точки зрения SEO это была ещё не система, а набор страниц.
Инсайт
Вайбкодинг с готовым макетом экономит не время на вёрстке — его в любом случае тратишь на итерации. Экономится время на споры о том, как должен выглядеть компонент: дизайн уже дал ответ, нейросети остаётся его реализовать и подсветить пограничные состояния, которые в макете просто не нарисованы.
Фаза 2: почему дропдауны — это не главное
На втором этапе я унифицировал разрозненные каталоги лотов и ЖК в единую систему с общими дропдаун-фильтрами: район, бюджет, тип объекта, количество комнат. Сами по себе фильтры — база любого маркетплейса, тут никакого открытия. Открытие было в том, как эти фильтры отдавать поисковику.
Классический паттерн — фильтр меняет состояние на клиенте через JavaScript, URL не меняется или меняется через query-параметры, которые не индексируются как отдельные страницы. Для интернет-магазина это иногда приемлемо. Для SEO-маркетплейса недвижимости — нет, потому что именно в срезах живёт весь долгий хвост спроса: «ЖК в Хамовниках до 50 млн», «квартиры на Кутузовском с террасой», «пентхаусы в Пресненском районе». Каждый такой срез — это потенциальная страница входа из поиска, и если она существует только как состояние клиентского JS, для Google и Яндекса её попросту нет.
Решение — SSR-срезы. Каждая комбинация фильтров отдаёт серверно-рендеренный HTML на своём URL, а не собирается в браузере поверх одной и той же болванки. Я прогонял это через Next.js App Router: серверные компоненты формируют разметку под конкретную комбинацию параметров, страница приходит к краулеру уже готовой, с текстом, заголовками и ссылками — SSR-навигация по фасетам, а не JS-надстройка над одним каталогом.
| Подход к фильтрам | Что видит пользователь | Что видит краулер |
|---|---|---|
| Клиентский JS, query-параметры | Мгновенный отклик, без перезагрузки | Одна и та же базовая страница, срезы невидимы |
| SSR-срезы, отдельные URL | Та же скорость с кэшированием на сервере | Каждый срез — отдельная индексируемая страница |
Разница ощущается не сразу, а через недели, когда в поиске начинают всплывать не только общие страницы каталога, а узкие запросы, которые никто вручную не оптимизировал. Это и есть смысл программной генерации SEO-страниц: не писать текст под каждый срез руками, а построить архитектуру, где срез сам становится страницей.
Как я проверял, что срезы действительно работают на SEO
- Отключил JS в браузере и прошёл по типовым комбинациям фильтров — если контент и ссылки видны без выполнения скриптов, значит краулер тоже их увидит.
- Проверил уникальность заголовков и текста на разных срезах — если у «ЖК в районе X» и «ЖК в районе Y» совпадает всё, кроме названия района, это не SEO-страница, а дубль с подменённой переменной.
- Собрал внутреннюю перелинковку так, чтобы со страниц каталога и карточек лотов были прямые ссылки на соседние срезы — иначе даже отрендеренная страница может остаться сиротой без входящих ссылок.
- Прогнал через Schema.org ключевые типы страниц, чтобы расширенные сниппеты подхватывались не только на карточках, но и на срезах каталога.
Контент и доверие: отзывы как данные, а не как текст
Каталога и фильтров недостаточно, если человек не понимает, стоит ли доверять площадке. Для этого я сделал блок «Что говорят жители» — реальные отзывы по 50 жилым комплексам. Ключевое архитектурное решение здесь — не вписывать отзывы вручную в каждую страницу, а вынести их в отдельный модуль данных, который рендерится и на странице ЖК, и на странице конкретного лота внутри этого ЖК.
Это тот же принцип, что и с SSR-срезами: контент должен жить как данные, а не как разовый текст на странице. Один источник — множество точек отображения. Отзывы я обернул в Schema.org-разметку типа Review, что даёт шанс на расширенные сниппеты в выдаче — рейтинг и цитату видно уже на уровне поискового результата, до клика.
Параллельно я запустил блог внутри проекта — статьи живут прямо в коде, что для Next.js означает: новый материал — это новый пункт в структуре данных, а не отдельная CMS, которую нужно поддерживать сбоку.
50
жилых комплексов с реальными отзывами жителей
5
вопросов в Telegram-боте до готовой заявки
2
фазы разработки: от каталога до SSR-фасетов
Воронка: от органики до заявки без ручного труда
Каталог с SEO-трафиком без механизма захвата лида — это просто дорогая витрина. Последний элемент, который я добавил, — Telegram-бот квалификации. Пользователь, дошедший до карточки лота из поиска, попадает в бот, который задаёт пять вопросов: бюджет, район, тип сделки, сроки, формат просмотра. На выходе бот формирует готовую структурированную заявку — не «здравствуйте, интересует квартира», а заявку с заполненными полями, с которой сразу можно работать отделу продаж.
Код бота крутится на VPS под PM2 — простой и предсказуемый способ держать процесс живым без лишней инфраструктуры. Здесь показательно, что нейросеть одинаково уверенно помогает и с фронтендом на Next.js, и с бэкенд-логикой бота на сервере: разница не в сложности задач, а в том, насколько чётко ты формулируешь, что должно получиться на выходе.
Сайт перестаёт быть витриной ровно в тот момент, когда у каждой страницы появляется путь до заявки, а не только до просмотра.
Что я вынес для себя и что стоит взять читателю
Главный технический урок этого проекта — SSR-фасеты не опция, а решение, от которого зависит, увидит ли поисковик 90% ценности каталога. Если ваш продукт построен вокруг фильтров — недвижимость, товары, услуги с параметрами — задайте себе вопрос до старта разработки: отдаёт ли каждая комбинация фильтров свой индексируемый URL с серверным рендерингом, или это просто состояние на клиенте. Ответ на этот вопрос определяет, будет ли у вас десяток страниц или тысячи точек входа из поиска.
Второй урок — про архитектуру контента. Отзывы, факты, характеристики — всё, что повторяется на разных страницах в разных комбинациях, должно жить как данные в одном модуле, а не копироваться руками. Это не только экономит время, это единственный способ масштабировать SEO-контент без пропорционального роста ручного труда.
И третий — воронка не заканчивается на карточке товара. Если у вас есть трафик, но нет простого механизма превратить интерес в структурированную заявку, вы теряете именно тот трафик, который сложнее всего получить. Бот на пять вопросов — не самая сложная часть стека, но именно она замыкает цепочку, ради которой всё остальное строилось.