Сайты под управлением ИИ: что это на самом деле и сколько стоит. Часть 1 из 3

Это первая из трёх статей про сайты под управлением ИИ. В этой части — концепции и экономика без маркетинговой пыли: что такое нейросайт на самом деле, чем он принципиально не является, и почему дешёвый VDS за пару тысяч рублей тут вообще ни при чём с точки зрения железа под нейросеть. Во второй части будет внутрянка (MCP‑брокер, пайплайн деплоя, безопасность), в третьей — прод‑механика на тысячах страниц (SSG/ISR, индексация, массовые операции). Здесь сознательно держусь на уровне архитектурных решений, не уходя в реализацию — она дальше.

Сразу оговорюсь про терминологию, потому что вокруг неё половина споров. Я буду называть это нейросайтом — короче, чем «сайт под управлением ИИ». И первое, что нужно сделать, — отделить это понятие от трёх соседних, с которыми его постоянно смешивают.

Чем нейросайт НЕ является: три ложных тождества

Прежде чем объяснять, что это, проще отрезать три вещи, которыми оно не является. Если убрать эти три недопонимания, дальше всё складывается само.

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

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

И это не fine‑tuning. Вот тут для инженерной аудитории самый частый ложный вывод. Когда в маркетинговом тексте пишут «сайт знает ваш тон голоса и непрерывно дообучается», технический человек слышит «дообучение весов» и справедливо кривится: непрерывный fine‑tuning под один сайт — это дорого, медленно и бессмысленно. Так вот, никакого дообучения весов нет. Об этом — отдельный раздел ниже, потому что это ключевая развязка.

Теперь, что это есть. Нейросайт — это обычный, полностью автономный сайт на вашем сервере, к управлению которым подключён внешний LLM‑агент. Ключевое слово — автономный: сайт работает, даже если к нему вообще не подключать никакую модель. Лежит, отдаёт страницы, принимает заявки, живёт сам по себе. Модель подключается не для того, чтобы сайт крутился, а для того, чтобы вносить в него изменения. Для посетителя это статика. Для владельца — система, которую можно менять запросом на естественном языке вместо цепочки согласований.

Изменения при этом разноуровневые, и полезно сразу разложить их по слоям — это снимает много вопросов:

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

Три модели на одной оси: конструктор, студия, нейросайт

Давайте сравним честно, по делу. Раньше выбор сайта был выбором двух свойств из трёх — как в старой инженерной шутке про «быстро, дёшево, качественно».

Конструктор: собрали за вечер, дёшево, но гибкость кончается там, где кончился шаблон. Студия: сделают что угодно, но вы платите сроками и деньгами. Нейросайт берёт скорость конструктора и соединяет её с гибкостью кастомной разработки.

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

Сначала смыслы, потом форма — и почему это инженерный, а не лозунговый принцип

Знакомая ситуация: трафик идёт, а заявок нет. Первое, что хочется, — винить рекламу или цвет кнопки. Иногда так и есть. Но в сложных нишах — B2B, производство, где в сделке участвуют десятки человек, а от заявки до контракта проходит месяц, а то и годы, — цвет кнопки решает примерно ничего. Решает одно: донесена ли ценность продукта так, чтобы её было удобно воспринять.

И вот где это становится технической проблемой, а не философией. Посмотрите, как устроен шаблонный сайт. Это типовые блоки. Три колонки с преимуществами. А у вашей компании преимуществ может быть два, а может быть пять — в зависимости от продукта, аудитории, конкретного отраслевого решения. Но шаблону это неинтересно. Есть три колонки — будьте добры заполнить три. И вы начинаете подстраивать смыслы под форму, которая уже задана.

Не сайт под ваш продукт, а ваш продукт под сайт.

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

Правильный порядок обратный: сначала модель данных (какие смыслы, в каком количестве, для какого типа клиента), потом форма, которая из этой модели выводится. На нейросайте это перестаёт быть дорогим, потому что блок — это не намертво свёрстанный HTML, а компонент, который агент генерирует под фактическое число и тип смыслов. Нужно три развёрнутых блока для глубоко вовлечённого читателя — делаем три. Нужно семь воздушных, по которым проскользить взглядом, — делаем семь. Форма подстраивается под смысл, а не наоборот.

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

Развенчиваем главный миф: «разместить нейросеть на сервере»

Теперь самый важный для Хабра раздел. В исходных материалах про экономику есть формулировка вроде «разместить свою нейросеть прямо на сервере, чтобы сайт работал быстрее и расходовал меньше токенов». Любой инженер тут обязан остановиться и сказать: ребят, серьёзно? VDS за 2–3 тысячи рублей в месяц физически не потянет self‑hosted LLM. Инференс приличной модели — это GPU за десятки тысяч в месяц, а не CPU‑шка за пару тысяч. Формулировка неверна, и разберём, в чём именно, потому что за ней прячется правильная архитектура.

Разведём, что где исполняется.

