# Кейс: генерация посадочных страниц из данных, а не из вёрстки

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

- Источник: https://lokai.ru/keysy/generator-posadochnyh-stranic/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Кейсы → Генератор страниц

---

Посадочная страница у нас — это файл данных, а не копия вёрстки. Автор пишет содержание по единой схеме, шаблон сам собирает мета-теги, хлебные крошки, разметку Schema.org, карту сайта и файл для ИИ-краулеров, а гейты сборки роняют билд, если заголовок длиннее нормы, описание дублирует соседнюю страницу, внутренняя ссылка ведёт в никуда или пропал блок вопросов.

- **1** — файл данных на страницу — вёрстка не копируется
- **60** — знаков предельная длина заголовка, проверяется на сборке
- **4–7** — вопросов обязательны на каждой странице раздела
- **0** — битых внутренних ссылок допускается в релизе

## Задача: перестать копировать вёрстку ради новой страницы

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

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

Мы перевернули порядок: содержание хранится как данные, оформление и служебная разметка считаются из этих данных шаблоном, а правила проверяются на сборке. Тот же свод требований, что использует [самообучающийся аудит](https://lokai.ru/keysy/samoobuchayushchiysya-seo-geo-audit/), только применяется до публикации, а не после.

## Что построили

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

1. **Единая схема страницы.** Заголовок, описание, лид, блоки, вопросы, связанные страницы — фиксированный набор полей с типами. Новый тип блока добавляется в шаблон, а не в отдельную страницу.
2. **Автоматическая служебная разметка.** Мета-теги, канонический адрес, Open Graph, разметка Schema.org и блок вопросов собираются из тех же данных, что и видимый текст. Рассинхрон между ними невозможен по устройству.
3. **Хлебные крошки из одного источника.** Раздел и родитель берутся из полей страницы, поэтому переименование раздела не оставляет висящих крошек в трёх местах.
4. **Карта сайта и файл для ИИ-краулеров.** Оба генерируются на каждой сборке из списка страниц: приоритет, дата изменения, короткое описание. Ручного списка адресов не существует.
5. **Гейты качества.** Длины полей, уникальность заголовка и описания по всему сайту, наличие блока вопросов, целостность внутренних ссылок. Нарушение останавливает сборку и называет файл и поле.
6. **Проверка ссылок по карте сайта.** Ссылка на несуществующий адрес не публикуется: сборка сверяет каждую внутреннюю ссылку со списком реальных страниц.

## Гейты сборки: что проверяется до публикации

Проверяется форма, а не смысл. Это важное разделение: машина закрывает то, что формализуется, редактор занимается тем, что нет.

*Правила, которые проверяются на каждой сборке сайта*

| Что проверяется | Норма | Реакция сборки |
|---|---|---|
| Длина заголовка страницы | не больше 60 знаков с пробелами | Стоп |
| Длина описания | 100–160 знаков | Стоп |
| Уникальность заголовка и описания | не повторяются нигде по сайту | Стоп |
| Заголовок H1 | 28–72 знака, содержит основу запроса | Стоп |
| Объём лида | 34–78 слов, ответ в первых словах | Стоп |
| Внутренние ссылки | адрес есть в карте сайта | Стоп |
| Блок вопросов | 4–7 вопросов на странице раздела | Стоп |
| Связанные страницы | ровно три существующих адреса | Предупреждение |

## Что изменилось в работе над страницами

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

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

Третий эффект менее очевидный: срабатывание гейта перестало быть личной ошибкой автора. Если одно и то же правило спотыкается регулярно, разбирают не автора, а схему — обычно там либо плохая формулировка требования, либо не хватает блока, который каждый раз собирают руками. Дальше данные страниц уезжают в общую витрину, где считается их эффект — про неё [отдельный кейс](https://lokai.ru/keysy/dashbordy-po-reklamnym-kabinetam/).

## Ограничения генератора

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

- **Генератор не пишет смысл за автора.** Он проверит длину и уникальность описания, но не заметит, что текст ни о чём.
- **Гейт ловит только формализуемое.** Две страницы под близкие запросы могут дублировать друг друга по смыслу и пройти все проверки — это разбирается вручную.
- **Схема ограничивает свободу макета.** Нестандартная страница требует нового типа блока в шаблоне, а не правки одной вёрстки.
- **Часть правил проверить на сборке нельзя.** Скорость на реальном железе, индексация и поведение краулеров видны только на живом сайте, поэтому регулярный аудит никуда не девается.
- **Миграция существующего сайта — отдельная работа.** Перенос страниц в схему занимает время и не происходит побочным эффектом от внедрения генератора.

## Частые вопросы про генератор посадочных страниц

**Чем это отличается от обычной CMS?**

В CMS страница — запись в базе, а её внешний вид и служебная разметка настраиваются в интерфейсе, поэтому расходятся от страницы к странице. Здесь страница — файл данных в репозитории, а мета-теги, крошки, разметка Schema.org и карта сайта считаются шаблоном из этих же данных, всегда одинаково. Второе отличие — проверки. В CMS редактор может опубликовать страницу с дублем описания, и никто этого не заметит месяцами. Здесь сборка останавливается и называет файл, поле и цифру, которая не сошлась.

**Кто пишет содержание — человек или модель?**

Черновик может собрать модель, но она работает по той же схеме и упирается в те же гейты, что и человек. Это важная деталь: генерация без проверок даёт правдоподобные страницы с одинаковыми описаниями, размытыми заголовками и вымышленными цифрами. Гейт ловит формальную часть — длину, дубли, ссылки, отсутствие блоков. Фактическую часть проверяет редактор: цифры, сроки, названия систем, ограничения. Правило простое: ни одна цифра не попадает на страницу без источника, и ни одна страница не публикуется без человека в конце цепочки.

**Что происходит, если гейт срабатывает прямо перед публикацией?**

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

**Сколько времени занимает новая посадочная страница?**

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

**Подходит ли такой подход интернет-магазину или большому порталу?**

Частично. Генератор рассчитан на страницы, у которых содержание пишет человек: услуги, отрасли, кейсы, статьи, посадочные под запросы. Каталог товаров устроен иначе — там карточки приходят из учётной системы, и правила проверяются не на сборке сайта, а на выгрузке номенклатуры. Общая часть переносится: единая схема, автоматическая служебная разметка, проверка правил до публикации. Различается источник данных. Для магазина мы обычно оставляем каталог на своей платформе, а генератором закрываем разделы, где текст пишется руками и живёт годами.

**Что даёт связка генератора с аудитом?**

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

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК