Можно ли добавить блог на сайт, собранный нейросетью

Да, двумя разными способами. Статьи можно собрать как обычные страницы многостраничной платформы: по 3 кредита за страницу сверх первых трёх. Либо хранить их в базе через коннектор Supabase, и тогда новые тексты добавляются без новой сборки. Выбор зависит от одного числа: сколько статей вы реально напишете.

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

Что значит «добавить блог» на практике?

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

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

Люди почти всегда просят первое, имея в виду второе. Поэтому полезно сразу ответить себе на один вопрос: кто и как часто будет добавлять текст. Если ответ «я, раз в неделю», статичные страницы вам не подойдут, сколько бы их ни было в начале.

Способ первый: статьи как страницы

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

Цена считается по общей формуле: платформа стоит 12 кредитов за первые три страницы и по 3 кредита за каждую следующую. То есть сайт с главной, страницей о компании, контактами и пятью статьями это восемь страниц, а значит 12 плюс пять дополнительных, итого 27.

Плюс подхода: он работает сразу и не требует базы. Минус виден на длинной дистанции: каждая новая публикация стоит 3 кредита и проходит через сборку. Для десятка материалов это нормально, для еженедельной рубрики уже нет.

Способ второй: статьи в базе

Здесь блог перестаёт быть набором страниц и становится маленьким приложением. Через коннектор Supabase у проекта появляется таблица со статьями, страница списка и страница одной статьи, которая подставляет содержимое из базы.

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

В промпте это стоит назвать прямо. «Раздел статей: список с заголовком, датой и кратким описанием, страница статьи с полным текстом, статьи хранятся в базе, добавлять их может только администратор». Последняя часть про доступ важна не меньше остальных: без неё редактировать материалы сможет любой залогинившийся. Как устроен коннектор, разобрано в статье AI-приложение с Supabase.

Честная плата за этот путь: появляется второй сервис, за которым надо следить, и вам придётся работать с записями в дашборде базы. Среди коннекторов Zugo нет отдельной системы управления содержимым, поэтому редактор статей это либо дашборд Supabase, либо экран администратора, который вы просите собрать отдельно.

Как выбрать между двумя способами?

По одному признаку: как часто вы будете публиковать.

Реже раза в месяц и всего несколько материалов: берите страницы. Механика проще, ничего не надо подключать, а разница в цене за год останется незаметной.

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

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

Есть и третий вариант, о котором стоит знать. Код проекта экспортируется в ваш репозиторий на GitHub, а деплой можно вести через коннектор Vercel в свой аккаунт. Дальше блог можно вести любыми привычными инструментами, потому что проект перестаёт зависеть от билдера.

Как перенести статьи со страниц в базу?

Одной сборкой механики и ручным переносом текстов. Автоматического превращения страниц в записи базы не существует, и планировать переезд стоит именно как ручную работу, а не как кнопку.

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

Главное, что стоит сделать до переезда, это сохранить адреса. Если статьи уже кто-то читал и на них ведут ссылки, новые адреса не должны отличаться от старых. Скажите об этом прямо в описании и проверьте пару ссылок после сборки: восстанавливать потерянные адреса дороже, чем сохранить их сразу.

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

Что важно описать в промпте про блог?

Четыре вещи, которые генерация не угадает.

Первое: как выглядит список. Только заголовки, или заголовок с картинкой и первым абзацем. Это решает, как раздел ощущается, и потом меняется правкой.

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

Третье: что делать с длинным текстом. Нужны ли подзаголовки, оглавление, картинки внутри статьи. Если нужны, попросите сразу: добавить структуру потом дороже, чем заложить её изначально.

Четвёртое: связь с остальным сайтом. Пункт меню, ссылка с главной, блок «читайте также» в конце статьи. Раздел, на который ниоткуда нет ссылок, просто не будет открываться людьми.

Общая логика многостраничного проекта, из которой вырастает и раздел со статьями, разобрана в статье можно ли собрать многостраничный сайт.

Где честные границы?

Четыре, и лучше знать их заранее.

• Тексты придётся писать вам. Генерация соберёт раздел и напишет черновик, но статьи, ради которых люди возвращаются, приходят из вашего опыта. Сгенерированное содержимое это заготовка, а не готовый материал.
• Отдельной системы управления статьями в коннекторах нет. Редактирование идёт через дашборд Supabase или через экран администратора, который вы просите собрать. Для одного автора это нормально, для редакции из пяти человек уже мало.
• Сложные функции доводятся правками. Поиск, теги, черновики, авторы, расписание публикаций: каждая появляется отдельным уточнением, а не из одного описания.
• Zugo не заменяет команду на сложном продукте. Если блог это медиа, а не раздел сайта, первая версия соберётся быстро, а дальше её ведут люди.

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

С чего начать?

Напишите три статьи в текстовом файле, прежде чем что-либо собирать. Если написать три оказалось тяжело, вопрос про способ хранения отпадает сам: вам хватит страниц.

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

Проверить оба пути можно за один вечер на zugo.dev: соберите список из трёх материалов и посмотрите, что удобнее лично вам.