Кейс: генерация посадочных страниц из данных, а не из вёрстки
Посадочная страница у нас — это файл данных, а не копия вёрстки. Автор пишет содержание по единой схеме, шаблон сам собирает мета-теги, хлебные крошки, разметку Schema.org, карту сайта и файл для ИИ-краулеров, а гейты сборки роняют билд, если заголовок длиннее нормы, описание дублирует соседнюю страницу, внутренняя ссылка ведёт в никуда или пропал блок вопросов.
Задача: перестать копировать вёрстку ради новой страницы
Классическая схема выглядит так: берём похожую страницу, копируем разметку, меняем текст. Через двадцать страниц раздел превращается в двадцать слегка разных шаблонов. Описание случайно повторяется у трёх страниц, хлебные крошки на одной ведут в старый раздел, у другой пропала разметка, а исправление в шапке приходится вносить руками в каждый файл.
Отдельная беда — регресс. Ошибку в мета-тегах никто не замечает месяцами, потому что визуально страница выглядит нормально. Обнаруживается она в отчёте аудита, когда исправлять надо уже пачками.
Мы перевернули порядок: содержание хранится как данные, оформление и служебная разметка считаются из этих данных шаблоном, а правила проверяются на сборке. Тот же свод требований, что использует самообучающийся аудит, только применяется до публикации, а не после.
Что построили
Три части: схема, шаблон и гейты. Каждая решает свою проблему, но ценность появляется только вместе — схема без проверок деградирует за пару месяцев.
- Единая схема страницы. Заголовок, описание, лид, блоки, вопросы, связанные страницы — фиксированный набор полей с типами. Новый тип блока добавляется в шаблон, а не в отдельную страницу.
- Автоматическая служебная разметка. Мета-теги, канонический адрес, Open Graph, разметка Schema.org и блок вопросов собираются из тех же данных, что и видимый текст. Рассинхрон между ними невозможен по устройству.
- Хлебные крошки из одного источника. Раздел и родитель берутся из полей страницы, поэтому переименование раздела не оставляет висящих крошек в трёх местах.
- Карта сайта и файл для ИИ-краулеров. Оба генерируются на каждой сборке из списка страниц: приоритет, дата изменения, короткое описание. Ручного списка адресов не существует.
- Гейты качества. Длины полей, уникальность заголовка и описания по всему сайту, наличие блока вопросов, целостность внутренних ссылок. Нарушение останавливает сборку и называет файл и поле.
- Проверка ссылок по карте сайта. Ссылка на несуществующий адрес не публикуется: сборка сверяет каждую внутреннюю ссылку со списком реальных страниц.
Гейты сборки: что проверяется до публикации
Проверяется форма, а не смысл. Это важное разделение: машина закрывает то, что формализуется, редактор занимается тем, что нет.
| Что проверяется | Норма | Реакция сборки |
|---|---|---|
| Длина заголовка страницы | не больше 60 знаков с пробелами | Стоп |
| Длина описания | 100–160 знаков | Стоп |
| Уникальность заголовка и описания | не повторяются нигде по сайту | Стоп |
| Заголовок H1 | 28–72 знака, содержит основу запроса | Стоп |
| Объём лида | 34–78 слов, ответ в первых словах | Стоп |
| Внутренние ссылки | адрес есть в карте сайта | Стоп |
| Блок вопросов | 4–7 вопросов на странице раздела | Стоп |
| Связанные страницы | ровно три существующих адреса | Предупреждение |
Что изменилось в работе над страницами
Новая посадочная страница перестала быть проектом. Автор заполняет файл данных, запускает сборку и получает страницу со всей служебной обвязкой. Времени уходит ровно столько, сколько нужно, чтобы разобраться в теме и собрать факты — техническая часть больше не съедает половину задачи.
Изменение шаблона теперь применяется ко всему разделу сразу. Поправили порядок блоков или разметку — пересобрали сайт, все страницы обновились одинаково. Раньше это была ручная работа по каждому файлу с гарантированным пропуском пары штук.
Третий эффект менее очевидный: срабатывание гейта перестало быть личной ошибкой автора. Если одно и то же правило спотыкается регулярно, разбирают не автора, а схему — обычно там либо плохая формулировка требования, либо не хватает блока, который каждый раз собирают руками. Дальше данные страниц уезжают в общую витрину, где считается их эффект — про неё отдельный кейс.
Ограничения генератора
Подход закрывает форму и регресс. Всё остальное остаётся людям, и делать вид, что это не так, вредно для результата.
- Генератор не пишет смысл за автора. Он проверит длину и уникальность описания, но не заметит, что текст ни о чём.
- Гейт ловит только формализуемое. Две страницы под близкие запросы могут дублировать друг друга по смыслу и пройти все проверки — это разбирается вручную.
- Схема ограничивает свободу макета. Нестандартная страница требует нового типа блока в шаблоне, а не правки одной вёрстки.
- Часть правил проверить на сборке нельзя. Скорость на реальном железе, индексация и поведение краулеров видны только на живом сайте, поэтому регулярный аудит никуда не девается.
- Миграция существующего сайта — отдельная работа. Перенос страниц в схему занимает время и не происходит побочным эффектом от внедрения генератора.
Частые вопросы про генератор посадочных страниц
Чем это отличается от обычной CMS?
В CMS страница — запись в базе, а её внешний вид и служебная разметка настраиваются в интерфейсе, поэтому расходятся от страницы к странице. Здесь страница — файл данных в репозитории, а мета-теги, крошки, разметка Schema.org и карта сайта считаются шаблоном из этих же данных, всегда одинаково. Второе отличие — проверки. В CMS редактор может опубликовать страницу с дублем описания, и никто этого не заметит месяцами. Здесь сборка останавливается и называет файл, поле и цифру, которая не сошлась.
Кто пишет содержание — человек или модель?
Черновик может собрать модель, но она работает по той же схеме и упирается в те же гейты, что и человек. Это важная деталь: генерация без проверок даёт правдоподобные страницы с одинаковыми описаниями, размытыми заголовками и вымышленными цифрами. Гейт ловит формальную часть — длину, дубли, ссылки, отсутствие блоков. Фактическую часть проверяет редактор: цифры, сроки, названия систем, ограничения. Правило простое: ни одна цифра не попадает на страницу без источника, и ни одна страница не публикуется без человека в конце цепочки.
Что происходит, если гейт срабатывает прямо перед публикацией?
Сборка не выпускает страницу и печатает, что именно не сошлось: файл, поле, текущее значение и допустимое. Автор правит одно поле и запускает сборку снова — это занимает меньше времени, чем обсуждение того, надо ли править. Важнее другое: срабатывание не остаётся личной проблемой автора. Если одно и то же правило спотыкается регулярно, разбирают не автора, а схему — вероятно, формулировка требования плохая или в шаблоне не хватает блока, который приходится каждый раз собирать руками.
Сколько времени занимает новая посадочная страница?
Техническая часть перестала быть узким местом: собрать страницу из готового файла данных — это одна команда сборки. Всё время уходит на содержание: разобраться в процессе, собрать факты, найти цифры и ограничения, которые не стыдно поставить на сайт. Поэтому честный ответ — столько, сколько занимает написать осмысленный текст, плюс минуты на сборку и проверку. До генератора к этому добавлялась вёрстка, ручная простановка мета-тегов, крошек и разметки, и правка их же после каждого изменения структуры раздела.
Подходит ли такой подход интернет-магазину или большому порталу?
Частично. Генератор рассчитан на страницы, у которых содержание пишет человек: услуги, отрасли, кейсы, статьи, посадочные под запросы. Каталог товаров устроен иначе — там карточки приходят из учётной системы, и правила проверяются не на сборке сайта, а на выгрузке номенклатуры. Общая часть переносится: единая схема, автоматическая служебная разметка, проверка правил до публикации. Различается источник данных. Для магазина мы обычно оставляем каталог на своей платформе, а генератором закрываем разделы, где текст пишется руками и живёт годами.
Что даёт связка генератора с аудитом?
Аудит и генератор работают с одним и тем же сводом правил, только в разные моменты. Аудит смотрит на сайт снаружи и находит нарушения там, где они уже случились. Генератор проверяет те же требования до публикации, поэтому большая часть находок аудита просто перестаёт появляться. Остаются те правила, которые нельзя проверить на сборке: скорость на реальном железе, поведение краулеров, индексация, разметка после рендера. Из-за этого регулярный прогон аудита никуда не девается — но список нарушений в нём становится заметно короче и содержательнее.
Бесплатный аудит: посчитаем эффект внедрения ИИ на ваших цифрах
30–40 минут разбора: смотрим ваши процессы, отмечаем, что можно передать ИИ, считаем ROI-модель на ваших объёмах и сроках. Вы уходите с расчётом и картой внедрения — даже если работать дальше не будете.