┌─────────────────── дешёвый VDS (2–3 тыс. ₽/мес) ───────────────────┐│  Next.js (фронт, SSG/ISR)                                          ││  headless WordPress + MariaDB  (контент, ACF)                      ││  тонкий MCP-брокер  (Node, один файл ~11 КБ)  ── даёт модели "руки" │└────────────────────────────────┬───────────────────────────────────┘                                 │ внешний вызов по API                                 ▼        ┌──────────── провайдер LLM (Anthropic / OpenAI) ───────────┐        │   сама модель, исполняется на ИХ GPU                       │        │   $50–100/мес — это плата за токены, не аренда железа      │        └────────────────────────────────────────────────────────────┘

На сервере крутится сайт и тонкий брокер. Интеллект — снаружи, в виде внешнего API класса Claude, GPT, Gemini (или любой другой модели на ваш вкус), и исполняется он на GPU провайдера. «Разместить нейросеть на сервере» корректно читается как «разместить агента‑посредника, который даёт модели доступ к серверу». Посредник этот лёгкий — по сути брокер, транслирующий команды модели в действия на машине (детали транспорта, авторизации и набор инструментов разберу во второй части, чтобы не растягивать). GPU‑инстанс под self‑hosting стоил бы десятки тысяч и здесь не нужен — и, что важнее, не дал бы ничего лучше топового внешнего API.

Отсюда честная экономика владения:

• VDS: ~2–3 тыс. ₽/мес. Хватает, чтобы не знать бед с ресурсом под сайт и брокер. Сервер полностью ваш — сами решаете, что и как на нём размещать. Экономить на нём в ноль не надо и не получится, но и разоряться не на чем.

• Токены модели: ~$50–100/мес при активной работе. Это не аренда железа. Это расход на вызовы API, когда вы реально что‑то меняете.

• Связь из РФ: прокси/VPN, чтобы стабильно ходить во внешний API. Копеечная, но в смете честно присутствует.

И вот ключевой момент, который снимает второе недопонимание из той же фразы — про «быстрее и меньше токенов».

Ноль инференса в рантайме: посетитель не тратит токены

Фраза «нейросеть на сервере, чтобы сайт работал быстрее и расходовал меньше токенов» неверна вдвойне. Первое мы разобрали — нейросеть не на сервере. Второе: скорость отдачи страниц и расход токенов не связаны вообще, потому что посетитель токенов не тратит. Ни одного.

Для посетителя инференса нет. Сайт — это пререндеренный статический HTML (SSG/ISR) плюс гидратация React. В момент запроса страницы — ноль вызовов модели. Никакого чата на лету, никакого семантического поиска через LLM, никакой генерации в рантайме. Модель работает только на этапе изменений сайта, то есть когда вы что‑то правите, а не когда к вам пришёл клиент.

Из этого следует довольно контринтуитивная для бизнеса вещь, которую инженеру как раз очевидна: расходы на токены не привязаны к посещаемости. Хоть десять визитов, хоть миллион — рантайм‑токенов ноль. $50–100/мес — это про объём вашей разработки и правок, а не про трафик. Сайт быстрый не потому, что рядом «стоит нейросеть», а потому что это статика, отданная с диска. LLM‑фичи в рантайме (живой ассистент на странице, генерация под запрос) — это отдельная возможная фича на будущее, и вот она бы токены в рантайме тратила. В базовой модели нейросайта её нет.

Это, кстати, и хорошая проверка на честность подрядчика. Если вам продают «нейросеть на вашем сервере, ускоряющую отдачу страниц» — вас, мягко говоря, путают. Отдачу страниц ускоряет пререндер и кэш, а не близость модели.

«Дообучается» — это RAG и канон в репозитории, а не fine‑tuning

Вернёмся к тому, что отложили. «Сайт знает ваш тон голоса и непрерывно дообучается» — что это в инженерных терминах. Не дообучение весов. Архитектура памяти такая:

