Лендинг, который две недели ждёт очереди у программиста, две недели продаёт ровно на ноль рублей, а реклама всё это время ведёт людей на старую страницу со старой ценой. ИИ-разработчик сайта — это роль ИИ-команды компании, которая собирает новые страницы из утверждённых блоков и брендбука, наполняет их фактами из базы знаний, правит текущие страницы, готовит A/B-варианты и выпускает изменения на сайт только после одобрения человека. Это не нейросеть, которая «рисует сайт», и не замена программисту. Я работаю в продажах и смотрю на сайт как на менеджера, который принимает клиентов круглосуточно и никогда не перезванивает. Поэтому разберу вопрос с этой стороны: какую работу с сайтом разумно отдать ИИ, какую нельзя, как проверить пользу на одной посадочной и когда вся затея не окупится.
Очередь к программисту измеряется в рублях, а не в раздражении
Типовая сцена. Вторник, маркетолог запускает рекламу под новый тариф. Посадочной страницы под тариф нет: программист занят интеграцией с CRM, и она правда важнее. Кампанию либо переносят, либо ведут на общую страницу, где про новый тариф написано одной строкой внизу. Никто не виноват, все заняты, а заявки тем временем идут туда, где их не ждут.
Цену такой очереди можно посчитать, и считать стоит до любых разговоров об ИИ. Условный пример, не данные конкретной компании: кампания даёт 10 заявок в день, в оплату доходит каждая десятая, средний чек — 30 000 рублей. Десять дней ожидания посадочной — это 100 заявок, 10 оплат и 300 000 рублей выручки, которые либо сдвинулись на потом, либо ушли к конкуренту. Не вся эта сумма потеряна: часть клиентов купит позже. Но даже половина — это уже аргумент.
Вторая статья расходов менее заметна. Большая часть задач по сайту — не новые лендинги, а мелочи: поменять цену на трёх страницах, перенести дату вебинара, убрать закончившуюся акцию, добавить отзыв. Для программиста каждая такая задача — десять минут работы и полчаса на то, чтобы вернуться к интеграции, от которой его оторвали. Мелочи копятся, и в какой-то момент на сайте висит акция, закончившаяся месяц назад.
Узкое место здесь не в том, что программист медленный. Оно в том, что время программиста уходит на работу, для которой программист не нужен.
ИИ-разработчик сайта собирает страницу из деталей, которые уже утвердили
ИИ-разработчик сайта — это роль ИИ-команды компании, которая работает с содержимым сайта внутри заранее заданных рамок: библиотеки блоков, брендбука, базы знаний и правил одобрения. Роль не придумывает, как сайт должен выглядеть, и не решает, что на нём публиковать. Она берёт запрос, собирает из готовых деталей черновик и приносит его человеку на решение.
Что такая роль делает:
- Новые лендинги и страницы — по утверждённым шаблонам и библиотеке блоков, в цветах, шрифтах и тоне брендбука.
- Наполнение из базы знаний — цены, сроки, состав продукта, условия, отзывы с разрешением на публикацию.
- Правки текущих страниц — тексты, блоки, устаревшие цены и даты, с построчным сравнением «было — стало».
- A/B-варианты — заголовков, призывов к действию и порядка блоков, с записанной гипотезой.
- Версии и откат — у каждого изменения есть дата, автор запроса, продукт и сегмент, а неудачную версию можно вернуть.
- Техническая SEO- и GEO-разметка — заголовки, описания, микроразметка и прочий обязательный минимум каждой страницы.
Чего роль не делает: не рисует новый дизайн, не меняет архитектуру сайта, не трогает платежи, формы и интеграции, не публикует ничего сама. Об этом подробно ниже, потому что именно на границах решается, будет ли от роли польза или новая головная боль.
Если нужна аналогия, то это заготовочный цех ресторана. Шеф утверждает технологические карты, заготовщик готовит по ним сотню одинаковых порций. Шеф свободен для нового меню, а гости получают то же блюдо, что и вчера. Если заготовщик начнёт импровизировать с солью, гости заметят это раньше шефа.
«Дизайн от нейросети» выглядит свежо ровно до третьей страницы
Соблазн понятен: нейросеть за минуту выдаёт макет страницы, и он даже симпатичный. Проблемы начинаются, когда таких страниц становится больше одной.
Бренд расползается. Каждая сгенерированная с нуля страница немного отличается: оттенок кнопки, скругление карточек, размер заголовков, манера фотографий. По отдельности это мелочи. Вместе клиент видит три разные компании на одном домене и начинает сомневаться, туда ли он попал.
Вёрстка ломается там, где её никто не смотрел. Блок из библиотеки уже проверен на телефоне, на узком экране, с длинным названием тарифа и с формой, в которую ввели ошибку. Свежий макет проверен только на той картинке, которую вы увидели. Первым ломается мобильная версия, а на ней у многих сайтов большая часть посетителей.
Аналитика отваливается молча. Цели в системе аналитики привязаны к кнопкам и формам. Новая вёрстка — новые элементы, и цель «отправил заявку» перестаёт срабатывать. Страница продаёт, а в отчёте ноль, и через месяц кто-то предлагает её выключить как неэффективную.
Каждое согласование идёт как в первый раз. Утверждённый блок не обсуждают: его уже обсудили. Свободный дизайн каждый раз открывает спор о цвете кнопки, в котором участвуют все, у кого есть глаза и мнение. Время, которое ИИ сэкономил на макете, уходит на совещание.
Теперь мнение, а не факт, и это взгляд из продаж: клиент покупает не оригинальную сетку страницы, а понятное обещание, доказательства и ответ на своё главное сомнение. Конверсию лендинга делают оффер, порядок аргументов и цифры, которым верят. Дизайн должен не мешать, и лучше всего не мешает тот, который клиент уже видел на остальных страницах компании.
Это не запрет на новый дизайн. Когда нужен новый блок, его рисует дизайнер, утверждает владелец бренда, программист добавляет в библиотеку, и с этого момента ИИ-разработчик может им пользоваться. Изменения дизайна — только по согласованию, а не по вдохновению модели.
Библиотека блоков — это договор между маркетингом, дизайном и юристом
Библиотека блоков — это набор утверждённых частей страницы, из которых собирается любой лендинг: первый экран, описание проблемы, решение, программа или состав, тарифы, отзывы, вопросы и ответы, гарантии, призыв к действию. Звучит как папка с макетами, но работает, только если в каждом блоке записано больше, чем картинка.
Что должно быть у блока, чтобы по нему можно было собирать страницы без программиста:
- Вёрстка для компьютера и телефона, проверенная на длинных и коротких текстах.
- Два-три варианта — например, тарифы карточками и тарифы таблицей, чтобы было из чего собирать A/B-версии без нового дизайна.
- Обязательные данные. Блок тарифов не собирается без цены, срока и условий возврата. Блок отзывов — без отметки, что разрешение на публикацию есть.
- Ограничения — длина заголовка, число пунктов, размер изображения. Именно они держат вёрстку целой, когда текст пишет не дизайнер.
- Кто утверждает содержимое. Гарантии и условия оферты — юрист, программу курса или технические характеристики — эксперт, тон и заголовки — маркетинг.
Брендбук добавляет к этому общие правила: цвета, шрифты, отступы, тон, запрещённые формулировки, требования к фотографиям. Для ИИ-разработчика брендбук — не вдохновляющий PDF, а список проверок, которые черновик проходит до того, как попасть к человеку.
Где взять библиотеку, если её нет. Не заказывать с нуля, а разобрать свои лучшие существующие страницы: те, что дают заявки. Повторяющиеся части вырезаются в блоки, у каждого появляются правила выше. Обычно выясняется, что у компании уже есть почти всё нужное, просто в разных версиях на разных страницах.
Порядок блоков повторяет разговор хорошего продавца
Типовая структура продающей страницы — заголовок, проблема, решение, экспертность, программа, тарифы, отзывы, FAQ, гарантии и призыв к действию — появилась не из учебника дизайна. Это порядок, в котором у покупателя возникают сомнения. «Это про меня?» — проблема. «Что вы предлагаете?» — решение. «А вы вообще кто?» — экспертность. «Что именно я получу?» — программа. «Сколько?» — тарифы. «А другим помогло?» — отзывы. «А если не подойдёт?» — гарантии.
Хороший продавец отвечает на эти вопросы по очереди и не называет цену раньше, чем клиент понял ценность. Страница делает то же самое, только молча. Поэтому структура лендинга — это не вкус, а сценарий разговора, записанный блоками.
Сценарий зависит от того, кто покупает. Три условных примера:
- Онлайн-школа. Главное сомнение — «научат ли меня». Программа и эксперт стоят выше, чем тарифы, а отзывы нужны с результатом ученика, а не с благодарностью за атмосферу.
- Производитель оборудования. Покупатель — инженер или снабженец. Ему нужны характеристики, документы, сроки поставки и форма запроса цены; блок «проблема» в эмоциональном стиле здесь скорее раздражает.
- Сервисная компания. Первый вопрос — «приедете ли вы ко мне и когда». Зона выезда, срок и цена работ идут на первый экран, гарантия — сразу за ними.
ИИ-разработчик берёт шаблон структуры под тип продукта и сегмент и заполняет его. Если для другого сегмента порядок должен отличаться, он предлагает вариант, а не переставляет блоки по своему усмотрению. Хороший источник для такого предложения — записи звонков и переписки: если клиенты в первые минуты разговора спрашивают про сроки, срок должен подняться на странице выше. Как искать на сайте вопросы, на которые он молчит, разобрано в статье о контентных разрывах.
Факты на странице берутся из базы знаний, а пустое поле остаётся пустым
Самая дорогая ошибка сгенерированной страницы — не кривой отступ, а неверная цифра. Цена, которой нет. Бонус, который закончился. Гарантия, которую юрист никогда бы не согласовал. Клиент приходит с этим обещанием к менеджеру, и разговор начинается не с продажи, а с объяснений, почему сайт врёт.
Поэтому ИИ-разработчик не пишет факты из головы. Цены, тарифы, сроки, состав продукта, бонусы, отзывы и кейсы с разрешением на публикацию, юридические ограничения по обещаниям — всё это он берёт из базы знаний компании, где у каждого раздела есть владелец и версия. Если нужного факта в базе нет, в черновике остаётся пометка «нет данных», а не правдоподобная выдумка. Пустое поле раздражает, зато его видно до публикации.
У этого подхода есть приятное следствие. Когда в базе знаний меняется цена, ИИ-разработчик может найти все страницы, где стоит старая, и подготовить правку сразу для всех. Раньше это была задача «пройтись по сайту», которую все откладывали.
Как устроить саму базу — разделы, источники, владельцев и версии, — разобрано в обзорной статье о базе знаний компании для ИИ, а как агент находит в ней ответ — в статье о базе знаний для AI-агента. Проверка текстов на тон бренда — часть работы контент-фабрики, здесь её повторять не буду.
Правки текущих страниц скучнее лендингов и приносят больше денег
О лендингах говорят чаще, но основная работа с сайтом — поддерживать в порядке то, что уже есть. Цена выросла. Вебинар перенесли. Акция закончилась. Появился новый отзыв. Изменились условия рассрочки. Каждая такая правка мелкая, а несделанная — дорогая.
Сцена из жизни отдела продаж, знакомая многим: менеджер называет цену, клиент присылает скриншот с сайта, где цена ниже. Дальше у менеджера два плохих варианта — уступить или спорить с собственным сайтом. Сделка, которая шла легко, превращается в торг, и повод для него компания дала сама.
С ИИ-разработчиком правка выглядит так. Руководитель или маркетолог пишет обычными словами: «уберите весеннюю акцию со всех страниц». Роль находит все места, где акция упоминается, готовит изменения по каждой странице и показывает построчное сравнение: вот что было, вот что станет. Человек смотрит, одобряет, правка уходит на сайт. Программист об этом узнаёт из журнала изменений, если вообще захочет узнать.
Отдельная полезная привычка — регулярная сверка сайта с базой знаний. Роль проходит по страницам и выписывает расхождения: здесь старая цена, здесь срок, которого больше нет, здесь отзыв без отметки о разрешении. Такой список не требует решения прямо сейчас, но показывает, где сайт начал отставать от компании.
A/B-вариант меняет одну вещь, иначе вы узнаете только, что что-то сработало
A/B-вариант страницы — это её вторая версия, которая отличается от основной одним элементом и показывается части посетителей, чтобы сравнить результат. На лендинге чаще всего сравнивают заголовок, текст и место кнопки призыва к действию, порядок блоков и формулировку оффера.
ИИ-разработчику подготовить варианты легко, и в этом ловушка. Он может за минуту сделать двенадцать заголовков, но двенадцать заголовков одновременно на небольшом трафике не дадут ответа ни на один вопрос. Поэтому вариант готовится не «на всякий случай», а под записанную гипотезу:
- что меняем — один элемент, например заголовок;
- почему — например, в звонках клиенты первым делом спрашивают про срок, значит, срок стоит вынести в заголовок;
- какую метрику ждём — долю посетителей, оставивших заявку, а лучше долю дошедших до оплаты;
- когда останавливаем — сколько посетителей нужно и что считаем результатом, решается до запуска.
Про трафик стоит сказать честно. Расчёт по стандартной формуле сравнения двух долей: если страница конвертирует 3% посетителей в заявку и вы хотите надёжно заметить рост до 4% (уровень значимости 5%, мощность теста 80%), нужно около 5 300 посетителей на каждый вариант. Если страницу посещают сто человек в день, тест растянется больше чем на три месяца, и сезон изменит картину сильнее заголовка. Почему подглядывание в промежуточные результаты даёт ложных победителей и как не обмануть себя маленькой выборкой, подробно разобрано в статье про A/B-тест агента и человека.
Ещё одна деталь, о которой вспоминают поздно, — поисковики. Google в справке о тестировании сайтов просит не показывать поисковому роботу отдельную версию страницы, для вариантов на разных адресах ставить rel="canonical" на основную страницу, использовать временный редирект 302, а не постоянный 301, и не держать тест дольше необходимого. Показ роботу не того, что видит человек, — клоакинг, и его запрещают правила и Google, и Яндекса. Настроить разделение трафика один раз — задача программиста; готовить варианты и вести их версии — задача ИИ-разработчика.
Версия страницы отвечает на вопрос «кто это поменял и зачем»
Версия страницы — это сохранённое состояние страницы вместе с тем, кто, когда и зачем её изменил. У ИИ-разработчика каждая правка записывается версией с понятными полями: дата, автор запроса, продукт, сегмент аудитории, гипотеза, если это вариант теста, и кто одобрил публикацию.
Зачем это продажам. В четверг заявок с посадочной стало вдвое меньше. Без версий начинается расследование в общем чате: «кто-нибудь трогал сайт?» — «вроде нет» — «а форму?». С версиями ответ находится за минуту: в среду поменяли текст кнопки под новый сегмент, и форма теперь открывается не сразу. Дальше решение простое — откатить версию и разобраться спокойно.
Откат — это возврат предыдущей версии одним действием, без программиста и без восстановления из резервной копии. В Везории роль веб-разработчика правит тексты и вёрстку в отдельной ветке сайта, показывает построчное сравнение, публикует после одобрения, а правку можно откатить; выполненное обратимое действие можно отменить в течение 3 часов.
Честное ограничение: откат возвращает страницу, но не возвращает то, что успело произойти. Заявки, оставленные на неудачной версии, остаются в CRM, письма, отправленные по ним, уже ушли, а посетители, которые закрыли страницу, не вернутся. Поэтому откат — страховка от долгой ошибки, а не разрешение публиковать не глядя.
Одобрение занимает минуту человека, и эта минута дешевле ошибки
Всё, что меняет сайт, приходит к человеку карточкой: какая страница, что меняется, построчное сравнение, зачем это нужно и чем рискуем. Человек одобряет, отклоняет или возвращает на доработку с комментарием. Без этого шага изменение на сайт не попадает.
Чтобы одобрение не превратилось в бутылочное горлышко, заранее решают, кто что утверждает:
- Тексты, заголовки, порядок блоков — маркетолог или руководитель направления.
- Цены, гарантии, условия оферты, обещания результата — тот, кто за них отвечает, а спорные формулировки — юрист.
- Любое изменение дизайна за пределами библиотеки — владелец бренда или дизайнер.
Главная опасность здесь не в том, что одобрять долго, а в том, что одобрять начинают не глядя. Если в день приходит сорок карточек, к обеду человек нажимает «одобрить» на автомате. Помогает простое правило: опечатки и перенос даты идут одной пачкой, а изменение цены или гарантии — отдельной карточкой, которую нельзя одобрить вместе с остальными. Почему действия ИИ во внешних системах вообще идут через человека и где эта схема начинает тормозить, разобрано в статье про human-in-the-loop.
Техническая SEO- и GEO-разметка входит в сборку страницы, а стратегия — нет
У каждой страницы есть обязательный технический минимум, который забывают чаще всего, потому что его не видно глазами. ИИ-разработчик собирает его вместе со страницей по правилам сайта:
- уникальный title и description нужной длины, один H1 с основным запросом, canonical;
- alt у изображений, хлебные крошки, адрес страницы в карте сайта;
- микроразметка JSON-LD — хлебные крошки, вопросы и ответы, описание услуги или продукта;
- для генеративных движков — определения «X — это …», цены и условия текстом, а не картинкой, самодостаточные абзацы.
Чего роль не решает: какие страницы сайту нужны, под какие запросы, не будут ли две страницы спорить за один запрос и когда шаблонные страницы превращаются в дорвеи. Это стратегия, и у неё свои правила и свои статьи: что такое генеративное SEO, каннибализация запросов, программатик SEO без дорвеев. Если нужна стратегия целиком, это отдельная услуга — генеративное SEO.
Программисту остаётся всё, где ошибка ломает не страницу, а бизнес
ИИ-разработчик не заменяет программиста, и подрядчик, который обещает обратное, скорее всего, не видел сайт, принимающий оплату. У программиста остаются три области, и все три важнее любого лендинга.
Архитектура. На чём работает сайт, как устроены шаблоны и сама библиотека блоков в коде, как изменения попадают на рабочий сервер, где отдельная ветка для черновиков. Именно программист строит ту песочницу, в которой ИИ-разработчик работает, и чем точнее её границы, тем спокойнее всем.
Интеграции. Формы, которые отправляют заявки в CRM, оплата, цели аналитики, рассылки, каталог из учётной системы, калькуляторы. Ошибка в тексте видна сразу, ошибка в интеграции — через неделю, когда выяснится, что заявки с формы никуда не приходили. Подключение ИИ-разработчика к сайту, под вашу CMS или конструктор, тоже настраивается на внедрении вместе с программистом.
Безопасность. Какие права есть у роли: содержимое страниц и ветка черновиков — да, сервер, пароли, настройки и платёжные ключи — нет. Резервные копии, обновления, защита форм от спама, согласие на обработку персональных данных в каждой форме. Это то, что в хорошем проекте никто не замечает, пока оно работает.
Плюс производительность: скорость загрузки, вес страниц, поведение под нагрузкой во время запуска рекламы. Если своего программиста нет и вы выбираете между наймом и подрядчиком, аргументы разобраны в статье «Свой разработчик или подрядчик», а сложные сайты и интеграции под задачу — это наша разработка.
ИИ-разработчик не отнимает у программиста работу. Он забирает у него вторник, который уходил на цену в трёх местах.
Где ИИ-разработчик ошибается и как это поймать до публикации
Честный список слабых мест полезнее перечня возможностей. Вот что встречается в работе такой роли и что с этим делать.
Текст влезает на компьютере и ломает телефон. Ограничения блоков спасают не всегда: длинное название тарифа может разъехаться на узком экране. Лечится тем, что карточка одобрения показывает черновик в двух ширинах, а не одной.
Верная правка по неверному источнику. Если в базе знаний устаревшая цена, ИИ-разработчик аккуратно разнесёт её по всем страницам. Роль не знает, что цена устарела, если этого не знает база. Лечится владельцем у каждого раздела базы и датой последней проверки.
Слишком буквальное выполнение. Просьба «уберите акцию» может задеть блок с условиями рассрочки, где тоже встречается слово «акция». Именно для этого нужно построчное сравнение: лишнее изменение видно до публикации, а не после звонка недовольного клиента.
Размножение вариантов. Варианты делать дёшево, поэтому их становится много, а завершённых тестов — ноль. Правило «один активный тест на страницу» решает проблему лучше любой технологии.
Одобрение на автомате. О нём выше. Если доля отклонённых карточек месяцами равна нулю, это не идеальная роль, а человек, который перестал читать.
Когда ИИ-разработчик сайта не нужен
Роль решает конкретную проблему: изменений на сайте много, они однотипные, и они ждут очереди. Если этой проблемы нет, роль её не создаст, а расходы добавит.
- Сайт меняется раз в квартал. Один лендинг в год дешевле заказать дизайнеру и верстальщику.
- Нет брендбука и повторяющихся блоков. Тогда собирать не из чего, и результат будет либо некрасивым, либо тем самым «дизайном от нейросети». Сначала дизайнер делает библиотеку.
- Маркетолог сам правит сайт в конструкторе за десять минут и не жалуется. Узкого места нет, лечить нечего.
- Сайт — это сложный продукт: личный кабинет, калькуляторы, каталог из учётной системы. Основная работа там — программирование, а содержимое страниц — малая часть.
- Трафика мало. A/B-тесты не дадут ответа, и из всех возможностей роли останутся только правки. Возможно, деньги лучше вложить в сам трафик.
- Проблема в оффере, а не в скорости выпуска страниц. Плохое предложение, опубликованное быстрее, продаёт так же плохо, только раньше.
- Некому одобрять. Все изменения идут через человека, и без ответственного работа остановится на первой карточке.
В этих случаях мы так и говорим на разборе: дешевле собрать библиотеку блоков, наладить базу знаний или поработать над оффером, а к ИИ-разработчику вернуться, когда появится очередь из правок.
Пилот на одной посадочной: цель, метрика, условие остановки
Проверять пользу роли на всём сайте сразу — плохая идея: слишком много всего меняется одновременно, и отличить эффект от шума невозможно. Пилот начинают с одной посадочной страницы или одного раздела и договариваются о цели по методу «Цель → метрика».
Метрики, которые стоит снять до запуска — хотя бы вручную, по задачам за последние два-три месяца:
- время от запроса до опубликованного изменения — главная метрика, ради неё всё и затевается;
- доля правок, возвращённых на доработку или откатанных — показывает качество черновиков;
- число расхождений сайта с базой знаний — цены, сроки, условия;
- конверсия посадочной в заявку и в оплату — с оговоркой, что на неё влияет сезон и реклама, поэтому сравнивать осторожно.
Условия остановки записываются до старта. Если одобрение карточек в среднем занимает больше, чем раньше занимало ожидание программиста, пользы нет. Если больше половины черновиков возвращается на доработку, значит, библиотека или база знаний не готовы, и сначала нужно чинить их. Если конверсия страницы после изменений устойчиво падает, изменения откатываются, а гипотезы пересматриваются.
Эту роль мы внедряем как часть Везории — агента компании, у которого веб-разработчик работает рядом с маркетологом и SMM и берёт факты из той же базы знаний. Запуск — от недели, стоимость складывается из внедрения, использования языковых моделей и сервера и считается на разборе под ваш сайт. Как роль разработчика стыкуется с маркетингом, разобрано в статьях про AI-маркетолога и про AI SMM-специалиста.
Журнал задач по сайту за квартал скажет больше любой демонстрации
Перед разговором с любым подрядчиком — нами или другими — сделайте одну вещь. Выгрузите задачи по сайту за последние три месяца из трекера, чата или почты. Напротив каждой запишите тип: новая страница, правка содержимого, вариант для теста, интеграция или техническая задача. И ещё две цифры: сколько задача ждала и сколько заняла работы.
Если большинство задач — правки содержимого, которые ждали дни, а делались минуты, ИИ-разработчик сайта закроет именно эту очередь. Если большинство — интеграции и технические задачи, вам нужен программист, а не ИИ, и это тоже полезный вывод. Если задач за квартал набралось пять, и все сделаны за день, — поздравляю, сайт в порядке.
А если окажется, что цена на сайте расходится с ценой в прайсе, помните: всё это время сайт честно продавал то, чего у вас уже нет.
