От статического зоопарка доменов до одного ядра на Next: лендинг ковровой студии и перенос в свой boilerplate

Несколько лет назад пришла задача сверстать лендинг для студии тафтинга (ковровая вышивка пистолетом) в Казани — MatyrKover. Формулировка обычная: дизайн в сеть, быстрый результат. Но «просто сверстать» было скучно, и я усложнил задачу: поднять много доменов под разные ключи, отдать всё статикой и автоматизировать деплой. Статика, GitHub Actions, Docker, nginx, сертификаты — в итоге за пару вечеров получился рабочий конвейер. Кстати, частично работающее решение находится так же в OpenSource.

Со временем накопились накладные расходы: сертификаты, продление доменов, отсутствие нормальной аналитики по заявкам и единой точки входа. Плюс внешняя реальность: когда Telegram перестаёт быть надёжным каналом для уведомлений админу, классическая схема «форма → бот» ломается без вашей вины. Да, я использую именно ТГ для доставки заявок, это было самое простое решение на тот момент, оно пока так же сохранено в новой реализации.

Я решил не чинить N отдельных статических сайтов, а перенести лендинг на свой production-ready boilerplate на Next.js — с полноценным бэкендом, админкой и заделом под контент и ЛК. Ниже — как устроен перенос, как я сохранил трафик с сателлитов без дублирования бэкенда на каждом домене, и что уже даёт платформа «из коробки».

Когда пришла новая задача - генерация сертификатов и онлайн оплата, я столкнулся с тем, что чтобы для статики сделать такую реализацию понадобиться интеграция платежного шлюза и какой нибудь новый бэк, в который будут отлетать запросы со всех источников. Мне показалось это довольно трудозатратным и сложным в будущей поддержке. А тут, карты сошлись, я не так давно реализовал свой единый бойлерплейт на Next.js, о котором уже писал ранее на VC. В общем, далее:

Изначально Next.js я не брал: задачи динамического рендера и API не было — нужен был быстрый лендинг и выдача HTML с nginx. Взял Vite, свой пайплайн и обеспечил:

Цель была простая: занять ключевые домены в нише и своем ГЕО (Казань) и висеть в выдаче без постоянных ручных действий. В целом цель отработала: отдельная глубокая SEO-кастомизация под каждый домен и ключ не делалась — хотелось минимум сопровождения при максимуме охвата.

Минус: сертификаты и домены требуют внимания раз в год; список доменов со временем сократил — оставил то, что реально окупает поддержку.

На статике упираешься в три вещи:

Свой boilerplate на Next уже включает то, что для бизнес-сайта критично: авторизация, роли, статьи, дашборды, задел под расширение. Лендинг студии — хороший «первый клиент» для этой базы.

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

Алгоритм был простым:

Суммарно локально от «папки с версткой» до крутящегося лендинга с полноценной подложкой ушло порядка получаса–часа — потому что каркас приложения, роутинг и инфраструктура уже были готовы; работа была в миграции фронта и ассетов, а не в изобретении проекта с нуля. Так же допом заняла доп кастомизаций встроенной SEO поддержки и улучшения общих показателей GEO и SEO. По анализу сайта активно пользовался CLAUDE скиллом - must have, по ощущениям, для улучшений производительности и показателей выдачи. После доработок под GEO сайт студии стал активно рекомендоваться в ChatGPT, Claude и Grok. Gemini заработал с пол пинка, он активно использует устаревшую информацию в сети, а DeepSeek с оф. сайта вовсе работает на старом слепке данных сети, хотя и пользуется выходом в интернет. У самого сайта студии низкий рейтинг ссылочной массы, возможно это так же активно влияет на показатели. В PageSpeed анализе для мобилок сайт все еще находится в желтой зоне по производительности, там нужно копаться по неиспользуемому js коду скриптов метрик и yclients, а так же по жирному чанку css. Это, в основном, изначальные проблемы первичной реализации сайта компании.

Чтобы не отказываться от действующих ключевых доменов и не тащить в них лишнюю логику backend'а, выбрал следующую схему обработки:

Эта схема помогает мне:

О Telegram и внешних ограничениях

В моем кейсе заявки уходили только в Telegram, а доступ к мессенджеру у части аудитории нестабилен, форма на сайте перестаёт быть «достаточной» без резервного канала (почта, CRM, собственные уведомления на бэкенде). Перенос на полноценный Next с API — как раз про то, чтобы не зависеть от одного канала доставки.

Помимо всего прочего, в текущем БП есть реализация поддержки ИИ функций через api Openai, если Вы собираетесь использовать эти функции, то в БП уже заложена интеграция проксей, для обхода блокировок запросов в ИИ сервисы/шлюзы, при желании, можно отказаться от OpenAI и ходить, например, через ИИ провайдеров на подобии OpenRouter.

Мультидоменная статика отлично подходит для быстрого захвата выдачи, но плохо масштабируется как продукт для бизнеса. Перенос готового лендинга в свой Next boilerplate оказался дешёвым по времени именно потому, что инфраструктура и админка уже были; самое интересное инженерно — схема с ядром и редиректом заявки, чтобы не плодить бэкенды по доменам.

Если тема зайдёт — во второй части можно развернуть обзор возможностей boilerplate отдельно (архитектура, модули, как подключаются новые сущности). В этой статье я хотел связать историю доменов, миграцию UI и практический трюк с трафиком в одну связную картину.

БП писал для своих нужд. MVP, мини продукты, сайт матур ковра вот, тоже был одной из причин. Я технарь, мне не интересны визуальные low/no-code решения. А еще у меня всегда основной затык - трафик, хотелось сделать готовый минимум, чтобы стартануть с реализацией только бизнес логики продукта, не пытаясь победить деплой/безопасность или SEO, теперь еще и GEO... Буду рад критике или любым другим комментариям. Спасибо, что дочитали.