1. Системный промпт + проектная база знаний — несколько.md‑файлов на сервере под git: техдокументация, бэклог, карта секций, дизайн‑система. Модель читает их в начале работы (грубо говоря, cat docs/*.md перед задачей).

2. Бренд‑канон — тон голоса, речевой профиль, факты о компании, ключевые формулировки ценности — в отдельном кросс‑проектном репозитории, который подмешивается в контекст.

3. Живой источник истины — сама кодовая база и база данных. Они читаются на лету (через GraphQL, wp‑cli, файлы) — retrieval по требованию, а не зашитое в веса знание.

То есть «память» здесь — это (а) канон в контексте перед задачей и (б) актуальное состояние кода и БД, подтягиваемое запросами. «Непрерывно дообучается» корректно читается как «база знаний непрерывно обновляется» — причём документацию правит та же модель и коммитит в git, поэтому канон не отстаёт от кода.

Векторная БД для этого, на текущем масштабе, не нужна: канон небольшой и целиком влезает в контекст, а точечный retrieval делается прямыми запросами к источнику. Для инженера резюме: это RAG плюс дисциплина документации, а не fine‑tuning. Никаких GPU под обучение, никакого дрейфа весов, никакого переобучения при каждой правке текста. Меняется не модель — меняется контекст, который ей подают.

Почему это лучше, чем fine‑tuning под задачу? Потому что канон версионируется в git, диффится, ревьюится и откатывается как обычный код. Поменяли формулировку ценности — это коммит, а не прогон обучения. Воспроизводимо и аудируемо.

Кому это подходит, а кому честно нет

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

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

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

В частном порядке — каталоги. Витрина до ~1000 SKU — спокойно, со всеми интеграциями, в том числе с 1С. А вот умные товарные сайты на сотни тысяч и десятки миллионов позиций, маркетплейсы — это уже не «переход», а точечный перевод отдельных функций под управление модели. Слишком специфические случаи, чтобы обобщать.

В частном порядке — сложный функционал. Авторизация, личные кабинеты, документооборот, много интеграций между сервисами. Типовое решение: готовая часть за авторизацией остаётся как есть, а витринная часть передаётся под управление ИИ. Граница режется по линии «публичная статика против приложения с состоянием».

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

Итого: в частном порядке — крупные товарные каталоги, тяжёлый функционал с авторизацией, совсем простые одностраничники. Для остального сложного B2B и продуктовых компаний это уже не nice‑to‑have.

Перенести рабочий сайт или собрать с нуля

Частый первый вопрос: у меня уже есть сайт — переносить под управление ИИ или проще с нуля? Ответ зависит от того, что на сайте есть ценного.

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

Если терять нечего — ни контента, ни структуры, ни небрендового трафика, а иногда и бренда ещё нет, потому что это никому не известный стартап, — честнее собирать заново.

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

Что переиспользуется между инсталляциями — это шаблон стека, а не клонированный образ. Каркас фронта (Next.js + типовой набор контентных блоков), набор серверных мостов, конфигурация CI, файл с каноном для модели. Новый проект стартует клонированием этого скелета. А вот серверная обвязка — провижининг VDS, веб‑сервер, PHP‑FPM, SSL, DNS — пока ставится руками по чек‑листу. Поэтому «самый быстрый перенос за полтора дня» — это не магия и не воспроизводимый из коробки рекорд: это клон скелета плюс ручная серверная обвязка, при уже готовой карте смыслов и развёрнутой инфраструктуре. Честная цифра, но с честными звёздочками. Превращение серверной части в воспроизводимый образ (cloud‑init / Ansible) — следующий шаг, и тогда полтора дня станут повторяемой величиной, а не удачным стечением.

Два инженерных нюанса переноса, которые стоит держать в голове уже на этом уровне:

• Код и контент разделены by design — в этом весь смысл headless. Код (компоненты, стили, логика) живёт в git; контент и его поля — в MariaDB. Эксперименты с визуалом откатываются через git, не задевая опубликованный контент, потому что контент лежит в БД. Но если эксперимент меняет схему данных (новые или переименованные поля) — перед ним нужен снапшот БД, потому что откат кода схему базы не вернёт. Это разные оси версионирования, и путать их нельзя.

• Карта редиректов при смене CMS — отдельная задача, от которой зависит сохранность того самого небрендового трафика. Основа — переезд с сохранением путей: где можно, новые адреса задаются равными старым, и большинство URL мапятся один‑к-одному, а не тремя тысячами ручных правил. Механику 301 и мониторинг битых ссылок подробно разберу в третьей части.

Что в сухом остатке

Если убрать маркетинговый глянец, нейросайт для инженера выглядит так. Обычный автономный сайт на вашем сервере (фронт + headless CMS + БД), для посетителя — статика без единого вызова модели. Рядом — тонкий агент‑посредник, дающий внешнему LLM возможность читать и менять кодовую базу и контент. Память агента — это RAG: канон и документация в git плюс живой источник истины в коде и БД, а не дообученные веса. Внешний API на чужих GPU, $50–100/мес за токены при активной разработке, ноль рантайм‑инференса и, как следствие, расходы, не зависящие от трафика. Дешевле классики выходит не за счёт урезания качества, а за счёт того, что из сметы уходят часы ручной возни с формой, а высвободившийся ресурс уходит на содержание.

И да, главное ограничение тоже инженерное по духу: система гениально соберёт и переберёт блоки, но что именно говорить на этих блоках и в чём ваша ценность — должен решить человек. Дешёвая итерация не отвечает на вопрос «что сказать», она лишь делает поиск ответа дешёвым. Сначала содержание, потом форма — иначе вы просто очень быстро соберёте сайт, который не отвечает на единственный вопрос посетителя: зачем ему на этом сайте оставаться (и совершать какие-либо конверсионные действия).

---

В следующей части — как это устроено внутри: тонкий MCP‑брокер и его «руки», цикл «запрос → правка на dev → стейджинг → git → CI → прод», почему модель не пишет в прод напрямую, и многослойная безопасность — от least‑privilege агента до защиты от prompt injection и детерминированных гейтов верификации (TypeScript, сборка, schema‑by‑construction)…