Как я устроил этот сайт: Markdown, Next.js и статический экспорт

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

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

Задача и требования

Сайт объединяет долгоживущие материалы о разработке, архитектуре и AI. Pro-leads и Tender Audit представлены как отдельные продукты со ссылками на их собственные сайты.

Основные требования:

тексты хранятся в Git вместе с историей изменений;
новый материал проходит проверку до публикации;
страницы можно обслуживать обычным веб-сервером;
чтение и основные переходы работают без JavaScript;
сайт не получает аккаунты, платежи или административную панель раньше, чем они нужны.

Как устроена система

Сайт использует Next.js App Router с output: "export". Во время сборки он читает Markdown и создаёт HTML, CSS и JavaScript в каталоге out/. Для обслуживания этих файлов не нужен постоянно работающий Node.js-процесс.

Markdown в Git
      ↓
проверка метаданных и обработка текста
      ↓
сборка Next.js → out/
      ↓
nginx → страницы для читателя

У поста есть метаданные: заголовок, дата, тип и краткое описание. Продуктовый материал дополнительно указывает продукт и текст перехода к нему. Загрузчик проверяет обязательные поля; некорректные метаданные останавливают сборку.

Маршруты статей формируются из имён Markdown-файлов. Та же коллекция материалов используется для блога, RSS и sitemap. Поэтому при добавлении статьи не нужно вручную поддерживать отдельный список адресов.

Почему сейчас достаточно статического сайта

Содержимое меняется при публикации материала, а не при каждом открытии страницы. Читателю не нужен личный кабинет, чтобы получить пользу от статьи.

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

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

Как появляется новый материал

Добавляю Markdown-файл в content/posts/ с заголовком, датой, типом и описанием.
Пишу текст и отдельно проверяю основания для фактов и выводов.
Запускаю lint и Playwright-проверки против статической сборки.
Проверяю страницу, переходы, мобильную верстку, RSS и sitemap.
После отдельного решения о выпуске изменение может пройти через настроенный CI.

В GitHub Actions предусмотрены lint, сборка и сквозные тесты. Публикация статического экспорта на VPS настроена для push в main; после неё workflow проверяет страницы сайта. Наличие этого workflow описывает механизм доставки, но само по себе не подтверждает успешный выпуск конкретного изменения.

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

Что остаётся за человеком

Автоматическая проверка метаданных не проверяет истинность текста. Корректная сборка не доказывает удобство чтения. Локальные тесты не подтверждают состояние сайта на сервере.

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

Когда архитектуру нужно пересмотреть

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

Пока основная задача — публиковать полезные тексты и показывать работу, Markdown и статический экспорт покрывают её. Сначала стоит доказать необходимость следующей функции, затем выбирать архитектуру для неё.